分流隧道的文档应在每条路由旁写清 DNS 规则

"办公流量走 VPN"这类分流笔记只写清了一个决策，却暗示了另外三个。在数据包层面，路由表按目的地址选择接口；在名称层面，解析器按查询选择服务器，而这两个选择是各自独立做出的。正因如此，一个记录正确的网段仍可能让机器把内部名称解析成公网地址，或者在路由看起来完美时什么也解析不出来。

两个选择器，一次连接尝试

当应用连接files.corp.example时，在数据包出现之前会发生两次查询。解析器借助搜索域、按链路的选路域或显式的配置文件规则，决定由哪台服务器接收查询。随后路由表按最长前缀匹配，决定得到的地址走哪里。

这两个决策之间没有任何联系。私有区可能用10.20.4.11作答，而路由表把10.20.0.0/16送进隧道，连接就能工作。反过来，任一环节出错都会表现为另一环节的症状：DNS 策略正确但缺少路由，会得到已解析的名称和超时；路由正确却使用公网解析器，地址会干净地路由到错误的地方。

分离视界 DNS 让这一点更尖锐。同一个名称可能从内部解析器返回私有地址，而从面向互联网的解析器返回公网地址，因此只记录网段的笔记无法预测客户端实际会用哪个地址。写清解析器路径，否则地址只是猜测。

只写路由的笔记漏掉了什么

只写路由的记录无法应对分流隧道最常见的故障：名称。用户报告内网打不开，隧道在运行，网段也存在。接手工单的人不知道本应由哪个解析器应答，无法区分错误的搜索后缀和被拦截的服务器，也没有基线可以比较。

第二个遗漏是例外清单。分流设计既由留在隧道之外的部分定义，也由进入隧道的部分定义；被排除的网段往往最先出问题，因为更具体的本地路由或客户端侧过滤器可以在不改动配置的情况下覆盖设计意图。

第三个是隧道的远端。客户端路由只是把数据包放到线路上；网关仍然必须转发它，并且要有回程路径。strongSwan 的转发指南提醒我们，网关上的转发和防火墙规则属于功能本身，而不是可以想当然的基础设施。

让笔记可执行的字段

每条流一行，而一条流就是目的地址、名称加负责人。以下这些字段能经受真实事件的检验：

"规则住在哪里"这一行恰恰是大家会跳过的。服务器下发的网段、客户端配置添加的路由，以及手工在 shell 里输入的路由，差别在于谁能修改它们，以及重连后它们是否还在。没有这个字段，下一位工程师分不清自己看的是三者中的哪一个。

每条规则一条测试，而不是每条隧道一条

每一行都需要两项无害的检查：一项验证路由，一项验证名称。路由方面，请求一个必须穿过隧道的东西，并确认路径而不是可达性，例如tracert -d 10.20.4.11（Windows）或ip route get 10.20.4.11（Linux）。名称方面，查询内部名称并记录哪台服务器应答，使用笔记中写明的解析器，配合resolvectl query files.corp.example或dig files.corp.example。

还要加入一个负向预期：隧道断开时应该发生什么。在启用了"无 VPN 时阻断"的 Android 或 iOS 设备上，被排除的应用可能完全无法联网；桌面客户端则可能在隧道重连期间让同一个应用继续工作。把预期答案记下来，"VPN 把我的应用弄坏了"就变成一句可核查的话。

让记录与配置放在一起

把笔记存放在它所描述的配置旁边，并随该配置一起做版本管理。没人更新的 wiki 文档只是传闻；与被下发的路由和解析器策略放在同一仓库里的表格，可以在同一次变更中一起审阅。

出问题时，先对照记录比较实际生效的路由和解析器，再添加新的例外。三个常见原因中有两个——过时的命名空间规则和应用策略之外的辅助进程——看起来和 VPN 故障一模一样，如果笔记只列网段，它们根本不会显现。

在宣布笔记完成之前，请确认它以书面形式回答了这些问题：哪个网段、属于哪个地址族；哪个私有命名空间、由哪个解析器应答；哪些名称有意保持公网解析；每条规则配置在哪里、由谁负责；以及证明路由的那一条命令和证明名称的那一条命令。只要缺少其中任何一项，下一次故障就得从零开始排查。