跳至主要内容

强制门户重定向故障排除:解决访客 WiFi 连接失败问题

您可以通过由下至上检查网络协议栈:寻址、DNS、探测重定向、围墙花园以及 RADIUS,从而诊断出访客 WiFi 显示已连接但无法上网的原因。随后,您可以将故障现象与其成因相匹配,在现有的硬件配置中予以修复,并建立变更控制流程以防止故障再次发生。

作者:Tom Hackett发布于 更新于
📖 14 分钟阅读783 字3 应用实例3 练习题10 关键定义

Video overview

收听本指南

查看播客转录
主持人(英国英语,自信的顾问语气): 欢迎来到 Purple 技术简报。今天,我们将解决企业网络中最令人头疼的顽疾之一:Captive Portal 重定向失败。当您的访客 WiFi 显示已连接但无法访问互联网时,您的访客会感到沮丧,您的服务台会收到大量投诉,而您的数据捕获策略也会停滞不前。在本次简报中,我们将深入剖析 Captive Portal 的技术架构,探讨为什么现代操作系统和浏览器经常拦截它们,并为您提供具体的实施策略,以永久解决这些问题。 [暂停] 让我们设想一下场景。您在一百个零售网点部署了 Cisco Meraki 或 HPE Aruba 接入点。硬件非常可靠。但访客抱怨无法访问互联网。他们选择了 SSID,设备显示了 WiFi 图标,但 Portal 页面却从未出现。或者更糟糕的是,他们看到了一个可怕的 SSL 证书错误。 为什么会发生这种情况?这归结于操作系统如何检测互联网连接。当设备连接到网络时,它会向已知 URL 发送 HTTP 探测。对于 iOS,它是 captive.apple.com。对于 Android,它是 connectivitycheck.gstatic.com。Windows 使用 msftconnecttest.com。如果设备收到标准的 HTTP 200 OK 响应,它会假定自己可以直接访问互联网。如果网络网关拦截了该请求,并回复了一个指向不同 URL 的 HTTP 302 重定向,操作系统就知道自己处于 Captive Portal 之后。然后它会打开一个伪浏览器来加载 Portal 页面。 失败通常就发生在这个拦截点。 [暂停] 第一个主要的失败点是网络连接状态指示器探测,即 NCSI。如果您的防火墙或网关拦截了这些未加密的 HTTP 请求,操作系统就永远不会收到 302 重定向。它只会简单地假定网络已损坏。要解决此问题,您必须确保您的预认证访问控制列表允许 HTTP 流量访问那些特定的操作系统检测 URL。 第二个且越来越常见的问题是 HTTP 严格传输安全,即 HSTS。现代浏览器对主流域名强制执行 HTTPS。如果用户连接到您的 WiFi 并立即尝试打开 google.com,他们的浏览器会坚持使用加密连接。当您的网关拦截该 HTTPS 请求并尝试将其重定向到 Captive Portal 时,浏览器会检测到中间人攻击。您的网关提供的证书与 google.com 不匹配。结果就是强制拦截。用户会看到安全警告,并且无法进入登录页面。 这里的解决方案有两个方面。首先,依赖我们刚刚讨论的操作系统级检测机制。它们专门使用未加密的 HTTP 来避免这种证书不匹配。其次,确保您的围墙花园配置完美无缺。 什么是围墙花园(walled garden)?它是访客在进行身份验证之前可以访问的域名和IP地址列表。如果您使用通过 Microsoft Entra ID 或 Google Workspace 的社交登录,或者通过 Stripe 处理付款,这些域名必须在您的围墙花园中。如果不在,页面可能会加载,但身份验证过程将会静默失败。 [PAUSE] 让我们来看一个现实世界中的场景。麦当劳在数千个地点为数百万客户提供服务。他们使用 Purple 来管理他们的访客 WiFi。如果他们的会话超时设置得太短,在享受漫长午餐时查看手机的顾客可能会被强制重新进行多次身份验证。这会破坏体验。我们建议将酒店餐饮和零售环境的会话持续时间设置为24小时,并使用 MAC 地址缓存来无缝识别返回的设备。 [PAUSE] 现在来看看实施建议。在部署 Captive Portal 时,您必须正确配置网关以拦截 DNS 和 HTTP 流量。如果您使用像 Purple 这样的云端覆盖网络,您的本地硬件(无论是 Juniper Mist 还是 Ubiquiti UniFi)必须能够连接到 Purple RADIUS 服务器。 这里有一个关键的陷阱:DNS 解析。如果访客设备无法解析您 Captive Portal 的主机名,重定向就会失败。请确保您的 DHCP 服务器分配了可靠的 DNS 地址,并验证您的网关是否允许 DNS 查询通过围墙花园。 此外,还要考虑物理环境。体育场馆或交通枢纽(如曼彻斯特机场集团)等高密度场所需要处理数千个并发连接尝试。如果您的本地 DHCP 池耗尽,新设备将连接到接入点,但无法获取 IP 地址。它们甚至永远无法到达 Captive Portal 阶段。请务必根据峰值容量合理规划子网大小,并对临时访客网络使用较短的 DHCP 租约时间。 [PAUSE] 现在进行一个基于常见服务台工单的快速问答环节。 问题一:为什么 Portal 在 iPhone 上可以工作,但在 Android 设备上失败? 回答:这几乎可以肯定是一个围墙花园问题。您可能已经将 captive.apple.com 加入了白名单,但遗漏了 connectivitycheck.gstatic.com。请更新您的预身份验证访问控制列表。 问题二:访客成功进行了身份验证,但仍然无法上网。为什么? 回答:请检查您的 RADIUS 配置。网关可能没有收到来自 RADIUS 服务器的 Access - Accept 消息,或者身份验证后的防火墙规则阻止了流量。请验证共享密钥并确保端口 1812 和 1813 已开放。 问题三:我们能否对初始重定向使用 HTTPS 以避免安全警告? 回答:不能。您无法在不引起证书错误的情况下拦截 HTTPS 请求,除非您在每个访客设备上都安装根证书,这对于公共 WiFi 来说是不可能的。您必须依赖未加密的 HTTP 系统探测来触发 Portal。 [PAUSE] 总结:Captive Portal 故障极少是由硬件故障引起的。它们几乎总是重定向流程、walled garden(围墙花园)或 DNS 设置中的配置不匹配导致的。 第一点:确保在身份验证之前可以访问 OS 检测 URL。 第二点:配置您的 walled garden,将所有必要的身份提供商和内容分发网络包含在内。 第三点:验证您的网关与身份验证平台之间的 RADIUS 通信。 第四点:根据峰值密度规划您的 DHCP 作用域大小。 通过掌握这些要素,您可以消除连接摩擦。您将不再让访客感到沮丧,并开始捕获推动忠诚度和收入所需的第一方数据。Purple 的 Identity-Based Networks 简化了这一过程,提供了一个与硬件无关的云覆盖层,可无缝处理全球 80,000 个活跃场馆中复杂的 RADIUS、Captive Portals 和分析。 感谢您参加本次 Purple 技术简报会。如需了解更详细的配置指南和架构图,请访问 purple.ai。

