備用NAP伺服器RADIUS無線身分識別驗證不通過，無線控制器時常Active / Block切換故障執行個體分析

前言+環境拓撲：

   最近公司新加了1台H3C WX6103無線控制器，用2台配成高可用，防止單點故障，我們的RAIDUS驗證服務器也是只有1台，領導讓我加1台作為備用RADIUS伺服器，無線控制器可用配置一主多從個RADIUS伺服器，實現熱切換，即主RADIUS掛點的時候，備用RADIUS伺服器可用接管使用者身分識別驗證的工作，整個環境的大概邏輯拓撲如下，我只畫了1台無線控制器，對本文分析並無影響。

大概邏輯結構：

650) this.width=650;" src="http://www.bkjia.com/uploads/allimg/131227/16314244H-0.jpg" title="radius.jpg" />

無線控制器配置：

650) this.width=650;" src="http://www.bkjia.com/uploads/allimg/131227/1631425136-1.jpg" title="radius2.jpg" />

   由於現在企業中使用2008R2和2012已經成為主流，再使用2003系統已經不太適合，這裡我選擇了08R2，拓撲右上方這台NAP伺服器就是我負責搭建的，搭建過程很簡單不囉嗦了，參考已有的2003 IAS配置下RADIUS用戶端IP、串連請求策略、網路原則。由於我們使用的是微軟的身分識別驗證方案，和AD整合，所以身分識別驗證方式選擇了PEAP-MSChap v2，它要求驗證伺服器端必須安裝認證，可以和企業CA申請也可以自我簽署憑證。

環境測試+故障現象：

   配置好了NAP伺服器後，接下來進入測試環節，我們的測試方案是：停止主驗證伺服器10.0.5.20上的RADIUS服務，測試此時無線用戶端可否串連上無線，可以串連表示備用RADIUS伺服器生效，使用者身分識別驗證成功，但是結果很遺憾，當主伺服器剛停服務之後的一段時間內，無線確實是可以串連上的，可是過一段時間後便串連不上了。

   當無線串連不上時，我們要考慮得問題是：

   1.到底是無線控制器出了問題，還是備用RADIUS伺服器出了問題？

   2.為什麼一會可以串連上無線通過身分識別驗證），一會又不行？

   3.Windows日誌裡有什麼報錯沒有？

   4.無線控制器上顯示的伺服器狀態是怎樣變化的？有無日誌可供參考。

   這是我們排錯所需要瞭解的問題，接下來我們開始分析和排錯。

排錯環節：

   首先，我們先對NAP伺服器進行驗證，因為伺服器是我搭建的，我不認為我哪裡出了錯，我對自己還是非常有信心的，下面我們來驗證下NAP伺服器的RADIUS驗證，這裡我使用了一個類比工具RadEapTest 2.6，它可以幫我們類比出一個NAS，同時可以讓我們自己編寫一個驗證方案，包含身分識別驗證方式，使用者名稱密碼等，類比出這樣的一個RADIUS Access-Request請求報文，同時可以完成後續的互動過程，完成身份認證的類比，這個過程我測試是成功的，這證明故障時刻待命伺服器可以成功進行身分識別驗證。進一步證明，故障時刻我們觀看Windows安全日誌，並未發現有任何身分識別驗證請求過來，既無身分識別驗證成功的，也無身分識別驗證失敗的，通過簡單的邏輯判斷，我們可以基本認定:故障時刻，備用NAP伺服器並未受到RADIUS Access-Request請求報文，即無線控制器並未將使用者的驗證請求轉給備用NAP伺服器，但是從伺服器是沒問題的。

   整個身分識別驗證過程有3個實體，使用者、無線控制器、RADIUS伺服器以下簡稱主/從伺服器），現在RADIUS伺服器已經排除了，接下來我們再來看看無線控制器。

   由於我對無線控制器不太熟，這塊是H3C廠商工程師負責的，我只會敲dis radius sch查看伺服器狀態：Active/Block，這裡我觀察到，Second Auth Server時常會由Active變為Block，過段時間會變回Active，這時我需要知道的是：什麼情況會觸發Active變為Block，什麼時候會變回Active？

   經過在H3C網站上尋找資料和諮詢H3C工程師，得出以下結論：當主從伺服器都是Active狀態時，當主伺服器Block後，無線控制器會把身分識別驗證請求轉給從伺服器，當從伺服器無法驗證使用者請求，從伺服器就會變為block狀態，當Active變為Block後，無線控制器會啟動一個“恢複啟用狀態的時間”，預設是5分鐘，5分鐘後，狀態自動變回Active，如此反覆，也就是說是定時恢複，而不是檢測恢複。

   查到這裡，問題已經已經確定，是因為Active/Block不定時切換狀態引起的，但我們似乎還是沒找到無線控制器狀態為什麼變化，Active變為Block，H3C的工程師也沒分析出是什麼原因，這時候我們要使用一些更深層的手段了，通過RADIUS協議和抓包來分析，任何事情都有它的本質，我們一起進入底層一探究竟。

   關於RADIUS協議，我參考了這篇文章：http://wenku.baidu.com/view/53f55000bed5b9f3f90f1cea.html，詳細介紹了RADIUS報文格式、類型、和身分識別驗證過程。

   協議看過了，我們開始抓包，我們抓包要有目的，我需要抓到什麼樣的包？我需要抓到的是：無線控制器從伺服器由Active變為Block這個過程，到底發生了什嗎？無線控制器給了我的從伺服器一個什麼的報文，伺服器有沒有給他回複，給他回複了什麼，才導致的狀態的變化，好了，開始吧！

   先在從伺服器上啟動Wireshark，抓包並啟動過濾條件ip.addr==10.1.156.1隻看從無線控制器發過的包，此時無線控制上看到的伺服器狀態是雙Active，然後我等他變為block，這裡我還有個一個一直沒想明白的問題，從伺服器既然是從伺服器，那麼主伺服器不掛，從伺服器怎麼可能收到RADIUS請求呢？這個問題我們抓包分析後再解釋。

