为什么更大的 OpenVPN 密钥并不能取消重新协商定时器

选择 AES-256 或更长的密钥，并不能说明这个密钥可以使用多久。 密钥强度描述的是算法；重新协商策略才决定会话何时派生新的密钥材料。部署可能选了当前最强的密码，却仍然在续期问题上出错，因为这两个决定是在不同地方做出的。把二者混为一谈，结果要么是多余的密码更换，要么是会话静默地活过了策略规定的时限。

在改动密码之前先读重新协商的设置，而且要看通信两端的设置。

密钥强度与密钥寿命回答的是不同问题

密码和密钥长度限制的是攻击被截获流量需要多高的成本。重新协商间隔限制的则是一个密钥保护多少流量、被泄露的密钥还能用多久。这是两个彼此独立的旋钮，更强的密码并不会延长会话的安全寿命。多数建议只说“使用 AES-256”，对续期只字不提，因为续期属于策略问题，而不是算法选择。

在部署记录里把两者都写清楚：数据通道由什么保护，以及什么条件触发它更换密钥。

重新协商有三个触发条件，任意一端都可以发起

OpenVPN 2.6 分别记录了按字节、按报文和按经过时间三种重新协商触发条件。时间触发是多数部署保持默认的那一项，这意味着即使隧道很安静，也会按计划更换密钥。任意一端都能发起交换，未发起的一端随后跟随。因此只改一端的定时器并不会决定会话的行为；真正生效的是先发起那一端的取值。

字节和报文触发在高吞吐或小报文负载下才有意义，因为只按时间判断的策略会让一个密钥保护远超预期的数据量。如果这些计数器一直关闭，就要在记录里明确写明，而不是把默认值留着不查。

一次密钥更新会暴露身份验证流程

重新协商就是一次全新的 TLS 握手，这意味着身份验证路径要重新走一遍。使用一次性验证码、硬件令牌或 RADIUS 挑战的部署会以很痛的方式发现这一点：第一次连接正常，一小时后第二次握手要求提供已经用过的验证码，会话就此中断。 auth-gen-token 的存在正是为了弥合这个缺口：让服务器为重新协商签发一个短时令牌，而不是要求用户重新做一次交互式登录。

应把它当作要和运维人员一起解决的工作流问题，而不是关闭续期的理由。

要在负载下测试续期，而不是在一分钟的会话里测试

连上、ping 一次、断开，这样的验收测试永远走不到重新协商那一步。要运行足够长的会话跨过配置的触发条件，期间保持传输不断，并观察两端的日志确认新的握手。然后再测失败路径：如果重新协商无法完成，客户端会怎么做。干净断开的隧道比一直往死会话里发数据的隧道更容易诊断。

不要把一次成功的大流量传输当成密码学阈值的证明。它只能说明路径和计数器扛住了那么多流量。

把两个选择都记录下来

记录需要两行：报文如何被保护，以及这种保护何时被替换。每个取值都要写明依据，因为密码可能来自发行版默认值，而定时器来自内部策略。后来的运维人员不该只能从配置文件里去猜这两件事。

如果兼容性迫使你要开一个例外，就把它限定在某个版本和某个结束日期。一个活得比理由更久的例外，会变成谁都不记得当初选过的策略。