×

【案例】现网中新增无线AP,终端接入该AP后802.1X认证失败?教科书般排障来了!

hqy hqy 发表于2025-07-15 10:39:54 浏览13 评论0

抢沙发发表评论

本期分享案例是有线网络的相关问题。



【问题背景】


甲方是一家大型的国企单位,注重安全保密工作,要接入核心现网就需要通过WPA/WPA2—802.1X认证认证成功才能成功入网。正好最近增添办公场所,所以新增了多个无线AP。但IT发现,手机、笔记本、平板等无线接入该AP后概率性没法通过认证入网!AC、AP都是同一个厂商某C的设备,只不过新增AP是新型号,二外接radius认证服务器是其它三方的。


图片
网络拓扑简化如下
图片


  • AC、AP、交换机等网络设备所在网段为192.168.1.1/24

  • radius三方认证服务器所在网段为10.64.X.X/24

好了,针对这个问题,我们一起来看下如何分析!



【802.1X协议认知】


对于802.1X无线认证,我们要对其原理有一个清晰的认识,否则便是“书到用时方恨少”。好了,复杂的原理我不讲,后续出一期《图解802.1X协议》详解,这里就简单讲大概逻辑:


图片


  1. radius服务器上配置如基于MAC的用户认证,并设置用户账号密码

  2. A终端输入认证服务器IP、账号密码后接入无线

  3. AP收到A终端的接入认证后(无线EAPOL),向服务器发起认证请求(RADIUS协议报文),问它A终端接入要不要放行;

  4. radius服务器收到AP过来的闻讯后查自己的库,对照MAC、账号密码等信息OK,于是返回告知AP可放行(RADIUS协议报文)

  5. AP收到后,就发A终端过去上网了。



【排查思路】


了解上述机制后,我们就可以考虑排查思路了:

  1. 确认入网终端输入的服务器IP、账号密码等参数信息是否正确;

  2. 确认AC上的radius认证配置是否正确;

  3. 确认无线终端与无线AP之间交互的EAPOL报文是否正常;

  4. 确认AP与radius服务器之间的RAIDUS报文交互是否正常。

显然这类问题,除了1、2步检查相关配置,剩下的就需要分析报文了。



【排查分析】


第一步、确认终端配置、AC参数配置是否正确

终端参数配置无问题,因为在旧AP可以正常认证成功。所以看下AC上给AP下发的配置,相关命令如下:



# 查看RADIUS方案配置

[beijing-AC] display radius scheme server_radius

Radius scheme name: server_radius

Server-type: extended

Primary authentication server: 10.64.9.113 
  Port: 1812
 
  State: active
....
# 查看认证方案配置

[beijing-AC] display authentication scheme server_auth

Authentication scheme name: server_auth

Authentication mode: radius

Radius scheme: server_radius....


以上便是关键信息,认证方案是radius没问题,服务器IP和认证端口1812也填的是对的。其它无用的敏感信息我就不附了。

第二步、确认无线终端与无线AP的交互

终端接入会发EAPOL认证报文给AP,但这个是无线层的,现场没有无线抓包条件和手段,这一步忽略。

第三步、确认正常和异常无线AP与radius服务器的交互

抓取正常和异常AP的上联口报文:


图片



发现异常新增AP是有将RADIUS报文发出去的,但是没有得到服务器响应


图片


而正常的旧AP能与服务器正常交互,并最最终收到服务器accept的放行指示


图片


到这里,乍一看是服务器那边未响应radius认证导致?可能是存在相关的限制之类的,因此向负责radius服务器的人询问,得到的答复是并未有任何的限制。

然后另一个怀疑点就是报文可能没有被服务器收到报文,但是那边没有条件在radius服务器接口处抓包,所以下一步只能深入分析两种radius报文的区别了。

第四步、报文分析

通过琢磨和分析,我们看到,这两种报文的目的MAC竟然是不一致的!


图片


因为是跨三层访问,目的MAC则是核心交换机192.168.1.1接口的MAC,然而新增AP学得是错误的04:d7:a5:aa:eb:e8,说明AP有线侧过来的ARP还有其它设备声明自己是192.168.1.1,即IP冲突!过滤ARP和对应MAC,果然发现有设备ARP:


图片


并且留意到该ARP打了VLAN tag=1,原来是上联交换机trunk类型同时也透传了VLAN,但新旧AP实际上是没有VLAN1的业务的,所以AP收到该tag=1的ARP后不应该学进去了:


图片


综上分析,明确了是新型号AP的未知BUG,自身未配置透传VLAN1的情况下收到了ARP tag=1的报文,也把它学到自己的表项里面去了。




【问题总结和解决方案】

问题总结:

AP上联交换机将ARP tag=1的报文透传给了AP,其中有设备的IP与核心的IP冲突都是192.168.1.1。新型号AP的存在未知BUG,自身未配置透传VLAN1的情况下收到了ARP tag=1的报文,也把它学到自己的表项里面去了,因此发radius报文跨三层给服务器时,目的MAC封错

解决方案:

  • 方法1:上联口不透传VLAN1即可,现场也没有用到VLAN1业务,采取了这种方法

  • 方法2:新型号AP升级固件解决。

