一台设备的公共 Wi-Fi：为什么 VPN 出口帮不上忙

笔记本电脑显示已连接，握手成功，而门户仍然拒绝在第二台设备上加载页面。这不是隧道问题。热点的设备上限属于它的接入系统，该系统统计的是已授权的设备和已释放的会话。VPN 改变的是授权之后流量从何处出去，对那套系统接纳多少设备毫无影响。

门户究竟在统计什么

强制门户跟踪的是一份授权配额，而配额通常绑定在网络能够识别的东西上。MAC 地址是常见选择，浏览器里的会话 cookie 是另一种，有些系统还会把其中任一与房间号或打印凭条结合起来。一个房间码上有四台设备就意味着四份授权，第五台则一份也没有，无论它运行什么软件。在那第五台设备上安装 VPN，只会让答案从被拒绝变成被拒绝。

关联与授权是两种状态。笔记本可以关联上接入点、持有 DHCP 租约，却依旧没有互联网，因为门户从未授予任何东西。把 Wi-Fi 图标读成门户成功的证据，是这一类工单里的第一个错误。

向场地确认规则

不要猜，问两个问题：账户允许几台设备，过期会话如何释放。第二个更重要，因为离开的设备遗留的授权通常正是挡住下一台的原因。前台往往能比任何客户端侧的办法更快地释放它或签发新码。在更改硬件地址之前先走这个流程，因为复制另一台设备的标识符违反网络条款，还会在网段上留下重复身份。

行为因运营商而异。有的系统绑定设备指纹，有的绑定浏览器会话，还有少数允许固定数量的并发授权并按计时器过期。一个场地的政策完全无法预测下一家，所以场地的答复胜过任何通则。

把门户凭据和 VPN 凭据分开

房间码不是网关登录，即便两个界面都显示用户名字段和密码字段，在门户里复用工作凭据也是笔坏交易。先授权目标设备，在场地允许的地方验证一个小而普通的请求，然后才连接隧道。这个顺序在出问题时会给出干净的归因，因为在 VPN 介入之前，门户这一环节已经得到验证。

门户拒绝时，隧道并不是该调试的地方。VPN 配置里没有任何东西能给出接入系统从未签发的授权。

旅行路由器改变了什么

旅行路由器可以帮忙：它向上游呈现为一台设备，在本地服务多台，并改变门户看到的东西。授权绑定的是路由器的标识符而不是每台笔记本，其后的每个客户端共享一份授权和一个公网地址。这种安排是否可接受取决于网络条款，许多场地明令禁止共享。无论技术优劣，在允许共享的地方路由器是正当设计，在不允许的地方就是违规。

这些都消除不了上限。它只是把唯一那份授权从笔记本挪到路由器上，对带着多台设备的单个旅行者有用，对各自都需要授权的两个人则毫无用处。

先解决本地的授权问题。即便隧道运行得完美，也造不出接入系统从未签发的授权。