IKEv2 服务器地址与身份：客户端实际检查的内容

更改地址的网关可以继续工作，而新证书后面的同一网关则停止工作，反之亦然。地址告诉客户端将数据包发送到哪里；经过身份验证的身份告诉客户端对等应答是否是它应该信任的那个。IKEv2 将它们保留为两个单独的字段，一旦您停止将它们视为一个字符串，这将很有用。它们也配置在不同的地方，因此一个可能是正确的，而另一个是错误的。

按此顺序检查它们，并在第一个不匹配处停止，因为后面的检查假定前面的检查通过了。

一、哪个值是地址

连接地址是客户端拨打的任何地址：IP、解析为某个地址的 DNS 名称或负载平衡的前端。这只是交通信息，仅此而已。该身份位于 IKEv2 ID 有效负载中，然后与对等方的证书进行匹配。地址框中的 DNS 名称不会成为预期的身份，并且原始 IP 不会仅仅因为套接字连接到它而成为身份。

在strongSwan术语中，地址是right或left，预期标识是rightid或leftid，这就是IKEv2配置文档所描述的。如果您只编辑过该地址，则您已经配置了该地址对的一半。

二、证书能证明什么

身份有一个类型，并且证书必须带有匹配的名称。DNS 身份由主题备用名称扩展中的 dNSName 条目满足； IP 身份需要 iPAddress 条目。为 vpn.example.com 颁发的证书无法证明有关文字地址 203.0.113.10 的任何信息，而为该地址颁发的证书则无法证明有关名称的任何信息。因此，即使重复使用相同的密钥和 CA，重新发布不同的名称也不是直接替换。

当存在主题替代名称时，现代客户端会忽略通用名称，并且许多客户端完全忽略它。如果SAN列表不包含客户端检查的值，则在证书已被接受为可信后握手会失败，这就是日志读起来像身份错误而不是信任错误的原因。

第三，每个客户如何陈述期望

Windows 获取您键入的服务器名称或地址，并要求证书与之匹配，因此键入 IP 会创建 IP 期望。Android 的 IKEv2 客户端的行为方式相同，并且都拒绝命名不同主机的有效的、公开信任的证书。配置文件可能仅仅因为有人在迁移期间用其地址替换了主机名而开始失败。在查看证书包含的内容之前先看看客户要求的内容。

在 strongSwan 上，期望是明确的：将 rightid 设置为服务器实际呈现的身份，这可能与正确的不同。将其设置为 %any 接受对等方提供的任何内容，并准确删除您试图保留的检查。

四、将用户登录与对等身份分开

EAP身份验证和服务器身份回答不同的问题。在客户端确定服务器是正确的之后，EAP 身份（例如 [email protected]）表明用户是谁。轮换该密码无法修复对等身份不匹配的问题，因为连接永远不会到达用户登录阶段。

经过清理的报告应同时列出以下内容：客户端期望的身份、服务器提供的身份以及证书的 SAN 条目。

五、通过经过验证的渠道进行更改

当网关合法移动时，先更新地址，不要管身份，因为这种情况IKEv2处理得很好。当身份本身发生更改时，请将其视为信任事件，并从您已经信任的源获取新值，而不是从当前发生故障的端点获取新值。通过您尝试验证的连接传递的消息并不是有关该连接的证据。

将最终地址、身份和 SAN 列表一起记录在个人资料注释中。下一个触摸证书的人将看到这三个人中的哪一个被允许移动。