什么是 Probe Request？深入理解设备如何发现网络

什么是 Probe Request（探测请求）？了解设备如何发现网络。Purple 技术简报。 介绍与背景 欢迎阅读本次 Purple 技术简报。我将带您深入了解企业级 WiFi 中最基础、也最常被误解的机制之一：probe request（探测请求）。如果您负责客用 WiFi 部署、多站点零售网络或场所分析项目，理解探测请求并不是可选项。它是所有其他功能的基础 - 从人流量分析和停留时间评估，到 MAC 随机化挑战以及 GDPR 合规性。 那么，让我们开始吧。 每当设备 - 智能手机、笔记本电脑、平板电脑 - 未连接到网络时，它都会不断扫描网络。该扫描过程始于探测请求。它是 IEEE 802.11 协议中定义的一种管理帧，由客户端设备而非接入点发送。可以把它想象成设备在房间里大喊：“这里有我认识的人吗？”接入点进行监听，如果识别出请求，它就会做出响应。 这种情况每天会发生数百次，而设备所有者往往毫不知情。对于网络架构师和场所运营商来说，如果您知道如何正确捕获和解读这些探测请求，它们就是运营数据的金矿。 技术深度解析 让我们更深入地了解其工作机制。 探测请求是在 2.4 GHz 或 5 GHz 无线频段上发送的第 2 层管理帧。在 IEEE 802.11 标准下，它被分类为子类型 4 管理帧。该帧包含几个关键信息元素：SSID 字段、支持速率元素、扩展支持速率元素以及功能信息，包括 802.11ac 设备的 HT - 即高吞吐量 - 和 VHT 功能。 探测请求有两种类型。第一种是广播探测请求，有时也称为通配符探测。在这种情况下，SSID 字段为空 - 设备实际上是要求范围内的任何接入点标识自己。第二种是定向探测请求，其中 SSID 字段包含特定的网络名称。当设备正在主动寻找先前连接过并已存储在其首选网络列表中的网络时，就会发生这种情况。 接入点的响应 - 探测响应帧 - 镜像了信标帧的大部分内容。它包括 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 Attacks）成为可能。捕获到针对特定 SSID 的定向探测请求的攻击者，可以搭建一个使用该 SSID 的恶意接入点，并等待设备自动连接。WPA3 的增强开放（Enhanced Open）和对等实体同时认证（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（快速初始链路设置）的发现机制和带外发现，这改变了探测动态。如果您正在部署WiFi 6E，请查看您的硬件厂商关于6 GHz扫描行为的文档。 探测请求和关联请求有什么区别？探测请求是关联前的 - 设备正在发现网络。关联请求发生在身份验证之后，当设备正式请求加入特定网络时。它们是802.11连接状态机的不同阶段。 连接后，MAC随机化是否保持一致？在iOS上，是的 - 设备针对给定的SSID使用稳定的随机MAC。在Android上，情况有所不同。某些实现会在每次连接时重新进行随机化。这就是为什么基于会话的身份而不是基于MAC的身份才是正确架构的原因。 总结与后续步骤。 总结一下：探测请求是WiFi发现的心跳。您场馆中的每台设备都在不断产生这些请求。了解它们的结构、局限性以及安全性影响，对于设计可靠、具备分析功能且合规的访客WiFi部署至关重要。 关键要点如下。第一：在MAC随机化普及的时代，没有身份验证的基于探测的分析是不可靠的。第二：经过身份验证的访客WiFi是您的身份层 - 它是让您的分析准确且符合GDPR合规要求的关键。第三：在密集的场馆中，探测风暴管理是一个实际的运营问题，需要在基础设施设计阶段予以解决。第四：定向探测请求会暴露您设备的常用网络列表 - 这是一个真正的安全风险，可以通过WPA3和网络卫生规范来缓解。 如果您想深入了解，Purple的技术文档介绍了我们的硬件中立平台如何捕获和处理探测数据以及经过身份验证的会话数据，从而为您提供准确的场馆分析。您还可以阅读我们关于WiFi寻路和三边测量定位的指南，这些指南直接建立在今天我们所涵盖的探测请求基础知识之上。 感谢收听。以上就是Purple的技术简报。