核心系列的一部分:强制门户指南 →

Useful? Link to this tool

当访客 WiFi 显示已连接但无法上网时,说明设备已加入网络,但强制门户重定向已中断。常见原因包括操作系统探测被拦截、缺少围墙花园(Walled Garden)条目或 DNS 故障。其他原因还包括 DHCP 地址池耗尽,或 RADIUS Access-Accept 响应未能到达网关。这些问题均可通过配置进行修复。

##“访客 WiFi 已连接但无法上网”具体表现为何?

设备加入网络名称(SSID)并显示满格信号,但无法加载任何内容。各平台报告的方式有所不同:

  • iOS 在网络名称下方显示“无互联网连接”。
  • Android 显示“已连接,无互联网连接”或弹出无法跳转的“登录网络”提示。
  • Windows 将网络标记为“无互联网”。

访客会看到 WiFi 图标显示正常,但浏览器无法使用,因此会归咎于场馆。

同一种症状可能掩盖了多种不同的故障。您通常会看到以下情形之一:

  • 所有设备均无法弹出登录页面。
  • 登录页面在 iPhone 上可以显示,但在 Android 手机上无法显示,反之亦然。
  • 浏览器显示证书或隐私警告,而非登录页面。
  • 访客填妥表格并看到成功提示后,依然无法上网。
  • 闲时一切正常,忙时出现故障。

每种情形都指向不同的网络层。请先分析故障模式,切勿盲目重启接入点。

强制门户检测的工作原理

强制门户是网关在授予互联网访问权限之前展示的网页。根据您的架构设计,网关可以是控制器、防火墙或接入点。

主流操作系统在加入网络时都会立即检测强制门户。设备会向已知地址发送一个明文 HTTP 请求,并将收到的回复与预期结果进行比较。每种结果对应的含义如下:

  • 回复符合预期。 设备认定已连接开放的互联网。
  • 网关返回 HTTP 302 重定向。 设备判定其处于门户限制之下。它会打开一个轻量级浏览器窗口(通常称为 captive network assistant),并加载您的登录页面。
  • 请求未收到回复。 设备提示无互联网连接,且不打开任何页面。
平台 探测 URL 在线时的预期回复
iOS 和 macOS http://captive.apple.com/hotspot-detect.html HTTP 200,附带“Success”页面
Android http://connectivitycheck.gstatic.com/generate_204 HTTP 204 无内容
Windows (NCSI) http://www.msftconnecttest.com/connecttest.txt HTTP 200,附带文本“Microsoft Connect Test”
Firefox http://detectportal.firefox.com/success.txt HTTP 200,附带文本“success”

Microsoft 文档指出,其网络连接状态指示器 (NCSI) 还会将 dns.msftncsi.com 作为 DNS 检查进行解析。因此,如果认证前 DNS 出现故障,即使 HTTP 正常,Windows 笔记本电脑也会报告无互联网连接。

导致强制门户重定向失败的常见原因有哪些?

大多数问题由七个原因导致。这些原因分布在不同层级,从地址分配一直到身份验证。

操作系统探测被拦截

网关的预身份验证访问控制列表 (ACL) 丢弃了探测请求,而不是对其进行重定向。设备未收到任何响应,因此判定没有网络连接,也就永远不会打开强制门户。

如果 DNS 过滤服务拦截了探测的主机名,也会产生同样的效果。这是强制门户从不弹出的最常见原因。

HTTPS 和 HSTS 破坏了拦截

