• 全部
  • 经验案例
  • 典型配置
  • 技术公告
  • FAQ
  • 漏洞说明
  • 全部
  • 是
  • 否
  • 全部
  • 是
  • 否
  • 大数据引擎
  • 知了引擎
产品线
搜索
取消
案例类型
发布者
是否解决
是否官方
时间
搜索引擎
匹配模式
高级搜索
问

交换机对接负载做认证

1天前提问
  • 0关注
  • 0收藏,82浏览
粉丝:0人 关注:0人

问题描述:

交换机直接对接radius服务器没问题,对接负载1812端口一直不通

3 个回答
粉丝:19人 关注:9人

交换机直连RADIUS服务器认证正常,但对接负载均衡后UDP 1812端口不通,通常是负载均衡健康检查或转发策略问题。按以下步骤排查:
1. 确认负载均衡配置
检查负载均衡是否配置了UDP 1812的健康检查,且健康检查报文源地址、目的地址正确
确认负载均衡虚拟服务监听的是UDP 1812,而非TCP
检查负载均衡是否对RADIUS报文做了源地址转换(SNAT),导致交换机收到的响应源IP与请求目的IP不一致
2. 交换机侧排查
bash
测试到负载均衡VIP的UDP连通性
ping -c 3 <负载均衡VIP>
查看RADIUS统计,确认报文是否发出、是否收到响应
display radius scheme
display radius statistics
开启debug观察RADIUS交互过程
debugging radius packet
terminal debugging
terminal monitor
3. 抓包定位
在交换机上行口或负载均衡侧抓包,确认:
交换机发出的RADIUS请求是否到达负载均衡
负载均衡是否转发到后端RADIUS服务器
后端响应是否返回负载均衡并转发回交换机
4. 常见原因
负载均衡健康检查失败,后端RADIUS服务器被标记为down,导致请求被丢弃
负载均衡仅配置了TCP转发,未启用UDP
RADIUS报文的源端口不是标准1812(部分交换机使用随机源端口),负载均衡基于五元组转发时回程路径不一致
5. 建议
在负载均衡上配置UDP 1812的健康检查,探测报文模拟RADIUS Access-Request
确保负载均衡对RADIUS做会话保持(基于源IP),保证请求和响应走同一路径
若负载均衡支持,关闭对UDP 1812的源端口转换,保持源端口为1812

暂无评论

粉丝:109人 关注:1人

注意协议类型,负载一般是tcp,radius是udp

暂无评论

粉丝:48人 关注:2人

RADIUS 是无连接 UDP 协议,经过负载均衡最常见坑集中在:USIP 透传源 IP、SNAT、UDP 会话超时、会话保持、后端服务器 NAS‑IP 白名单、防火墙放通、NAS‑IP 源地址配置。

一、组网简要

交换机 → 负载均衡 VIP (1812/1813 UDP) → 负载均衡业务池 → 多台真实 RADIUS 后端服务器。

直连后端真实服务器正常,说明交换机侧共享密钥、ISP 域、802.1X 业务逻辑本身没问题,故障发生在交换机‑LB‑后端 RADIUS 交互链路。

二、交换机侧关键检查

  1. 配置固定 RADIUS NAS‑IP(必做) RADIUS 报文源 IP 不要依赖路由出接口动态变化;指定 loopback 或者管理 VLAN IP 作为 nas‑ip,该 IP 需要在负载均衡、后端 RADIUS 服务器白名单内H3C。
system‑view radius nas‑ip X.X.X.X

注意:后端每一台真实 RADIUS 服务器,接入设备列表必须添加这个 NAS‑IP,不能只加负载均衡 IP。

  1. RADIUS 方案配置,服务器填写 LB‑VIP,端口 1812 认证、1813 计费,密钥和后端 RADIUS 保持一致。
radius‑scheme rad primary authentication LB‑VIP 1812 primary accounting LB‑VIP 1813 key authentication simple xxx key accounting simple xxx quit
  1. 查看服务器状态、调试报文
display radius scheme rad #观察State,如果显示Blocked,代表多次重传没有收到回应 debugging radius packet debugging radius event terminal debugging terminal monitor

调试看:交换机发出 Access‑Request,完全没有收到 Access‑Accept/Reject 应答,属于单向不通,请求出去,应答回不来。

三、负载均衡设备侧高频故障点(按优先级)

1、USIP(透传客户端源 IP)开启,无 SNAT,应答报文绕开负载均衡(最高概率)

如果 LB 虚服务开启 USIP(透传源 IP,不做 SNAT): 交换机 RADIUS 请求源 IP 为交换机 NAS‑IP,LB 原样把源 IP 透传给后端 RADIUS。后端 RADIUS 回包查路由,如果回包路由直接指向交换机,不经过负载均衡设备,应答报文旁路绕过 LB,交换机收不到响应,表现就是 1812 不通,但 ping VIP 可以通(ICMP 不受影响)。

✅解决:

  • 方案 A(推荐):虚服务关闭 USIP,开启SNAT;后端 RADIUS 看到的源 IP 是 LB 的内网 SNIP 地址。此时后端 RADIUS 接入设备白名单添加 LB 的 SNIP,共享密钥匹配。
  • 方案 B(业务要求保留真实 NAS‑IP):不做 SNAT,必须保证后端 RADIUS 服务器返回给交换机 NAS‑IP 的路由下一跳强制指向负载均衡内网接口,所有应答必须经过 LB 回传给交换机。

2、UDP 会话超时时间太短

RADIUS 属于 UDP 无连接,负载均衡四层虚服务 UDP 会话老化时间默认通常比较短。认证报文交互间隔超过老化时间会话被删除,回复报文被丢弃。 ✅调整 LB 虚服务 UDP 会话超时,建议设置≥10s。

