什么是 Probe Request？了解设备如何发现网络

什么是 Probe Request？了解设备如何发现网络。Purple 技术简报。 介绍与背景。 欢迎阅读本次 Purple 技术简报。我将带您深入了解企业级 WiFi 中最基础、也是最常被误解的机制之一：probe request（探测请求）。如果您负责处理宾客 WiFi 部署、多站点零售网络或场所分析项目，了解 probe request 并非可选项。它是所有其他功能的基础 - 从客流量分析和停留时间测量，到 MAC 随机化挑战和 GDPR 合规性。 让我们开始吧。 每当设备（智能手机、笔记本电脑、平板电脑）未连接到网络时，它都会不断扫描网络。该扫描过程始于 probe request。这是一种在 IEEE 802.11 协议下定义的管理帧，由客户端设备而非接入点发送。可以把它想象成设备在房间里大喊：“这里有我认识的人吗？” 接入点进行监听，如果识别出该请求，就会做出响应。 这种情况每天会发生数百次，而设备所有者通常对此一无所知。对于网络架构师和场所运营商而言，如果知道如何正确捕获和解读这些 probe request，它们就是运营数据的金矿。 技术深度解析。 让我们深入了解其工作机制。 probe request 是在 2.4 GHz 或 5 GHz 无线频段上发送的第 2 层管理帧。在 IEEE 802.11 标准下，它被归类为子类型 4 管理帧。该帧包含几个关键信息元素：SSID 字段、支持的速率元素、扩展的支持速率元素，以及包括 HT（即高吞吐量）和 802.11ac 设备的 VHT 功能在内的功能信息。 probe request 有两种类型。第一种是广播 probe request，有时也称为通配符探测。在这种情况下，SSID 字段为空 - 设备实际上是在请求范围内的任何接入点标识身份。第二种是定向 probe request，其中 SSID 字段包含特定的网络名称。当设备主动寻找之前连接过并存储在其首选网络列表中的网络时，就会发生这种情况。 接入点的响应（即 probe response 帧）镜像了大部分信标帧内容。它包括 SSID、BSSID、信标间隔、时间戳和完整的功能集。正是通过这种交互，设备才能在用户打开 WiFi 设置之前，构建其可用网络列表。 现在，主动扫描和被动扫描之间存在一个重要的区别。主动扫描就是我刚刚描述的探测请求和响应循环。被动扫描则不同 - 设备只是简单地倾听接入点定期广播的信标帧，通常是每 100 毫秒一次。被动扫描较慢，但功耗较低。大多数现代设备会结合使用这两者，具体取决于其电量状态和所处的监管区域。 这就是在运营上具有重大意义的地方。在高密度场所 - 体育场、会议中心、大型零售卖场 - 可能会有数千台设备同时在多个信道上发送探测请求。这会产生所谓的探测风暴。每个探测请求都会消耗空口时间。在设计不良的网络中，这种管理帧开销会显著降低已连接客户端的吞吐量。这就是为什么企业级接入点将探测请求过滤和速率限制作为标准配置的原因。 现在让我们来谈谈 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 的人流量数据。 网络安全分析师还需要了解探测请求所涉及的安全维度。由于探测请求是未加密的管理帧，因此任何在监控模式下使用数据包捕获工具的人都可以看到它们。定向探测请求会泄露设备之前连接过的网络的 SSID - 即首选网络列表（PNL）。这是一种真实存在的隐私泄露。在您的场所中移动的设备正在广播它曾经加入过的每个网络的名称。这也是最初引入 MAC 随机化的原因之一。 从攻击面的角度来看，探测请求使邪恶双子（evil twin）攻击成为可能。捕获特定 SSID 的定向探测请求的攻击者可以架设一个具有该 SSID 的恶意接入点，并等待设备自动连接。WPA3 的增强型开放和对等实体同时身份验证（SAE）协议显著降低了这种风险，但前提是您的基础设施支持并强制执行它们。 实施建议和常见陷阱。 好吧，让我们来看看您在实际部署中究竟该如何处理这些问题。 首先，如果您要在高密度场所部署或升级访客 WiFi 网络，您的接入点布局和信道规划必须考虑探测请求开销。使用最小信道宽度策略 - 2.4 GHz 上为 20 MHz - 并实施最小 RSSI 阈值，以防止远距离设备进行关联。大多数企业级控制器允许您设置探测响应过滤，以便 AP 仅响应高于特定信号强度的设备。这可以显著减少管理帧噪声。 其次，如果您正在进行人流量或停留时间分析，请接受仅靠探测数据已不再足够的事实。您的分析策略需要围绕已验证的会话来构建。这意味着您的 Captive Portal 或入网流程需要足够流畅，以便访客真正进行连接。Purple 的数据显示，拥有精心设计的入网体验（社交登录、电子邮件获取或免密流程）的场所，其设备连接率可达到场所内设备的 60% 至 80%。这就是您的分析样本群。 第三，为了遵守英国和欧盟的 GDPR，收集探测请求数据（即使是匿名数据）也需要进行仔细的法律依据评估。如果您为了进行分析而捕获并存储探测帧，则需要记录您的合法利益依据并确保数据最小化。ICO 关于 WiFi 追踪的指南非常明确：如果您可以从数据中识别出个人，即使是间接识别，这也属于个人数据。在部署任何基于探测的分析系统之前，请先与您的 DPO 合作。 第四，在密集环境中要注意探针风暴。如果您在人流量大的场馆中看到无法解释的吞吐量下降，请拉取您的 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 扫描行为的文档。 探针请求和关联请求有什么区别？探针请求是关联前的 - 设备正在发现网络。关联请求发生在身份验证之后，当设备正式请求加入特定网络时。它们是 802.11 连接状态机的不同阶段。 连接后 MAC 随机化是否保持一致？在 iOS 上，是的 - 设备会对特定的 SSID 使用稳定的随机化 MAC。在 Android 上，情况有所不同。某些实现会在每次连接时重新随机化。这就是为什么基于会话的身份（而非基于 MAC 的身份）才是正确架构的原因。 总结与后续步骤。 总结一下：探针请求是 WiFi 发现的脉搏。您场馆中的每个设备都在不断生成它们。了解它们的结构、局限性以及安全性影响，对于设计可靠、具备分析能力且合规的访客 WiFi 部署至关重要。 核心要点如下。第一：在 MAC 随机化后的世界里，没有身份验证的基于探针的分析是不可靠的。第二：经过身份验证的访客 WiFi 是您的身份层 - 它是让您的分析准确且数据符合 GDPR 的关键。第三：探针风暴管理在高密度场馆中是一个实际的运营问题，需要在基础设施设计阶段予以解决。第四：定向探针请求会暴露您设备的首选网络列表 - 这是一个真正的安全风险，可以通过 WPA3 和网络卫生规范来缓解。 如果您想深入了解，Purple 的技术文档介绍了我们独立于硬件的平台如何捕获和处理探针数据以及经过身份验证的会话数据，从而为您提供准确的场馆分析。您还可以探索我们的 WiFi 寻路和三边测量指南，这些指南直接建立在我们今天介绍的探针请求基础之上。 感谢收听。以上是 Purple 技术简报。