如何在酒店强制门户之后设置旅行路由器
先让场所授权，再启动隧道。检查客户端模式、DNS 以及下游设备实际拿到什么，而不是相信路由器的状态灯。
你打开旅行路由器的管理页面，第一反应往往是立刻启动 VPN。酒店网络另有打算：你的路由器是场所 Wi-Fi 的客户端，在这条上行链路获得授权之前，任何隧道都到不了任何地方。按顺序走完两个阶段，路由器就不再显得像坏了。
先确认路由器能同时胜任两件事
你需要一个上行客户端模式，通常叫作中继、客户端或 WISP，以及一个出站 VPN 客户端。这两项功能与 VPN 服务器不同，很多廉价路由器只有后者而没有前者。
在管理页面找到 WAN 或互联网一栏，把它切换到无线客户端模式。扫描场所的 SSID，加入进去，先让路由器拿到地址，再去配置别的。
既然打开了，就顺便确认固件版本。菜单名称会随版本变化，旧教程里的路径可能已经不存在，但功能仍在。把型号和版本记在旅行装备旁。当文档里的步骤与你眼前的界面对不上时，版本差异几乎总是原因。
其次，为上行连接授权
把笔记本接到路由器上，打开任意 HTTP 页面。门户应当发生跳转，之后按场所自己的流程操作。有些门户用手机比用没有屏幕的路由器更顺，所以从已连接的设备上做通常更快。
严格的 VPN 封锁会让这次引导变复杂。如果场所在授权之前就丢弃隧道流量，那么门户还没通过时路由器上的 VPN 客户端就会失败，这种失败是预期内的，而不是配置错误。
用受支持的方法绕过去。一次性拆掉多项控制，或者安装门户页面当作“修复”提供的证书，都是拿暂时的不便换取永久的问题。
第三，用它支持的配置文件启动 VPN
普通访问通了之后，再用路由器真正支持的配置文件启动 VPN 客户端。WireGuard 配置和 OpenVPN 配置文件不能互换，两者也都无法导入原生的 IPsec 字段。
信任它之前先查三件事：端点可达、解析器返回预期值、出口地址正是你以为的那个。只有出口检查能证明隧道真的在承载流量，而不只是被配置好了。
curl -sS https://ifconfig.me
cat /etc/resolv.conf如果路由器报告已连接，而出口地址仍是场所的地址，那隧道并没有承载你以为的流量。先把这一点修好，再把下游设备拉进画面。
第四，从下游设备测试
路由器的状态页描述的是它自己的连接。从本应被覆盖的笔记本上重新发一次请求，分别检查 IPv4、IPv6 和解析器，因为一台设备可能只被覆盖了一个地址族。
| Stage | What to verify | Where |
|---|---|---|
| Upstream join | Router has an address from the venue | Router WAN status |
| Portal authorization | A fresh request loads a public page | Connected laptop |
| Tunnel | Egress address changed | Router or laptop |
| Downstream coverage | Laptop resolves and reaches the private resource | Laptop |
如果路由器成功而笔记本失败，问题出在下游路径：NAT、DHCP，或者只覆盖路由器自身流量的隧道策略。先确认笔记本拿到了路由器地址池里的地址，再确认它的默认网关就是路由器。仍持有场所 DHCP 服务器租约的设备，完全处在错误的网络上。
第五，定好退路并保留登录方式
测试门户过期或隧道掉线时会发生什么。你选的策略必须覆盖被转发的流量，而不只是路由器自己发出的请求，否则下游设备会悄悄退回场所的连接。
把验证过的上行登录流程和路由器放在一起，写在纸上或记在本地笔记里。下一次入住时，重启就变成两分钟的事，而不是又一次临时搭建。路由器之外也要留一份副本，因为只存在设备里的笔记，恰恰在设备坏掉时用不上。这件事上纸面仍然更可靠。
然后写下让它跑通的四个值：上行模式、门户流程、VPN 配置类型和出口检查。这四项就是下次需要的，也是最难凭记忆还原的四项。