EAP 还是客户端证书？IKEv2 身份验证怎么选

网关可以用证书证明自己的身份，同时通过 EAP 证明你的身份，这种组合很常见，并不矛盾。两套机制回答的是不同问题：这个端点是不是我预期的那个，这个用户或设备是否被允许。在配置里看到 EAP 并不会关闭服务器校验。把配置当成单一设置来读，正是人们重置错凭据的原因。

在动这两样东西之前，先判断是哪一项主张失败。按顺序读下去，失败环节会告诉你答案。

两种凭据，两项主张

服务器证书把名称绑定到密钥，客户端拿自己的信任库校验这层绑定。客户端证书把身份绑定到密钥，网关则校验所提交的证书能否链到它信任的对象。EAP 承载的是一次认证交换，其内容取决于所选方法。这是三种生命周期、归属方和失效方式都不同的结构。

解锁私钥的口令不是账户密码，哪怕两个提示相隔几秒先后出现。一个属于设备密钥库的本地范围，另一个由网关背后的认证服务器校验。

EAP 是容器，不是方法

EAP 是一套框架：网关与客户端协商方法，由方法决定涉及密码、令牌、隧道内层交换还是证书，正如 strongSwan 的 IKEv2 文档 所述。这就是为什么从客户端一侧看，EAP-TLS 与 EAP-MSCHAPv2 毫无相似之处，尽管两者在菜单里都显示为 EAP。只写 EAP 的配置，并没有告诉你用户会被要求提供什么。

把方法和后端放在一起读。后端决定账户格式、锁定行为以及重置密码究竟改变了什么，而这些在客户端配置里都看不到。

混合部署是常态

为用户使用服务器证书加 EAP，是大多数远程访问网关采用的形态，因为它既给客户端一个可验证的端点，也给运维方在集中账户库中按用户区分身份。也存在使用客户端证书的部署，通常出现在设备身份比密码更重要的场景。两者都合理，错的是把上周见到的那套当成眼前的这一套。

向运维方索取有文档记载的方法与账户格式，而不是从客户端里的字段名去推断。

从失败环节判断

把观察结果排序。任何用户提示之前的信任错误都是服务器证书问题，任何密码都修不好。提示之后被拒绝，属于用户认证问题，嫌疑对象是 EAP 方法与后端。认证成功之后出现 child-SA 失败，则两者都不是。

还有两处区别值得注意。拒绝服务器证书的客户端通常报告名称不匹配或未知颁发机构，这是信任库的问题。拒绝用户的网关往往会记录 EAP 方法和原因类别，这是账户或策略的问题。

运营两套模型

证书这边的工作是签发、续期、吊销和丢失设备下线，按你可控的时间表进行。EAP 这边的工作是账户生命周期、各客户端平台的方法支持，以及后端要求的任何第二因素。两种模型在抽象意义上都不更便宜，它们压在不同团队身上。写清楚你的部署实际用的是哪一种，因为支持脚本的差异比配置更大。

在笔记里把两者分开。证书过期会在某个日期造成失败，账户锁定会在改密之后造成失败，方法不匹配只会在单一平台上造成失败。

身份被接受之后

认证只是一道门。child 安全联盟、流量选择器、DNS 以及应用自身的权限都是后面的门，各自按各自的条件失败。被接受却什么都到不了的身份，不是认证问题。

记录方法、所用账户或证书，以及失败的环节。这条记录能把下一次故障变成一次查阅，而不是一次试验。