SSTP 与 OpenVPN：同一个 443 端口，不同的协议

两种方案都可以放在 TCP 443 后面，因此人们以为它们是可互换的端点。其实不是： SSTP 服务器在 HTTPS 内部讲 PPP，而 OpenVPN 服务器在 TLS 之上或通过原始 UDP 流讲自己的协议。把一个客户端指向另一方的端口，得到的连接永远到不了登录提示。选择取决于 你能支持哪种客户端和传输方式，而不是端口号。

共用端口不等于共用协议

TLS 握手可以完成，却仍然走不通，因为之后客户端和服务器对接下来该说什么并不一致。在抓包中，你会看到一次干净的握手，随后是对端拒绝或忽略的应用数据。这种模式是协议不匹配的特征，而不是防火墙拦截。

改名后的配置文件和另一个菜单项都不会把一种协议变成另一种。SSTP 连接在 Windows 的 VPN 设置中创建，需要服务器地址和运营方提供的认证信息；而 OpenVPN 连接需要客户端和匹配的配置文件。 Microsoft 的 SSTP 规范 描述的是前者，而没有描述 OpenVPN 握手。

443 端口是一种策略上的便利。它能穿过几乎不放行其他流量的网络，这确实是优势，但它并不说明后面跑的是哪种协议。

SSTP 在 HTTPS 内部封装 PPP

这个名字描述的正是结构：PPP 帧被封装在 HTTPS 会话中传输，也就是说下面有 TLS，还有客户端可以验证的证书。Windows 把它作为原生 VPN 类型内置，因此受管理的笔记本电脑常常无需运营方所给配置文件之外的任何软件即可连接。

其他平台则是另一回事。Linux 或 macOS 客户端需要有人维护的实现，而它们在支持范围和报错方式上各不相同。请检查你真正打算使用的客户端，不要假设 Windows 内置的能力可以照搬，并确认配置中的服务器名称与服务器出示的证书一致。

SSTP 通常只走 TCP。这种单一传输会影响它在有丢包的链路上的表现，因为重传既发生在隧道内部，也发生在隧道之下。

OpenVPN 自带客户端并提供传输方式的选择

OpenVPN 提供自己的客户端和配置文件，从而给出原生 Windows 对话框看不到的诊断信息。服务器可以监听 UDP 或 TCP，而运营方的配置决定你的客户端必须用哪一种。指向错误传输方式的配置文件会在认证之前就失败。

认证同样由配置决定。一次部署可能只要求证书，也可能要求证书加用户名和密码，或者在之上再加第二因素，客户端必须与该安排完全一致。连接走到 TLS 阶段，并不说明接下来会索取哪种凭据。

UDP 是常见的默认值，因为它避免把一条可靠流嵌套进另一条可靠流。TCP 模式是为封锁 UDP 的网络准备的，它确实可用，但严重丢包会让它比被它取代的 UDP 路径更难用。该用 TCP 时再用，而不是因为它听起来更可靠。

按客户端、传输方式和支持来选择

三个问题就能定下其中大多数决策。每台客户端设备是否都需要一条无需额外软件即可工作的连接？你依赖的网络是否允许 UDP，还是只有 TCP 443 这一个出口？以及当配置文件过期时，谁负责支持客户端、它的更新和恢复？

比较两者时，请在同一台设备和同一个接入网络上测试。如果 SSTP 端点和 OpenVPN 端点属于不同服务器或不同站点，你的结果会把那些路由和机器也算进去，而不是隔离协议本身。这正是这类比较最常见地给出自信却错误答案的方式。

然后再确认你实际建立的是哪一种，之后再去排查其他问题：

> Get-VpnConnection -Name "Office SSTP" | Select-Object TunnelType, ServerAddress
> openvpn --config office.ovpn --verb 4

无论如何，最后要测试你需要的资源和 DNS，而不是在隧道状态上宣布成功。两种协议都可以配置为只承载选定的私有流量，而一条已连接但没有可用域名解析的隧道看起来像 VPN 坏了，实际上却是拆分隧道或 DNS 设计。

在受管理的设备群中，配置文件的分发和更新支持通常远在任何传输性能测试之前就决定了这个问题。