你的配置文件实际安装的是哪种 Windows VPN

Windows 里有两样不同的东西都挂在 VPN 这个名目之下：操作系统自己实现的协议配置文件，以及一个承载供应商插件的平台，后者带来自己的实现。插件并不是在原生配置里选择 IKEv2 或 SSTP 的另一个名字，原生配置也无法通过给隧道类型改名就把供应商的设置吸收进来。这里的大部分混淆，都始于一篇为其中一方而写、却被套用到另一方的支持文章。搞清楚自己手上是哪一种，这是第一步，也只需要大约一分钟。

两个都叫 VPN 连接的东西

内建类型是 Windows 自己实现的那几种：IKEv2、SSTP、L2TP/IPsec、PPTP，以及在其中自动选择的那一项。供应商插件是独立的软件包，通常由厂商自己的安装程序装入，向平台注册一种实现，并作为它自己的连接类型出现。

应用这个词并不能判定装的是哪一种。厂商可能只发布插件，也可能只发布独立的桌面客户端，或者两者都有，它们的行为并不相同。

沿着设置走一遍，看看这个连接提供了什么。设置、网络和 Internet、VPN，然后打开该连接的属性：原生配置会给出一个带内建名称的 VPN 类型下拉列表，它的高级选项会列出 Windows 支持的认证方式。如果唯一的配置界面是厂商自己的对话框，或者类型不在那个下拉列表里，你面对的就是插件或独立客户端。在动手改动之前，先把这三者中的哪一种记下来。

走一遍设置，看看自己手上是哪种

如果管理多台机器，用 PowerShell 看更快。Get-VpnConnection 列出由 Windows 自己管理的连接，每条结果都带一个 TunnelType。由供应商管理的连接可能根本不出现，而这本身就是答案。

原生配置是用它自己支持的参数创建的：Add-VpnConnection -Name Corp -ServerAddress vpn.example.com -TunnelType IKEv2 -AuthenticationMethod EAP，以及在该方法要求时以 XML 提供的 EAP 配置。这才是 Windows 有文档记录的那一面，它不接受任意厂商的 XML，也不接受 OpenVPN 配置文件作为等价配置。正是这种翻译的尝试，让人得出平台坏了这个结论，而那份配置从来就不是原生的。

供应商拥有什么

插件拥有实现细节，这也是这一区分在名字之外还有意义的原因。它的应用、它的认证流程、它的配置架构都归供应商所有，唯一正确的资料来源就是供应商的文档。

这种归属有实际后果。更新通道是厂商的而不是 Windows Update，所以修复兼容性问题的版本会从另一条渠道到来。卸载路径同样是厂商的，在设置里删掉那条连接记录，可能把供应商的应用及其受管部署留在原处。而配置架构也是厂商的，所以某个供应商配置里存在的设置，在另一家的配置里毫无意义，哪怕标签一模一样。

跟着真正的配置来源走

面对受管部署时，把供应商文档与组织文档合起来用，而不是拿一份去替代另一份。检查受支持的版本、配置架构，以及部署针对的是用户还是设备。

最后这一点比看上去更要紧。按用户部署和按设备部署有不同的前提条件，也有不同的失败方式，在一个情境里装得很正确的包，在另一个情境里可能完全看不见。如果该有的供应商不在，装一个名字相近、但其实无关的客户端并不会带来兼容性，名字再怎么暗示都没用。

配置之后，先测认证，再测这份配置实际应用了什么。配置出现在设置列表里，并不是应用可达性测试。确认流量走的路径和正在使用的 DNS 服务器，因为插件可能装入自己的路由和解析器，而用户察觉到的正是这些部分出错。然后打开用户真正需要的那个应用，因为已连接和能工作是两个不同的说法。

测一测这份配置实际应用了什么

升级处理时，请写明供应商名称与版本，而不只是 Windows 版本和服务器地址。一张只说 VPN 在 Windows 11 上连不上的工单，对下一个人来说，完全没说清这三种安排里到底是哪一种。

把更新和卸载与拥有它的组件绑在一起，并在连接名旁边记下是哪个组件。Microsoft 关于 VPN 连接类型与插件的文档是内建列表与插件模型的参考。如果组织的说明点名了某个供应商，那就以供应商的文档为准。其余的一切，都是在猜你面前到底是 Windows 的哪项功能。