Windows 的 VPN 还是 Cisco Secure Client：哪个才对

同一个网关收到两条指示：用 Windows 的 VPN 连接，或者安装 Cisco 客户端。两者都没点明网关期待的那种交换，因为 Windows 暴露了多种原生连接类型，而厂商客户端携带的配置覆盖不止一种模式。两个标签都只是在说软件，而网关协商的是协议、认证与策略。答案在配置文件里，而且不用连接就能读。

标签说的是软件，不是一种交换

品牌和操作系统是两件不同的事实，两者都不决定线上格式。Windows 自带一组原生类型，Cisco 客户端自带一个既能驱动 SSL 又能驱动 IPsec/IKEv2 的配置引擎。把两者混为一谈，得到的图表比较的是公司，而不是交换。

下表把产品问题换成三个读取位置，以及各自保存的字段。把这些字段记下来，歧义就消失了：

微软发布的 Windows VPN 类型参考 把 IKEv2 和 SSTP 列入原生类型，这否定了“原生的配置就等于 PPTP”的说法。Cisco 的配置文档描述了 SSL 与 IPsec/IKEv2 两种模式，以及与之匹配的头端策略。每家厂商都提供多个选项，所以哪个名字都不能指向单一协议。

原生类型在线上放的是什么

IKEv2 在 UDP 上协商安全关联，并在 IPsec 内部承载流量，这使它与其他 IKEv2 实现平起平坐，而不是微软专属设计。SSTP 把 PPP 包进 HTTPS 会话，因此能穿过 IKEv2 过不去的代理，在线上看起来像 TLS，却并不是 TLS VPN 协议。这两点解释了大部分工单：隧道在一个网络上可用，在另一个网络上失败。

带 IPsec 的 L2TP 和更老的 PPTP 条目在同一个下拉菜单里，它们出现在那里并不说明服务器支持。下拉菜单是操作系统能尝试什么的菜单，不是网关的能力声明。把它读成支持列表，就是两小时翻找凭据的开始。

原生配置里要紧的字段是连接类型、认证方法和服务器标识。类型选错失败在另一个阶段，而不是密码错误，这个差别就是值得追的线索。

厂商客户端增加的是配置，而不是协议

Cisco 客户端是配置的容器。SSL 模式与 IPsec/IKEv2 模式在交换、端口预期和错误文本上都不同，导入的配置在两者之间选择。因此安装客户端并不能证明可达性。

版本成对出现是有原因的。功能、认证流程和态势检查都在客户端与头端之间协商，所以旧客户端对上新的头端，可能以读起来像网络故障的方式失败。这一对属于连接定义，而不属于升级说明。

别的组织导出的配置很少与本地头端相符，导入它可能让客户端提出网关并不提供的模式。先从配置里读出模式，再与网关上配置的协议和认证策略比对。只有两者一致，网络才是嫌疑对象。这个顺序省下一次抓包——那次抓包只会显示一个健康的 TLS 会话指向了错误的服务。

改任何东西之前，先读本地配置

在 Windows 上，不拨号就能读到原生配置，输出会直接给出类型和认证方法。把这些值与网关所有者所说的头端接受条件比对。如果类型与工单不符，先修工单，因为那比重装一个从来没错的客户端更便宜。

这四条命令覆盖配置、它的路由、连接尝试和端口可达性。在已装好该配置的机器上按这个顺序运行：

Get-VpnConnection | Format-List Name,TunnelType,AuthenticationMethod,ServerAddress
Get-VpnConnection -Name 'Corp' | Select-Object -ExpandProperty Routes
rasdial
Test-NetConnection -ComputerName vpn.example.com -Port 443

被过度解读的是端口测试。提供登录页的 TCP 443 监听与终结 IKEv2 的监听，从外部看完全一样，因为端口是位置，不是协议。

把结果写成三个字段：客户端、模式、网关，放在工单旁边。再短一点，下一个人就得重新发现同样的歧义。