strongSwan EAP：IKE 身份与预期的 AAA 名称

在 IKEv2 之上的 EAP 认证，可能要求客户端在一条连接里校验两个不同的服务器名称。终结 IKE 的网关出示一个身份，而终结内部 TLS 交换的 EAP 后端可能出示另一个。在 strongSwan 里，它们位于不同的配置块，把名称放进错误的块会产生看起来像证书问题的那种失败。只有读清是哪一项校验失败，才知道该改哪个块。

一条连接，两个服务器身份

第一个身份属于 IKE 交换。客户端拨号到某个地址，并期望对端证明某个特定身份，通常就是网关证书里的名称。

第二个属于 EAP。使用 PEAP 或 TTLS 时，客户端在 IKE SA 内部建立到认证服务器的 TLS 隧道，那个内部服务器会出示它自己的证书。当后端是另一台主机时，它的名称与网关不同。只校验第一个名称的客户端，会接受第二个名称所声明的任何内容。而在两处都配置同一个名称的客户端，一旦两者确实不同就会失败。

两个名称都来自运营方的配置，而不是来自那个让错误消失的证书。向运营方询问部署细节，比猜测两个主机名更快。

哪个字段属于哪一层

在 swanctl 中，地址和 IKE 身份是分开的设置，EAP 身份是第三项。

远程地址决定数据包发往何处，远程身份说明对端必须证明什么。EAP 的期望写在 local 块下面，因为它描述的是本客户端的 EAP 交换，而不是对端的 IKE 行为。正是这个位置常被误读。名称位于客户端的配置中，却在描述一台服务器，所以它才显得放错了地方。

connections {
    office {
        remote_addrs = vpn.example.com
        local {
            auth = eap-peap
            aaa_id = auth.example.com
        }
        remote {
            auth = pubkey
            id = vpn.example.com
        }
    }
}

这段片段并不是一条完整的连接；信任材料、凭据和子连接策略仍然必须存在。把它逐字复制到工作文件里，会替换掉你仍然需要的设置。

aaa_id 为什么住在 local 下面

local 块描述这一端在认证期间做什么，包括它将使用的方法，以及它期望对端为该方示出的身份。其中没有任何内容声称 AAA 服务器运行在同一台机器上。

默认值让陷阱更锋利。没有显式设置值时，预期的 AAA 身份会跟随远程身份，于是单名称部署能工作，并掩盖了这一区别。只有当 EAP 部署确实终结在别处时，显式值才有意义。没有那个理由就把它设成另一个名称，会造成运营方无法复现的失败。在编造第二个名称之前，先读部署。

让取值与后端证书实际声明的内容完全一致，包括名称的形式。结尾多一个点，或通配符覆盖不到该主机，就足以让校验失败。

无法表达这种分离的前端

NetworkManager 配置文件并不是与 swanctl 相同的配置接口。它背后的插件只暴露较窄的一组身份控制项，具体有哪些取决于已安装的版本。

当部署确实需要两个名称时，这一点就很重要。标为服务器身份的字段可能只配置了一层而没有配置另一层，于是配置文件看起来正确，却仍在内部校验上失败。在假定该配置文件能表达这种安排之前，先确认已安装的插件支持什么。如果它不支持，选择权在运营方：换一条开通路径，或者修正服务器身份设计。削弱 PEAP 或接受任意名称，是在改变认证策略而不是修正它。

替代方案不是要在客户端上发明的东西。以书面形式索取受支持的安排，然后把那份答复与配置文件放在一起。

把身份不匹配与证书过期区分开

名称不匹配和证书过期是两种不同的失败，日志会把它们区分开。在决定改哪个字段之前，先读那条消息。

swanctl --list-conns
swanctl --list-sas
journalctl -u strongswan -n 50 --no-pager

设置预期的 AAA 身份不会续期证书，也不会建立对其签发者的信任；而续期证书也不会纠正错误的预期名称。在编辑另一个身份字段之前，先读清是哪项校验失败。然后重新加载配置，确认已加载的连接显示出你设置的值，因为一个从未被加载的已编辑文件什么也不会改变。把两个名称及其所属层写进部署笔记。