为什么酒店式宾客 WiFi 在住宅建筑中会失效

酒店式的宾客 WiFi 在住宅楼中之所以失败，是因为它默认了短暂的停留、一部手机和一家浏览器。一间精装修公寓可能拥有 10 台或更多联网设备，其中许多设备没有用于完成 Captive Portal 认证的浏览器，而居民期望投屏和智能家居套件能够正常工作。相反，您应该为每个家庭提供专属的 iPSK 密钥和私有网络段。

住宅楼中的宾客 WiFi 故障表现如何？

故障很少表现为网络完全瘫痪。它往往表现为源源不断的来自付租金（而非短暂停留）居民的日常抱怨。

在联合青年公寓（BTR）、学生公寓或多住户单元（MDU）中典型的症状包括：

• 智能电视、音箱或温控器无法接入。 这些设备没有浏览器，因此无法完成 Captive Portal（即宾客网络在允许接入前显示的网页登录页面）认证。
• 投屏失败。 居民的手机找不到自己的 Chromecast 或 AirPlay 接收器，或者直接找到了邻居的接收器。
• 每个人每天都需要重新登录。 门户会话在 24 小时定时器到期后失效，这适合酒店宾客，但会让住在那里的居民感到厌烦。
• 软件更新后设备掉线。 轮换其硬件地址的手机看起来就像新设备，因此网络会忘记它们。
• 搬走后依然留有访问权限。 前居民的笔记本电脑在租约结束数周后仍能连接。

如果您经营 酒店 并正在向服务式或长租公寓拓展业务，您首先会在长租楼层遇到这些症状。

为什么酒店式宾客 WiFi 对居民不起作用？

酒店宾客 WiFi 背后的四个设计假设一旦有人入住就无法再成立。

设备数量不同

酒店宾客网络是围绕入住一两晚的一部手机和一台笔记本电脑构建的。相反，数一数一居室公寓中的设备：两部手机、两台笔记本电脑、一台智能电视、一个流媒体棒、一个音箱、一个可视门铃、一个温控器和一台打印机。在有人来访之前，设备数量就已达到 10 台。其中每一台都需要连接，而且大多数设备都没有可以输入文字的屏幕。

无头设备无法使用 Captive Portal

Captive Portal 的工作原理是拦截浏览器请求并显示登录页面。智能音箱永远不会打开浏览器，因此它永远看不到页面，也永远无法完成身份验证。通常的解决方法是 MAC 地址注册，即居民将每个设备的硬件地址输入到表单中。但这同样会失效。

MAC 随机化破坏了设备记忆功能

Apple 在 iOS 14 中引入了针对每个网络的私有地址，而 Android 10 默认会随机化硬件地址。通过 MAC 地址记住设备的门户网站在地址更改时就会丢失这些设备。居民需要重新进行身份验证，您的服务台就会接到求助电话。

客户端隔离阻碍了家庭网络体验

访客网络通常会隔离客户端，以防止陌生人访问彼此的设备。这在酒店大堂是完全正确的。但 Chromecast 和 AirPlay 是通过多播 DNS（mDNS，定义在 RFC 6762）来寻找接收端的，这是一种仅在同一网络段内的设备之间起作用的发现协议。启用隔离后，投屏就会失败。如果在一个共享网络上关闭隔离，每个住户就都能看到其他所有住户的设备。

短期逗留信任是错误的信任模型

酒店 WiFi 信任一个设备仅限一次入住期间，随后便会遗忘。住户 WiFi 则必须在租期内（有时长达数年）信任一个家庭的设备。它还必须在特定日期撤销该信任。Portal 门户会话定时器无法表达这两种规则。

如何确定您遇到了哪种原因？

在做出任何更改之前，请将投诉与原因进行匹配。大多数建筑都会遇到不止一种原因。

住户报告的症状	最可能的原因	如何确认
智能电视或音箱无法连接	无浏览器设备上的 Captive Portal	在控制器日志中检查设备是否曾访问过门户页面
手机找不到自己的 Chromecast	客户端隔离阻断了 mDNS	在单个测试 SSID 上禁用隔离并测试投屏
住户在投屏时看到邻居的设备	共享扁平网络且关闭了隔离	从住户设备扫描 mDNS 广播
每个设备每天都需要重新登录	专为短期逗留设计的门户会话超时	读取访客 SSID 上的会话超时设置
手机更新后设备被“遗忘”	针对基于 MAC 记忆的 MAC 随机化	对比更新前后设备的硬件地址
前住户仍能连接	租约结束与网络访问之间没有关联	对照当前的租约记录审核活跃的凭证

如果前两行描述了您大楼的情况，那么修复会话超时将无济于事。您需要一种不同的认证模型，而不是一个经过微调的门户。

