RADIUS 经 F5 VIP 后真实地址回包问题分析笔记

· 9 分钟阅读
RADIUS F5 802.1X 网络排障 负载均衡

1. 结论摘要

本次抓包中，锐捷 S5310 交换机 93.4.19.204 向 F5 虚拟地址 93.0.177.12 发起 RADIUS/802.1X 认证请求，但响应报文由后端真实地址 93.224.14.1 直接回给交换机。

测试时交换机配置为：

aaa group server radius 2
 server 93.0.177.12
 server X.X.X.X

aaa authentication dot1x default group 2

其中 group 2 不包含旧配置中的 F5 后端真实地址 93.224.14.1。因此，本次认证能够通过，不能解释为“93.224.14.1 本来就在 RADIUS 服务器列表中”。更合理的判断是：

锐捷 S5310 在该 dot1x/RADIUS 场景下，没有强制要求响应报文源 IP 必须等于配置的 radius-server IP。
它接受了来自 93.224.14.1 的 RADIUS Access-Challenge / Access-Accept，
并依据 RADIUS 协议层的 Identifier、Response Authenticator、shared secret 继续完成认证。

认证结果可用，但 F5/VIP 回程形态不规范。标准和更稳妥的生产形态应当让交换机看到响应源地址仍为 VIP：

93.0.177.12:1812 -> 93.4.19.204:1812

而不是：

93.224.14.1:1812 -> 93.4.19.204:1812

2. 拓扑示意

flowchart LR
    Client["终端 / Supplicant"] -->|EAPOL| SW["锐捷 S5310<br/>SD53XF04-A4<br/>93.4.19.204"]

    SW -->|RADIUS Access-Request<br/>dst 93.0.177.12:1812| F5["F5 Virtual Server<br/>VIP 93.0.177.12:1812"]

    F5 -->|负载均衡 / DNAT| RS["后端 RADIUS 真实服务器<br/>93.224.14.1:1812"]

    RS -.->|Access-Challenge / Access-Accept<br/>src 93.224.14.1:1812<br/>dst 93.4.19.204:1812| SW

    note1["现象：请求目的地址是 VIP，响应源地址是后端真实地址"]
    RS -.-> note1

3. 抓包文件与对象

抓包文件：

F:\A-工作间\A-FTP\ras_2_办公网_(2026-06-25 15_39_00 - 2026-06-25 15_43_05)_1782437338409.pcap

关键地址：

对象地址说明
交换机93.4.19.204锐捷 S5310，dot1x NAS / RADIUS client
F5 VIP93.0.177.12交换机配置的 RADIUS 目标地址
后端真实 RADIUS93.224.14.1抓包中实际回包源地址
RADIUS 端口1812/UDP认证报文端口

抓包统计：

类型数量方向
Access-Request693.4.19.204 -> 93.0.177.12
Access-Challenge393.224.14.1 -> 93.4.19.204
Access-Accept393.224.14.1 -> 93.4.19.204

二层 MAC 方向：

方向源 MAC目的 MAC
交换机发往 F5/VIP9c:ce:88:51:45:d4c4:d4:38:1d:e9:02
真实 RADIUS 回交换机c4:d4:38:1d:e9:029c:ce:88:51:45:d4

4. 抓包显示的状态

Wireshark 中可见的 RADIUS 交互状态如下：

No.相对时间源地址目的地址RADIUS 类型IdentifierEAP 内容
10.00000000093.4.19.20493.0.177.12Access-Request9EAP Response Identity
20.02129368993.224.14.193.4.19.204Access-Challenge9EAP Request MD5-Challenge
30.02928812593.4.19.20493.0.177.12Access-Request10EAP Response MD5-Challenge
40.05055957493.224.14.193.4.19.204Access-Accept10EAP Success
533.17568883293.4.19.20493.0.177.12Access-Request11EAP Response Identity
633.20095256593.224.14.193.4.19.204Access-Challenge11EAP Request MD5-Challenge
733.20702414593.4.19.20493.0.177.12Access-Request12EAP Response MD5-Challenge
833.23029376393.224.14.193.4.19.204Access-Accept12EAP Success
9203.71226568993.4.19.20493.0.177.12Access-Request13EAP Response Identity
10203.71330709093.224.14.193.4.19.204Access-Challenge13EAP Request MD5-Challenge
11203.72311212493.4.19.20493.0.177.12Access-Request14EAP Response MD5-Challenge
12203.72410431193.224.14.193.4.19.204Access-Accept14EAP Success

