Windows VPN：保存的配置文件与活动接口状态

Windows VPN 会出现在两个回答不同问题的地方，把它们混为一谈就会得出自信却错误的判断。保存的配置文件说某人配置了什么；活动接口说协议栈刚才应用了什么。当连接建立后流量仍走错路径时，必须按这个顺序阅读两个视图。任何单独一个都无法告诉你应用程序的数据包是否离开了隧道。

同一条隧道的两个视图

配置文件视图是配置：服务器地址、隧道类型、身份验证方式、分离隧道设置。它可能是正确的，而连接却忽略它；也可能是过时的，而连接却运行完美，因为重新连接的客户端可能不会重新读取你编辑过的内容。接口视图是已应用的状态：存在哪些适配器、它们承载哪些地址族、它们的度量值和连接状态。它会随隧道的出现和消失而变化，因此它是实时路由问题的合适地方，也是配置问题的不合适地方。

把两者一起读才是完整方法，只读其中一个正是人们最终删掉健康适配器的原因。下面的命令在不改变任何东西的情况下给出两个视图。

不改变任何东西地读取两个视图

从保存的配置文件开始，因为这是最容易确认的事实。注意隧道类型和分离隧道的取值，因为两者决定哪些目的地应该进入隧道。如果配置文件有误，请通过其受支持的配置界面修正，因为接口列表里的任何东西都无法修复指向错误网关的配置文件。

Get-VpnConnection | Select-Object Name,ServerAddress,TunnelType,SplitTunneling,ConnectionStatus

接口视图的形状不同：当一条隧道承载两个地址族时，它可能占用两行。把索引当作身份，把别名当作某人选的标签，并预期别名会在客户端版本之间变化。

Get-NetIPInterface | Select-Object InterfaceIndex,InterfaceAlias,AddressFamily,ConnectionState,InterfaceMetric

存在并不等于被使用，因为接口可以存在、可以连接，却仍然不是通往目标的路由所选择的那一个。在把一个陌生适配器当成故障之前，请记住这一点。这两种故障从外部看完全一样：配置正确但路由从不使用它，以及配置错误但路由确实使用它。它们的修复方式完全不同，这正是下一节存在的原因。

沿着路由走到目标

问协议栈，对于应用程序实际联系的地址，它会走哪条路径。这是接口列表无法独自回答的问题。

Find-NetRoute -RemoteIPAddress 10.60.20.10 | Select-Object -First 1
Get-NetIPAddress -InterfaceIndex 37 | Select-Object IPAddress,AddressFamily,PrefixLength

第一条命令报告两个值得读取的字段：所选来源的接口别名，以及该目标的下一跳。第二条命令里的索引 37 是第一次输出打印出来的值，不是要照抄的常量，而地址 10.60.20.10 只是示例。如果选中的来源属于物理适配器，而目标本应在隧道内部，你就找到了选择问题，因为 VPN 接口可能完全健康，只是没有被优先选用。度量值只是这个决定的一部分，因为路由的具体程度、策略和接口状态都参与其中。

在相同条件下比较三种状态

在连接前、连接中以及断开后，用相同的目标和相同的命令记录接口列表和选中的路由。这种比较能把当前的隧道接口与卸载后留下的旧隐藏适配器区分开，也能与同时运行的第二个客户端区分开。它还会告诉你隧道接口是否干净消失，因为断开后仍然存在的适配器，与从未出现过的适配器是不同的问题。没有这三份快照，每个陌生别名看起来都像罪魁祸首。

把三份输出与工单放在一起，因为两段命令输出胜过一段描述。同事可以完全不用重复你的会话就进行比较。

不要删除你没有确认的东西

陌生适配器通常属于某个东西：受管理的客户端、虚拟交换机、容器网络或安全代理。删除其中一个可能移除正常工作的组件，并把原始症状原封不动地留在原处。如果路由已过时，找到路由的所有者并在那里修正；如果配置文件有误，就编辑配置文件。Get-NetIPInterface 文档列出了上面用到的字段，包括让比较有意义的度量值和状态列。

给对象命名，找到它的所有者，然后针对那个所有者行动。其他任何做法都只是给问题改名，而不是阅读它。