OpenVPN 日志：控制通道加密与数据通道加密

日志中写着 DHE-RSA-AES256-SHA 的那一行并不是整条连接的总结。它属于保护控制通道的 TLS 握手，而隧道内的流量可能完全用别的方式加密。把它当作 VPN 的数据加密算法来报告，正是要避免的错误。

有两个结果值得关注，它们回答的是不同的问题。一个是控制通道协商出的 TLS 套件，另一个是隧道承载的数据包所用的数据加密算法。

两个结果，两个问题

控制通道承载握手以及对等节点之间的管理消息。它的加密算法由 TLS 协议栈选定，因此名称遵循 TLS 的惯例。数据通道承载用户流量，由 OpenVPN 自身的加密协商来配置。

在读任何一行之前，先确定你回答的是哪一个问题。隧道是否加密，与握手是否足够强，并不是同一个问题。

同时显示这两行的日志片段才有用。控制行给出 TLS 版本与套件，数据行给出真正保护载荷的算法。

在其自身语境中解读 TLS 套件名称

在诸如 DHE-RSA-AES256-SHA 这样的历史 OpenSSL 风格名称里，每个组成部分描述的是不同的决定。DHE 是临时 Diffie-Hellman 密钥协商，RSA 是身份验证方法，AES256 是用于 TLS 记录的 AES-256（CBC 模式），SHA 是基于 SHA-1 的记录 MAC。

最后一个组成部分不是证书指纹，把它读成指纹是常见错误。名称本身也不能告诉你协议版本，因为 TLS 1.3 使用的是完全不同的命名方案。TLS_AES_256_GCM_SHA384 遵循那种较新的形式，其中末尾的哈希是套件构造的一部分，而不是 MAC 的选择。按组成部分解读只适用于较旧的命名风格。

OpenSSL 套件参考 可以在某个组成部分不熟悉时，把这些名称对应到各自的定义。

为承载的流量读取数据通道结果

对于承载的流量，要从同一个会话中读取数据通道那一行。配置里的 data-ciphers 列表是允许使用的集合，并不能证明协商了某个特定算法。日志记录的是选择结果；配置记录的是菜单。

AES-GCM 这类 AEAD 加密自带完整性校验，因此这条路径上并不存在单独的数据通道 HMAC。

auth 指令不会升级 TLS、证书或数据加密算法。它为仍在使用摘要的那部分协议挑选摘要，而在 AEAD 数据加密之下，没有单独的数据 HMAC 需要配置。

把身份校验与加密结果分开

证书签名算法、信任链校验和对等节点名称验证，是另外三项属性，加密名称对它们只字未提。证书过期就会失败，无论套件多强都一样。服务器名称不匹配也同样失败。修改配置里的摘要设置，这两者都修不好。

把这些校验放在加密结果旁边的复核记录里，而不是并进结果里。

记录当前会话协商出的结果

从当前连接取结果，并把客户端与服务器版本一并记录下来。只追加的日志会保留旧会话的行，把它当作当前结果引用，就会让已经修好的问题看起来仍在继续。

做策略复核时，把协商出的 TLS 版本与套件、选定的数据加密算法、证书校验设置一起交给配置负责人。改动那一层之后，再读一份新日志来确认新的协商值。