迪普 ADX3000 使用自定义 UDP 报文检测 RADIUS 服务

这次配置的核心思路并不复杂。

由于 RADIUS 使用 UDP/1812，ADX 不能像检测 TCP 服务一样，通过三次握手判断服务是否正常。因此，需要让 ADX 主动发送一份真实的 RADIUS Access-Request 报文，再根据服务器有没有返回响应来判断服务状态。

迪普官方案例中也提供了“UDP 健康监测配置举例（自定义内容）”。配置方式就是选择自定义输入、填入报文内容并启用十六进制模式。

一、先抓取一份正常的 Access-Request

抓包时，最好不要随便构造 RADIUS 报文，而是从当前已经能够正常认证的环境中获取一份真实请求。

本次环境中，锐捷交换机下联终端能够正常完成 RADIUS 准入认证，因此可以利用一台测试终端重新触发认证，让交换机向 RADIUS 服务器发送一次正常的 Access-Request。

比较方便的抓包位置有两个：

在 RADIUS 服务器网卡上直接抓包；
在交换机上联链路做端口镜像，再使用 Wireshark 抓包。

为了避免影响正常用户，建议找一台测试终端操作。可以通过重新插拔网线、禁用再启用网卡，或者重新启动 802.1X 客户端来触发认证。

Wireshark 中先使用下面的过滤条件：

udp.port == 1812

也可以直接使用：

radius

如果环境中 RADIUS 报文很多，可以进一步限制目标服务器地址：

ip.dst == RADIUS服务器IP && udp.dstport == 1812

抓到报文后，找到交换机发往 RADIUS 服务器的请求，确认 Info 或协议详情中显示：

Access-Request

不要选服务器返回的 Access-Accept、Access-Reject 或 Access-Challenge。

二、只复制 RADIUS Payload，不要复制整帧

找到 Access-Request 后，在 Wireshark 中展开报文详情：

Ethernet II
Internet Protocol
User Datagram Protocol
RADIUS Protocol

这里要选中的是：

RADIUS Protocol

选中后，下方十六进制窗口会自动高亮 RADIUS 对应的那部分字节。

右键高亮区域，选择类似下面的菜单：

复制
→ 作为十六进制流

不同 Wireshark 版本的菜单名称可能略有区别，也可能显示为：

Copy
→ ...as a Hex Stream

正确复制出来的内容应该是一整串连续的十六进制字符，例如：

01ee00ce54499e19f64957bd3d40c657...

RADIUS Access-Request 的第一个字节通常是：

因为 01 表示 Access-Request。

前四个字节可以简单理解为：

01      Code，Access-Request
ee      Identifier
00ce    RADIUS 报文长度

本次抓到的报文开头是：

01 EE 00 CE

其中 00CE 表示报文长度为 206 字节。

三、复制出来带偏移量时怎么处理

有时不是通过“作为十六进制流”复制，而是直接从十六进制窗口复制。这时内容可能是下面这种格式：

0000  01 EE 00 CE 54 49 9E 19 F6 49 57 BD 3D 40 C6 57
0010  40 1B A1 E5 01 09 6B 79 6C 69 6E 6F 73 57 16 47
0020  ...

这里左边的：

0000
0010
0020

只是字节偏移量，不属于 RADIUS 报文，必须删除。

每个字节之间的空格、换行和冒号也要删除，最终整理成：

01ee00ce54499e19f64957bd3d40c657401ba1e5...

可以使用 Notepad++ 快速处理。

先删除每行开头的偏移量：按 Ctrl+H，搜索模式选择“正则表达式”。

查找：

(?m)^[0-9A-Fa-f]{4}\h+

替换为空。

然后再次替换，删除所有空格和换行。

查找：

\s+

替换为空。

处理完成后，文本里只能剩下：

0-9
a-f
A-F

不能包含空格、冒号、0x、中文说明或偏移地址。

四、检查十六进制内容是否完整

粘贴到 ADX 前，最好简单检查一次。

第一项是开头：

表示这是一份 Access-Request。