可以看到：

  1. 交换机每次 Access-Request 都发往 93.0.177.12。
  2. 每次 Access-Challenge / Access-Accept 都从 93.224.14.1 返回。
  3. RADIUS Identifier 是连续配对的，例如 id=9 的 Request 对应 id=9 的 Challenge，id=10 的 Request 对应 id=10 的 Accept。
  4. EAP-MD5 流程完整，最终出现 Access-Accept / EAP Success，说明终端认证已通过。

5. 抓包分析

5.1 五元组现象

请求方向：

93.4.19.204:1812 -> 93.0.177.12:1812

响应方向：

93.224.14.1:1812 -> 93.4.19.204:1812

如果按严格的 UDP 会话五元组反向匹配，响应源地址应当是 93.0.177.12。实际源地址变成 93.224.14.1，说明外层 IP 五元组不对称。

5.2 为什么仍能认证通过

本次测试配置的 RADIUS group 2 不包含 93.224.14.1，但认证仍然通过，说明锐捷 S5310 在此场景下没有把“响应源 IP 不等于配置 server IP”作为硬失败条件。

更可能的处理逻辑是：

1. 交换机本机 UDP 1812 收到 RADIUS 响应报文。
2. RADIUS 客户端用 Identifier 匹配 pending Access-Request。
3. 使用对应请求的 Request Authenticator 和 shared secret 校验 Response Authenticator。
4. 校验通过后继续 EAP Challenge / Accept 流程。
5. 外层源 IP 93.224.14.1 != 93.0.177.12 没有触发丢弃。

5.3 F5 侧含义

该现象通常意味着以下情况之一：

可能原因说明
后端服务器直回请求经 F5 到后端，后端回交换机时绕过 F5
F5 未对回程做源地址转换回包没有被转换回 VIP
回程路由非对称后端 RADIUS 到交换机网段的路由不经过 F5
类 DSR/nPath 设计如果是故意设计，必须确认交换机和安全策略都接受这种形态

生产上更建议检查 F5 Virtual Server、Pool、SNAT Automap/SNAT Pool、后端服务器默认网关和回程路由，使交换机侧看到的响应源统一为 VIP。

6. RFC 2865 原理依据

RFC 链接：

https://datatracker.ietf.org/doc/html/rfc2865

6.1 Section 3 - Packet Format

链接：

https://datatracker.ietf.org/doc/html/rfc2865#section-3

相关内容：

  1. RADIUS 报文封装在 UDP Data 字段中，RADIUS 认证端口为 UDP 1812。
  2. Identifier 字段用于匹配 request 和 reply。
  3. Authenticator 字段用于认证来自 RADIUS server 的 reply。
  4. 对 Access-Accept、Access-Reject、Access-Challenge，Response Authenticator 的计算要素为：
Code + Identifier + Length + 原始 Access-Request 的 Request Authenticator + 响应 Attributes + Shared Secret

摘要算法为 MD5。注意这里没有外层 IP 源地址、目的地址、UDP 源端口、UDP 目的端口。

对应 RFC 公式：

ResponseAuth = MD5(Code + ID + Length + RequestAuth + Attributes + Secret)

这说明：RADIUS 协议层的响应认证摘要本身不把外层 IP 源地址纳入计算。

6.2 Section 4.2 - Access-Accept

链接：

https://datatracker.ietf.org/doc/html/rfc2865#section-4.2