RFC 6797 中定义的 HTTP 严格传输安全 (HSTS) 会告知浏览器仅通过 HTTPS 访问域名。浏览器附带了 HSTS 域名的预加载列表,其中包括 Google 和大多数银行的域名。当访客输入 google.com 时,浏览器会在请求离开设备之前将其升级为 HTTPS。

网关如果不出示 google.com 的证书就无法重定向该请求,但网关并不拥有该证书。浏览器会显示严重的安全警告,且无法绕过。

解决方法是仅重定向上表中的纯 HTTP 探测请求,这些请求正是为此目的而设计的。切勿为了强制门户重定向而拦截 HTTPS 请求。

围墙花园 (Walled Garden) 限制过于严格

围墙花园是设备在身份验证前可以访问的域名和 IP 地址列表。如果缺少某个条目,登录页面将加载不完整或导致登录步骤失败。常见的漏项包括:

  • 社交登录或单点登录的身份提供商端点,例如 Microsoft Entra ID、Okta 或 Google Workspace。
  • 为您的登录页面提供字体、脚本和样式表服务的内容分发网络 (CDN) 域名。
  • 支付处理商域名(如果您对网络访问收费)。
  • Purple 的强制门户和 RADIUS 端点(已列在适用于您硬件的 Purple 集成指南中)。

身份验证前 DNS 解析失败

设备在加载页面之前必须先解析强制门户的主机名。在以下两种情况下,重定向会失效:

  • 网关在预身份验证状态下拦截了 DNS。
  • DHCP 分配了设备无法访问的 DNS 服务器。

Android 带来了一个特殊情况。如果访客设置了特定的私人 DNS 主机名,Android 会在端口 853 上寻求 DNS over TLS。在自动模式下,它会退回到普通 DNS。

DHCP 地址池耗尽

当地址池耗尽时,新设备虽然能关联到无线接入点 (AP),但无法获取 IP 地址。此时 Windows 会为自己分配一个 169.254.x.x 的链路本地地址,其他系统也会显示类似的自分配状态。

由于没有有效地址,设备无法发送探测请求。它看起来已连接,但无法上网。这是体育场馆、会议中心和交通枢纽在高峰期发生的经典故障。

RADIUS 未送达 Access-Accept

RADIUS (远程鉴别拨号用户服务) 将登录决策从身份验证服务器传输到您的网关。按照 RFC 2865 的定义,服务器会回复 Access-Accept 或 Access-Reject。随后网关会开放访问权限或保持拒绝状态。

访客填写了表单却仍然保持离线状态,这几乎总是意味着网关未收到 Access-Accept。常见的三个原因是:

  • 共享密钥不匹配。
  • 防火墙阻止了 UDP 1812(认证)或 UDP 1813(计费)。RFC 2865 和 RFC 2866 定义了这些端口。
  • 控制器上的服务器地址错误。

Portal 自身的证书已过期

您的登录页面是通过 HTTPS 提供的。如果其 TLS 证书过期,所有现代浏览器都会显示安全警告并阻止该页面。虽然重定向工作完全正常,但访客仍然无法登录。

如何确定具体原因?

按照协议栈自下而上依次排查。每次检查都可以排除一个层级,因此请在发现第一个故障点时停下。

  1. 设备是否有有效的 IP 地址? 在 Windows 上运行 ipconfig /all,或检查手机上的网络详情。如果是 169.254.x.x 地址或根本没有地址,则指向 DHCP 问题。请检查 DHCP 服务器上的地址池使用率。高于 90% 即意味着即将耗尽。
  2. DNS 是否能正常解析? 从访客虚拟局域网(VLAN,即逻辑上隔离的网络区段)上的设备查询 Portal 主机名。如果查询失败,则说明认证前 DNS 被阻止或 DHCP 分配的 DNS 服务器错误。
  3. 探测是否收到 302? 在访客 VLAN 上进行数据包捕获,或在浏览器中访问其中一个 HTTP 探测 URL。您应该会看到探测请求,随后是一个指向 Portal 的 HTTP 302。如果探测没有响应,则意味着 ACL 丢弃了该请求。如果完全没有探测请求,则意味着设备认为自己已经在线,这通常是由于缓存状态导致的。请忽略该网络并重新连接。
  4. 登录页面是否完全加载? 打开浏览器开发者工具 (F12) 并查看网络选项卡。如果对第三方域名的请求被阻止,则指向围墙花园 (walled garden) 配置缺失。
  5. 网关是否收到 Access-Accept? 检查控制器的 RADIUS 日志。登录成功后会紧跟一个状态为 Start 的 Accounting-Request。如果登录后未出现计费记录,则说明 RADIUS 路径已中断。

然后将您观察到的现象与下表进行对照。

症状 最可能的原因 解决方法
任何设备上都不显示 Portal 探测被网关 ACL 或 DNS 过滤器阻止 在认证前允许探测主机名并对其进行重定向
Portal 在 iOS 上显示,但在 Android 上不显示 重定向规则中缺少 Android 探测主机 重定向 connectivitycheck.gstatic.com 并重新测试
显示证书警告而非 Portal HTTPS 拦截或 Portal 证书过期 仅重定向 HTTP 探测,并更新证书
Portal 加载但缺少图像或按钮 内容分发网络 (CDN) 域名被阻止 将登录页面的资源域名添加到围墙花园
社交登录无响应失败 缺少身份提供商端点 添加 Microsoft Entra ID、Okta 或 Google Workspace 端点
登录成功但无法上网 Access-Accept 未到达网关 检查共享密钥、UDP 1812 和 1813 以及服务器地址
访客每次访问都要求登录 会话时间过短或 MAC 地址随机化 延长会话时间并针对 MAC 随机化做好规划
仅在高峰期出现故障 DHCP 地址池耗尽 扩大子网并缩短租约时间

