完整隧道比一长串拆分隧道规则更简单吗？

拆分隧道清单往往从三个应用开始，最后却覆盖了整台机器的大半，而每一行新增都是某个人的例外。到那一步，清单已经悄悄变成了带额外步骤的默认设置。完整隧道把格局倒过来：除非有书面记录的排除，否则一切都进入隧道。这算不算更简单，取决于网关，也取决于你会破坏的本地服务。

先数一数你在维护的规则

数清条目，再数清其中有多少条写明了负责人、以及上次验证的日期。第二个数字才是关键，因为一条没人负责的例外，在它所指的软件改名或被替换时根本无法评估。绑定到可执行文件路径的规则会在更新后静默失效，而这种失效看起来像 VPN 不稳定，而不是规则过期。先把清单写下来，再对它形成看法。

每条规则都该回答三个问题：没有它会坏什么、是谁决定的、以及如果理由失效你要多久才能发现。三个问题都答不上的条目，更适合删除而不是迁移；先删掉它们，后面的比较才诚实。

如果多数条目都在分流大部分流量，那你其实已经在跑一条带着维护负担的完整隧道。此时要决定的是默认设置放在哪里，而不是要不要有默认设置。

看看网关是否扛得住这个默认

完整隧道把所有数据包都送到同一台设备，这会同时改变该设备的 CPU 负载、conntrack 表、地址转换和上行带宽需求。一台曾经轻松服务几个内网子网的网关，未必按一个用户的全部浏览行为来配置。看你能预期的最大并发会话数，而不是平均值，因为峰值总是先撑不住。

ip -s link show dev tun0
conntrack -C
ss -s

与其根据规格推理，不如在改动前后测量同样的工作负载。在一台机器上用一个下午的日常使用，就能看出网关是否接近上限；相比周一早上才发现，这几乎不花什么代价。

还要端到端检查路径 MTU，因为完整默认会把每个应用都暴露在隧道的最大包长之下。原本在隧道外正常工作的应用，现在可能依赖你从未考虑过的分片行为。

确认本地服务与私有 DNS 仍然可用

按协议而不是按应用名来列出必须留在本地的东西：打印机和显示器的发现协议、智能家居桥接、路由器的管理页面、只能通过局域网内解析的名字访问的本地开发服务器。当默认路由开始指向隧道时，这些都会坏，而且是悄悄坏掉，因为客户端上没有任何错误记录。

私有 DNS 是另一项依赖。如果内网名字过去由隧道的解析器负责，那就没有变化；如果它们原本在本地解析，完整默认就必须把它们带到认识这些区域的解析器。改动后各测一个内网名字和一个公网名字，而不要假设解析器列表还完好。

把本地例外写进拥有它们的配置里。只存在于某人记忆中的例外，是下一次迁移最先丢掉的东西。

迁移一个配置并验证边界

通过拥有该配置的设置来修改它，而不是在早期实验留下的手工路由上再叠一层新的默认。这些残留路由正是迁移看起来能用、一天后又表现不一致的常见原因。保留旧配置可用，这样回滚是一次选择，而不是重建。

然后分别验证两条边界：公网和私网目的地都能用，以及不希望走的流量没有跑到隧道之外。一次成功的页面加载只能证明前者，对后者一无所知。

ip route get 203.0.113.10
ip route get 10.40.8.15
resolvectl query intranet.example
curl -sS -o /dev/null -w "%{remote_ip}\n" https://example.com

重连之后和断网之后再重复检查一次，因为丢线时阻断流量的 kill switch，与之后能正确恢复的路由是两种不同的属性。更简单的设计，是那种在应用或网络变化之后你仍然能解释清楚实际覆盖范围的设计。