经 VPN 网关的 EAP：谁终止了认证方法

服务台工单常把 VPN 登录失败和 RADIUS 要求更强方法当成同一个问题来描述，但两者并不是一回事。网关要么接收凭据并转发，要么在客户端与认证服务器之间承载一段 EAP 对话。究竟属于哪种情况，决定了改服务器端策略能否解决问题。在改动服务器组之前，先读懂这次交换。

日志里看起来相同的两条认证路径

第一条路径中，VPN 网关收集用户名和口令，并发送带口令属性的 RADIUS Access-Request。认证服务器拿它与自己的凭据库比对，返回接受或拒绝。客户端从不执行 EAP 方法，因为没有人要求它这样做。

第二条路径中，客户端与认证服务器端到端地执行 EAP 方法，网关只在两者之间转发 EAP-Message 属性。网关仍然终止外层 RADIUS 对话，但方法逻辑位于两端。

两条路径都会在日志里留下“认证失败”的一行。只有第二条会受到服务器偏好哪种 EAP 方法的影响，也只有第一条会受到网关如何读取口令的影响。把两者当成可互换的，正是团队为一个根本不会说 PEAP 的客户端白改一整天服务器组的原因。

RFC 3579 定义了透传安排：NAS 用 RADIUS 属性承载 EAP 报文，不需要为每种 EAP 类型编写专门代码。所以网关可以在不实现任何一方的情况下支持 PEAP 与 EAP-TLS。

投递口令的网关并没有承载 PEAP，即使后端会接受来自另一个客户端的 PEAP。在服务器策略里启用 PEAP，并不会给一个从未提供过该方法的客户端增加方法。

PPP 认证设置属于 PPP 服务。它不会悄悄重配使用同一台 AAA 服务器的每条 IPsec 或旧式 XAuth 路径，因此对一种接入类型有效的改动，可能完全不影响另一种。

透传把要求从方法代码转移到承载能力上。网关必须能通过自己的 VPN 协议承载 EAP，其上的 RADIUS 客户端必须能发送和接收相应大小的 EAP-Message 属性。

对 IKEv2 来说，EAP 属于一条已定义的认证流程，服务器身份与信任检查都来自该流程。从 802.1X 部署借来的 PEAP 标签不会自动迁移，因为围绕它的协商并不相同。

客户端一侧同样有要求。它必须为该方法配置好、信任方法出示的服务器证书，并持有方法可用的凭据。基于证书的方法若没有客户端证书，会在 RADIUS 看到任何东西之前就失败，这属于配置发放问题，而不是服务器策略问题。

在网关和认证服务器上各抓取一次已批准的尝试。在 RADIUS 请求里查找 EAP-Message 属性。出现了，说明走的是透传路径；没有出现，则指向凭据交换。

在 Linux 网关上，对 RADIUS 端口抓包可以看出链路上有哪些属性：

sudo tcpdump -ni any -X 'udp port 1812' -c 20

然后比较被拒绝的位置。在任何 RADIUS 报文之前网关就失败，说明客户端与网关对方法没有达成一致。带 EAP 属性的 RADIUS 拒绝，说明两端执行了方法，而其中一方拒绝了结果。

换方法意味着同时改客户端配置、网关的承载支持、服务器的方法策略和凭据库。按这个顺序来做，并在新路径被证实之前保留可用路径。只改服务器端只是猜测，而且通常会弄坏原本正常的客户端。动服务器组之前，先在一个测试身份上演练变更。

记录可用的组合：VPN 协议、EAP 承载、对端方法、服务器方法、凭据类型和服务器身份检查。

除非任务明确同时涉及两者，否则把管理登录 AAA 与 VPN 认证分开。为远程访问做的改动，不应该让你失去管理那台终止它的设备的能力。