OpenVPN：基于 TLS 的 VPN 架构

OpenVPN 使用两个独立通道：控制通道和数据通道。控制通道使用 TLS 处理身份验证、会话建立和配置交换。数据通道承载实际的 VPN 流量，并使用通过控制通道协商的对称密码进行加密。这种分离使 OpenVPN 能够充分利用 TLS 生态系统进行密钥管理。

OpenVPN 控制通道运行完整的 TLS 会话。双方使用由同一 CA 签发的 X.509 证书进行身份验证。TLS 提供密钥交换、证书验证以及数据通道密码参数的协商。由于 TLS 支持 ECDHE，控制通道能够提供完美前向保密：即使拥有 CA 密钥，也无法从捕获的会话中恢复数据通道密钥。

数据通道加密通过 TLS 控制通道进行协商。OpenVPN 2.4 及更高版本默认使用 AES-256-GCM，这是一种在单次操作中同时提供机密性和完整性的 AEAD 密码。早期版本分别使用 AES-256-CBC 和 HMAC-SHA256。之所以优先使用 AEAD 模式，是因为它们不再需要单独进行 MAC 验证，并且能够抵御填充预言机攻击。

tls-crypt 选项使用预共享密钥，将整个 TLS 会话（包括客户端问候消息）封装在经过对称 HMAC 身份验证的信封中。这意味着未经身份验证的客户端甚至无法开始 TLS 握手；它们的初始数据包会被静默丢弃。这可以保护 OpenVPN 服务器免受基于 TLS 的 DDoS 放大攻击，并隐藏 VPN 服务器正在运行这一事实。

较旧的 tls-auth 选项会为 TLS 控制通道数据包添加 HMAC 标签，但不会对其加密。它可以阻止数据包注入，却仍会向观察者暴露 TLS 握手。tls-crypt 会对控制通道封装进行加密和身份验证，同时提供 DoS 防护和抵抗流量分析的能力。tls-crypt 是现代配置中推荐的选项；tls-auth 已被弃用，推荐改用 tls-crypt-v2。

OpenVPN 使用由 VPN 的证书颁发机构签发的 X.509 证书对客户端进行身份验证。每个客户端都会获得唯一的证书和私钥。服务器会验证证书链，并可选择检查证书吊销列表（CRL）以拒绝已吊销的证书。吊销证书会立即移除某个客户端的访问权限；而在基于 PSK 的系统中，更改密钥会影响所有客户端。

OpenVPN 可以运行在 UDP（默认且推荐）或 TCP 之上。UDP 避免了 TCP over TCP 问题：数据包丢失时，TCP 层和 VPN 应用层都会进行重复重传，从而导致性能显著下降。不过，某些网络会阻止 UDP。在 TCP 443 端口上运行 OpenVPN，可以绕过只允许 HTTPS 流量的防火墙，但在数据包丢失的情况下会牺牲性能。

OpenVPN 以 tun（路由）模式或 tap（桥接）模式运行。tun 模式创建点对点 IP 网络接口，在客户端与 VPN 网络之间路由 IP 数据包。tap 模式创建以太网桥接接口，传递包括广播和非 IP 协议在内的以太网帧。tun 模式效率更高，适用于大多数 VPN 使用场景；需要桥接网络分段或传输非 IP 协议时，则需要使用 tap 模式。

OpenVPN 服务器可以自动向连接的客户端推送配置指令。常见的推送指令包括 push "route 10.0.0.0 255.0.0.0"（在客户端添加路由）、push "dhcp-option DNS 10.0.0.1"（设置 DNS 服务器）以及 push "redirect-gateway def1"（通过 VPN 路由客户端的所有流量）。这样无需修改各个客户端的配置文件，就能集中管理客户端配置。

OpenVPN 通过控制通道中的 TLS ECDHE（椭圆曲线迪菲-赫尔曼临时密钥）实现完美前向保密。每个 TLS 会话都会使用新的临时密钥对，因此无法从服务器的长期证书私钥推导出会话密钥。即使今天捕获了加密流量，日后又获得了服务器证书，也无法解密过去的会话。

OpenVPN 2.5 弃用了 Blowfish 密码（BF-CBC），它在历史上曾是默认密码。BF-CBC 使用 64 位分组大小，在长会话中容易受到 SWEET32 生日攻击。现代 OpenVPN 默认使用 AES-256-GCM。OpenVPN 2.5 还弃用了数据通道中的非 AEAD 密码，并提高了 TLS 最低版本要求，放弃支持 TLS 1.0 和 1.1。

OpenVPN 回顾：控制通道使用 TLS 进行身份验证和密码协商；数据通道使用经过协商的 AEAD 密码（默认是 AES-256-GCM）；tls-crypt 封装 TLS，以阻止未经身份验证的握手；ECDHE 提供前向保密；基于证书的客户端身份验证结合 CRL 吊销机制；出于性能考虑优先使用 UDP 而不是 TCP；对于 IP 路由场景，优先使用 tun 模式。