IKEv2 交换成功之后认证失败：该从哪里查

收到 IKEv2 响应的客户端已经证明网关可达、双方能够协商提案、初始密钥交换也已完成。但它还没有证明任何一方通过了认证。下一次交换会携带身份、证书或 EAP，连接通常就停在这里。读懂是哪一道检查失败，就是全部诊断工作，而仅凭错误信息很少能说清楚。

检查 1：看阶段，不要只看消息

拒绝可能来自三处：客户端拒绝服务器身份、网关拒绝客户端凭据，以及外部认证服务拒绝该账户。

每一种都会在不同机器上留下不同的日志行，修复方式也各不相同。客户端侧拒绝服务器证书，是客户端上的信任或命名问题；网关侧拒绝客户端证书，是网关上的信任问题；EAP 失败则是账户或后端问题。你看到的消息通常只是客户端对其中之一的概括，所以网关日志和客户端日志同样重要。

检查 2：检查的是哪一个身份

在提供任何用户凭据之前，客户端就可能拒绝服务器证书或它期望的身份，而一个可用的服务器地址并不能替代这项检查。客户端期望的标识必须与网关出示的一致，这属于配置事实，而不是网络事实。

用 strongSwan 的说法，就是客户端上的 rightid 与另一侧网关自身的身份，一旦不匹配，在讨论 EAP 之前就会失败。

网关还可以单独拒绝客户端证书、密钥证明或账户认证，这三者不能互相替代。重置用户密码不会续期设备证书，重装设备证书也修不好错误的服务器身份。遇到证书失败，先查时钟，再查信任链，最后查期望的标识；时钟偏差几分钟的客户端会在有效性检查上失败，看起来却像信任问题。swanctl --list-certs 可以在两端显示各自实际持有什么。

检查 3：如果涉及 EAP

客户端和服务器必须就一种受支持的方法达成一致，后端也必须接受所提供的身份。

用户名可能需要部署所要求的域后缀或特定账户格式，而这种格式是有文档的，不是猜出来的。按运维文档填写字段比反复试错更快，也能避免第二个问题：反复尝试可能触发账户锁定，从而把最初的阶段藏在一个新的失败后面。如果方法是针对目录的 EAP-MSCHAPv2，失败可能属于目录而不是 VPN。

不要通过关闭身份检查来测试身份问题。那会把可诊断的失败变成无法诊断的失败，并让连接比之前更弱。

检查 4：登录成功之后会发生什么

IKE_AUTH 完成之后，由 CHILD_SA 协商决定安装哪些流量选择器，连接可能在这里成功却什么都传不过去。

刚刚可用的登录往往会暴露此前藏在认证失败背后的选择器或路由问题。如果隧道起来了而应用仍然到不了目的地，就去看协商出的选择器和路由，而不是再看身份。此时改身份设置瞄准的是错误的阶段，通常会弄坏原本可用的登录。用 swanctl --list-sas 确认，它会把子连接及其选择器与 IKE SA 分开显示。

检查 5：该交给支持团队什么

一份清理过的时间线加上精确的拒绝点，比完整的诊断导出更有价值，而导出里可能含有你不该分享的私钥或凭据。

记录时间与时区、客户端和网关版本、方法、所提供的身份字符串（而不是密码），以及拒绝它的确切阶段。strongSwan 的 IKEv2 配置文档 描述了决定这些结果的身份与 EAP 设置，是在改动字段之前应该阅读的参考。然后一次只改一处，并重新测试新连接，因为缓存的会话只会告诉你旧配置的情况。