VPN 显示已连接却什么都不走：两处该查的地方

一条隧道可以报告已连接，而没有任何东西能到达它，这两件事发生在不同的地方。一处是路由表，它可能仍把数据包发往一个无人拥有的设备。另一处是解析器，它可能仍在一个已经消失的链路上列出服务器。网络变更并没有破坏配置文件，而是让上一个连接所拥有的状态变成孤儿，修复方式取决于你实际在看这两处中的哪一处。

先问内核会用哪个设备

路由列表显示存在什么；路由查询显示将会发生什么。查询一个公网地址，并读出回答中的设备名，因为正是这一个字段决定了数据包是否发往有用的地方。当回答是一个隧道设备时，内核会把数据包交给它，即使该接口后面已经没有任何客户端进程在运行。当回答是物理网卡、而客户端仍声称已连接时，隧道是起来的，只不过不是被选中的路径。

第二种情况在网线取代无线之后很常见，它表现为 VPN 坏了。

ip route show default
ip route get 203.0.113.9

接着读默认路由条目，因为上一条基础连接添加的路由可能比链路变更活得更久，并挡在新路由前面。经由已下线设备的默认路由比没有默认路由更糟，因为内核仍然优先选它。注意每条条目旁的度量值，这个顺序比接口名更快地解释优先级。

再看每个链路的解析器，而不是看文件

域名解析有它自己的状态，也有它自己的过期。按链路列出 DNS 服务器的解析器会保留一条已下线但仍注册着的隧道链路的服务器，于是每次查询都在等待一个不会应答的服务器。症状是网络像死了一样，而路由表看起来完美无缺。

要看的是每链路的状态而不是文件，因为在许多发行版里那个文件只是指向解析器的符号链接，编辑它要么无效，要么很快被覆盖。看清楚哪条链路拥有哪些服务器和哪个搜索域，然后问这条隧道链路究竟还应不应该处于注册状态。如果不应该，就停用拥有它的那个连接，而不是手工修改生成出来的状态。名字能解析、而路由查询把数据包送到别处，这是第三类、独立的故障。

resolvectl status
resolvectl query app.internal.example

如果地址能解析而连接失败，解析器没问题，是路由的问题。如果地址完全解析不出来，这里才是该开始查的地方。

过期的路由如何熬过一次变更

客户端并不独自拥有网络。在 NetworkManager 主机上，VPN 配置文件是激活在一个基础连接之上的，连接设置允许这个基础连接指定应当跟随它的 VPN。当基础连接因为另一个配置文件更受青睐而变化时，隧道要么跟到新的基础上，要么就没有基础。

VPN 配置文件不会自己起来，所以这段配对关系远比配置文件自身的自动连接偏好重要。

读活动列表，在动隧道之前先记下哪个基础连接是起来的。如果基础连接在列表里而隧道不在，那是路由缺失而不是过期，修法是激活。如果激活隧道时报错说没有源连接，说明与它配对的基础连接已经没了，那就先把基础连接起来，或者修好这段配对，而不是反复重试隧道。对一个父级不存在的配置文件反复重试，每次都会得到同样的错误，这是有用的信号，不是麻烦。

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

把过期状态和父级缺失区分开

三种状态几乎能解释所有报告，而每一种需要不同的修法。经由仍然存在但已不再承载隧道的设备的默认路由属于过期状态，清除方式是删除该条目，或者重启负责它的配置文件。客户端进程已经消失的隧道设备属于清理失败，所以该关注的是断开连接的路径，而不是路由表。完全没有隧道设备意味着父连接或配对关系缺失，路由表从来就没参与。

重启会掩盖你当时是三种中的哪一种，这正是它感觉像修好的原因。

修完之后，向内核要一个公网地址和一个内网地址，再查询一个内网名字。当地址通了而名字不通，你找到的是解析器里的域范围问题，不是路由问题。记下你发现的是哪种状态，因为下一次网络变更会把你没管的那一种再演一遍。