实战场景:高峰期容纳 1,500 个座位的会议中心

情况。 一家会议中心在单个 /24 子网中运行其参会人员网络,DHCP 租约时间为 8 小时。上午的主旨演讲运行顺畅。午饭后,参加下午会议的参会人员显示“已连接,无 Internet”。服务台将其视为门户故障,并两次重启了控制器。

处理措施。 诊断的第 1 步发现新设备获取的是 169.254.x.x 地址。一个 /24 子网提供 254 个可用地址,而 8 小时的租约保留了上午的所有地址。团队将参会人员 VLAN 迁移到了 /21 子网,并将租约缩短至 30 分钟。

结果。 可用地址从 254 个增加到 2,046 个,大约是之前容量的 8 倍。离开的参会人员留下的地址现在会在 30 分钟内归还给地址池,而不是 8 小时。该修复仅需一个变更窗口,无需任何新硬件。

实战场景:拥有 200 间客房的酒店中 Android 客人无法登录

情况。 在重新设计登录页面后,一家拥有 200 间客房的酒店接到了来自 Android 客人的前台投诉。他们中的大多数人选择了 Google 登录选项。门户正常显示,但点击按钮毫无反应。

处理措施。 IT 经理在一部 iPhone、一部 Android 手机和一台 Windows 笔记本电脑上测试了该流程。笔记本电脑上的开发者工具显示针对字体分发网络和 Google 登录域名的请求被拦截。新设计添加了这两项。团队将它们添加到了围墙花园(Walled Garden)中。

结果。 在首次重新测试中,所有三台测试设备均成功完成了 Google 登录。该修复需要两条围墙花园条目,无需更改硬件。

实战场景:防火墙更新后的 40 家门店零售资产

情况。 一家零售商利用周末更换了 40 家门店的防火墙。周一,每家已更新门店的购物者都可以填写登录表单,但依然保持离线状态。尚未更新的门店工作正常。

处理措施。 第 5 步发现没有来自已更新门店的计费记录。新的防火墙模板默认拒绝出站 UDP,从而拦截了 1812 和 1813 端口。团队在模板中添加了显式的出站规则,并推送到所有 40 家门店。

结果。 推送后,每家门店都重新出现了计费记录。因为只有已更新的门店出现故障,这一规律直接指向了模板问题,排除了 WiFi 的原因。

对您的具体配置有疑问吗?

我们的团队与 80,000 多个场所的运营方、IT 经理和网络工程师保持合作。预约 20 分钟的通话,我们将为您展示同行是如何解决类似问题的。

如何在每个操作系统和控制器上修复此问题?

控制器上的修复在所有平台上都遵循相同的模式。操作系统的修复主要是了解每个系统的行为方式。

在您的控制器上

Purple 作为云叠加层运行在 Cisco Meraki、HPE Aruba、Ruckus、Juniper Mist、Ubiquiti UniFi、Cambium、Extreme 和 Fortinet 上。所有这 8 个平台上的修复模式都是相同的:

  1. 将访客 SSID 指向 Purple 集成指南中提供的外部强制门户 URL,并禁用任何本地 Splash 页面。
  2. 将未认证的 HTTP 流量(包括探测流量)重定向至该 URL。请勿更改 HTTPS。
  3. 在认证前允许 DNS 和 DHCP 通信。
  4. 添加 Walled Garden 条目:Purple 端点、身份提供商端点以及登录页面资源域名。
  5. 输入 Purple 控制面板中提供的 RADIUS 服务器地址和共享密钥。然后确认防火墙已放行出站 UDP 1812 和 1813 端口。

菜单名称因厂商和固件版本而异,因此请遵循适您所用平台的 Purple 集成指南。Fortinet 社区文档中关于 FortiGate 强制门户流程的说明,是重定向顺序方面极具参考价值的厂商端参考资料。

在 iOS 和 macOS 上

如果强制网络助理未能打开,请在“设置”中忽略该网络并重新连接。这会强制发起一次新的探测。

近期发布的 iOS 和 macOS 版本还支持强制门户 API。它允许网络通过 RFC 8910 中定义的 DHCP 选项 114 通告其门户,从而减少对拦截的依赖。如果助理能打开但保持空白,请检查 Walled Garden 中是否包含相应的资源域名。

在 Android 上

Android 在检测到门户时会显示“登录网络”通知。如果通知从未出现,请确认网关重定向了 connectivitycheck.gstatic.com,而不是将其丢弃。

如果访客看到“无法访问私有 DNS 服务器”,说明其手机设置了严格的私有 DNS 主机名。您有两种选择:

  • 在认证前放行端口 853 上的基于 TLS 的 DNS 通信。
  • 请访客将私有 DNS 切换为自动模式。

在 Windows 上

Windows 依赖于 NCSI HTTP 探测及其 DNS 检查。如果门户未能自动打开,请访问任意纯 HTTP 网站以手动触发重定向。如果在登录后持续显示“无 Internet 连接”,通常意味着网关仍在重定向该探测。在这种情况下,网关尚未应用 Access-Accept 响应。