哪种认证模型适合住户？

下表对比了大楼实际运行的四种选择。

方案	准入引导	无浏览器设备	投屏与智能家居	撤销单个家庭	最适合
Captive Portal（酒店模式）	每个设备上通过浏览器登录，超时后重复登录	无法连接，除非进行手动 MAC 注册	被客户端隔离阻断	等待会话过期	酒店访客、购物者、粉丝、乘客
每栋大楼一个共享密码	所有人使用同一个密码	连接	正常工作，但每个住户都能看到所有设备	更改整栋大楼的密码	无多租户大楼
每个家庭一个 iPSK	每个公寓一个独一无二的密码	连接	仅在家庭网段内部正常工作	删除单个密钥	联合租赁（BTR）、学生公寓、多住户单元（MDU）、长期住宿

iPSK（身份预共享密钥）运行单个 WPA2-Personal 网络，每个住户拥有自己的密码。当设备加入时，RADIUS 服务器（一种验证凭证的认证服务）会识别其使用了哪个密钥。然后，网络将该设备放入该住户的 VLAN（虚拟网络段）中。住户拥有的每台设备（无论是否配备屏幕）只需使用其已知密码加入一次即可。

其结果是为每户公寓提供了一个私有的网络气泡。住户的手机能够找到他们自己的 Chromecast，因为两者处于同一个网段。它无法看到隔壁邻居，因为那户人家持有不同的密钥并处于不同的网段。

IEEE 802.1X 对个人的安全性更强，但大多数智能电视、音箱和恒温器无法使用它。请将其保留用于员工网络。

如何在 Cisco Meraki、HPE Aruba、Ruckus 和其他硬件上进行修复？

您不需要新的接入点。每个主要厂商都以其自己的名称支持单密钥认证：

• Cisco Meraki: Identity PSK (iPSK)
• HPE Aruba: MPSK (Multiple Pre-Shared Key)
• Ruckus: DPSK (Dynamic Pre-Shared Key)
• Juniper Mist: Multi PSK
• Ubiquiti UniFi: Private Pre-Shared Keys
• Cambium: ePSK
• Extreme: PPSK (Private Pre-Shared Key)
• Fortinet: MPSK

在切换之前，请检查您厂商文档中的两件事。首先，确认您的控制器版本上每个 SSID 支持的最大密钥数量。其次，确认 WPA3-Personal 是否支持单密钥认证，因为许多部署仍运行在 WPA2-Personal 上。

Purple 的多租户 WiFi 作为云覆盖层运行在这些硬件之上，因此无需推倒重来。Purple 提供将每个密钥映射到其对应住户的云 RADIUS 服务。您可以通过单一窗口管理每栋建筑的密钥。Purple 持有 ISO 27001 认证并符合 GDPR，该平台已在 80,000 多个活跃场所运行（数据源自 Purple 自身数据）。

请保留您的访客网络供访客使用。Purple 的 Guest WiFi 会为每位连接的访客创建一条 WiFi Visitors 记录。根据 Purple 的 WiFi Visitors 支持文章，该记录保存了访问过的场所、访问次数和连接方式。这适用于大堂或一楼咖啡厅，而不适用于住户的家庭连接。

操作场景：酒店新增长期住宿楼层

情况： 一家拥有 180 间客房的城市酒店将其中一层改造成 40 间服务式公寓，供入住一至六个月的客人使用。长期住宿客人使用的是现有的访客 SSID，该 SSID 具有 Captive Portal、客户端隔离和 24 小时会话超时限制。

所做的调整：酒店保留了适用于短期住宿客房和大堂的 Portal SSID。并在长期住宿楼层增加了一个 iPSK SSID，包含 40 个密钥，每个密钥映射到其专属的 VLAN。密钥在办理入住时发放，在退房时删除。

成效：每位长住客人的登录次数从每周七次减少到入住时的一次。智能电视和投屏设备在首次尝试时就成功连接，因为它们不再遇到 Portal 页面。退房时，只需删除一个密钥，即可移除该公寓连接的所有设备。

实践案例：大学宿舍取代 MAC 注册

背景：一所公立大学拥有一个 600 张床位的宿舍楼，过去使用 Captive Portal 进行网络准入。学生需要将每个游戏机和智能音箱的 MAC 地址手动输入到网页表单中进行注册。手机上的随机 MAC 地址意味着每学期都需要重新注册。

所做的调整：IT 部门在现有的接入点上，为每个学生宿舍发放了一个 iPSK 密钥。每个学生在分配宿舍时都会收到自己的密钥。密钥与住宿合同的截止日期绑定。

