某局点无线Portal认证重定向过程耗时长问题处理经验案例

某局点无线Portal认证重定向过程耗时长问题处理经验案例

一、组网拓扑：

某校园网局点采用了我司WX6000系列高性能无线控制器，管理800多个AP，为校区学生宿舍、读书馆、教室提供无线接入服务，并使用我司IMC做无线Portal认证，AC作为接入BAS：

二、问题描述：

有学校老师和学生反馈，部分终端概率性出现关联SSID后，打开WEB认证页面过程非常慢的问题，有的甚至需要耗时10秒以上，影响了WLAN网络的使用体验。但同时，一旦用户Portal认证通过，后续的上网过程就非常流畅了，也即是问题仅仅发生在Portal页面弹出过程。

三、问题定位过程：

首先，我们第一直觉是怀疑无线网络质量不佳。但这一点又和用户反馈的认证通过后网络使用流畅的说法相悖，所以排除这种可能。

其次，由于是学校局点，WLAN业务量大，也可能和Portal服务器性能瓶颈相关。于是，我们对Portal服务器WEB页面弹出做了测试，即让问题终端绕过AC重定向过程，直接输入Portal认证url，发现页面能非常快的打开，并无卡顿现象，重复多次都未复现问题。于是排除了imc故障的可能性。

再次，我们协调客户检查了网络中是否有防火墙对WLAN用户做了特殊策略，得到的答复是否定的。到这里，基本明确该问题与有线网络侧没有关系。

最后，问题点回归到AC上，我们仔细检查了AC状态，包括CPU、内存、日志信息，未见明显异常。于是，我们开始在终端侧wireshark抓包，并同步在AC上抓取debug portal信息。问题终于露出端倪。

（1）AC上debug portal信息有报错，显示故障终端有旧TCP连接存在。

*Nov  2 16:53:08:132 2013 AC-C TCPCHEAT/7/TCPCHEAT_DEBUG: Error:Connection exist, Srcport:49325, DstIP:50.19.209.45, new Srcport:49326,DstIP: 50.19.209.45

*Nov  2 16:53:08:135 2013 AC-C TCPCHEAT/7/TCPCHEAT_DEBUG:  Source MAC = b0aa-36fc-9efd

 VLAN =  112, PortIndex =    0

 45 00 00 28 b3 1b 40 00

 40 06 d3 99 0a 0c 10 9c

 7b 7d 1d f6 a6 cb 00 50

 8f eb f6 5e b9 ad 3a 66

 50 10 72 10 68 2f 00 00

（2）终端抓包上，看到终端访问***.***域名的TCP连接请求未收到AC的响应。同时该终端后台软件（非用户web认证所使用的IE浏览器）访问***.***的连接却被成功重定向。注意，后台软件的HTTP重定向对用户来说是不察觉的，即用户无法在后台软件中完成Portal认证。

四、定位结论及过程总结：

问题根因已明确，原来终端装了360安全管理软件，这款软件会在PC系统的后台运行，并每隔一段时间就向360服务器发送http请求。设备侧并不能识别这个链接是用户正常的IE浏览器行为的还是终端后台程序行为，所以AC对这个后台访问链接进行了重定向，而一旦这个重定向链接建立，设备IE浏览器正常的web访问就无法同时被AC重定向。必须等原TCP链接自动老化或者终端主动RST断开链接后才能发起下一次重定向过程。

问题原因总结为，终端后台程序的干扰导致用户的IE浏览器概率性出现需要等待几秒甚至十几秒才能成功重定向。

回顾整个处理过程，我们逐一排除了WLAN网络质量差丢包、Portal服务器性能瓶颈、防火墙故障的可能性，最终通过在终端抓包和AC侧debug找到了问题根因。并且前期的故障问题点排除过程并未花费过多人力和时间，比较高效率的完成了这个故障定位。

五、问题解决：

解决办法是彻底卸载360相关软件。大家可能会提出疑问，为什么不允许设备同时和终端建立多个http连接并全部重定向呢？

这确实是一种可能的解决办法，但要考虑实际应用环境可能存在安全攻击的风险。即AC设备为了防止受到恶意攻击，限制了和同一个终端的TCP并发连接数，防止不怀好意的客户端对AC进行破坏性的饱和DOS攻击，导致AC陷于瘫痪的风险。