前言+环境拓扑：
最近公司新加了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，到最后还是个无言的结局，公司网络组的大神们讨论后改成冷备了。。。
转载于:https://blog.51cto.com/blankspace/1294568
6万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
