两种「更新」不是一回事
rekey 是密钥轮换：按 RFC 7296 的流程重新协商新的密钥材料，但 SA 与身份关系延续，业务通常感觉不到中断。reauth 则是完整的重新认证：重跑一次 IKE_AUTH，重新校验双方身份，代价是更高的中断风险，尤其在依赖外部认证服务器或严格策略的环境里。IKEv1 只有 rekey 概念，reauth 属于 IKEv2 的能力。两者的周期由各自的定时参数控制，实践中的原则是让 reauth 周期远长于 rekey，或者直接关闭 reauth，把密钥更新的职责交给 rekey 完成。
基本信息
| rekey | 仅轮换密钥，SA 与身份延续，影响小 |
|---|---|
| reauth | 完整重新认证，重新校验身份，中断风险更高 |
| 控制参数 | rekey 时间与 reauth 时间分别设置 |
| 协议差异 | IKEv1 只有 rekey，reauth 属于 IKEv2 |
| 建议取值 | reauth 周期明显长于 rekey，或关闭 reauth |
典型使用场景
- 合规要求定期换密钥：通过 rekey 周期满足要求而尽量不影响业务
- 排查隧道周期性中断：确认中断周期是否与 reauth 或 rekey 时间吻合
- 两端参数对齐：避免一方频繁重协商导致另一方也被拖入重建
- 对接外部认证的隧道：评估 reauth 是否会因认证服务器响应慢而失败
- 调整生存期：按业务对中断的容忍度选择更保守的参数
参数示例
参数示例
# strongSwan 配置：轮换与重认证分开设置
connections {
site2site {
rekey_time = 1h # 每小时轮换一次密钥
reauth_time = 0 # 0 表示不启用重新认证
}
}
swanctl --list-sas | grep -i rekey # 查看下次轮换时间
show crypto ikev2 sa | include rekey # Cisco 侧观察生存期参数与影响
| 参数 | 作用 | 设置不当的后果 |
|---|---|---|
| rekey 时间 | 密钥轮换周期 | 过短会频繁重协商，产生抖动 |
| reauth 时间 | 重新认证周期 | 过短会在严格策略下反复中断业务 |
| 生存期 | SA 最长存活时间 | 两端差异过大导致交替重建 |
| 两端一致性 | 双方参数需协调 | 差距过大时按各自节奏重协商，形成额外抖动 |
排查周期性中断时，把中断间隔与 rekey、reauth、生存期三组时间对照，往往一眼就能看出是哪个定时器在起作用。
把 reauth 当作无关紧要的过场配置是有风险的：它会重新触发身份校验，遇到认证服务慢或策略收紧时可能直接导致隧道无法恢复。