成效：手动 MAC 注册降至零，因为游戏机和音箱现在可以通过密码直接加入。在学年结束时，IT 部门一键注销了所有 600 个密钥，而无需逐个清理单个设备记录。

如何防止此类问题再次发生？

围绕租约而非访客来设计居民网络。

1. 按受众隔离网络：为访客运行带 Portal 的 Guest SSID，为居民运行 iPSK SSID。保持较低的 SSID 数量，因为每个额外的 SSID 都会增加信标流量并占用空口时间。
2. 将密钥与人员入职、变动和离职进行绑定：在入住时发放密钥，在居民搬迁房间时重新分配，并在租约结束时注销。Purple 的多租户 WiFi 可以集中管理这一生命周期。
3. 按公寓而非按人头规划容量：根据每个单元的完整设备数量（包括傍晚高峰时段的流媒体播放需求）来规划每个单元的网络容量。
4. 保持数据模型独立：Guest WiFi 的存在部分是为了通过用户自主选择加入来构建第一方数据。居民 WiFi 是您在租约下提供的一项服务，因此不要对其进行营销数据收集。如果您想了解共享空间的使用情况，请阅读《存在分析与互动分析对比》。如果您使用的是 HPE Aruba 设备，请阅读《HPE Aruba Central 存在分析：设置、导出和限制》。
5. 在混合用途场所应用相同的模式：一栋在一楼设有 零售 商铺或在 医疗保健 园区内设有员工宿舍的建筑，需要为公众提供 Portal，并为居住在此的人员提供 iPSK。

常见问题解答

我可以为居民使用 captive portal 吗？

不行，不能作为主要的住户网络。Captive Portal需要每个设备上都有浏览器，而智能电视、音箱和温控器并没有浏览器。Portal还会使会话过期，并遗忘硬件地址轮换的设备。请将Portal留给访客和短暂停留的客人。为住户提供每个家庭专属的iPSK密钥，以便每个设备只需连接一次，并在租期内保持连接状态。

iPSK能否在我现有的接入点上运行？

可以，前提是您运行的是主流厂商的最新控制器。Cisco Meraki、HPE Aruba、Ruckus、Juniper Mist、Ubiquiti UniFi、Cambium、Extreme Networks和Fortinet都以各自的功能名称支持单密钥认证。请查看您厂商的文档，了解您控制器版本上每个SSID支持的最大密钥数量。Purple在这些硬件上作为云端覆盖层运行，因此您无需更换接入点即可将住户迁移到iPSK。

访客WiFi和住户WiFi可以在相同的接入点上运行吗？

可以。在相同的接入点上将它们作为独立的SSID运行，每个SSID映射到各自的VLAN。访客看到带有Captive Portal的访客网络，而住户则使用其家庭密钥加入iPSK网络。请保持总SSID数量处于较低水平，因为每个新增的SSID都会增加信标流量，从而消耗广播该SSID的每个接入点上的空口时间。

住户搬走后，他们的设备会怎么样？

您只需撤销他们的密钥，使用该密钥的每个设备就会失去访问权限。因为每个家庭都拥有自己的密码，所以一次删除即可同时移除手机、笔记本电脑、电视和音箱，而不会影响任何其他住户。将密钥撤销与租期结束日期绑定，这样访问权限就会在合同到期当天结束，而不是等到有人想起去修改密码时才结束。

iPSK和802.1X一样安全吗？

不，但它是适合住宅设备的控制方式。IEEE 802.1X为每个人提供单独的凭据，这适合员工笔记本电脑。大多数智能电视和音箱无法使用它，因此它在公寓中无法发挥作用。iPSK为每个家庭提供一个唯一的密钥，并将其隔离在自己的VLAN中，因此密钥泄露只会暴露一间公寓，而不是整栋大楼。对员工使用802.1X，对住户使用iPSK。

GDPR如何以不同的方式适用于住户WiFi？

根据UK GDPR，住户的连接是您根据租约提供的一项服务，因此合法依据很可能是第6(1)(b)条下的合同，而不是营销同意。访客WiFi通常通过选择加入来收集营销数据。请将两者分开：不要在住户网络上运行营销数据捕获。Purple已通过ISO 27001认证并符合GDPR规范，并在此基础上处理住户网络数据。

从Portal迁移到iPSK需要付出多少精力？

这是一项配置更改，而不是硬件项目。您只需在现有的控制器上创建一个 iPSK SSID，将其连接到诸如 Purple 的云 RADIUS 等 RADIUS 服务，并将密钥映射到住户 VLAN。更重要的任务在于运营层面：在入住时分发密钥，并将注销操作与租期结束日期相关联。在过渡期间同时运行门户和 iPSK 网络，确保没有居民失去网络连接。