公共 WiFi 故障排查：解决“已连接但无互联网连接”以及欢迎页面重定向失败问题

欢迎阅读来自 Purple 的技术简报。今天，我们将解决企业无线网络中最顽固、最容易被误解的问题之一：根本无法加载的访客 WiFi Captive Portal。 您一定遇到过这种情况。访客到达您的酒店、零售店、体育场或会议中心。他们加入了 WiFi 网络。但什么也没发生。没有登录页面。没有网络连接。只有不断旋转的加载图标和日益增加的挫败感。对于场馆运营总监和 IT 经理来说，那一刻不仅仅是小小的出行不便。它代表了访客体验的直接失败、前台支持电话的激增，以及错失了捕获第一方数据的机会，而这些数据正是您进行无线基础设施投资的价值所在。 在本次简报中，我们将深入了解其底层机制。我们将解释操作系统层面 Captive Portal 检测的具体工作原理，找出导致绝大多数连接失败的六个根本原因，并为您提供一个实用、可操作的排错框架，您现在就可以将其移交给您的 IT 团队。 让我们从其机制开始。大多数人认为 Captive Portal 仅仅是一个登录页面。它实际上是一个网络级的流量拦截机制，当出现问题时，这种区别至关重要。 以下是其运行顺序。访客的设备加入您的访客 SSID，并通过 DHCP 接收 IP 地址。此时，操作系统不会等待用户打开浏览器。在后台，系统服务会立即向供应商控制的探测 URL 发起一个未加密的 HTTP GET 请求。iOS 等 Apple 设备会查询 captive.apple.com。Android 设备会查询 connectivitycheck.gstatic.com。Windows 设备会查询 msftconnecttest.com。Firefox 在 detectportal.firefox.com 上有自己的探测点。 如果网络具有开放的互联网访问权限，这些探测将返回其预期响应，操作系统从而认定一切正常。但在访客网络上，您的无线网关或控制器会在该 HTTP 探测到达互联网之前拦截它。网关不会返回预期的响应，而是返回一个指向您的 Captive Portal 欢迎页面的 HTTP 307 重定向。操作系统检测到这个非预期的重定向，意识到其处于 Captive Portal 之后，并打开一个沙盒浏览器窗口（通常称为 Captive Network Assistant）来显示登录页面。 这就是正常情况下的运行流程。现在，让我们来看看导致其失效的六种常见原因。 根本原因之一：DHCP 池耗尽。这是高密度活动中的无形杀手。如果您在标准的 /24 子网上举办一场有 2,000 名参会者的会议，您将拥有 254 个可用 IP 地址。如果您的 DHCP 租约时间设置为默认的 24 小时，那么在会场开门后的几分钟内，该地址池就会枯竭。此后，甚至在 Captive Portal 流程启动之前，所有后续的连接尝试都会失败。解决办法很简单：在人员流动率高的环境中，将访客 DHCP 租约时间缩短至 15 到 30 分钟，并根据并发用户峰值（而不仅仅是总人数）合理规划子网大小。 根本原因之二：DNS 拦截失败。Captive Portal 重定向依赖于网关对 HTTP 探测的拦截。但该探测首先需要进行 DNS 解析。如果您的 DNS 配置不允许未授权客户端解析外部域名，则探测永远不会触发。请确保您的防火墙策略明确允许来自未授权客户端的 DNS 查询，并通过对测试设备进行数据包捕获来验证您的 DNS 拦截是否正常工作。 根本原因之三：围墙花园（walled garden）配置不完整。围墙花园 - 也称为预身份验证访问控制列表 - 定义了未授权访客可以访问的外部域名。如果您的 Portal 认证页面从不在围墙花园中的 CDN 加载资源，页面将显示为空白。如果您通过 Google、Apple 或 Facebook 提供社交登录，则这些提供商使用的每个 OAuth 域名都必须加入白名单。至关重要的一点是：社交身份提供商会定期更新其 CDN IP 范围和身份验证域名。半年前运行良好的围墙花园现在可能已经失效了。请安排每季度的围墙花园审计，并在您的硬件支持的情况下使用通配符域名探查。在 Cisco Meraki、HPE Aruba、Ruckus 和 Juniper Mist 上，此功能是原生提供的。 根本原因之四：HSTS 阻止重定向。HTTP 严格传输安全（即 HSTS）是一种浏览器安全策略，强制仅通过 HTTPS 连接到特定域名。如果访客的设备尝试访问预载了 HSTS 的域名（这几乎涵盖了所有主流网站），并且您的网关尝试拦截该 HTTPS 请求以重定向到 Portal，浏览器将检测到证书不匹配。它会呈现一个无法绕过的安全警告，并完全阻止重定向。正确的解决方案是绝不尝试 HTTPS 拦截。您的网关应该只重定向未加密的 HTTP 探针。基于标准的长期解决方案是 RFC 8910，它定义了 DHCP Option 114。此选项允许您的 DHCP 服务器直接将 Captive Portal URL 播发给客户端设备，从而完全无需进行 HTTP 重定向。iOS 14 和 Android 11 及以上版本已原生支持此功能。 根本原因之五：访客设备上启用了活跃的 VPN。VPN 会加密来自设备的所有流量，并在其到达您的网关之前通过外部通道进行路由。您的网关永远无法检测到 HTTP 探测。Captive Portal 检测序列永远不会触发。访客看不到登录页面，也无法上网。针对访客的解决方法很简单：禁用 VPN，连接到门户，然后重新启用 VPN。对于您的前台工作人员来说，当访客报告连接问题时，这应该是他们询问的第一个问题。 根本原因之六：MAC 地址随机化破坏了会话持久性。现代 iOS 和 Android 设备默认使用随机 MAC 地址作为隐私功能。设备每次连接到网络时，都可能呈现不同的 MAC 地址。由于 Captive Portal 会话状态是通过 MAC 地址进行跟踪的，因此一小时前已通过身份验证的访客在其设备的 MAC 地址轮换后可能会再次看到登录页面。面向访客的解决方法是在网络设置中针对您的特定 SSID 禁用“私有地址”。运营商端的解决方法是实施基于配置文件的身份验证 - 例如通过 Passpoint 和 802.1X 的 OpenRoaming - 它在第 2 层使用凭据而不是 MAC 地址进行身份验证，从而使随机化失效。 现在让我们谈谈实施。在实践中，一个配置良好的 Captive Portal 部署到底是什么样的？ 从您的 DHCP 架构开始。对于任何预计有超过 200 台并发设备的场所，请不要使用单个 /24 子网。使用 /22 或更大子网，并设置租约时间以匹配您场所的逗留特征。酒店将租约设置为 8 小时。体育场将租约设置为 3 小时。购物中心将租约设置为 90 分钟。会议中心将租约设置为 30 分钟。 接下来，在每次重大活动之前验证您的围墙花园（Walled Garden）。最低要求的条目包括：您门户的完全限定域名和所有关联的 CDN 域名，Apple、Google、Windows 和 Firefox 的 Captive Portal 检测 URL，以及您支持的每个社交登录提供商的 OAuth 域名。在 Purple 平台，我们作为云管理服务的一部分自动维护和更新这些围墙花园条目，从而减轻了您团队的手动维护负担。 对于您的门户证书，请使用来自公认证书颁发机构的公开受信任的 TLS 证书。自签名证书会在每台设备上触发浏览器警告。在过期前更新证书 - 证书过期是导致突然、全场所门户故障的最常见原因之一。 一个让许多 IT 团队中招的陷阱是：从先前已通过身份验证的设备测试门户。您设备的会话仍处于活跃状态，因此您会完全绕过门户并得出一切正常的结论。请始终从处于全新、未授权状态的设备进行测试 - 可以是新设备，也可以是您已忽略该网络并清除了 WiFi 配置文件的设备。 让我给你举两个说明这些原则的实际场景。 场景一：伦敦市中心的一家拥有350间客房的酒店。该物业为 guest WiFi 运行了一个单 /24 子网。在一次大型会议期间，400名代表同时到达。在20分钟内，DHCP 池就被消耗殆尽。宾客报告已连接，但无法访问 Captive Portal 或互联网。最直接的解决方法是将子网扩展到 /22，提供1,022个可用地址，并将租约时间从24小时缩短至8小时。长期解决方法是部署 Purple 的云管理 Captive Portal，该系统可实时监控 DHCP 池利用率，并在耗尽前向网络团队发出警报。更改后48小时内，门户故障率降至接近于零。 场景二：一家拥有200家门店的大型连锁零售商。该连锁店在其宾客门户上使用了通过 Google 和 Facebook 的社交登录。在 Google 更新其 OAuth 基础设施后，新的身份验证域未包含在 walled garden 中。宾客可以到达门户页面，但社交登录按钮显示空白屏幕。该连锁店的 IT 团队花了整整两天时间诊断问题，才确定是 walled garden 漏洞。一经确认，修复仅需10分钟。教训：永远不要在针对云端 OAuth 提供商的 walled garden 中硬编码 IP 地址。请使用通配符域名条目并进行每季度审查。 现在解答一些我们经常从场馆 IT 团队听到的快速问答。 为什么门户在 iPhone 上可以使用，但在 Android 设备上不行？Android 使用 connectivitycheck.gstatic.com 作为其探测 URL。如果该域名被您的防火墙阻止或未包含在您的 walled garden 中，Android 设备将永远不会触发门户。请明确添加该域名。 宾客表示门户已加载，但登录后无法上网。这几乎总是 RADIUS 授权失败。请检查您的无线控制器是否可以访问您的 RADIUS 服务器，验证双方的共享密钥是否匹配，并查看 RADIUS 日志中的 Access-Reject 消息。 我们如何处理每隔几分钟就会被登出的宾客？请检查您的空闲超时设置。许多控制器的默认空闲超时为5分钟，这对于在交互之间休眠的移动设备来说过于激进。在酒店和零售环境中，请将空闲超时设置为至少30分钟。 总结一下今天简报的关键点。 Guest WiFi Captive Portal 故障分为六类：DHCP 池耗尽、DNS 拦截失败、walled garden 不完整、HSTS 重定向阻止、客户端设备上处于活动状态的 VPN 以及 MAC 地址随机化。每种故障都有具体的、可测试的解决方案。 对于您的 IT 团队，立即可采取的行动是：审计您的 DHCP 租约时间和子网规划，对照社交登录提供商当前的 OAuth 域名验证您的 walled garden，并在每次配置更改后使用全新的未授权设备测试您的门户。 对于您的长期路线图，请评估将 OpenRoaming 作为回头客 Captive Portal 重新认证的替代方案。该技术已经成熟，标准基于 IEEE 802.1X 和 WPA3-Enterprise 制定，且 Purple 在 Connect 方案下免费提供该功能，无需额外的软件费用。 仅在 2024 年，Purple 的业务就已经覆盖了 80,000 个场所，并处理了 4.4 亿次登录。我们已经历过本简报中描述的所有故障模式 - 并构建了防止这些故障的工具。如果您想了解 Purple 的云覆盖网络如何与您现有的 Cisco Meraki、HPE Aruba、Ruckus 或 Juniper Mist 基础设施相集成，请访问 purple.ai 或联系您的客户经理。 感谢您的聆听。