目录
目录X
客户 VPN 劫持路由导致远程连接中断
AI摘要（BLUF）
场景客户提供一个 SSL VPN 客户端访问其内网。这个客户端"全接管"得很彻底：装在笔记本 A 上，A 的整个网络被切断，连 ESXi 管理台和虚拟机控制台都黑屏；改装到跳板虚机 B（ESXi 上的 Windows）后 A 恢复正常，但 A 到 B 的 RDP 一开 VPN 就断。原因VPN 客户端连接时会新建一块虚拟网卡，把默认路由 0.0.0.0/0 指向它，并把接口跃点数（metric）压到最低。于是所有流量都进了客户内网隧道，包括访问 ESXi、RDP 回连跳板机这些与客户无关的流量。这类零信任客户端多出于合规要求强制全接管，还会检测被拆分的隧道。根子在 Windows 的路由查找遵……
场景
客户提供一个 SSL VPN 客户端访问其内网。这个客户端"全接管"得很彻底：装在笔记本 A 上，A 的整个网络被切断，连 ESXi 管理台和虚拟机控制台都黑屏；改装到跳板虚机 B（ESXi 上的 Windows）后 A 恢复正常，但 A 到 B 的 RDP 一开 VPN 就断。
原因
VPN 客户端连接时会新建一块虚拟网卡，把默认路由 0.0.0.0/0 指向它，并把接口跃点数（metric）压到最低。于是所有流量都进了客户内网隧道，包括访问 ESXi、RDP 回连跳板机这些与客户无关的流量。这类零信任客户端多出于合规要求强制全接管，还会检测被拆分的隧道。
根子在 Windows 的路由查找遵循最长前缀匹配：先比前缀长度，长度相同才比 metric。
目标 192.168.188.227 ├─ 192.168.188.227/32 → 物理网卡 ← 长度 32，最先命中 ├─ 192.168.188.0/16 → VPN 网卡 ← 长度 16 └─ 0.0.0.0/0 → VPN 网卡 ← 长度 0，兜底
所以只要加一条比 VPN 更精确的路由，它就永远赢——VPN 客户端怎么刷路由表都抢不走。
处理
在跑 VPN 的机器上，连 VPN 之前，用管理员 CMD 执行：
netsh interface ipv4 add route 192.168.188.0/24 "Ethernet0" metric=1 store=persistent
192.168.188.0/24是要保住的本网段，也可换成一个 IP 的/32"Ethernet0"是物理网卡名（用Get-NetAdapter查）。名字有歧义时改用接口索引：route -p add <IP> mask <掩码> 0.0.0.0 metric 1 IF <索引>store=persistent让路由重启后依然存在
执行完再连 VPN，A 的上网与 RDP 都不再受影响。若客户端会定期清理路由表，把这条命令放进计划任务定时重跑即可。
