AES-256 还是 OFB：选择完整的 VPN 加密构造

AES-256 和 OFB 回答的是不同的问题，把它们当作互相竞争的选项，正是加密评审出错的地方。一个指的是带密钥长度的分组密码，另一个描述的是分组密码如何变成用于更长报文的流。选择防护方案的操作手册必须看整个构造，包括接收方如何发现被改动的数据包。

说清构造的四个部分

任何评审都会归结为四个问题：用哪种原语和密钥长度，报文如何处理，接收方如何拒绝未经授权的改动，以及协议如何管理输入、密钥及其生命周期。熟悉的名字清单只回答了第一个。第二个和第三个才是真正差异所在，第四个则是各实现悄悄分道扬镳的地方。按这个顺序提问，并把答案写下来。

OFB 出现在 NIST 关于分组密码模式的出版物中，属于机密性模式，而它提供的也只有机密性。把加密模式与独立 MAC 搭配的协议必须正确组合两者，算法名称并不能证明这种组合。因此仅凭模式名称无法决定部署选择。

第四个问题才是运维人员真正能在运行系统上核实的。

优先选择带认证的构造

带认证的加密同时提供机密性与完整性，AEAD 构造还能在不加密关联数据的前提下保护其不被改动。这是数据包保护的性质，与是否有人成功登录无关。

Netgate 的 Netgate 关于 OpenVPN 加密设置的指南 为数据通道指出 AEAD 选项，其中包括 AES-GCM，这正是应当遵循的受支持策略。使用已安装版本和对端客户端支持的选项，而不是把历史上的模式排序照搬到新部署里。遗留兼容性、加密后端和卸载支持都会限制实际可用的范围。

受支持的构造每次都胜过聪明的组合。

读协商结果，而不是候选列表

某个密码出现在可接受列表里，并不能说明当前会话。从客户端或网关读取协商出的数据通道保护，再与你想执行的策略比较。为某个老对端仍列着旧选项的配置，是兼容性决定，不是对你面前这次会话的陈述。

openvpn --config client.conf --verb 4 2>&1 | grep -Ei 'cipher|data channel|auth'

在网关上，等价输出是安全关联或连接的加密细节，具体取决于平台。两种情况下，候选与实际结果是不同的事实。列表里包含针对某个老对端的旧选项，并不意味着每次会话都用它；真正用了它的那次会话，才是你需要知道的。

把两个事实一起记录下来，附上日期和客户端版本。

只测量可比的内容

吞吐量取决于端点硬件、实现、加速、数据包大小和所选配置。密钥长度和 OFB 这个词都不会告诉你哪种部署更快。因此别的站点上的基准测试，充其量只是关于别人硬件的提示。你自己的数字要从你自己的端点开始。

做获准的对比时，保持端点、工作负载和所需策略不变，并记录协商出的保护与实现版本。然后根据应用是否完成、丢了多少、端点当时在做什么来判断，而不是从一次测速推断加密开销。在别的条件下得出的数字是故事，不是测量。

如果老对端无法满足策略，那是它自己的兼容性决定。

别把完整性当作交换筹码

关闭完整性检查，或接受未经核验的服务器，不是性能优化，也不是兼容性修复。它改变了选择该构造所要提供的安全性质。把可接受密码列表放宽到老对端能连上，也是同一回事：连接成功了，策略却不存在了。

把可接受的构造及其负责人写进操作手册，让下一次改动从决定出发，而不是从偏好出发。

你要的是两端都能执行的策略。争论哪个名字最强是另一场对话，而且通常在没有结论中结束。