本期分享的案例是有線網(wǎng)絡(luò)的相關(guān)問題。

問題背景

甲方是一家大型的國(guó)企單位，注重安全保密工作，要接入核心現(xiàn)網(wǎng)就需要通過WPA/WPA2—802.1X認(rèn)證認(rèn)證成功才能成功入網(wǎng)。正好最近增添辦公場(chǎng)所，所以新增了多個(gè)無線AP。但I(xiàn)T發(fā)現(xiàn)，手機(jī)、筆記本、平板等無線接入該AP后概率性沒法通過認(rèn)證入網(wǎng)！AC、AP都是同一個(gè)廠商某C的設(shè)備，只不過新增AP是新型號(hào)，二外接radius認(rèn)證服務(wù)器是其它三方的。

網(wǎng)絡(luò)拓?fù)浜?jiǎn)化如下：

• AC、AP、交換機(jī)等網(wǎng)絡(luò)設(shè)備所在網(wǎng)段為192.168.1.1/24
• radius三方認(rèn)證服務(wù)器所在網(wǎng)段為10.64.X.X/24

好了，針對(duì)這個(gè)問題，我們一起來看下如何分析！

802.1X協(xié)議認(rèn)知

對(duì)于802.1X無線認(rèn)證，我們要對(duì)其原理有一個(gè)清晰的認(rèn)識(shí)，否則便是“書到用時(shí)方恨少”。好了，復(fù)雜的原理我不講，后續(xù)出一期《圖解802.1X協(xié)議》詳解，這里就簡(jiǎn)單講大概邏輯：

• radius服務(wù)器上配置如基于MAC的用戶認(rèn)證，并設(shè)置用戶賬號(hào)密碼；
• A終端輸入認(rèn)證服務(wù)器IP、賬號(hào)密碼后接入無線；
• AP收到A終端的接入認(rèn)證后（無線EAPOL），向服務(wù)器發(fā)起認(rèn)證請(qǐng)求（RADIUS協(xié)議報(bào)文），問它A終端接入要不要放行；
• radius服務(wù)器收到AP過來的聞?dòng)嵑蟛樽约旱膸?kù)，對(duì)照MAC、賬號(hào)密碼等信息OK，于是返回告知AP可放行（RADIUS協(xié)議報(bào)文）；
• AP收到后，就發(fā)A終端過去上網(wǎng)了。

排查思路

了解上述機(jī)制后，我們就可以考慮排查思路了：

• 確認(rèn)入網(wǎng)終端輸入的服務(wù)器IP、賬號(hào)密碼等參數(shù)信息是否正確；
• 確認(rèn)AC上的radius認(rèn)證配置是否正確；
• 確認(rèn)無線終端與無線AP之間交互的EAPOL報(bào)文是否正常；
• 確認(rèn)AP與radius服務(wù)器之間的RAIDUS報(bào)文交互是否正常。

顯然這類問題，除了1、2步檢查相關(guān)配置，剩下的就需要分析報(bào)文了。

排查分析

第一步、確認(rèn)終端配置、AC參數(shù)配置是否正確

終端參數(shù)配置無問題，因?yàn)樵谂fAP可以正常認(rèn)證成功。所以看下AC上給AP下發(fā)的配置，相關(guān)命令如下：

# 查看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
....


# 查看認(rèn)證方案配置
[beijing-AC] display authentication scheme server_auth
Authentication scheme name: server_auth
Authentication mode: radius
Radius scheme: server_radius
....

以上便是關(guān)鍵信息，認(rèn)證方案是radius沒問題，服務(wù)器IP和認(rèn)證端口1812也填的是對(duì)的。其它無用的敏感信息我就不附了。

第二步、確認(rèn)無線終端與無線AP的交互

終端接入會(huì)發(fā)EAPOL認(rèn)證報(bào)文給AP，但這個(gè)是無線層的，現(xiàn)場(chǎng)沒有無線抓包條件和手段，這一步忽略。

第三步、確認(rèn)正常和異常無線AP與radius服務(wù)器的交互

抓取正常和異常AP的上聯(lián)口報(bào)文：

發(fā)現(xiàn)異常新增AP是有將RADIUS報(bào)文發(fā)出去的，但是沒有得到服務(wù)器響應(yīng)。

而正常的舊AP能與服務(wù)器正常交互，并最最終收到服務(wù)器accept的放行指示。

到這里，乍一看是服務(wù)器那邊未響應(yīng)radius認(rèn)證導(dǎo)致？可能是存在相關(guān)的限制之類的，因此向負(fù)責(zé)radius服務(wù)器的人詢問，得到的答復(fù)是并未有任何的限制。

然后另一個(gè)懷疑點(diǎn)就是報(bào)文可能沒有被服務(wù)器收到報(bào)文，但是那邊沒有條件在radius服務(wù)器接口處抓包，所以下一步只能深入分析兩種radius報(bào)文的區(qū)別了。

第四步、報(bào)文分析

通過琢磨和分析，我們看到，這兩種報(bào)文的目的MAC竟然是不一致的！

因?yàn)槭强缛龑釉L問，目的MAC則是核心交換機(jī)192.168.1.1接口的MAC，然而新增AP學(xué)得是錯(cuò)誤的04:d7:a5:aa:eb:e8，說明AP有線側(cè)過來的ARP還有其它設(shè)備聲明自己是192.168.1.1，即IP沖突！過濾ARP和對(duì)應(yīng)MAC，果然發(fā)現(xiàn)有設(shè)備ARP：

并且留意到該ARP打了VLAN tag=1，原來是上聯(lián)交換機(jī)trunk類型同時(shí)也透?jìng)髁薞LAN，但新舊AP實(shí)際上是沒有VLAN1的業(yè)務(wù)的，所以AP收到該tag=1的ARP后不應(yīng)該學(xué)進(jìn)去了：

綜上分析，明確了是新型號(hào)AP的未知BUG，自身未配置透?jìng)鱒LAN1的情況下收到了ARP tag=1的報(bào)文，也把它學(xué)到自己的表項(xiàng)里面去了。

問題總結(jié)和解決方案

問題總結(jié)：AP上聯(lián)交換機(jī)將ARP tag=1的報(bào)文透?jìng)鹘o了AP，其中有設(shè)備的IP與核心的IP沖突都是192.168.1.1。新型號(hào)AP的存在未知BUG，自身未配置透?jìng)鱒LAN1的情況下收到了ARP tag=1的報(bào)文，也把它學(xué)到自己的表項(xiàng)里面去了，因此發(fā)radius報(bào)文跨三層給服務(wù)器時(shí)，目的MAC封錯(cuò)。

解決方案：

• 方法1：上聯(lián)口不透?jìng)鱒LAN1即可，現(xiàn)場(chǎng)也沒有用到VLAN1業(yè)務(wù)，采取了這種方法
• 方法2：新型號(hào)AP升級(jí)固件解決。