公共 Wi-Fi 与 VPN：隧道没有覆盖的部分

绿色徽章、顺利通过的入口页面、正常工作的浏览器：这就是全部可见的故事。徽章略去的是，加密连接恰恰由它本应保护你免受其害的那条无线链路承载。那条链路仍然投递每一个数据包，仍然看得到目的地址，也仍然决定是否有任何东西抵达。走一遍酒店连接的笔记本这一侧，就能看出隧道覆盖了哪些部分、又留下了哪些部分给你。

接入链路承载一切

IPsec ESP 隧道把受保护的内层数据包封装在网络可路由的外层报头里，RFC 4303 第 3.1.2 节说明了这种划分。内层数据包是隧道保护的东西。外层报头是热点为了转发而读取的东西。其他设计封装方式不同，但规划问题完全相同：这条连接由哪条接入路径承载？

网关故障或丢包的链路会在不暴露内容的情况下中断投递。改用更强的密码对此毫无帮助，因为缺失的一环是传输，而不是密码学。成功投递在反方向上同样证明不了什么，因为一条能用的路径对两台机器的状态都只字不提。

你的笔记本仍然有自己的门

加入不受信任的网段会改变谁能触达你机器上监听的端口。文件共享服务、远程管理代理，或绑定到所有接口的开发服务器，除非有东西挡住，否则该网段上的任何人都能访问。从不进入隧道的流量不受它保护。在隧道建立之前就作出应答的监听者，恰好在那段时间里暴露。

要求很窄，值得准确表述：笔记本必须能到达 VPN 端点，而热点上无关的设备不得访问本地服务。主机防火墙规则表达的就是这条边界，平台自带的共享设置也表达了其中一部分。打印机或入口页面的某一步，是你刻意加入的限定例外，并不能证明整个热点都值得办公室局域网那样的信任。

有些组织在办公连接处于活动状态时还会限制本地访问，这属于制度而非工程。在为让某个外设工作而关闭防火墙之前，先读一读这项制度。

检查实际在监听什么

看套接字，而不是设置页面，因为页面描述的是意图，套接字表描述的才是这台机器。下面两条命令把每个监听套接字与邻居可能触达的套接字区分开来。在连接隧道之前，先在这个不受信任的网段上运行它们。

ss -lntu
ss -lntup | grep -v 127.0.0.1
resolvectl query vpn.example.net

第一条命令显示所有套接字，第二条筛选出绑定在回环之外的套接字。0.0.0.0 或 :: 上的服务在包括无线在内的每个接口上可用，而 127.0.0.1 上的同一服务根本无法从该网段访问。解析器查询确认了隧道建立之前域名走哪条路径，而圈禁门户正是在那里干扰。连接之后要重跑一遍列表，因为某些客户端会拉起改变结果的接口。

只在隧道在线时出现的端口暴露较少，但仍然值得了解。记录差异而不是绝对列表，因为增量才是隧道新增的部分。

不要在会话中途接受新身份

意外的路由变化、重连或门户重定向，都不是接受另一个服务器身份的许可。如果客户端报告证书或密钥不匹配，应把它当作身份方面的发现，而不是需要绕开的连接问题。为了让门户可用而安装来路不明的根证书，会把投递问题变成信任问题。而信任问题会比造成它的那次出行活得更久。

先用门户自带的浏览器流程，然后重新连接隧道，并在客户端日志中读取它验证过的身份。身份失败意味着对方不是你以为的那一方，而投递失败意味着对方从未应答。前者是停下的理由，后者是换一条路径的理由。

先决定断网时的行为

这里容易混淆两个不同的特性。重连试图恢复服务，而阻断策略控制隧道断开期间允许哪些流量。两者都不能提供可用的无线链路，也都不能证明端点干净。明确选择：对绝不能使用本地路径的应用采用关闭式失败；如果可以接受，就允许在隧道之外进行普通浏览。

把选择写下来，因为多数客户端的默认值两者都不是，而且随版本而异。然后，如果可用性重要，就另备一条接入路径，比如带独立数据套餐的手机热点。可以接受的验收测试有三个彼此独立的结果：预期流量走已验证的隧道，无关的本地监听端口不可达，断网时产生你所选择的行为。