在浏览器中

请向一线员工宣贯,指导访客访问 HTTP 地址,切勿访问诸如 google.com 等 HSTS 域名。Firefox 会针对 detectportal.firefox.com 运行自有的探测,因此请在重定向测试中包含该主机。

如何防止访客 WiFi 重定向故障再次发生?

大多数重复发生的故障源于变更,而非初始构建。固件更新、新的防火墙模板、登录页面重新设计或即将过期的证书可能会绕过测试。请将以下控制措施融入您的变更流程中:

  • 每次变更后在三个平台上进行测试。 使用一台 iPhone、一台 Android 手机和一台 Windows 笔记本电脑。如果某个平台失败而其他平台通过,请首先排查 Walled Garden 是否存在遗漏。
  • 按峰值而非平均值规划容量。 计算最大并发设备数量并预留冗余空间。临时访客网络通常将租约设置为 15 至 30 分钟。
  • 设置与到访匹配的会话时长。 酒店和零售场所通常设置 24 小时会话,因此访客在每次入住或到访期间只需登录一次。
  • 每日监控登录量。 Purple 的 WiFi 分析 可以按场所报告登录情况。某个场所的登录量突然下降,通常会在访客投诉之前向您预警 RADIUS 或围墙花园故障。
  • 将证书和共享密钥纳入变更控制。 在日程表中记录门户证书的到期日期。将 RADIUS 共享密钥存储在防火墙和控制器团队都可以查看的位置。
  • 隔离访客流量。 将访客置于独立的 VLAN 中。PCI DSS 将网络隔离视为防止访客网络影响持卡人数据环境合规范围的方法。
  • 针对 MAC 随机化做好规划。 最近发布的 iOS 和 Android 对每个网络使用随机 MAC 地址,且某些模式会随时间轮换该地址。基于 MAC 地址的会话缓存随后会要求再次到访的访客重新登录。
  • 合规地收集同意。 GDPR 要求针对营销数据取得知情且明确的同意。Purple 的知情选择订阅选项针对每个用途提供单独的选择。

为再次到访的访客跳过强制门户

最持久的解决方案是完全移除针对重复到访的重定向。

  • Passpoint 是基于 Hotspot 2.0 规范构建的行业认证。它允许设备使用存储的配置文件自动加入网络。
  • OpenRoaming 由无线宽带联盟(WBA)运营,用于联合身份提供商。访客现有的凭据随后可在参与该计划的各个场所通用。

两者均使用 IEEE 802.1X(基于端口的网络访问控制标准),因此不存在会发生故障的门户。

接入方式 首次到访 再次到访 空口加密 主要故障点 适用场景
带强制门户的开放式 SSID 访客完成登录页面 会话或 MAC 缓存到期时重新登录 无,除非 SSID 使用增强型开放网络(OWE) 探测、围墙花园、DNS、RADIUS 每次到访都需要收集第一方数据的场所
共享预共享密钥(PSK) 访客输入密码 自动 WPA2 或 WPA3-Personal 密码共享、无访客身份 无数据收集需求的小型咖啡馆
Passpoint 或 OpenRoaming 访客安装配置文件或使用联合身份 自动,无门户 WPA2 或 WPA3-Enterprise 配置文件配置、证书 有重复到访者的酒店、机场、铁路和园区

Purple 的定位

Purple 访客 WiFi 作为与硬件无关的云端叠加层运行,因此您可以通过配置修复重定向故障,而无需购买新硬件。Purple 为 90 多个国家的 80,000 多个活跃场所提供服务,每年支持 5 亿用户和登录。该平台实现 99.999% 的可用性,并通过了 ISO 27001、Cyber Essentials 及 B Corp 认证。此外,它还符合 GDPR 和 CCPA 标准。

当门户发生故障时,原因几乎总是出于本地:探针规则、围墙花园条目、DHCP 地址池或防火墙规则。

这些模式在不同行业屡见不鲜:

  • 酒店 在办理入住高峰期会出现重定向故障。
  • 零售 园区在进行全园区防火墙变更后会出现此类故障。
  • 列车 和车站随着乘客成批上车,会面临 DHCP 压力。
  • 医疗 场所需要可正常工作的患者及访客 WiFi,且无需将临床工作人员卷入支持电话中。

常见问题解答

Purple 是否兼容我们现有的无线接入点?

是的。Purple 与硬件无关,它作为云端叠加层运行于 Cisco Meraki、HPE Aruba、Ruckus、Juniper Mist、Ubiquiti UniFi、Cambium、Extreme 和 Fortinet。您可以保留现有的接入点和控制器。您只需将访客 SSID 指向 Purple 的强制门户,并根据 Purple 的集成指南添加围墙花园条目和 RADIUS 详细信息,然后进行测试。无需拆除或全面更换硬件。

解决访客 WiFi“已连接但无法上网”是否需要购买新硬件?

不需要。在几乎所有情况下,故障均为配置问题:探针受阻、围墙花园缺失、认证前 DNS、DHCP 地址池耗尽或 RADIUS 防火墙规则限制。您只需在现有的控制器、防火墙或 DHCP 服务器上修复对应项即可。只有当无线接入点密度无法满足高峰期的设备数量时,硬件才会成为问题,而现场勘测可以对此做出确认。