3、缺少 RADIUS 会话保持(持久化)

同一个认证会话的请求、计费报文,必须调度到同一台后端 RADIUS 实例。

  • 四层 LB:基于源 IP 做会话保持;
  • 七层 RADIUS 类型 LB:使用 RADIUS‑User‑Name 属性做持久化。

不配置保持,同一个会话的请求和应答被调度到不同后端服务器,认证异常。

4、虚服务只监听 TCP,没有开启 UDP 1812/1813

RADIUS 使用 UDP,很多负载均衡虚服务默认 TCP,需要单独新建 UDP 类型虚服务,分别监听 1812、1813 端口。健康检测要使用 UDP 类型 NQA 检测,不要用 ICMP ping 判断 RADIUS 服务状态。

5、负载均衡与后端服务器之间防火墙 / ACL 拦截 UDP‑1812/1813

即使直连后端正常,经过 LB 后,后端服务器防火墙、系统 iptables 需要放行来自 LB SNIP 的 UDP 1812/1813。

四、后端 RADIUS 服务器侧检查

  1. 如果 LB 开启 SNAT,RADIUS 接入设备列表添加LB 内网 SNIP 地址,密钥和交换机配置一致。
  2. 如果 LB 关闭 SNAT(透传源 IP),每台 RADIUS 服务器添加交换机 NAS‑IP。

❗不能只添加 VIP,VIP 是 LB 虚地址,后端看不到这个源 IP。

五、快速定位排错手段

  1. 在负载均衡上抓包:
    • 是否收到交换机发过来 UDP 1812 Access‑Request;
    • 是否把报文转发到后端 RADIUS;
    • 是否收到后端 RADIUS 回复 Access‑Accept;
    • 是否把回复报文回传给交换机。
  2. 在后端真实 RADIUS 服务器抓包,看请求是否到达本机,回复报文目的 IP 是否正确,下一跳是否走 LB。

表格

现象根因判断
交换机发出请求,LB 收到,转发后端,后端回复,LB 没有还给交换机开启 USIP,后端回包路由绕过 LB;或者 UDP 会话超时删除会话表项
LB 没有把请求转发后端虚服务协议类型选错(TCP)、健康检测把全部后端池成员标记 down
请求到达后端 RADIUS,服务器直接丢弃报文RADIUS 接入设备白名单缺少源 IP,密钥不匹配

六、临时验证手段

交换机 RADIUS 方案直接填其中一台后端真实 RADIUSIP,认证正常,说明交换机配置完全没问题,问题 100% 出在负载均衡链路与配置。


暂无评论

编辑答案

你正在编辑答案

如果你要对问题或其他回答进行点评或询问,请使用评论功能。

✖

分享扩散:

➤

提出建议

✖

    +
✖

亲~登录后才可以操作哦!

确定
✖

亲~检测到您登陆的账号未在http://hclhub.h3c.com进行注册

注册后可访问此模块

跳转hclhub
✖

你的邮箱还未认证,请认证邮箱或绑定手机后进行当前操作

✖

举报

×

侵犯我的权益 >
对根叔社区有害的内容 >
辱骂、歧视、挑衅等(不友善)

侵犯我的权益

×

泄露了我的隐私 >
侵犯了我企业的权益 >
抄袭了我的内容 >
诽谤我 >
辱骂、歧视、挑衅等(不友善)
骚扰我

泄露了我的隐私

×

您好,当您发现根叔知了上有泄漏您隐私的内容时,您可以向根叔知了进行举报。 请您把以下内容通过邮件发送到pub.zhiliao@h3c.com 邮箱,我们会尽快处理。
  • 1. 您认为哪些内容泄露了您的隐私?(请在邮件中列出您举报的内容、链接地址,并给出简短的说明)
  • 2. 您是谁?(身份证明材料,可以是身份证或护照等证件)

侵犯了我企业的权益

×

您好,当您发现根叔知了上有关于您企业的造谣与诽谤、商业侵权等内容时,您可以向根叔知了进行举报。 请您把以下内容通过邮件发送到 pub.zhiliao@h3c.com 邮箱,我们会在审核后尽快给您答复。
  • 1. 您举报的内容是什么?(请在邮件中列出您举报的内容和链接地址)
  • 2. 您是谁?(身份证明材料,可以是身份证或护照等证件)
  • 3. 是哪家企业?(营业执照,单位登记证明等证件)
  • 4. 您与该企业的关系是?(您是企业法人或被授权人,需提供企业委托授权书)
我们认为知名企业应该坦然接受公众讨论,对于答案中不准确的部分,我们欢迎您以正式或非正式身份在根叔知了上进行澄清。

抄袭了我的内容

×

原文链接或出处

诽谤我

×

您好,当您发现根叔知了上有诽谤您的内容时,您可以向根叔知了进行举报。 请您把以下内容通过邮件发送到pub.zhiliao@h3c.com 邮箱,我们会尽快处理。
  • 1. 您举报的内容以及侵犯了您什么权益?(请在邮件中列出您举报的内容、链接地址,并给出简短的说明)
  • 2. 您是谁?(身份证明材料,可以是身份证或护照等证件)
我们认为知名企业应该坦然接受公众讨论,对于答案中不准确的部分,我们欢迎您以正式或非正式身份在根叔知了上进行澄清。

对根叔社区有害的内容

×

垃圾广告信息
色情、暴力、血腥等违反法律法规的内容
政治敏感
不规范转载 >
辱骂、歧视、挑衅等(不友善)
骚扰我
诱导投票

不规范转载

×

举报说明