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

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