IKEv2 不止一次握手：先 IKE SA，再认证，然后 CHILD SA
网关的回应只证明可达，不证明身份。依次观察 IKE_SA_INIT、IKE_AUTH 和第一个 CHILD SA，再检查流量通过前必须成立的条件。
你可能以为 IKEv2 连接就是一次交换，最后你的流量被加密。其实至少是两次，而且第一次不认证任何人。双方先用控制消息协商加密参数、证明身份，之后才协商承载应用数据包的状态。这个顺序解释了人们反复报告的现象：网关回应了，客户端显示已连接，私有应用却仍然超时。下面说明每个阶段实际做了什么，以及之后必须成立什么。
误解：网关回应了就等于连上了
对第一条消息的回应证明端点可达并且愿意对话。但它不证明账号被接受、证书链通过验证，也不证明装上了任何数据策略。
这些失败发生在后面，症状也不同。证书被拒或 EAP 失败都出现在第一次交换成功之后，所以 ping 一下 UDP 500 和绿色的客户端图标说明不了什么。
IKE_SA_INIT：协商参数，而不是身份
第一次交换携带 IKE 安全关联的提议：加密与完整性算法、伪随机函数和 Diffie-Hellman 组。双方还交换 nonce，各自用这些值产生的共享秘密推导 IKE SA 的密钥材料。这次交换不确立对方是谁，只确立双方能算出相同的密钥并就一份提议达成一致。任何提议都不满意的响应方会在这里拒绝交换。所以版本或算法不匹配看起来像服务器挂了。
此时建立的 IKE SA 保护之后所有管理交换。这是它的职责，与保护你的数据包是两回事。
IKE_AUTH：证明身份，然后建立第一个 CHILD SA
第二次交换携带身份。使用证书时，每一方用自己的私钥签名，并出示对方必须验证的证书链；使用 EAP 时，响应方用选定的方法向发起方发起挑战。错误的服务器名、过期的证书或被拒绝的密码都在这里浮现。
通常情况下 IKE_AUTH 还协商第一个 CHILD SA，数据保护在同一来回中确定。发起方提出流量选择器，响应方收窄或拒绝，数据路径的密钥从 IKE SA 推导。这意味着一次交换可能在两个完全不同的地方失败：身份或策略。要看通知载荷或错误码，而不是笼统的握手失败，因为一个是证书问题，另一个是子网不匹配。
两个 SA，两种职责
| 关联 | 保护对象 | 生命周期行为 |
|---|---|---|
| IKE SA | 管理交换：重新生成密钥、删除、配置载荷 | 按自己的时间表重新生成；数据路径可以在变更中存活 |
| CHILD SA | 与流量选择器匹配的应用流量 | 独立重新生成，通常更频繁 |
把两者分开就能解释两种看似故障的行为。隧道显示已建立，而后台的重生成密钥正在失败；CHILD SA 被替换，客户端却不会断线。
在 strongSwan 上，IKEv2 配置参考和swanctl --list-sas会显示两个层次，而ip xfrm state加上ip xfrm policy显示内核实际安装了什么。对比这两个视角，是判断协商真的完成还是看起来完成的最快办法。如果守护进程列出的 CHILD SA 在内核里没有状态，安装就是静默失败的。如果内核持有守护进程不知道的状态，你看到的是上次尝试的残留。
隧道建好之后还必须成立什么
流量选择器决定覆盖哪些地址。如果客户端提议一个子网而服务器期望另一个，CHILD SA 装上了却不承载任何有用的东西，错误表现为路由问题而不是协商问题。接着本机协议栈必须配合：在主机做路由的地方开启转发、指向隧道的路由、允许解封装数据包的防火墙规则，以及涉及私有名称时的内部解析器。这些各自独立失败，重启 IKE 守护进程一个也修不好。
排障时让日志保持可见：先看初始交换，再看身份验证，然后看适用的用户认证，接着看 CHILD 安装，最后看应用流量。停在哪一步就修哪一步，后面的路由故障绝不是放松已通过的身份检查的理由。