OpenVPN 详解：为什么它到今天仍然不可替代
Yalgorup 编辑部 · 更新于 2026年8月1日
核心要点
- 控制通道走 TLS 负责协商，数据通道走对称加密负责传输，两者分离。
- 走 TCP 443 时流量外观接近普通 HTTPS，这是它至今不可替代的原因。
tls-crypt会把控制通道整体加密，使握手包也不再呈现明显特征。- 传统实现跑在用户空间，性能弱于内核态的 WireGuard；OpenVPN 2.6 起的 DCO 把数据通道移入内核以弥补。
双通道结构
OpenVPN 把连接拆成两条逻辑通道：
控制通道 跑标准 TLS。负责验证服务器证书、验证客户端身份、协商数据通道使用的密钥和算法。这一步复用了成熟的 TLS 生态，也意味着它继承了 TLS 的安全属性和历史问题。
数据通道 用协商好的对称密钥加密实际流量，常见配置是 AES-256-GCM 或 ChaCha20-Poly1305。
两条通道复用同一个 UDP 或 TCP 连接。这种分离让 OpenVPN 可以在不中断传输的情况下重新协商密钥。
UDP 与 TCP 的取舍
| UDP 模式 | TCP 模式 | |
|---|---|---|
| 延迟 | 低 | 较高 |
| 丢包处理 | 交给上层应用 | 隧道层重传 |
| 网络变差时 | 平缓退化 | 可能急剧恶化 |
| 穿透能力 | 一般 | 强，尤其 443 端口 |
TCP 模式的问题有个专门名字：TCP meltdown。隧道内是 TCP、隧道外也是 TCP，两层重传机制互相叠加，一旦丢包率上升，速度会掉得比想象中快得多。
所以经验法则是：能用 UDP 就用 UDP，只在连不上时才退到 TCP。
为什么它在受限网络里更好用
三个原因叠加：
- 可以监听 443 端口。 这是 HTTPS 的标准端口，在几乎所有网络里都放行。
- 外层是 TLS。 流量的第一印象与访问网站高度相似。
tls-crypt把控制通道也加密了。 握手阶段的明文特征被消除，主动扫描时服务端也不会给出可识别的响应。
需要说明的是，这只是「不显眼」，不是真正的伪装。深度检测仍可以通过报文长度分布、时序特征做出判断。真正的伪装需要专门的混淆层，见 混淆与伪装协议。
性能短板与 DCO
传统 OpenVPN 完全运行在用户空间：数据包要从内核复制到用户态、加解密、再复制回内核。这一来一回的上下文切换是它比不过 WireGuard 的主要原因。
OpenVPN 2.6 引入了 DCO（Data Channel Offload）：控制通道仍在用户空间，数据通道下沉到内核模块处理。在高带宽场景下改善明显。前提是客户端、服务端和操作系统三方都支持。
什么时候选它
- 所在网络封锁 UDP，或对 VPN 协议做了主动阻断
- 需要复杂的路由策略、脚本钩子、按证书区分权限
- 设备或系统还不支持 WireGuard
如果没有这些约束，WireGuard 在速度和省电上更划算。多数商用客户端支持一键切换，遇到连不上时换个协议试试，往往比换服务器有效。
常见问题
OpenVPN 用 UDP 还是 TCP？+
默认且优先 UDP，延迟低、无重传叠加。只有在 UDP 被封锁或丢包严重时才切 TCP，代价是 TCP-over-TCP 会在网络变差时急剧退化。
OpenVPN 比 WireGuard 慢多少？+
取决于硬件和是否启用 DCO。传统用户空间实现在高带宽下差距明显；启用 DCO 后差距大幅缩小。低带宽日常使用两者感受不出区别。
tls-auth 和 tls-crypt 有什么区别？+
tls-auth 给控制包加 HMAC 校验，能挡住扫描和 DoS，但握手内容仍可见；tls-crypt 直接加密整个控制通道，隐蔽性更好，是现在的推荐做法。
.ovpn 配置文件可以随便用别人的吗？+
不建议。配置文件里包含证书、密钥和服务器地址，等于把信任完全交给提供者，其中可以指定 DNS、路由甚至执行脚本。