本期分享案例是有线网络的相关问题。



【问题背景】


甲方是一家大型的国企单位,注重安全保密工作,要接入核心现网就需要通过WPA/WPA2—802.1X认证认证成功才能成功入网。正好最近增添办公场所,所以新增了多个无线AP。但IT发现,手机、笔记本、平板等无线接入该AP后概率性没法通过认证入网!AC、AP都是同一个厂商某C的设备,只不过新增AP是新型号,二外接radius认证服务器是其它三方的。


图片
网络拓扑简化如下
图片


  • AC、AP、交换机等网络设备所在网段为192.168.1.1/24

  • radius三方认证服务器所在网段为10.64.X.X/24

好了,针对这个问题,我们一起来看下如何分析!



【802.1X协议认知】


对于802.1X无线认证,我们要对其原理有一个清晰的认识,否则便是“书到用时方恨少”。好了,复杂的原理我不讲,后续出一期《图解802.1X协议》详解,这里就简单讲大概逻辑:


图片


  1. radius服务器上配置如基于MAC的用户认证,并设置用户账号密码

  2. A终端输入认证服务器IP、账号密码后接入无线

  3. AP收到A终端的接入认证后(无线EAPOL),向服务器发起认证请求(RADIUS协议报文),问它A终端接入要不要放行;

  4. radius服务器收到AP过来的闻讯后查自己的库,对照MAC、账号密码等信息OK,于是返回告知AP可放行(RADIUS协议报文)

  5. AP收到后,就发A终端过去上网了。



【排查思路】


了解上述机制后,我们就可以考虑排查思路了:

  1. 确认入网终端输入的服务器IP、账号密码等参数信息是否正确;

  2. 确认AC上的radius认证配置是否正确;

  3. 确认无线终端与无线AP之间交互的EAPOL报文是否正常;

  4. 确认AP与radius服务器之间的RAIDUS报文交互是否正常。

显然这类问题,除了1、2步检查相关配置,剩下的就需要分析报文了。



【排查分析】


第一步、确认终端配置、AC参数配置是否正确

终端参数配置无问题,因为在旧AP可以正常认证成功。所以看下AC上给AP下发的配置,相关命令如下:



# 查看RADIUS方案配置

[beijing-AC] display radius scheme server_radius

Radius scheme name: server_radius

Server-type: extendedPrimary
authentication server: 10.64.9.113
 
  Port: 1812
  State: active....
# 查看认证方案配置

[beijing-AC] display authentication scheme server_auth

Authentication scheme name: server_auth

Authentication mode: radiusRadius
scheme: server_radius
....


以上便是关键信息,认证方案是radius没问题,服务器IP和认证端口1812也填的是对的。其它无用的敏感信息我就不附了。

第二步、确认无线终端与无线AP的交互

终端接入会发EAPOL认证报文给AP,但这个是无线层的,现场没有无线抓包条件和手段,这一步忽略。

第三步、确认正常和异常无线AP与radius服务器的交互

抓取正常和异常AP的上联口报文:


图片



发现异常新增AP是有将RADIUS报文发出去的,但是没有得到服务器响应


图片


而正常的旧AP能与服务器正常交互,并最最终收到服务器accept的放行指示


图片


到这里,乍一看是服务器那边未响应radius认证导致?可能是存在相关的限制之类的,因此向负责radius服务器的人询问,得到的答复是并未有任何的限制。

然后另一个怀疑点就是报文可能没有被服务器收到报文,但是那边没有条件在radius服务器接口处抓包,所以下一步只能深入分析两种radius报文的区别了。

第四步、报文分析

通过琢磨和分析,我们看到,这两种报文的目的MAC竟然是不一致的!


图片


因为是跨三层访问,目的MAC则是核心交换机192.168.1.1接口的MAC,然而新增AP学得是错误的04:d7:a5:aa:eb:e8,说明AP有线侧过来的ARP还有其它设备声明自己是192.168.1.1,即IP冲突!过滤ARP和对应MAC,果然发现有设备ARP:


图片


并且留意到该ARP打了VLAN tag=1,原来是上联交换机trunk类型同时也透传了VLAN,但新旧AP实际上是没有VLAN1的业务的,所以AP收到该tag=1的ARP后不应该学进去了:


图片


综上分析,明确了是新型号AP的未知BUG,自身未配置透传VLAN1的情况下收到了ARP tag=1的报文,也把它学到自己的表项里面去了。




【问题总结和解决方案】

问题总结:

AP上联交换机将ARP tag=1的报文透传给了AP,其中有设备的IP与核心的IP冲突都是192.168.1.1。新型号AP的存在未知BUG,自身未配置透传VLAN1的情况下收到了ARP tag=1的报文,也把它学到自己的表项里面去了,因此发radius报文跨三层给服务器时,目的MAC封错

解决方案:

  • 方法1:上联口不透传VLAN1即可,现场也没有用到VLAN1业务,采取了这种方法

  • 方法2:新型号AP升级固件解决。



打赏

本文链接:https://kinber.cn/post/5277.html 转载需授权!

分享到:


推荐本站淘宝优惠价购买喜欢的宝贝:

image.png

 您阅读本篇文章共花了: 

群贤毕至

访客