为什么删除的 VPN 路由会在重连后回来

你手动删除的路由在下一次重连后又会回来，路由表看起来和之前一模一样。这不是路由错误：有东西从配置或从连接生命周期操作中重新创建了该条目。大多数运行手册只看到活动路由表就停下，所以删除看起来奏效一分钟，然后失败。找出所有者，在那里修改，并在重连时验证。

谁安装了这条路由

先从候选清单入手，而不是先修。VPN 配置文件可以自带路由，服务器可以在连接时推送路由，网络管理器配置文件可以声明路由，启动单元或脚本可以添加路由，而 IPsec 实现会为协商的流量选择器安装路由。策略路由规则也可能把流量完全重定向到另一张表。

时间线比翻配置更快地区分来源。接口一建立就出现的条目属于客户端；晚一秒出现的通常来自服务器推送；启动时已存在的属于已保存的配置。在连接、断开和重启前后记录路由表，规律会指出所有者。只有服务重启才回来的路由指向某个单元，而不是 VPN。

查看内核自己的视图，而不是已保存的文件。协议列显示每个条目由什么安装：

ip route show
ip route show table all
ip rule show

协议字段、metric 和表号能告诉你看到的是静态条目、内核创建的条目，还是守护进程添加的东西。规则列表很重要，因为一次查找可能完全离开主表，从而使那里的编辑对你正在排查的应用不可见。从左到右读这一行：目标、网关、设备、协议和 metric。

然后问内核实际会使用哪条路由。受保护地址比公网地址更适合探测：

ip route get 10.20.5.7

一旦知道所有者，修改就应该落在所有者身上。从客户端配置文件中删除路由，修正服务器上推送的路由，或者编辑网络管理器连接，而不是添加一条靠 metric 胜出的竞争性永久路由。两条互相打架的规则会造出一张以后没人能解释的表。

保留端点排除。把 VPN 服务器自己的公网地址经物理网关发送的主机路由，正是让外层隧道数据包持续流动的东西；删掉它，隧道就会试图承载自己。在拆分隧道配置中，本应绕过隧道的本地子网也需要同样的照顾。

重连，然后一次检查两个目标。受保护地址与被排除的端点回答的是不同问题：

ip route get 10.20.5.7
ip route get 198.51.100.20

前者应通过隧道接口解析，后者应通过物理网关解析。如果两者都走隧道，说明缺少排除；如果两者都不走，说明配置修改没有生效，你看到的所有者并不是你以为的那个。