同一台电脑上的两个 VPN 客户端：什么会冲突，什么能用

你的第二个客户端连上了，第一个客户端的资源却解析不了，工单上说工作 VPN 弄坏了个人 VPN。从故障的意义上讲，什么都没坏：两个客户端都在按设计行事，而机器只有一张路由表。冲突围绕每个客户端都视为己有的四项资源展开。按顺序过一遍，修复通常就变成一项设计选择，而不是一次修理。

第 1 步：查明出口归哪个客户端

动手之前，先读当前的出口决策。对公网地址做一次路由查询，会告诉你数据包此刻会走哪个接口、哪个下一跳，这就是“谁赢了”的答案。再把它和客户端创建的接口名对照，接口名通常带着产品或协议的名字。如果查询指向了你没预料到的隧道，你就已经找到冲突了。

ip route get 1.1.1.1
ip route show default
route print

有些客户端根本不替换默认路由，而是补上两个半区：一个覆盖地址空间的下半段，一个覆盖上半段，合起来就是全部。这样原来的默认路由仍然可见，手动修复看起来没问题，流量却依旧从隧道出去。要看度量和前缀长度，而不只是看有没有默认条目。

如果两个客户端用同样的度量争抢同一个前缀，就停下来。内核只会选一个，另一个会显示已连接却什么都传不了。

第 2 步：检查解析器和重叠的前缀

DNS 是第二个冲突，症状很典型：地址能通，域名却失败。每个客户端都会推入自己的解析器，后来的查询由最后写入的一方说了算。别读客户端的设置页，直接问解析服务每条链路在用哪个解析器。

resolvectl status
Get-DnsClientServerAddress
dig +short intranet.corp.example

然后比较两个网络使用的私有前缀。如果两边都从同一段地址里分配，任何客户端侧的安排都救不了，因为机器分不清哪个 10.0.0.0/8 的目标属于哪条隧道。必须有一侧重新编号或做转换，而这是和网络负责人商量的事，不是改配置。重叠是唯一一种诚实的答案就是“设计必须改”的冲突。

前缀重叠就停在这里。这份清单后面的所有内容都假设它们不重叠。

第 3 步：选一种能站得住的隔离方式

可靠的做法都避免让两个客户端对着同一张路由表运行。用一个客户端加能同时到达两个私有网络的分流隧道策略最简单，前提是目标不重叠且策略负责人同意。虚拟机或网络命名空间是下一步，因为各自都有自己的表和自己的解析器。

sudo ip netns add vpn2
sudo ip netns exec vpn2 ip link show
sudo ip netns exec vpn2 curl -sI https://intranet.corp.example/

命名空间能提供和虚拟机一样的隔离，又不需要第二套操作系统，但它的边角很粗糙：隧道设备要搬进去，应用必须在里面启动。对个人 VPN 来说，摆在受管工作客户端旁边的一台独立物理设备，往往是最不让人意外的选择。把一条隧道套进另一条，不算隔离方式：内侧端点必须能通过外层隧道到达，而且这种叠法还会额外带来 MTU 和延迟问题。

选一种方式，并写下理由。给一个应用用命名空间、其余用分流隧道，会把原来的冲突以更难排查的形式重新造出来。

第 4 步：在同一个会话里验证两个网络

在每个私有网络上各测一个资源，而且要从应用真正运行的环境里测；应用跑在命名空间里，就别在自己的 shell 里测。出口接口、解析出的地址和响应码要一起看，因为三者中有一项成功可能掩盖另外两项的失败。重启后再做一遍，因为客户端启动的先后决定了谁赢。恰恰是这个顺序，人们常常忘了记录。

curl -sI https://intranet.corp.example/
curl -sI https://files.personal.example/
ip route get 10.20.30.40

记录客户端版本、接口、解析器状态，以及每个网络的前缀。当客户端更新并改变路由行为时，这份记录就是五分钟修复和推倒重来之间的差别。下一个人不会共享你关于哪条隧道先起来的记忆。

当你能说出拥有默认路由的接口、每个域名所用的解析器、隔离第二条隧道的方式，以及重启后每个网络各一次请求的结果时，清单才算完成。少于此，就只是今天碰巧能用的配置。