第二项是字符数量必须为偶数，因为两个十六进制字符表示一个字节。

第三项是根据 RADIUS 头部的 Length 字段核对总长度。

例如，本次报文头是：

01ee00ce

其中长度字段为：

00ce

转换为十进制是 206 字节，因此完整十六进制字符串长度应该是：

206 × 2 = 412 个字符

如果最终字符数不是 412，通常说明复制时漏了字节，或者偏移量、空格还没有清理干净。

五、把报文粘贴到 ADX3000

进入 ADX 配置页面：

【业务】
→【应用负载】
→【健康监测】
→ 新建

健康监测类型选择：

UDP

目标端口填写：

发送报文方式选择：

自定义方式

在【自定义发送内容】中粘贴前面整理好的连续十六进制字符串：

01ee00ce54499e19f64957bd3d40c657...

然后启用：

十六进制模式

这个选项必须开启。

因为不开启时，ADX 会把输入内容当作普通文本发送。例如输入：

01ee

不开启十六进制模式时，实际发送的是 ASCII 字节：

30 31 65 65

开启十六进制模式后，实际发送的才是：

01 EE

本次配置中同时启用了：

监测响应报文

这样 ADX 不只是把 UDP 报文发出去，还会等待 RADIUS 服务器返回响应，用服务器是否回包来判断健康状态。

完成后提交配置，再进入对应的【真实服务组】，引用这条 UDP 健康监测。

官方案例中的真实服务也是将 RADIUS 服务器地址配置为真实服务，并使用 UDP/1812，再在真实服务组中引用健康监测。

六、配置完成后的抓包验证

配置提交后，继续在 RADIUS 服务器侧抓包。

过滤条件仍然使用：

udp.port == 1812

正常情况下应该看到：

ADX 源 IP → RADIUS 服务器
Access-Request

随后服务器可能返回：

RADIUS 服务器 → ADX 源 IP
Access-Accept

或者：

Access-Reject
Access-Challenge

只要服务器能够识别并处理报文，通常就会产生响应。实际健康状态仍应以 ADX 的响应判定方式和配置结果为准。

如果只能看到 ADX 发出的 Access-Request，却没有任何回包，应重点检查：

ADX 探测源 IP 是否有回程路由
RADIUS 服务器是否允许该源 IP
服务器是否要求已登记的 NAS Client
Shared Secret 或 Message-Authenticator 校验是否失败
中间防火墙是否放行 UDP/1812

需要特别注意，抓到的报文原本是锐捷交换机生成的，其中可能包含：

Request Authenticator
Message-Authenticator
User-Password
NAS-Identifier

这些内容可能与原交换机的 RADIUS Client 身份和 Shared Secret 有关。

因此，把原交换机报文交给 ADX 重放后，某些 RADIUS 服务器可能接受并回复，也可能因为源 IP、NAS Client 身份、认证字段或时间相关属性校验失败而静默丢弃。

本次环境能够正常使用这种方法，但在其他环境中仍需要以服务器侧抓包结果为准。

七、本次配置要点

整个过程可以概括为：

触发一次正常 RADIUS 认证
→ 抓取 Access-Request
→ 只复制 RADIUS Protocol 字节
→ 转换为连续十六进制字符串
→ 粘贴到 ADX 自定义发送内容
→ 开启十六进制模式
→ 开启监测响应报文
→ 在真实服务组中引用
→ 抓包确认服务器有响应

最容易出错的地方有三个：

第一，不要复制整帧报文，只复制 RADIUS Payload。

第二，不要把偏移量、空格和换行粘贴到 ADX。

第三，十六进制模式必须开启，否则 ADX 发出的只是普通 ASCII 字符串。

这种方法适合无法直接使用 ADX 内置 RADIUS 健康监测，或者暂时无法取得 Shared Secret、但现有重放报文又确实能触发服务器响应的环境。它的优点是可以快速利用现有正常认证流量完成探测配置；缺点是报文与原 NAS 身份、Shared Secret 及部分动态字段可能存在关联，因此上线后一定要结合服务器侧抓包确认实际效果。