故障排除公共 WiFi：解决“已连接但无法访问互联网”和登录页面重定向失败的问题

欢迎阅读来自 Purple 的技术简报。今天我们将探讨企业无线网络中最顽固、最容易被误解的问题之一：访客 WiFi Captive Portal 根本无法加载。 您一定遇到过这种情况：访客来到您的酒店、零售店、体育场或会议中心，连接了 WiFi 网络，但什么也没发生。没有登录页面，没有互联网，只有一个不断旋转的加载图标和愈发沮丧的体验。对于场所运营总监和 IT 经理而言，那一刻绝不仅仅是小小的不便。它代表着访客体验的直接失败、前台支持电话的激增，以及错失了收集第一方数据的绝佳机会——而这些数据正是证明您无线基础设施投资合理性的关键。 在本简报中，我们将深入探究其技术细节。我们将详细解释 Captive Portal 检测在操作系统层面的工作原理，找出导致绝大多数连接失败的六大根本原因，并为您提供一个实用、可操作的排错框架，您可以直接将其交给您的 IT 团队。 让我们先从其运作机制开始。大多数人认为 Captive Portal 仅仅是一个登录页面。但实际上，它是一个网络层的流量拦截机制，当出现问题时，这种区别至关重要。 以下是其运作流程：访客设备连接到您的访客 SSID，并通过 DHCP 获取 IP 地址。此时，操作系统不会等待用户打开浏览器。在后台，系统服务会立即向设备厂商控制的探测 URL 发起一个未加密的 HTTP GET 请求。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子网中举办有2000名参会者的会议，您只有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 Canary探测。基于长期标准的解决方案是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）。所需的最少条目包括：您门户的完全限定域名和所有关联 of CDN 域名，Apple、Google、Windows 和 Firefox 的 Captive Portal 检测 URL，以及您支持的每个社交登录提供商的 OAuth 域名。在 Purple 的平台上，我们作为云托管服务的一部分自动维护和更新这些围墙花园条目，从而减轻了您团队的手动维护负担。 对于您的门户证书，请使用来自公认证书颁发机构且公开受信的 TLS 证书。自签名证书将在每台设备上触发浏览器警告。请在到期前更新证书——证书失效是导致整个场所门户突然故障的最常见原因之一。 让许多 IT 团队踩坑的一个陷阱是：从以前进行过身份验证的设备测试门户。您的设备会话仍然处于活动状态，因此您完全绕过了门户并得出一切正常的结论。请务必在设备处于全新的、未验证的状态下进行测试——无论是使用新设备，还是忘记网络并清除 WiFi 配置文件的设备。 让我用两个真实场景来解释这些原则。 场景一：伦敦市中心一家拥有 350 间客房的酒店。该酒店为访客 WiFi 运行了单个 /24 子网。在一次大型会议期间，400 名代表同时到达。在 20 分钟内，DHCP 地址池就被耗尽。住客反馈称已连接但无法访问 Portal 页面或互联网。紧急解决方案是将子网扩展到 /22，提供 1,022 个可用地址，并将租期从 24 小时缩短至 8 小时。长期解决方案是部署 Purple 的云端托管 Captive Portal，它可以实时监控 DHCP 地址池的使用率，并在地址耗尽前向网络团队发出告警。更改后，Portal 的故障率在 48 小时内降至接近于零。 场景二：一家拥有 200 家门店的大型连锁零售商。该连锁店在访客 Portal 上使用 Google 和 Facebook 社交登录。在 Google 更新其 OAuth 基础架构后，新的身份验证域名未包含在围墙花园（Walled Garden）内。顾客可以访问 Portal 页面，但社交登录按钮显示空白屏幕。该连锁店的 IT 团队 spent 两个天时间诊断问题，最终才确定是围墙花园的配置漏洞。问题确诊后，仅用了 10 分钟便得以解决。教训：切勿在针对云端 OAuth 提供商的围墙花园中硬编码 IP 地址。请使用通配符域名条目并每季度进行审查。 现在来解答一些场所 IT 团队经常遇到的常见问题。 为什么 Portal 页面在 iPhone 上可以正常工作，但在 Android 设备上却不行？Android 设备使用 connectivitycheck.gstatic.com 作为其探测 URL。如果该域名被您的防火墙阻止或未包含在围墙花园中，Android 设备将无法触发 Portal 页面。请务必显式添加它。 有访客反映 Portal 页面已加载，但登录后无法上网。这几乎总是 RADIUS 授权失败。请检查您的无线控制器是否可以访问 RADIUS 服务器，验证双方的共享密钥是否匹配，并查看 RADIUS 日志中的 Access-Reject（拒绝访问）消息。 如何处理几分钟后就被不断登出的访客？请检查您的空闲超时设置。许多控制器的默认空闲超时为 5 分钟，对于在操作间隙会进入休眠状态的移动设备来说，这个时间太短了。对于酒店和零售环境，请将空闲超时至少设置为 30 分钟。 总结一下今天简报的关键要点。 访客 WiFi Captive Portal 故障主要分为六类：DHCP 地址池耗尽、DNS 拦截失败、围墙花园配置不完整、HSTS 重定向阻止、客户端设备上启用了活动 VPN，以及 MAC 地址随机化。每种故障都有具体的、可测试的解决方案。 对于您的 IT 团队，立竿见影的行动包括：审计您的 DHCP 租期和子网规划大小，根据社交登录提供商当前的 OAuth 域名验证您的围墙花园，并在每次更改配置后使用全新的未认证设备测试您的 Portal 页面。 对于您的长期路线图，可以评估将 OpenRoaming 作为返程访客 captive portal 重新认证的替代方案。该技术已经成熟，标准已在 IEEE 802.1X 和 WPA3-Enterprise 下确立，并且 Purple 在 Connect 计划下免费提供该功能，无需额外的软件费用。 Purple 在 80,000 个场所运营，仅在 2024 年就处理了 4.4 亿次登录。我们经历过本简报中描述的每种故障模式，并构建了防止这些故障的工具。如果您想了解 Purple 的云覆盖网络如何与您现有的 Cisco Meraki、HPE Aruba、Ruckus 或 Juniper Mist 基础设施相集成，请访问 purple.ai 或联系您的客户经理。 感谢您的聆听。