为什么我的访客 WiFi 无法连接？Captive Portal 常见问题排查

TITLE: 为什么我的宾客 WiFi 无法连接？Captive Portal 常见故障排查 FORMAT: Purple 技术简报播客 VOICE: 英式英语 - 资深解决方案架构师语气 DURATION: 约 10 分钟 --- SECTION 1: 导言与背景 - 约 1 分钟 您好，欢迎收听 Purple 的技术简报。我是您的主持人。今天我们将探讨企业级无线网络中最顽固、最容易被误解的问题之一：无法加载的宾客 WiFi Captive Portal。 您一定遇到过这种情况。宾客来到您的酒店、零售店、体育场或会议中心。他们加入了 WiFi 网络。但什么也没发生。没有登录页面。没有网络。只有一个一直在旋转的加载图标和日益增加的挫败感。对于场所运营总监和 IT 经理来说，那一刻不仅是一个小麻烦。它代表着宾客体验的直接失败，前台支持电话的激增，以及错失了收集第一方数据的机会，而这些数据正是您投资无线基础设施的合理依据。 在本次简报中，我们将深入了解其底层机制。我们将解释操作系统层面 Captive Portal 检测的具体工作原理，识别导致绝大多数连接失败的六大根本原因，并为您提供一个实用、可操作的排查框架，您今天就可以将其交给您的 IT 团队。让我们开始吧。 --- SECTION 2: 技术深挖 - 约 5 分钟 要解决 Captive Portal 问题，您首先需要了解 Captive Portal 在网络层面究竟做了什么。大多数人认为它只是一个登录页面。实际上，它是一个网络层的流量拦截机制，当出现问题时，这种区别至关重要。 以下是其运行顺序。宾客的设备加入您的宾客 SSID，并通过 DHCP 获取 IP 地址。此时，操作系统不会等待用户打开浏览器。在后台，系统服务会立即向设备厂商控制的探测 URL 发起一个未加密的 HTTP GET 请求。iOS 和 macOS 设备会查询 captive.apple.com。Android 设备会查询 connectivitycheck.gstatic.com。Windows 设备会查询 msftconnecttest.com。Firefox 在 detectportal.firefox.com 上也有自己的探测点。 如果网络可以公开访问互联网，这些探测会返回预期的响应，操作系统就会断定一切正常。但在宾客网络上，您的无线网关或控制器会在该 HTTP 探测到达互联网之前拦截它。网关不会返回预期的响应，而是返回一个指向您的 Captive Portal 引导页面的 HTTP 302 重定向。操作系统检测到这个异常重定向，意识到自己处于 Captive Portal 之后，并会打开一个沙盒浏览器窗口（通常称为 Captive Portal 助手）来显示登录页面。 这是正常情况下的流程。现在我们来谈谈导致其失效的六种情况。 根本原因一：DHCP 地址池耗尽。这是高密度活动中的无形杀手。如果您在标准的 /24 子网上为两千名参会者举办会议，则您拥有 254 个可用 IP 地址。如果您的 DHCP 租期设置为默认的 24 小时，那么在开门后的几分钟内，该地址池就会耗尽。在 Captive Portal 流程启动之前，后续的每个连接尝试都会失败。解决方法很简单：对于高周转率的环境，将访客 DHCP 租期设置为 15 到 30 分钟，并针对并发用户峰值（而不仅仅是总人数）合理规划子网大小。 根本原因二：DNS 拦截失败。Captive Portal 重定向依赖于网关对 HTTP 探测的拦截。但该探测首先需要进行 DNS 查询。如果您的 DNS 配置不允许未认证的客户端解析外部域名，则探测永远不会触发。请确保您的防火墙策略明确允许来自未认证客户端的 DNS 查询，并通过对测试设备进行数据包捕获来验证您的 DNS 拦截是否正常工作。 根本原因三：Walled Garden（围墙花园）不完整。Walled Garden - 也称为预认证访问控制列表 - 定义了未认证的访客可以访问哪些外部域名。如果您的 Portal 认证页面从不在 Walled Garden 中的 CDN 加载资源，则页面将显示为空白屏幕。如果您通过 Google、Apple 或 Facebook 提供社交媒体登录，则这些提供商使用的每个 OAuth 域名都必须列入白名单。这里有一个关键点：社交身份提供商会定期更新其 CDN IP 范围和认证域名。六个月前工作完美的 Walled Garden 今天可能会在无声无息中失效。建议安排每季度进行一次 Walled Garden 审计，并在您的硬件支持时使用通配符域名探查。在 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 地址进行身份验证，从而使随机化变得无关紧要。 - - 第 3 部分：实施建议和常见陷阱 - 约 2 分钟 既然我们已经了解了根本原因，那么让我们来谈谈配置良好的 Captive Portal 部署实际上是什么样的。 从您的 DHCP 架构开始。对于任何预计有超过 200 台并发设备的场所，请放弃使用单一的 /24 子网。使用 /22 或更大子网，并设置租约时间以匹配您场所的停留特征。酒店将租约设置为 8 小时。体育场将租约设置为 3 小时。购物中心将租约设置为 90 分钟。会议中心将租约设置为 30 分钟。 接下来，在每次重大活动之前验证您的围墙花园。最少所需的条目包括：您门户的 FQDN 和所有关联的 CDN 域名，Apple、Google、Windows 和 Firefox 的 Captive Portal 检测 URL，以及您支持的每个社交登录提供商的 OAuth 域名。在 Purple 的平台上，我们自动维护和更新这些围墙花园条目，作为我们云端托管服务的一部分，这减轻了您团队的手动维护负担。 对于您的门户证书，请使用来自公认证书颁发机构的受公共信任的 TLS 证书。自签名证书将在每台设备上触发浏览器警告。在过期前更新证书 - 过期的证书是导致突然发生、影响整个场所的门户故障最常见的原因之一。 许多 IT 团队都会遇到的一个陷阱：从之前已进行身份验证的设备测试门户。由于您的设备会话仍处于活跃状态，因此您会完全绕过门户并得出一切正常的结论。请务必在全新、未进行身份验证的状态下测试设备 - 可以是新设备，也可以是已忽略网络并清除 WiFi 配置文件的工作站。 最后，考虑战略发展方向。Captive Portal 是一项成熟的技术，但它们带有固有的摩擦。基于 Passpoint 和 802.1X 构建的 OpenRoaming 允许再次到访的访客自动、安全地连接，而无需看到登录页面。在我们的 Connect 计划下，Purple 充当 OpenRoaming 的免费身份提供商。Premier Inn 和 Manchester Airports Group 等场所已经部署了该技术，以消除回头客的重新身份验证摩擦，同时保持完全符合 GDPR 合规性并进行第一方数据捕获。 - - - 第 5 节：快速问答 - 约 1 分钟 让我们运行一下我们从场所 IT 团队那里听到的最常见问题。 问题：为什么该门户在 iPhone 上可用，但在 Android 设备上不可用？回答：Android 使用 connectivitycheck.gstatic.com 作为其探测 URL。如果该域名被您的防火墙阻止或不在您的围墙花园中，Android 设备将永远不会触发门户。请明确添加它。 问题：访客表示门户已加载，但登录后无法上网。回答：这几乎总是 RADIUS 授权失败。请检查您的无线控制器是否可以访问您的 RADIUS 服务器，验证双方的共享密钥是否匹配，并查看 RADIUS 日志中的 Access-Reject 消息。 问题：我们如何处理几分钟后不断被注销的访客？回答：请检查您的空闲超时设置。许多控制器的默认空闲超时为 5 分钟，这对于在交互之间休眠的移动设备来说过于激进了。对于酒店和零售环境，请将空闲超时设置为至少 30 分钟。 - - - 第 6 节：总结和后续步骤 - 约 1 分钟 总结一下：访客 WiFi Captive Portal 故障分为六类 - DHCP 耗尽、DNS 拦截失败、围墙花园不完整、HSTS 重定向阻止、客户端设备上的活动 VPN 以及 MAC 地址随机化。每个故障都有特定的、可测试的解决方案。 对于您的 IT 团队，立即可采取的行动是：审计您的 DHCP 租约时间和子网大小，根据社交登录提供商当前的 OAuth 域名验证您的围墙花园，并在每次配置更改后从全新的未授权设备测试您的门户。 对于您的长期路线图，评估将 OpenRoaming 作为再次到访的访客进行 Captive Portal 重新身份验证的继任者。该技术已成熟，标准已在 IEEE 802.1X 和 WPA3-Enterprise 下确立，并且 Purple 在 Connect 计划下免费提供此服务，无需额外的软件费用。 如需更多技术指南、案例研究和部署资源，请访问 purple.ai。感谢收听本次 Purple 技术简报。确保您的网络稳定可靠，访客连接畅通无阻。