650) this.width=650;" src="http://www.bkjia.com/uploads/allimg/131227/163142L22-2.jpg" style="float:none;" title="no1.jpg" />

650) this.width=650;" src="http://www.bkjia.com/uploads/allimg/131227/1631422V3-3.jpg" style="float:none;" title="no2.jpg" />

   分析過程：    

   1.第一幅圖，在No.4039號包，我們看到從伺服器收到了1個RADIUS Request請求，id 是100，通過我們剛才學習RADIUS協議得知，此時從伺服器應該回複一個Access-Challenge報文，我們仔細觀察id是101、102、103...的包，可以看到從伺服器都有給無線控制器回複Access-Challenge報文，唯獨id 100沒有回複，並且在第二幅圖中，我們看到了id是100的重複請求報文，在整個抓包的過程，我都沒有看見id 100的回複報文，大概在收到4039號包的9秒鐘之後，開始抓不到RADIUS報文了，我猜這時無線控制器已經顯示從伺服器block了，結果也確實如我所料。

   2.我們再來看看從伺服器的溫都死安全日誌，我們篩選一下時間，把時間鎖定在這9秒鐘範圍稍微放大一點，可能會略有點時間差），按時間升序排列。

650) this.width=650;" src="http://www.bkjia.com/uploads/allimg/131227/1631422036-4.jpg" title="no3.jpg" />

   你發現一種巧合了嗎？沒錯，第一個審核失敗對應抓包裡的4039號包，第二、三個審核失敗對應4215和4235號包。我們再來看看這幾個審核失敗的日誌，到底記錄了什麼。

650) this.width=650;" src="http://www.bkjia.com/uploads/allimg/131227/1631425Y2-5.jpg" title="no4.jpg" />

650) this.width=650;" src="http://www.bkjia.com/uploads/allimg/131227/1631423Q1-6.jpg" title="no5.jpg" />

   這3個審核失敗都是這個原因，“網路原則伺服器從網路存取伺服器接收的 RADIUS 請求訊息格式不對。”

   這個時候我想到的是百度、Google、微軟technet裡搜尋這個錯誤解決辦法，但是很遺憾沒有找到。

   有個小經驗順便分享下，我們天朝IT還是比較落後的，有時候中文搜不到的東西，換英文搜，也許會有意想不到的結果，比如我之前解決一個Asterisk bug問題就是這樣，將英文出錯提示或錯誤碼在google裡搜，終於找到了自己想要的答案。

   言歸正傳，度娘和穀爹都沒結果，我們還是靠自己啊！看到了這個失敗的原因，考驗邏輯思維的時候到了，“請求訊息格式不對”，我想到了以下問題：

   1.會不會是包格式不對呢？

   2.別的請求包為什麼審核成功了呢？

   3.失敗的包和成功的包在包的格式上，到底有什麼區別？為什麼一個失敗了，一個卻成功了？

   4.在RADIUS 的EAP架構中，能夠變化的只有身分識別驗證協議。

   於是，我仔細分析對比4039號包的格式與4051、4055號包的區別重點看應用程式層RADIUS包），如下：

650) this.width=650;" src="http://www.bkjia.com/uploads/allimg/131227/16314250F-7.jpg" style="float:none;" title="no6.jpg" />

650) this.width=650;" src="http://www.bkjia.com/uploads/allimg/131227/163142Hb-8.jpg" style="float:none;" title="no7.jpg" />

   好，我已經看出區別來了，驗證失敗的是Version 1，而驗證成功的是：Version 0，那麼接下來你肯定也會想到他們是什麼意思呢？區別是什麼呢？搞清楚了這個，我們就接近真相了，真相只有一個。

   再次請出度娘、穀爹，找到了這裡：http://www.cisco.com/en/US/docs/net_mgmt/access_registrar/5.0/user/guide/eap.html

650) this.width=650;" src="http://www.bkjia.com/uploads/allimg/131227/16314249E-9.jpg" title="no8.jpg" />

   可以清楚的看到，Version 0是微軟PEAP，Version 1是Cisco PEAP。

650) this.width=650;" src="http://www.bkjia.com/uploads/allimg/131227/163142N92-10.jpg" title="NO10.jpg" />

   好了，我們可以總結一下故障原因了，當然我還是加上了自己的一點判斷：

   有使用者使用了cisco PEAP協議，RADIUS伺服器不支援這種包格式，識別不了，驗證過不去，所以就不會給無線控制器回複Access challenge報文，無線控制器在9秒Interval for timeout(second) : 3  Retransmission times for timeout  : 3）以後會認為RADIUS伺服器掛了，就把狀態置為block，就不給RADIUS伺服器發認證請求了，從而導致當前沒有可以驗證身份的RADIUS是Active的。

問題找到了，但是很遺憾，還是解決不了，因為要我們的微軟RADIUS伺服器不可能支援思科的PEAP驗證方法，而且我們也不可能安裝Cisco的AAA證明伺服器端，網路層面也沒法單純只將cisco PEAP拒絕掉，或者只允許微軟PEAP，到最後還是個無言的結局，公司網路組的大神們討論後改成冷備了。。。

本文出自 “BLANK SPACE” 部落格，謝絕轉載！