RADIUS 为何看到 IP 地址而不是 VPN 用户名

strongSwan 可以在任何 EAP 交换之前把 IKE 身份写入 RADIUS User-Name。先确定由谁请求账户身份，再关联一次尝试。

Windows IKEv2 客户端连接后，RADIUS 请求带着一个地址到达，而那里本应是账户名。目前还没有任何失败，令人困惑的正是这一点：网关报告的是 客户端在 IKE 层出示的身份。后端想要的用户名可能来自一次尚未发生的独立 EAP 交换。在改动账户之前，先确定由谁去请求它。

一个连接中有两个身份

一个连接中可能出现两个名字。IKE 身份在隧道建立时标识对端，eap-radius 插件最初把它复制到 RADIUS User-Name。EAP 身份是另一个值，用于用户认证；如果没人请求，它可能永远不会被发送。

因此，即使账户存在、密码正确，RADIUS 日志也可能显示一个地址。后端被问询的是错误的层。RADIUS 属性只是所选名字的传输载体。

让网关请求 EAP 身份

一种受支持的配置让网关在把认证交给 RADIUS 之前请求 EAP 身份。在连接的远程认证部分，把方法设为 eap-radius，并显式请求 EAP 身份。下面的片段属于现有连接块内部，而不是独立文件。在从其他部署复制语法之前，先确认连接和配置后端。

remote {
    auth = eap-radius
    eap_id = %any
}

这样一来，后端收到的是客户端在 EAP 交换中提供的身份，而不是 IKE 地址。连接的其他部分不会改变。

或者让 RADIUS 发起 EAP 交换

另一种配置把第一步放在 RADIUS 一侧。插件可以发送 EAP-Start 指示，而不是等待初始身份响应，这让服务器能够主导交换。这是插件级配置，因此会影响所有使用该插件的连接。

charon {
    plugins {
        eap-radius {
            eap_start = yes
        }
    }
}

与 RADIUS 运营方一起选定一种配置，而不是把两种都打开再碰运气。它们描述的是不同的工作流，而期待自己先开始的服务器未必能应付主动开启会话的网关。插件文档 描述了这两种方式，包括每一步携带哪个身份。

在两个日志中跟踪一次尝试

在两个日志中关联同一次尝试。先看 IKE 身份，再看是否发生 EAP-Identity 交换，然后看认证步骤收到的是哪个名字。如果在 EAP 交换之前就拒绝该地址，后端可能会在你预期的身份出现之前终止流程。

journalctl -u strongswan -f

保留身份系统所期望的准确用户名格式，包括域前缀。绝不要用形似地址的值去编造账户，也绝不要为了满足策略规则而关闭认证。EAP 身份是一个被声明的名字，方法仍然必须证明它。把结果名字写入测试记录，让下一次尝试从已知状态开始。

如果修正后的流程到达了正确的账户却仍被拒绝，下一步的证据是 EAP 方法和后端策略，而不是身份。重复重置密码无法修复在更早协议层上选定的值。

相关文章