前言+環境拓撲：
最近公司新加了1台H3C WX6103無線控制器，用2台配成高可用，防止單點故障，我們的RAIDUS身份驗證伺服器也是隻有1台，上司讓我加1台作為備用RADIUS伺服器，無線控制器可用配置一主多從個RADIUS伺服器，實作熱切換，即主RADIUS挂點的時候，備用RADIUS伺服器可用接管使用者身份驗證的工作，整個環境的大概邏輯拓撲如下，我隻畫了1台無線控制器，對本文分析并無影響。
大概邏輯結構：
無線控制器配置：
由于現在企業中使用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請求呢？這個問題我們抓包分析後再解釋。
分析過程：
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秒鐘（範圍稍微放大一點，可能會略有點時間差），按時間升序排列。
你發現一種巧合了嗎？沒錯，第一個稽核失敗對應抓包裡的4039号包，第二、三個稽核失敗對應4215和4235号包。我們再來看看這幾個稽核失敗的日志，到底記錄了什麼。
這3個稽核失敗都是這個原因，“網絡政策伺服器從網絡通路伺服器接收的 RADIUS 請求消息格式不對。”
這個時候我想到的是百度、谷歌、微軟technet裡搜尋這個錯誤解決辦法，但是很遺憾沒有找到。
有個小經驗順便分享下，我們天朝IT還是比較落後的，有時候中文搜不到的東西，換英文搜，也許會有意想不到的結果，比如我之前解決一個Asterisk bug問題就是這樣，将英文出錯提示或錯誤代碼在google裡搜，終于找到了自己想要的答案。
言歸正傳，度娘和谷爹都沒結果，我們還是靠自己啊！看到了這個失敗的原因，考驗邏輯思維的時候到了，“請求消息格式不對”，我想到了以下問題：
1.會不會是包格式不對呢？
2.别的請求包為什麼稽核成功了呢？
3.失敗的包和成功的包在包的格式上，到底有什麼差別？為什麼一個失敗了，一個卻成功了？
4.在RADIUS 的EAP架構中，能夠變化的隻有身份驗證協定。
于是，我仔細分析對比4039号包的格式與4051、4055号包的差別（重點看應用層RADIUS包），截圖如下：
好，我已經看出差別來了，驗證失敗的是Version 1，而驗證成功的是：Version 0，那麼接下來你肯定也會想到他們是什麼意思呢？差別是什麼呢？搞清楚了這個，我們就接近真相了，真相隻有一個。
再次請出度娘、谷爹，找到了這裡：http://www.cisco.com/en/US/docs/net_mgmt/access_registrar/5.0/user/guide/eap.html
可以清楚的看到，Version 0是微軟PEAP，Version 1是Cisco PEAP。
好了，我們可以總結一下故障原因了，當然我還是加上了自己的一點判斷：
有使用者使用了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，到最後還是個無言的結局，公司網絡組的大神們讨論後改成冷備了。。。