Windows 上的分离隧道：网关选项与缺失的前缀

隧道报告已连接，维基也还能打开。随后一个下载卡住，机架上的共享不再响应。隧道做了它该做的事，而配置文件只是把所有目的地都揽了下来。

Windows 把 VPN 连接当成一个路由决策。在这个决策被收窄之前，机器就像搬去了办公室。

为什么正常的隧道感觉像断网

允许使用远程网关的配置文件会安装一条经过隧道的默认路由。于是不在本地链路上的目的地都会从办公室防火墙出去。本地共享不再响应，因为它们的流量现在要跑到另一个大洲再回来。客户端状态里没有任何东西反映这一点。

这些症状是故意让人困惑的。共享超时的同时名称解析可能仍然可用，或者反过来。用户说 VPN 坏了，客户端说自己一切正常，而这两种说法都准确。

藏在 IPv4 对话框里的复选框

这项设置藏在好几层对话框之下。打开 ncpa.cpl，右键单击连接，然后依次进入 IPv4 属性、高级，取消那个让连接成为远程默认网关的选项。就是这一个框决定配置文件是不是全局隧道。配置文件里的其余部分照旧生效。

比较重连前后的 route print -4 输出。原先指向隧道的那条 0.0.0.0 记录应当消失，而公司前缀应当仍然存在。

route print -4 | findstr /c:"0.0.0.0"
Get-VpnConnection -Name 'Work VPN' | Select-Object Name, SplitTunneling, Routes

改接口跃点数并不是替代办法。跃点数只在两条互相竞争的默认路由之间做选择，而每次连接都重装自己默认路由的客户端，无论把数字设成多少都会赢下这场较量。

没人列出来的前缀

分离隧道只暴露 配置文件里记录的那些前缀。配置文件写好之后才加入的办公室子网依然不可达，尽管隧道本身完全正常。于是报告就变成“一台服务器坏了”，而不是“VPN 坏了”。

手工添加的路由能补上这个缺口，直到网关地址改变。把前缀记进连接里更牢靠，因为前缀会跟着连接走，而不是跟着一个猜出来的地址。

route -p add 172.20.8.0 mask 255.255.255.0 10.8.0.1
Add-VpnConnectionRoute -ConnectionName 'Work VPN' -DestinationPrefix 172.20.8.0/24
Get-VpnConnection -Name 'Work VPN' | Select-Object -ExpandProperty Routes

把保存的列表和实际路由表放在一起看。保存的前缀可能存在，而路由表始终收不到它，这发生在连接建立后管理代理过滤路由的时候。反过来也有，注册表里的路由指向一块已停用的网卡。只看其中一边都说不清全部情况。

重启之后验证结果

两个方向都做一次跟踪，并按名称解析。公网跟踪应当从运营商出去，内网跟踪应当进入隧道，内部主机应当能按名称而不只是按地址响应。

tracert -4 www.example.com
tracert -4 wiki.corp.example
ping -4 fileserver.corp.example
ping -4 172.20.8.20

断开、重连并重启一次之后再重复一遍。一次手动重连后还在、重启后却消失的前缀，从来没有被保存进配置文件。

把打印机和 NAS 也留在测试里，因为一条切断笔记本旁边设备的分离隧道，是靠制造一个更小也更烦人的问题来解决原来那个问题的。核对参数拼写与模块版本是否一致的地方，是微软的 Add-VpnConnectionRoute 参考文档。