这个 NetworkManager 插件能同时运行两个 VPN 吗？

连接列表里躺着两个 VPN 条目，都显示已连接，可真正承载你预期流量的只有一个。或者第二个根本起不来，而没人说得清问题出在插件、客户端还是你忘掉的一条策略。关于只能用一个 VPN 的说法，描述的是特定实现，而实现各不相同。先摸清能力，再谈协调。

先数已保存的配置，再数已激活的连接

已保存的配置是一个配置对象，而活动的连接是一个正在运行的实例。列表把这两个概念在视觉上合并了，所以两种说法听起来都对。先按 UUID 点名确切的对象，因为显示名称并不唯一，旧的导入常常和新条目共用标签。然后单独查看活动列表，看清楚哪些 UUID 出现在其中。到这一步你才知道，自己比较的是两份配置，还是两条活着的隧道。

把同一个 UUID 激活两次又是第三种情况，那不是并发，而是一个实例的重新激活。

读插件自己的元数据

每个 VPN 插件都附带一个管理器会读取的小元数据文件，而这些文件可以声明该插件是否支持同时建立多条连接。要读这台机器上已安装的那份文件，而不是复述上游项目目前写了什么，因为决定你手上到底有什么的是发行版软件包。同样的检查要按协议分别做：一个插件的答案对另一个插件毫无意义。 把软件包版本和结果记在一起，这样日后的比较才有意义。

关于只能用单个 VPN 的老建议，描述的是更早的集成方式。它既非永远成立，也不该被当作固定不变，而眼前这份文件在本地就能定论。

并发不等于协调

两个插件都能启动，只能证明能力，不能证明设计。两条都提供默认路由的隧道会互相竞争，后装上路由的那条通常悄悄取胜，还不打个招呼。重叠的私有网段也有同样的问题，只是规模小一些。

在激活任何东西之前，先确定哪些目标属于哪份配置。改个配置名并不能区分这些目标。

不管你愿不愿意，DNS 都会选出赢家

解析器设置是按配置分别生效的，当两份同时活动时，解析顺序由策略和优先级决定，而不是由意图决定。最后起来的那份配置，可能悄悄占住所有公司内部域名。

把每个私有命名空间指派给应当为它作答的解析器，并且刻意设置路由偏好，而不是听任顺序决定。然后在两条隧道都起来的情况下，分别测试每个命名空间里的一个名字，再断开其中一条重测一次。只在两条隧道同时在线时才工作的解析器，是一种会在最糟糕的时刻让人措手不及的设计。

按固定顺序推进，并在每一步之间检查

先激活一份配置，检查它的路由和解析器状态，再激活第二份并重复检查。比较这两个状态，就能看出改了什么、哪份配置拥有什么。不要先把两条都激活，然后再去诊断结果。

通过本该承载它的那条隧道，逐一测试每项必需资源，然后断开一份配置，确认另一份仍保有它的路由、DNS 以及预期的故障行为。如果部署的插件确实做不到你需要的事，那就选择受支持的升级，或者明确隔离的替代方案，而不是在管理器旁边复活一个过时的协议。没人管理的第二条独立隧道不是隔离，它只是又一个意外路由的来源。