有几件事不明白。

首先是大多数 VPN 工具最初设计用于在不安全、可能被屏蔽或防火墙但对 VPN 没有积极敌意的网络上提供私有连接。

第二个是传统的 TLS 是 TCP 的包装器。TCP 对 VPN 来说是一个糟糕的选择，因为它会受到“线头阻塞”的影响。如果一个数据包丢失，那么它后面的所有数据都会被阻塞，直到它被成功重传。这过去在通过 TCP 运行 VPN 时会引起很大的问题，现在我们有了 TCP 快速重传，这不再是一个问题，但它仍然不太理想。

第三是深度包检测是一个相当新的事物。将通过不受干扰的合法 TLS 流量但不会通过端口 443 上的其他流量的网络仍然是例外而不是规则。

虽然 Openvpn 确实有一个 TCP 选项，但它最初设计为通过 UDP 运行。它使用 TLS 进行密钥交换，但使用专门为此目的设计的系统加密实际的网络数据包。

https://openvpn.net/index.php/open-source/documentation/security-overview.html

也有人应该说一下 DTLS（TLS over UDP）

DTLS 是一个相当新的协议。我看不出你为什么不能/不应该在其上构建 VPN 解决方案，但我猜 VPN 软件供应商并不是特别愿意重新设计他们的软件。

无论如何，它对问题中描述的场景没有帮助。

简洁版本：

• VPN 协议需要提供 TLS 不提供的封装
• 当然，可以通过 TLS 隧道 VPN 来获得相同的效果！

长版：

虚拟专用网络这个名称暗示了您的问题的答案。真正的 VPN 协议模拟网络，这意味着能够通过单个通道同时路由多种流量类型和端口。这就是为什么使用 IPSec 之类的 VPN 协议后，您最终会得到封装在 ESP 数据包中的 TCP 数据包，这些数据包封装在其他 TCP 数据包中。（另请参阅SSH 和 IPsec 有什么区别？）

默认情况下，TLS 不提供此功能。TLS 获取字节，对其进行加密，然后将它们传输给可以解密的接收者。而已; 其他所有要做的事情都必须由应用程序来完成。在 HTTPS 下，Web 服务器和客户端通过 TLS 通道交换 HTTP 数据字节。在 IMAPS 下，邮件服务器和客户端通过 TLS 通道交换 IMAP 数据字节。

为了通过 TLS 获得通用的“网络”连接，您需要一个能够在任一端进行封装和解封装的客户端和服务器。你不是免费的。

这并不是说您不能拥有通过 TLS 运行的 VPN。有很多产品可以做到这一点；甚至像 Checkpoint 这样的主流供应商也支持 IPSec 和基于 TLS 的 VPN。在某些情况下，TLS 只是简单地封装 IPSec 数据报，因此实际的“N”是通过 IPSec 但 TLS 通过 Internet 获取的。

请注意，在某些情况下，老练的对手可以根据通信模式推断何时将 TLS 连接用于 VPN。操作安全不仅仅是加密位！

许多 VPN 协议确实使用 TLS。特别是，几乎所有现代客户端-服务器 VPN（例如，用于将笔记本电脑远程连接到公司网络）都支持将 TLS 作为主要或备用传输。

我是著名的基于 TLS/SSL 的 VPN 的开源客户端的贡献者：openconnect。我几乎完全靠自己对 GlobalProtect VPN 协议 (TLS+ESP) 进行了逆向工程。我已经详细研究了足够多的 VPN 协议，以注意到一些非常清晰的模式和设计权衡。

TLS 用于 VPN 身份验证和传输的优势：

• 稳健性。基于 TLS 的 VPN 流量在数据包结构和加密内容方面与“正常”HTTPS 流量没有区别——尽管数据包的时间和大小，以及连接持续时间，暗示它承载的不是“正常”浏览器流量。HTTPS 的普遍性意味着基于 TLS 的 VPN 可以通过几乎所有的防火墙和中间盒；只有真正确定的进行流量分析或通过 DNS 或 IP 将 VPN 端点列入黑名单的审查员才能阻止它。
• 强大的安全保证：现代 TLSv1.2（即将发布 1.3）是一种设计精良、经过仔细分析且逐渐成熟的安全通信协议。许多库以一种很难误用的方式包装它。如果您使用基于 TLS 的 VPN，您可以预期您与网关的连接使用现代密码（例如，没有古老的 1DES）和网关的 x509 公钥证书验证，从而限制了中间人攻击。这可能搞砸了TLS的实施，严重破坏其安全，但比较困难的，因为高质量的图书馆里面做最棘手位的标准化。编写基于“自定义”协议的不安全 VPN 要容易得多。

与ESP（基于 IPSEC 的 VPN 的正常传输层）相比，TLS 用于 VPN传输的缺点：

• TLS 通常在 TCP 上运行，这在底层网络拥塞或有损的情况下作为隧道传输的性能很差……尤其是在 TCP-over-TCP 的情况下。
• 幸运的是，DTLS（“数据报 TLS”）可以缓解这种情况；它在 AnyConnect/openconnect VPN 协议以及 WebRTC 等实时通信协议中的使用最为显着。
• 大多数现代操作系统都优化了对 IPSEC 和 ESP 的内核支持。如果实施得当，这使得 ESP对于网关、防火墙和终端客户端系统非常高效且开销低。TLS 通常在用户空间中实现，并结合底层 TCP 流的复杂性，这使其效率较低。
• （ D TLS的类似有效内核实现应该是可能的，但我不知道主流操作系统中有任何实现。）

... 至于使用 TLS 进行 VPN 的身份验证/设置？除了缺乏标准化协议之外，我基本上看不出那里有什么真正的缺点。

TLS 比ISAKMP（IPSEC 的身份验证/密钥交换组件）更灵活、实现更广泛且更易于调试。包括 GlobalProtect 在内的一些现代企业 VPN 协议使用TLS 进行身份验证和密钥交换，然后使用ESP 进行数据传输（尽管如果需要，它们可以回退到 TLS）。根据我的经验，这是一个非常有效和高效的组合。