VPN 显示已连接，默认路由却已失效

客户端报告已连接，托盘图标看起来正常，却什么都加载不出来。它始于你从 Wi-Fi 换到网线之后，或者始于一次发行版升级刚刚结束之时。坏掉的不是配置，而是为上一个基础连接建立起来的状态。内核里仍有一条指向无人拥有的隧道设备的默认路由，或者解析器仍在列出一个已经消失的链路上的服务器。两种故障看起来都像网络已死，而两者都能就地修好。

这些残留在你察觉之前就已经错了。拔掉网线只是让它们显形。

问内核：一个数据包会走哪里

路由列表难读，因为它把系统知道的一切都列出来，包括已经不再生效的条目。路由查询回答唯一值得问的问题：此刻这个数据包由哪个设备承载。如果答案指向隧道设备，内核就会用它，即使后面没有任何存活的客户端进程，数据包随之落进没人维护的接口。如果答案指向以太网适配器，而客户端坚称自己连着，那就是隧道还在却丢了选中位，这也是从无线切到有线时的常见结果。

把这个查询跑两次，一次用公网地址，一次用内网地址，因为分离隧道的策略可能诚实地转发其中一个，却丢掉另一个。

ip route show default
ip route get 1.1.1.1
ip route get 10.20.30.40

解析器也留着那条死掉的链路

在运行 systemd-resolved 的主机上，DNS 服务器属于各个链路，而不属于一张全局列表。掉线的 VPN 链路可能还带着它的服务器注册一段时间，于是每次查询都在等一个永远不会应答的地址。那种等待像网络已死，于是人们跑去查路由，而路由其实没问题。

resolvectl status
resolvectl query intranet.example.com

逐链路读那些区块，确认该域名归哪条链路。隧道起来了却不是内网域名的所有者，就会把内网名字转给公网解析器，症状与路由故障无从区分。

要修的是注册，而不是 /etc/resolv.conf。在当前的 Ubuntu 和 Fedora 安装里，那个路径是指向解析器运行时状态的符号链接，所以改动要么被忽略，要么在下一个网络事件时被覆盖。

VPN 从不会自己启动

NetworkManager 把 VPN 架在基础连接之上，它从 connection.secondaries 上学会该跟随哪一条。 连接设置参考 明确指出自动连接并未对 VPN 配置实现。这就是这一类故障背后的全部机制：换掉基础连接，VPN 就得重新配对或手动重新启用。

nmcli device status
nmcli connection show --active
nmcli connection up office-vpn

当活动列表显示基础连接而没有 VPN 时，隧道根本未激活，路由是从未装上，而不是留成了旧的。当启用过程抱怨不存在源连接时，它与基础连接配对的那一端已经消失，所以先修基础连接或配对，别再反复重试 VPN。

升级可能静默丢掉设置

升级发行版会替换客户端，往往也替换它的 NetworkManager 插件，而保存的配置仍保留写入时的属性名。新插件不再认识的东西被悄悄跳过。配置照样激活，设备照样出现，但过去随它一起来的路由再也不来了。

手写的钩子同样会挪位。一个在旧时序里可预期时刻安装路由的脚本，现在可能在接口存在之前就运行，或者在客户端已经超时之后才运行。

拿实际持有的插件去比对线上配置，而不是拿你记得的行为去比。如果某个键已从文档中消失，就把工作移到分发器脚本或受支持的替代方案里，而不是把旧属性恢复回来。

三种状态，三种不同的修法

动手之前先判断自己在哪种状态，因为重启会毁掉证据，故障会在下一次网络变化时回来。

最后各做一次：一个公网地址查询、一个内网地址查询、一次名字查询。如果地址通而名字不通，剩下的故障是解析器里的域名作用域，路由表从来都不是问题。