什麼是 Probe Request？深入了解裝置如何探索網路

什麼是探針請求？深入了解裝置如何探索網路。Purple 技術簡報。 簡介與背景。 歡迎觀看本次 Purple 技術簡報。我將帶您深入了解企業級 WiFi 中最基本 - 也是最常被誤解的機制之一：探針請求（Probe Request）。如果您負責管理訪客 WiFi 部署、多站點零售網路或場域分析專案，了解探針請求並非可有可無。它是所有後續應用的基礎 - 從客流量分析與停留時間量測，到 MAC 隨機化挑戰與 GDPR 合規性，皆基於此。 讓我們開始吧。 每當智慧型手機、筆記型電腦、平板電腦等裝置未連線到網路時，它就會不斷掃描網路。這個掃描過程始於一個探針請求。它是一個在 IEEE 802.11 規範下定義的管理框架，由用戶端裝置（而非存取點）傳送。您可以將其想像成裝置在房間裡大喊：「這裡有我認識的人嗎？」存取點會進行監聽，如果辨識出該請求，就會做出回應。 這種情況每天會發生數百次，而裝置擁有者通常毫無察覺。對於網路架構師和場域營運商而言，如果您知道如何正確擷取和解讀，這些探針請求就是營運數據的寶庫。 技術深度剖析。 讓我們深入探討其運作機制。 探針請求是在 2.4 GHz 或 5 GHz 無線電頻段上傳送的 Layer 2 管理框架。在 IEEE 802.11 標準下，它被歸類為子類型 4 的管理框架。該框架包含多個關鍵資訊元素：SSID 欄位、支援速率元素、延伸支援速率元素，以及包含 HT（高吞吐量）和 802.11ac 裝置的 VHT 功能在內的能力資訊。 探針請求分為兩種。第一種是廣播探針請求，有時稱為萬用字元探針。此時 SSID 欄位為空 - 裝置基本上是在要求範圍內的任何存取點表明身分。第二種是定向探針請求，其中 SSID 欄位包含特定的網路名稱。當裝置主動尋找先前曾連線過、且已儲存在其偏好網路清單中的網路時，就會發生這種情況。 存取點的回應 - 探針回應框架 - 鏡像了大部分指標框架（Beacon Frame）的內容。它包含 SSID、BSSID、指標間隔、時間戳記和完整的能力集。在使用者開啟其 WiFi 設定之前，正是透過這種交換，裝置才能建立其可用網路的清單。 現在，主動掃描（active scanning）與被動掃描（passive scanning）之間存在著一個重要的區別。主動掃描是我剛才描述的探測請求（probe request）與回應週期。被動掃描則不同 - 設備只是單純監聽存取點（access point）定期（通常是每 100 毫秒）廣播的信標影格（beacon frame）。被動掃描速度較慢，但功耗較低。大多數現代設備會根據其電源狀態和運作所在的監管網域，結合使用這兩種掃描方式。 這在運作層面上具有重大意義。在高密度場所 - 如體育場、會議中心、大型零售賣場 - 您可能會有數千台設備同時在多個頻道上發送探測請求。這會造成所謂的「探測風暴（probe storm）」情況。每個探測請求都會消耗空中傳輸時間。在設計不良的網路中，這種管理影格開銷會顯著降低已連接用戶端的吞吐量。這就是為什麼企業級存取點會將探測請求過濾和速率限制列為標準功能的原因。 現在我們來談談 MAC 位址，以及為什麼這對分析至關重要。 在過去，每個探測請求都攜帶著設備的真實硬體 MAC 位址 - 這是燒錄在網路介面卡中的全域唯一 48 位元識別碼。這使得基於探測的分析極其可靠。您可以追蹤整個場所內的設備、測量停留時間、識別重複訪客，並以高度可信度建立人流熱圖。 這種情況在 2020 年的 iOS 14 以及更早的 Android 10 出現後發生了重大變化。Apple 和 Google 針對探測請求引入了 MAC 位址隨機化。設備現在會生成隨機的 MAC 位址進行掃描，而不是廣播真實的硬體 MAC。在 iOS 上，這種隨機化是針對每個 SSID 的 - 這意味著設備在連接到特定網路時會使用一致的隨機 MAC，但在進行探測時則使用不同的隨機 MAC。在 Android 上，其實作方式則因製造商而異。 這對場所營運商的實際影響非常顯著。對於未連接的設備，依賴持續性 MAC 位址的探測型人流分析現在已不再可靠。唯一設備數量會被誇大。僅憑探測數據來識別重複訪客已不再可行。 解決方案 - 這也是驗證過的人客 WiFi 變得至關重要的原因 - 是將您的識別層從 MAC 位址轉移到經過驗證的使用者。當訪客透過 Captive Portal 或社群登入進行連接時，您便能擷取不受 MAC 隨機化影響、且經同意的持續性身分識別。Purple 的人客 WiFi 平台正是如此運作 - 它將分析與驗證過的會話（session）綁定，而非硬體位址，無論設備的 MAC 行為如何，都能為您提供準確且符合 GDPR 規範的人流數據。 對於網路安全分析師而言，探測請求（probe request）還存在著需要了解的安全層面。由於探測請求是未加密的管理框架，因此任何使用監聽模式下封包擷取工具的人都可以看見它們。定向探測請求會洩漏裝置先前連接過的 SSID - 即所謂的偏好網路清單（PNL）。這是一個真實存在隱私洩露風險的問題。一個穿梭於您場域中的裝置正在廣播它曾加入過的每個網路名稱。這也是當初引入 MAC 隨機化技術的原因之一。 從攻擊面的角度來看，探測請求使邪惡雙生（evil twin）攻擊成為可能。捕獲到特定 SSID 定向探測請求的攻擊者，可以架設一個使用該 SSID 的惡機存取點，並等待裝置自動連接。WPA3 的加強版開放式網路（Enhanced Open）和對等實體同時驗證 - SAE - 協定能顯著降低此風險，但前提是您的基礎設施必須支援並強制執行這些協定。 實作建議與常見陷阱。 好的，讓我們轉到您在實際佈署中該如何處理這些問題。 首先，如果您要在高密度場域中佈署或更新訪客 WiFi 網路，您的存取點配置與頻道規劃必須將探測請求的負載納入考量。請使用最小頻道寬度策略 - 在 2.4 GHz 上使用 20 MHz - 並實作最小 RSSI 閾值以阻止遠距離裝置進行關聯。大多數企業級控制器都允許您設定探測回應篩選，使 AP 僅回應訊號強度在特定值以上的裝置。這能顯著減少管理框架的雜訊。 其次，如果您正在執行人流量或停留時間分析，請接受僅靠探測的數據已不再足夠。您的分析策略必須圍繞著已驗證的連線階段來建構。這意味著您的 Captive Portal 或登入流程必須足夠流暢，才能讓訪客真正進行連線。Purple 的數據顯示，擁有設計良好的登入體驗（例如社群媒體登入、電子郵件收集或免密碼流程）的場域，其裝置連線率可達到場域內裝置的 60% 至 80%。這才是您的分析樣本母體。 第三，為了符合英國與歐盟的 GDPR 規範，收集探測請求數據（即使已去識別化）也需要經過仔細的法律依據評估。如果您為了進行分析而擷取並儲存探測框架，您需要記錄您的合法利益依據，並確保數據最小化。ICO 關於 WiFi 追蹤的指引非常明確：如果您能從數據中識別出個人（即使是間接識別），該數據即屬個人資料。在佈署任何基於探測的分析系統之前，請先與您的資料保護官（DPO）合作。第四，在密集環境中要注意探測風暴（probe storm）。如果您在人流量大的場所發現不明原因的吞吐量下降，請擷取您的 AP 日誌並查看管理框架速率。探測風暴通常是罪魁禍首。解決方法是結合最小 RSSI 過濾、探測回應速率限制，並確保正確廣告您的 5 GHz 頻段，以便支援的裝置優先選擇它而非 2.4 GHz。 快速問答。 讓我快速解答幾個經常出現的問題。 我可以在沒有 Captive Portal 的情況下使用探測請求來計算人流量嗎？技術上可以，但在 iOS 14 之後，準確度很低。您會看到膨脹的唯一計數，且沒有重複訪客數據。若要獲得粗略數量級估算之外的任何數據，您需要經過身分驗證的會話。 探測請求在 6 GHz WiFi 6E 網路中有效嗎？是的，但有所不同。6 GHz 頻段使用一種稱為 FILS - 快速初始連結設定（Fast Initial Link Setup）的身分驗證機制和頻外探索，這改變了探測動態。如果您正在部署 WiFi 6E，請查閱您的廠商關於 6 GHz 掃描行為的說明文件。 探測請求和關聯請求（association request）有何不同？探測請求是關聯前的階段 - 裝置正在探索網路。關聯請求則是在身分驗證之後，裝置正式請求加入特定網路時發送。它們是 802.11 連線狀態機的不同階段。 連線後 MAC 隨機化是否一致？在 iOS 上，是的 - 裝置針對特定的 SSID 會使用穩定的隨機化 MAC。在 Android 上，情況各有不同。某些實作會在每次連線時重新隨機化。這就是為什麼基於會話的身分識別，而非基於 MAC 的身分識別，才是正確的架構。 總結與後續步驟。 總結來說：探測請求是 WiFi 探索的脈搏。您場所中的每台裝置都在不斷產生這些請求。了解它們的結構、限制以及安全性影響，對於設計可靠、具備分析能力且符合規範的訪客 WiFi 部署至關重要。 關鍵結論如下。第一：在 MAC 隨機化普及的世界中，沒有身分驗證的探測型分析是不可靠的。第二：經過身分驗證的訪客 WiFi 是您的身分識別層 - 它是讓您的分析精確且資料符合 GDPR 規範的關鍵。第三：在密集的場所中，探測風暴管理是一個實際的營運問題，需要在基礎架構設計階段予以解決。第四：定向探測請求會暴露您裝置的偏好網路清單 - 這是一個真正的安全風險，可以透過 WPA3 和網路衛生實踐來降低風險。 如果您想深入瞭解，Purple 的技術說明文件介紹了我們與硬體無關的平台如何擷取和處理探測資料以及經過身分驗證的會話資料，從而為您提供準確的場所分析。您也可以參考我們關於 WiFi 尋路和三邊測量的指南，這些指南直接建立在我們今天介紹的探測請求基礎之上。 感謝您的收聽。以上是 Purple 技術簡報。