为什么只加 route-nopull 会让文件服务器失联
忽略下推的路由只是分流隧道的一半。先确定路由归属，再手动补上办公网段，并测试三条路径后再判定问题已修复。
文件服务器打开正常，而旁边窗口的视频通话开始卡顿。没有任何东西变慢，也没有 MTU 出错：客户端接受了服务器下发的路由表，于是所有数据包都改从办公室防火墙出去。修复不是再加一个调优开关，而是决定客户端路由表归谁管。这个决定只应属于一处，下面的失效方式会告诉你实际选了哪一处。
先确定路由表归谁管
可能有三种归属。服务器可以下推路由和默认网关，此时客户端照单全收，成为全局隧道。客户端配置文件也可以接管，即丢弃下推内容并自带路由行。桌面连接管理器同样可以凭借自己的路由和默认路由属性拥有这个决定。
每种选择失败的方式都不同，所以改动配置前值得先读一遍这张表。与你症状相符的那一行，才是你真正的归属。
| Owner | Where it lives | Result |
|---|---|---|
| Server | server config, redirect-gateway, pushed routes | client becomes a full tunnel |
| Profile | route-nopull and its own route lines | tunnel up, office prefix missing |
| Manager | never-default plus its own routes | desktop decides, profile ignored |
选一种并写下来。混用两种会留下一台默认路径与自身文档互相矛盾的主机，下一位工程师看不出哪一层生效。要明确删掉落败的那一种。
route-nopull 只过滤下推，不新增路由
route-nopull 属于客户端配置文件，它在该文件中的位置无关紧要，因为它只丢弃来自服务器的取值。它会丢弃下推的路由，包括下推的默认路由，而隧道仍能正常建立。
人们常忽略的后果是，下推的 DHCP 选项也一并消失。服务器发送的 DNS 设置同样被丢弃，于是即便隧道健康、服务器用地址可达，内部域名也解析不了。
这样一来，除非你自己补一条，隧道就没有通往办公网段的路径：在同一份配置里先写 route-nopull，再写 route 10.30.0.0 255.255.0.0。那一行 只携带地址和掩码，并不指定下一跳。
另一种写法会附加网关标记 route 10.30.0.0 255.255.0.0 vpn_gateway，按名称把该条指向隧道。各家导入工具是否会转换这一变体并不一致，所以如果内核路由表里没有这条记录，请检查已保存的连接。
用路由查询验证，而不是用 ping
ping 只能告诉你有人回应。路由查询才会告诉你内核会选哪个接口，而这正是你真正想问的问题。四条短命令就能区分“路由缺失”和“路由指错了设备”。
用 ip route show dev tun0 读取隧道安装了哪些路由。完全没有输出意味着零条路由，这不是可用的分流隧道，也正是只加过滤器却不写显式路由时的常见结果。
接着用 ip route get 10.30.5.7 查一个办公地址，用 ip route get 1.1.1.1 查一个普通公网地址。后者应当指向物理接口；如果它指向隧道，说明下推的路由根本没被过滤。
最后读一下 ip rule，因为上一次尝试遗留的策略规则可能盖过你刚修好的路由表。配置正确但上面压着一条过期规则，看起来和配置损坏一模一样。在新增规则之前，先删掉上次加的那一条。
网段重叠看起来像隧道坏了
两个私有网段从客户端看可能完全相同，分流隧道常在这里替别的问题背锅。如果办公室下发的网段和你家路由器用的是同一段，隧道路由就会覆盖路由器，家里网络看起来像消失了。
在改动任何东西之前，先用普通的地址列表把自己接口上的地址与配置安装的路由对照一遍。重叠是真实存在的，任何配置选项都解决不了。你能修的是命名，让下一个人看到的是两个网段而不是一个。
诚实的做法是给一侧重新编址，或者在办公室做地址转换。把单条主机路由钉在路由器上，只在路由器地址不变时有效，一旦变了就会变成压在前一个谜题上的第二个谜题。
让这个决定在重连后依然成立
手敲进去的条目熬不过一次重连，而连接管理器每次启动配置都会重建路由表。把决定放在建立连接的地方，无论是配置文件还是管理器里保存的设置。然后有意重启一次连接，而不是等通话中途才发现行为。只撑到下次重连的配置不算做完。
同时演练三条路径：用字面地址访问办公主机、用域名访问同一台主机、再访问一个普通公网站点。中间那条依赖你丢弃下推 DNS 选项后配置的域名服务，而它恰恰是最容易静默失败的一条。