相关内容：

  1. 收到 Access-Accept 后，NAS 使用 Identifier 匹配一个 pending Access-Request。
  2. Response Authenticator 必须是该 pending Access-Request 的正确响应。
  3. 无效报文会被静默丢弃。
  4. Access-Accept 中的 Identifier 是触发它的 Access-Request 的 Identifier 副本。

本次抓包里，id=10 的 Access-Request 对应 id=10 的 Access-Accept，id=12 对应 id=12，id=14 对应 id=14，符合这一匹配逻辑。

6.3 Section 4.4 - Access-Challenge

链接：

https://datatracker.ietf.org/doc/html/rfc2865#section-4.4

相关内容：

  1. 收到 Access-Challenge 后，Identifier 字段也要匹配 pending Access-Request。
  2. Response Authenticator 必须是该 pending Access-Request 的正确响应。
  3. 如果 NAS 支持 challenge/response，收到有效 Access-Challenge 后会发送新的 Access-Request。

本次抓包里，id=9 的 Access-Request 对应 id=9 的 Access-Challenge，随后交换机继续发出 id=10 的 MD5-Challenge Response，说明交换机接受了该 Challenge。

6.4 关于“源 IP 是否必须一致”的边界

RFC 2865 定义的是 RADIUS 协议层的报文格式、Identifier 匹配和 Authenticator 校验逻辑。它没有把外层 IP 源地址写入 Response Authenticator 计算，也没有明确要求 NAS 必须因为响应源 IP 不等于配置 server IP 而丢弃该响应。

但是，这不等于所有厂商设备都会接受这种报文。厂商实现可以额外增加源地址校验、防重放检查、会话五元组检查或安全策略。

因此，本次现象应表述为：

锐捷 S5310 当前版本/当前 dot1x 场景下，实测接受了源 IP 为后端真实地址的 RADIUS 响应；
从 RFC 2865 的 RADIUS 协议层校验逻辑看，这在 Identifier + Response Authenticator + shared secret 校验通过时可以解释；
但从 F5 负载均衡与生产规范角度，仍建议修正为 VIP 源地址回包。

7. 风险与建议

7.1 风险

风险说明
设备兼容性风险换其他型号、其他版本、其他厂商设备后，可能严格校验响应源 IP
安全策略风险防火墙、IPS、会话检测设备可能认为回包源地址异常
运维排障风险配置目标是 VIP，但日志和抓包显示真实地址，容易误判
多后端风险如果 F5 后端池有多台 RADIUS，源地址可能随调度变化
后续功能风险Accounting、CoA、审计联动可能对源地址更敏感

7.2 建议检查项

F5 侧建议检查：

1. Virtual Server 93.0.177.12:1812 是否启用地址转换。
2. Pool member 是否包含 93.224.14.1。
3. 是否启用 SNAT Automap 或 SNAT Pool。
4. 后端 RADIUS 服务器到 93.4.19.0/24 的回程路由是否经过 F5。
5. 是否存在 DSR/nPath/透明转发类设计。

交换机侧建议保留的验证命令：

show running-config | include radius-server|aaa group server radius|aaa authentication dot1x

建议的规范目标：

交换机请求：
93.4.19.204:1812 -> 93.0.177.12:1812

交换机收到：
93.0.177.12:1812 -> 93.4.19.204:1812

8. 最终表述

可用于报告中的一句话：

本次锐捷 S5310 终端 802.1X 认证可通过，但抓包显示 RADIUS 请求发往 F5 VIP 93.0.177.12 后，响应由后端真实地址 93.224.14.1 直接返回交换机。测试时交换机 RADIUS group 不包含该真实地址，说明该设备在当前版本/场景下未强制校验响应源 IP 与配置 server IP 一致，而是依据 RADIUS Identifier、Response Authenticator 和共享密钥完成协议层校验。该行为可解释认证成功原因，但 F5 回程形态不规范，建议整改为由 VIP 源地址统一回包。