将访客 WiFi 迁移至 Purple 需要做什么?

迁移至 Purple 是一项配置工程,而非安装工程。在每个控制器上,将访客 SSID 设置为 Purple 的外部门户,并添加围墙花园和 RADIUS 设置。然后确认 UDP 1812 和 1813 的防火墙规则。接下来,在 Purple 中构建登录页面和同意选项,并在 iOS、Android 及 Windows 上进行测试。多场所园区可以对控制器设置进行模板化处理。

强制门户是否符合 GDPR 合规要求?

是的,前提是同意是在知情、具体且自愿的情况下给出的。GDPR 要求针对每个目的(例如营销电子邮件)提供单独的确认选择,并禁止预选框。Purple 的知情选择 Opt-in 功能可单独呈现每个选项。Purple 通过了 ISO 27001 认证,持有 Cyber Essentials 证书,并符合 GDPR 及 CCPA 要求。这可为您的数据保护官提供他们所需的标准。

再次访问的访客能否跳过登录页面?

可以。Passpoint 和 OpenRoaming 允许设备使用存储的配置文件或联合身份自动连接。两者均使用基于 WPA2 或 WPA3-Enterprise 加密的 IEEE 802.1X 认证,因此再次访问时不会发生强制门户重定向失败的情况。许多场所同时运行这两者:为首次访问的访客和数据捕获提供强制门户,并为再次光临的访客、乘客和学生提供 OpenRoaming。

我们如何才能在登录开始出现故障时收到通知?

按场所监控登录量。Purple 的 WiFi 分析功能会报告每个场馆的登录情况,因此某个位置登录量的突然下降在其正常模式和您的其他场所衬托下会非常明显。这种下降通常意味着最近的更改引发了 RADIUS、围墙花园或 DHCP 故障。在仪表板中发现此问题要比等待前台投诉传达至 IT 部门更快。

我们应该使用强制门户还是共享 WiFi 密码?

如果您希望获取第一方数据和同意,请使用强制门户;只有在两者都不需要时,才使用共享密码。共享预共享密钥虽然可以使用 WPA2 或 WPA3-Personal 对流量进行加密,但它无法告诉您连接者的身份,且密码容易泄露。强制门户可以收集获得同意的第一方数据,而 Passpoint 或 OpenRoaming 则为再次访问添加了自动加密接入功能。

关键定义

强制门户

网关(控制器、防火墙或接入点)在授予互联网访问权限之前提供的网页。操作系统通过发送纯 HTTP 探测并将 HTTP 302 重定向视为存在强制门户的标志来检测它。

当访客 WiFi 显示已连接但无网络时,故障往往发生在这一层。您需要将访客 SSID 配置为指向外部强制门户 URL,并将未认证的 HTTP 流量重定向到该 URL。

操作系统探测

各个平台在加入网络时发送的纯 HTTP 请求:iOS 和 macOS 使用 captive.apple.com,Android 使用 connectivitycheck.gstatic.com/generate_204,Windows 使用 www.msftconnecttest.com/connecttest.txt,Firefox 使用 detectportal.firefox.com,每个平台在在线时都期望获得固定的回复。

如果认证前 ACL 或 DNS 过滤器丢弃了探测,设备就会判定没有互联网连接,且永远不会打开强制门户。这是强制门户从未出现的最常见原因。

HSTS(HTTP 严格传输安全)

在 RFC 6797 中定义,HSTS 指示浏览器仅通过 HTTPS 访问域名。浏览器内置了 HSTS 域名的预加载列表,并在请求离开设备之前对其进行升级。

网关在没有相应证书的情况下,无法将针对 HSTS 域名的 HTTPS 请求进行重定向,因此访客会看到严重的安全警告。请仅重定向 HTTP 探测,并明确指示员工切勿让访客访问 google.com。

围墙花园

设备在预认证状态下可以访问的域名和 IP 地址允许列表,由网关的预认证访问控制列表强制执行。

缺少身份提供商(如 Microsoft Entra ID、Okta 或 Google Workspace)、内容分发网络或 Purple 端点的条目,会导致页面部分加载和社交登录静默失败。

RADIUS

远程认证拨号用户服务,在 RFC 2865 中定义为 UDP 1812 上的认证,在 RFC 2866 中定义为 UDP 1813 上的计费。服务器会对每个 Access-Request 回复 Access-Accept 或 Access-Reject。

RADIUS 将登录决策传输至您的网关。共享密钥不匹配、防火墙阻断 UDP 1812 或 1813,或者服务器地址错误,都会导致访客在成功登录后仍处于离线状态。

计费请求(开始)

在 RFC 2866 中定义的 RADIUS 计费消息,在会话开始时通过 UDP 1813 发送,包含 Start 状态类型。

登录后,控制器日志中出现该请求可确认网关已应用 Access-Accept。如果登录后没有计费记录,则说明 RADIUS 路径已中断。

NCSI(网络连接状态指示器)

Windows 连接性检查机制,该机制向 www.msftconnecttest.com 发送 HTTP 探针,并解析 dns.msftncsi.com 作为 DNS 检查,期望获取文本 Microsoft Connect Test。

如果预认证 DNS 中断,即便 HTTP 正常工作,Windows 笔记本电脑也可能报告无网络连接;而在登录后持续显示“无互联网”,通常意味着网关仍在重定向探针。

