导入的 VPN 路由与正常客户端不一致？对比两者

某些私有服务能通过 VPN 得到应答，而普通互联网流量的表现却和同事的机器完全不同，于是人们很容易断定 Ubuntu 客户端坏了。这个结论跳过了一步。私有操作正常和公共路径不同是两个观察结果，差异通常存在于各客户端安装的流量策略中，而不是客户端本身。

把已保存的配置与实际网络状态做对比只需要三条命令，却能回答猜测想要回答的问题。

先看已保存的配置文件，再看实际状态

导入的 OpenVPN 连接会成为独立的 NetworkManager 配置文件。导入完成的那一刻，来源 .ovpn 文件就不再是事实来源，所以之后再编辑该文件不会改变你正在使用的连接。这是对比最先出错的地方，而且出错时毫无提示。

nmcli -f connection.id,connection.uuid,ipv4.never-default,ipv4.routes,ipv4.dns connection show office-vpn

名称冲突时要读取 UUID；重名会在重装和配置文件恢复后保留下来，你可能花一小时去编辑那份并未在用的副本。你看到的值描述的是已保存的意图：配置文件是否可以接管默认路由、保存了哪些路由、请求哪些解析器和搜索域。它们并不描述连接激活时发生了什么，因为插件或服务器推送可能添加配置文件未提及的状态。这就是下一条命令重要的原因。

然后看看系统实际如何对待这份意图，包括策略规则和所有表，而不只是主表。保存的属性是输入，已安装的表是结果。

ip -4 rule show
ip -4 route show table all

两个目标，一次对比

选一个可用的私有目标和一个普通公共目标，然后询问内核各自会走哪条路径。在两台机器上都这样做，才能把模糊的差异变成具体的差异。

ip -4 route get 10.40.0.20
ip -4 route get 203.0.113.20

这些地址只是示例，请替换成你自己的；重点在于这一对，而不在于数字。比较每个输出中的接口、源地址和表名。当私有查询指向隧道、公共查询也指向隧道时，你用的是全隧道，而另一个客户端可能是拆分隧道，反之亦然。

不要要求两个客户端打印完全相同的文本。OpenVPN 的 redirect-gateway def1 通常表示为两条半前缀路由而不是一条默认路由，显示方式不同的管理器并不因此就是错的。要判断覆盖范围，也就是查询所显示的内容，而不是格式。

两个客户端可以合理不同的地方

客户端的默认值是策略选择，允许不一致。某个产品可能偏好全隧道，另一个可能保留本地默认值、只路由私有前缀，第三个可能遵循服务器推送的内容。只有当差异与你收到的需求相矛盾时，它才是缺陷。

所以要把每个客户端与已批准的拆分或全隧道意图对比，而不是互相比较。如果需求是私有流量走隧道、本地互联网路径保持本地，那么全隧道就是缺陷，拆分隧道才是正确的，无论哪个客户端做了什么。在看任何一份配置之前先写下意图，否则你最先检查的那个客户端会悄悄成为标准。

DNS 是第二个维度，并且会独立失效。正确的路由仍可能把查询发给无法应答私有区域的解析器，而正确的解析器也修不好错误的路由。两者都要检查，并把「私有名称能解析、私有地址却不能」视为两层分别处理的证据。

保持对比干净

一次只运行一个连接所有者。在导入的配置文件旁边运行命令行 OpenVPN 会话会安装自己的路由和解析器状态，得到的混合状态不属于任何一个客户端的行为。测量另一个之前先拆掉一个。如果不确定还有什么在保持状态，就重启，因为一小时前的残留路由看起来和策略问题一模一样。

其他条件也要固定：相同的端点、相同的账户、相同的软件版本、相同的网络。在同事的 Windows 笔记本上成功，测试的是另一个客户端、另一套解析器集成，可能还有另一个服务器配置文件，所以不能作为 Ubuntu 管理器的证据。

NetworkManager 的 IPv4 设置参考精确定义了 never-default 和已保存的路由属性，在修改受管值之前值得一读。还要记住这次对比的范围：它只涉及 IPv4，对相应的 IPv6 策略只字未提，而后者有自己的默认值和自己的惊吓方式。