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

什麼是探針請求（Probe Request）？瞭解裝置如何探索網路。Purple 技術簡報。 簡介與背景。 歡迎閱讀本次 Purple 技術簡報。我將帶您深入瞭解企業 WiFi 中最基礎 - 且最常被誤解 - 的機制之一：探針請求。如果您負責管理顧客 WiFi 部署、多站點零售網路或場域分析專案，瞭解探針請求絕非可有可無。它是所有後續應用的基石 - 從人流量分析與停留時間量測，到 MAC 隨機化挑戰與 GDPR 合規性，皆以此為基礎。 現在，讓我們切入正題。 每當裝置 - 例如智慧型手機、筆記型電腦、平板電腦 - 未連線至網路時，它會持續掃描可用網路。此掃描程序便是從探針請求開始。這是一種在 IEEE 802.11 規範下定義的管理訊框，由用戶端裝置發送，而非由存取點發送。您可以將其想像成裝置在房間裡大喊：「這裡有我認識的人嗎？」存取點會進行接聽，如果識別出該請求，就會做出回應。 這種情況每天會發生數百次，而裝置擁有者通常毫無察覺。對於網路架構師與場域營運商而言，如果您知道如何正確擷取與解讀，這些探針請求就是營運數據的寶庫。 技術深入探討。 讓我們更深入探討其運作機制。 探針請求是在 2.4 GHz 或 5 GHz 無線電頻段上傳輸的第 2 層（Layer 2）管理訊框。在 IEEE 802.11 標準下，它被歸類為子類型 4 的管理訊框。該訊框包含幾個關鍵資訊元素：SSID 欄位、支援速率元素、延伸支援速率元素，以及包含 HT（高吞吐量）與 802.11ac 裝置 VHT 功能在內的相容能力資訊。 探針請求有兩種類型。第一種是廣播探針請求，有時稱為萬用字元探針。此時 SSID 欄位為空 - 裝置基本上是在要求範圍內的任何存取點表明身分。第二種是定向探針請求，其中 SSID 欄位包含特定的網路名稱。這發生在裝置正在主動尋找先前連線過且已儲存在其偏好網路清單中的網路時。 存取點的回應 - 探針回應訊框（Probe Response Frame）- 鏡像了大部分指標訊框（Beacon Frame）的內容。它包含 SSID、BSSID、指標間隔、時間戳記以及完整的相容能力集。這種交換機制讓裝置在使用者打開 WiFi 設定之前，就能建立可用網路的清單。 現在，主動掃描與被動掃描之間有一個重要的區別。主動掃描就是我剛才描述的探測請求與回應循環。被動掃描則不同 - 裝置只是單純監聽存取點定期廣播的信標訊框（beacon frame），通常是每 100 毫秒一次。被動掃描速度較慢，但耗電量較少。大多數現代裝置會根據其電源狀態和所處的法規網域，結合使用這兩種掃描方式。 這在營運上具有重大意義。在高密度的場域中 - 例如體育場、會議中心或大型零售賣場 - 可能會有數千台裝置同時在多個頻道上發送探測請求。這會造成所謂的「探測風暴（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 平台正是這樣做的 - 它將分析與已驗證的階段作業綁定，而非硬體位址，不論裝置的 MAC 行為如何，都能為您提供準確且符合 GDPR 規範的人流數據。探針請求（probe requests）對網路安全分析師而言也存在安全維度需要理解。由於探針請求是未加密的管理訊框，任何人在監視模式下使用封包擷取工具都能看見。定向探針請求會揭露裝置先前曾連線過的 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 storms）。如果您在人流量大的場所看到無法解釋的吞吐量下降，請提取您的 AP 日誌並查看管理影格速率。探測風暴通常是罪魁禍首。解決方法是結合最小 RSSI 過濾、探測回應速率限制，並確保您的 5 GHz 頻段被正確播送，以便支援該頻段的裝置優先選擇它而非 2.4 GHz。 快速問答。 讓我快速解答一些經常出現的問題。 我可以在沒有 Captive Portal 的情況下，使用探測請求來計算人流量嗎？技術上可以，但在 iOS 14 之後，準確度很低。您會看到膨脹的獨特計數，且沒有回訪者數據。對於粗略數量級估算以外的任何需求，您都需要已驗證的連線階段。 探測請求在 6 GHz WiFi 6E 網絡上有效嗎？有效，但有所不同。6 GHz 頻段使用一種稱為 FILS（快速初始鏈路設定）的探索機制和帶外探索，這改變了探測動態。如果您正在部署 WiFi 6E，請查看您的硬體廠商關於 6 GHz 掃描行為的說明文件。 探測請求（probe request）和關聯請求（association request）有何不同？探測請求是關聯前的狀態，此時裝置正在探索網絡。關聯請求則是在驗證之後，當裝置正式請求加入特定的網絡時發出。它們是 802.11 連線狀態機的不同階段。 連線後 MAC 隨機化會保持一致嗎？在 iOS 上是的，裝置針對特定的 SSID 會使用穩定的隨機化 MAC。在 Android 上則各有不同，某些實作會在每次連線時重新隨機化。這就是為什麼以連線階段為基礎的識別，而非以 MAC 為基礎的識別，才是正確的架構。 總結與後續步驟。 總結來說：探測請求是 WiFi 探索的脈搏。您場所中的每部裝置都在不斷產生這些請求。了解其結構、限制以及安全性影響，對於設計可靠、具備分析能力且符合規範的訪客 WiFi 部署至關重要。 關鍵結論如下。第一：在 MAC 隨機化的世界中，沒有驗證的探測型分析是不可靠的。第二：已驗證的訪客 WiFi 是您的識別層，這正是讓您的分析準確且數據符合 GDPR 規範的關鍵。第三：探測風暴管理在高密度場所是一個實際的營運問題，需要在基礎架構設計階段予以解決。第四：定向探測請求會暴露您裝置的偏好網絡清單，這是一個真正的安全風險，可以透過 WPA3 和網絡維護實踐來減輕。 如果您想深入了解，Purple 的技術文件介紹了我們的硬體中立平台如何擷取和處理探測數據，並結合已驗證的連線階段數據，為您提供準確的場所分析。您也可以探索我們關於 WiFi 定位導航和三邊測量的指南，這些指南直接建立在我們今天涵蓋的探測請求基礎之上。 感謝您的聆聽。這是一場 Purple 技術簡報。