强制门户 API (DHCP option 114)

RFC 8910 中定义的 DHCP option 114 允许网络将其强制门户 URI 直接通告给设备,从而使设备无需依赖截获探针。

较新的 iOS 和 macOS 版本支持该功能,这减少了对重定向及随之而来的故障点的依赖。

私人 DNS (DNS over TLS)

一项 Android 设置,当设置了特定主机名时,会通过端口 853 上的 TLS 加密发送 DNS 查询,而不是普通 DNS。在自动模式下,它会退回使用普通 DNS。

设置了严格私人 DNS 主机名的访客会看到“无法访问私人 DNS 服务器”。您需要么在认证前允许端口 853,要么要求访客切换为自动模式。

Passpoint 和 OpenRoaming

Passpoint 是基于 Hotspot 2.0 规范建立的行业认证,用于使用已保存的配置文件自动加入网络。由无线宽带联盟(Wireless Broadband Alliance)运营的 OpenRoaming 则联合了身份提供商。两者均使用 IEEE 802.1X 基于端口的网络访问控制以及 WPA2 或 WPA3-Enterprise 加密进行认证。

它们使重访者完全脱离强制门户,因此重复访问时不会出现重定向失败,同时门户仍能处理首次访问和数据捕获。

应用实例

一家拥有 1,500 个座位的会展中心在一个 /24 子网上运行参会者 WiFi,DHCP 租期设为 8 小时。上午的会议一切正常,但午饭后新到的参会者显示已连接但无网络服务,服务台为此重启了两次控制器。

诊断的第一步发现新设备获取到了 169.254.x.x 链路本地地址,这表明问题出在 DHCP 而非强制门户。一个 /24 子网提供 254 个可用地址,而 8 小时的租期保留了上午的所有地址,导致地址池耗尽。团队将参会者 VLAN 迁移至一个 /21 子网并将租期缩短至 30 分钟。可用地址从 254 个增加到 2,046 个,约为此前容量的 8 倍,离场参会者的地址现在会在 30 分钟内返回地址池。该修复仅需一个变更窗口,且无需采购新硬件。

在一家拥有 200 间客房的酒店重新设计登录页面后,有 Android 访客在前台投诉。虽然弹出了强制门户页面,但 Google 登录按钮没有任何响应。

IT 经理在一台 iPhone、一台 Android 手机和一台 Windows 笔记本电脑上测试了该流程。笔记本电脑上的浏览器开发者工具显示,针对字体分发网络和 Google 登录域名的请求被拦截,这两个域名均是在重新设计时添加的。由于强制门户本身已加载,因此故障出在围墙花园,而非探测重定向。团队将这两个域名添加到了围墙花园中。在首次重新测试中,所有三台测试设备均成功完成了 Google 登录,仅需添加两条围墙花园条目,且未对硬件进行任何更改。

一家零售商在周末替换了 40 家门店的防火墙。周一,每个已更新门店的顾客均填写完成了登录表单,但依然处于离线状态;而尚未更新的门店则运行正常。

诊断的第 5 步检查了控制器 RADIUS 日志,发现没有来自已更新门店的计费记录,这意味着网关从未收到 Access-Accept。新的防火墙模板默认拒绝出站 UDP,从而拦截了端口 1812 和 1813。团队在模板中添加了明确的出站规则并推送到所有 40 家门店,所有门店随后重新出现了计费记录。由于仅有已更新的门店出现故障,故障模式直接指向了防火墙模板,排除了 WiFi 本身的问题。

练习题

Q1. 在拥有 5,000 个座位的大型场馆举办大型会议期间,IT 团队收到报告称有数百位参会者无法访问访客 WiFi 门户。接入点显示的关联数量正常。问题在活动开始 45 分钟后出现。最可能的原因是什么,即时解决方案是什么?

提示:该问题是在活动开始后出现的,而不是在刚启动时。请考虑随着更多设备的加入,哪种资源会变得紧张。

查看标准答案

最可能的原因是 DHCP 地址池耗尽。随着参会者到达并关联至 SSID,DHCP 地址池被填满。新设备虽然与接入点建立了关联,但无法获取 IP 地址,因此它们从不发送触发强制门户所需的 HTTP 探针。即时解决方案是将 DHCP 租约时间缩短至 15 分钟(从而更快地收回已离开设备的地址),并在可能的情况下通过添加第二个子网来扩大地址池。长期解决方案是在下一次活动中,根据最大并发设备数而非平均值来规划 DHCP 地址池的大小。

Q2. 您已在某零售连锁企业的 Ubiquiti UniFi 无线接入点上部署了 Purple。 Splash 页面在所有设备上均能正常加载。访客填妥电子邮件收集表单并看到了成功提示消息。但当他们尝试上网时,却无法连接互联网。Purple 仪表盘显示登录状态为成功。您首先应该检查什么?

提示:云平台已记录认证。故障发生在本地强制执行步骤。

查看标准答案

由于 Purple 的仪表盘显示登录成功,说明云端身份验证步骤已正确完成。故障出在 RADIUS 授权步骤 - UniFi 控制器未能接收或执行来自 Purple 的 RADIUS 服务器的 Access-Accept 消息。请按以下顺序检查:(1) UniFi 控制器上的 RADIUS 共享密钥是否与 Purple 仪表盘中的密钥完全一致;(2) 控制器到 Purple 的 RADIUS 服务器 IP 地址的出站 UDP 端口 1812 和 1813 是否已放行;(3) UniFi 控制器上配置的 RADIUS 服务器 IP 地址是否为最新地址(Purple 可能已更新过这些地址)。在控制器上抓包可以确认 Access-Accept 消息是否已到达。

