IKEv2：密钥更新与重新认证的区别——连接为何会稍后掉线

隧道早上建立，能连续工作几个小时。随后它掉线，重试一次后重新连上，第二天又是同样的情形。网络没有任何变化，也没有人动过密码。在更新边界失败的会话，通常越过的是两种不同操作之一，而其中只有一种会重新校验你的凭据。读对它究竟是哪一种，整个诊断就完成了。

两种从外部看很相似的操作

密钥更新在协议规定的交换范围内替换安全关联或密钥材料。身份认证不会重复，因此会话开始时被接受的身份只是被继续沿用。

重新认证则更进一步：它建立一段全新的已认证关系，这意味着凭据会被再次评估。凡是已过期、已被吊销或在目录中被改动的，都会在那一刻暴露出来。

密钥更新真正替换的是什么

IKEv2 维护两类生命周期彼此独立的安全关联。IKE SA 保护控制通道，CHILD SA 保护实际流量。更新其中一类并不等于让客户端重新连接。

这种分离解释了一个常见情形：流量一直正常，随后某个 CHILD SA 被更新，提议却不再匹配，因为几周前有人在一侧改过第 2 阶段。那处改动一直无害地待在那里，直到更新把它触发出来。

生命周期不一致也是同样的表现。哪一端先到达自己的上限，就由它发起交换，另一端必须接受。

重新认证重新评估的是什么

在重新认证中，登录时还有效的客户端证书此时可能已经过期。被吊销的凭据、轮换过的密码，或不可用的第二因素，都会在这里浮现，而不是在更新时。

所以把每个生命周期都拉长，看起来像是修复，其实不是。你只是把检查推迟了，并没有通过它。下一次更新会带着同样的缺陷到来，而且留给你察觉的停摆窗口更短。

有些实现会在重新认证期间让新旧状态重叠。另一些则产生短暂空档。因此，两家厂商上的相同配置可能带来不同的用户体验。应当测试实际行为，而不是假定标准已经规定了一切。

先读时间戳，再动手改任何东西

把失败时刻与关联在失败前后的状态一起记录下来。如果旧关联在没有认证交换的情况下被替换，你处在更新边界。如果失败前紧接着出现 AUTH 交换，你处在重新认证。

strongSwan 把这些暴露为彼此独立的设置：rekey 控制密钥更新，reauth 控制是否进行新的认证，而 margin 值决定两者各自在到期前多久开始。关于密钥更新的文档描述了这种相互作用，值得在从论坛帖子照抄生命周期之前先读一遍。

把这一切与普通网络丢包区分开。链路中断会产生对端失效检测事件或重传风暴，而不是带有匹配提议的干净交换。

改动真正失败的那一环

凭据被拒需要修好身份问题：续期证书、恢复账户、重新登记因素。提议或生命周期不匹配，则需要比对两侧的参数。

为回避症状而拉长生命周期，是唯一一种看上去总是奏效、实际却从不奏效的做法。

做一次受控的更新测试

主动强制触发更新，而不是等上一天。然后，如果部署支持，再用重新认证重复一次，并同时观察两端。

首次登录成功并不会演练这些。真正让这类部署出问题的，是之后的整个生命周期。