Windows 内置 VPN 为何连不上厂商的 SSL 网关

Windows 只自带四种隧道类型，厂商的 SSL 网关不在其中。即便如此把内置配置文件指向它，连接也会在提示输入凭据之前失败，通常提示连接被本地系统终止。这段话是不匹配的信号，而不是诊断。配置文件类型和拥有该协议的客户端必须一致，而两者缺了一个。

四种类型与一个对话框

每个已保存的配置文件都带一个隧道类型。内置客户端接受 PPTP、L2TP、IKEv2 和 SSTP，另有一个按顺序尝试的自动模式。没有通用的 SSL VPN 条目，也无法通过对话框添加。厂商网关在 TLS 之上运行自己的应用协议，只有该厂商的客户端实现了它。

列出它只需一条命令，而且值得在其他排查之前先跑一遍，因为只需一秒，却能排除一整类错误假设：

Get-VpnConnection | Select-Object Name, ServerAddress, TunnelType, SplitTunneling
Get-VpnConnection -Name "Office" | Format-List

如果配置文件写的是 SSTP 而网关不是 RRAS 服务器，不匹配就已经成立。再怎么折腾证书或防火墙都改变不了。

SSTP 与厂商 TLS 在 443 端口上看起来一样

SSTP 把 PPP 会话封装进 TLS，走 TCP 443。在 Microsoft 协议栈里由 RRAS 终止，并出示客户端会校验的服务器证书。Fortinet、Citrix 或 Pulse 设备同样在 443 端口终止 TLS，其门户在任何浏览器里都能正常打开。

那个浏览器测试只能证明可达，不能证明兼容。门户背后的会话协议属于厂商，内置客户端完全没有它的实现。厂商是否提供自己的客户端，决定了你面对的是不匹配的哪一半。

反向的混淆也会发生。按 SSTP 配置、对着真正的 RRAS 服务器连接时，可能门户正常却在证书校验上失败，那是证书问题而不是协议问题。

隧道建立之前就出现的报错

800 系列错误码都在隧道建立之前上报，所以防火墙规则很少能改变它们。错误 812 是服务端策略拒绝了客户端提出的身份验证方式。这一区间里的其他错误来自本地连接管理器，而不是网络。

重建任何东西之前先开跟踪。跟踪会指明失败的阶段，而阶段名称比对话框文字更有价值：

netsh ras set tracing * enable
Get-ChildItem "$env:windir\tracing" | Sort-Object LastWriteTime -Descending | Select-Object -First 5

跟踪日志落在 tracing 目录里，会一直留到你清理为止，所以用完就关掉跟踪，别让它跑上几周。

连接成功的配置文件也可能搞坏一切

能连上却让浏览、本地共享或容器引擎失效的配置文件，问题在路由而不在隧道。默认网关被移进了隧道，于是每个目标都要经过一个可能不为其转发的对端。

两个设置决定这件事。一个是配置文件上的拆分隧道属性。另一个是每个适配器在远程网络上使用默认网关的选项，位于 IPv4 高级设置里。

Set-VpnConnection -Name "Office" -SplitTunneling $true
Add-VpnConnectionRoute -ConnectionName "Office" -DestinationPrefix 10.20.0.0/16

只开拆分隧道而不加路由，得到的隧道能连上却哪儿也到不了。关掉拆分隧道却不检查 DNS，内部名称会解析成公网答案，因为适配器自己的后缀和服务器没被使用。

先验证管道，再验证类型

按这个顺序做，并且某一步失败就停下，而不是把所有设置一起改：

Test-NetConnection vpn.example.net -Port 443
Get-VpnConnection -Name "Office" | Format-List TunnelType, ServerAddress, DnsSuffix
netsh interface ipv4 show route
rasdial Office

第一条命令把可达性与协议分开。第二条确认配置文件声称的类型。路由表显示隧道有没有吃掉默认路由。拨号命令报告连接管理器自身的错误，往往比对话框更清楚。

把隧道类型、网关产品和确切错误写进工单。下一个人就能在一分钟内判断这是协议不匹配、证书失败还是路由决策，而不是从“VPN 不工作”开始。