Q3. 某酒店 IT 经理反馈称,在其设备上使用 VPN 的访客完全无法访问强制门户。未开启 VPN 的访客则能正常连接。该酒店使用的是 Cisco Meraki MX 设备。IT 团队是否应该修改强制门户配置以兼容 VPN 用户?

提示:思考一下在强制门户能够拦截设备的网络流量之前,VPN 会对该流量做什么。

查看标准答案

不需要 - 无需更改强制门户配置。VPN 客户端会在设备发送流量之前将其加密,其中也包括 HTTP 连通性探测流量。网关无法拦截已加密的 VPN 流量,因此永远不会发出 302 重定向。访客必须禁用其 VPN,完成强制门户身份验证,然后再重新启用 VPN。这是强制门户与 VPN 的基本架构限制,而非配置错误。IT 团队应在访客 WiFi 使用说明中添加提示,建议 VPN 用户在连接前关闭 VPN。

常见问题

Why does the captive portal redirect fail to open automatically on mobile devices?

Mobile operating systems (iOS, Android, Windows) rely on unauthenticated HTTP probes to vendor endpoints (such as captive.apple.com or connectivitycheck.gstatic.com/generate_204). If the network gateway does not intercept port 80 traffic with a clean HTTP 302 redirect, or if DNS queries for those probe domains are dropped before authentication, the Captive Network Assistant (CNA) will not launch.

Why does the 'captive portal login keeps stopping' error occur on Android devices?

The 'captive portal login keeps stopping' error on Android occurs when the system WebView crashes during redirection or when the gateway drops the generate_204 HTTP probe midway through authentication. Clearing the cache of the Android System WebView or Chrome app, disabling randomized MAC addresses for the venue SSID, and navigating manually to an unencrypted HTTP probe address resolves the crash loop.

How do unencrypted HTTP sites like neverssl.com force a captive portal login screen to load?

Because modern browsers enforce HTTP Strict Transport Security (HSTS) on encrypted domains like google.com, wireless gateways cannot intercept HTTPS traffic without triggering browser certificate warnings. Navigating to an unencrypted HTTP destination such as http://neverssl.com or http://1.1.1.1 sends a plaintext request that the gateway can safely intercept with an HTTP 302 redirect to the login splash page.

Why do Android devices show 'Sign into network' errors or fail the generate_204 probe?

Android devices query clients3.google.com/generate_204 and connectivitycheck.gstatic.com. If the wireless controller or walled garden blocks access to Google IP addresses without intercepting the HTTP request with a 302 redirect, Android detects a connection error or assumes an isolated intranet, suppressing the portal prompt. Whitelisting the required probe domains or ensuring transparent HTTP redirection resolves this.

How do you prevent HTTPS certificate warnings when intercepting captive portal traffic?

When a guest browser navigates to an HTTPS domain prior to login, intercepting the TLS handshake triggers severe browser security warnings (such as NET::ERR_CERT_COMMON_NAME_INVALID) due to HSTS and certificate mismatch. Enterprise networks prevent this by leaving HTTPS traffic undisturbed and relying exclusively on plaintext HTTP probe interception to trigger the operating system's native captive portal browser.

What causes RADIUS authentication timeouts during captive portal guest login?

RADIUS timeouts occur when the wireless access point or controller fails to receive a RADIUS Access-Accept packet from the authentication server within the timeout window (typically 5 seconds). Common causes include outbound UDP ports 1812 and 1813 being filtered by perimeter firewalls, mismatched RADIUS shared secrets, or asymmetric routing between the access point and the cloud RADIUS service.

How does RFC 8910 (Captive Portal API) resolve modern captive portal connection issues?

RFC 8910 standardizes captive portal discovery via DHCP Option 114 and IPv6 Router Advertisements. Rather than intercepting DNS queries or HTTP packets, the network directly advertises the captive portal API endpoint URL to connecting client devices. Modern operating systems query this API directly, eliminating HSTS certificate collisions, DNS hijacking latency, and CNA browser rendering bugs.

How does MAC address randomisation affect captive portal reconnection?

iOS 14+ and Android 10+ rotate private MAC addresses periodically or when re-associating with SSIDs. If a guest network tracks sessions solely by physical MAC address, returning visitors are forced to authenticate repeatedly. Enterprise platforms like Purple solve this by tying session authorisation to user identity tokens and Passpoint (Hotspot 2.0) profiles rather than transient hardware MACs.

How does Purple resolve captive portal redirect failures across multi-vendor networks?

Purple operates as a hardware-agnostic cloud overlay across Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Fortinet, and UniFi hardware. By automating walled garden configurations, managing trusted SSL redirect domains, and providing high-availability cloud RADIUS clusters with sub-second failover, Purple eliminates captive portal redirect drops and delivers reliable guest onboarding.

对您的具体配置有疑问吗?

我们的团队与 80,000 多个场所的运营方、IT 经理和网络工程师保持合作。预约 20 分钟的通话,我们将为您展示同行是如何解决类似问题的。