本文作者:小烨
江湖告急令:
歪伯(Web)的认证消失了
大事不好了,你家隔壁的XX大学歪脖(Web)认证消失了,底下的众多小弟不能上网冲浪,要造反啦!
急死我了。浏览器里输入6.6.6.6都不行,上次输入后就可以溜得起飞,这次不管用了。
目测拿小米+步枪(某米手机)的人最近好像买了一些新装备(手机操作系统),正要找歪伯炫耀,就发现怎么都找不到歪伯了。
莫慌,我给你传授几招 “四两拨千斤” 的掌法,保证给你找回歪伯。
1
招式一:分而治之定位法
我跟你说这一招啊,就是一刀下去,歪伯就两段。我呸……是一刀下去就知道歪脖消失在哪里了。
那这一刀要砍在哪里呢?我们来看一下昨天他们是怎么找到歪伯的:
很明显,村口的小卖部老板纳斯是个重要的角色,那就拿他“开刀”。
“一刀”口诀:
在浏览器里输入一个IP地址访问(例:6.6.6.6,和自己手机地址不同网段的,使报文可以发到NAS上)。
“一刀”的效果:
如果出现如下图,浏览器的地址栏变成了另一个地址(是WEB认证页面的URL地址) ,说明 纳斯看到过歪伯在坡头家里。
如果出现如下图,浏览器的地址栏内容没有变化,有时候直接显示“页面无法显示”,说明纳斯没有听到小弟们的问题。
Tips:如果我们输入域名(比如http://www.baidu.com)不能显示认证页面,而输入IP地址(比如6.6.6.6)能能显示认证页面, 则大概率是DNS解析问题,建议排查终端与DNS的连通性或更换DNS地址。
2
招式二:顺蔓摸瓜寻踪法
“带刀”去问过纳斯后,我们大概知道了原因了,但具体是哪里出问题了呢?我们就把全村的地图拿出来瞅瞅,看歪伯可能丢在哪个路口了。
1) 终端(小弟)通过 DHCP 协议获取到 IP 地址 。
2) 终端打开浏览器,发起 HTTP 请求(以 6.6.6.6 为例)。
3) 交换机将自己伪装成目标站点 6.6.6.6,与终端建立TCP连接(TCP三次握手) 。
4) 交换机收到终端发出的 HTTP GET报文后回应一个 HTTP 响应报文,报文中携带了重定向的 URL 等参数。
5) 终端收到交换机的 HTTP 回应之后,与URL参数中的Portal 服务器再次建立TCP连接,并获取认证页面(重定向URL)。
看了地图,我们就可以用一些探测器,探探路:
1)看一下路好不好走,会不会掉坑里了?
终端上访问(PING)交换机 或 其他 直通地址(direct-vlan XX、 web-auth direct-host X.X.X.X、http redirect direct-site X.X.X.X、安全通道等),哪里不通点哪里!
2)看一下路上的指示牌对不对,会不会被引到其他地方去了?
设备配置命令是遗漏,特别是URL、KEY和接口下调用的Portal名称。
3
招式三:草蛇灰线寻踪法
如果歪伯藏得太隐秘,上面的招数都没办法查到他藏身之处,那小锐也只能出动左膀右臂:第八阿哥(DEBUG)和抓包妹(镜像抓包),他们可是我在纳斯家安插了两个卧底,他们早就告诉我歪伯经常和协姨(交互协议)有来有去,看看他们的本事:
抓包妹在纳斯家的分店上下联的一台二层汇聚设备上抓包,发现:TCP连接被纳斯reset,也没有看到纳斯给小弟们响应200 OK报文:
正常交互报文应该是这样的:纳斯响应200 ok报文后,TCP拆连接。
接下来我们就要去问问纳斯:为什么要重置(reset)。第八阿哥,该你出手了。
终于,发现纳斯家在歪伯消失时大量异常日志,如下:
[2020-06-16-172.168.200.1:31:11][2020-6-11 23:46:39][20213]<httprd_proc_eportalv2>Get the template failed
[2020-06-16-172.168.200.1:31:11][2020-6-11 23:46:39][20214]<httprd_proc_eportalv2>Get the template failed
最后查出来,原来小弟们给纳斯问话的时候带了口音(GET报文的DSCP非0),导致纳斯听不懂的情况,同时分析抓包的数据,发现无法重定向的情况,DSCP的值都是非0,如下:
因此根据上述分析看是小弟里最近来了一些口音比较重的(例如新款X米10 手机),802.11E的优先级不为0,当GET报文通过无线AP, 由于AP缺省开启WMM,使AP会根据802.11E的优先级不同映射到DSCP上,导致DSCP值被AP修改成一个非0值, 从而导致纳斯(NAS)听不懂(发出的HTTP报文QoS字段不为0)就没有告诉他们歪伯在哪里(用户连接WiFi,获取到IP地址后发现无法重定向到Portal页面)。
后续我们设备上口音翻译器(交换机上将DCSP端口修改为0), 将我们纳斯(NAS)听不懂的名称转换成能听得懂的口音(能够识别的报文)以后, 歪伯顺利回家了。
为了解决终端发送上来的GET报文中QoS字段不为0的问题, 我司提供了如下解决方案:
1、在汇聚设备上通过QoS功能,强制修改所有报文的DSCP值为0,具体汇聚上配置如下:
ruijie(config)#mls qos map ip-precedence-dscp 0 0 0 0 0 0 0 0 ===》全局配置修订DSCP值为全0
ruijie(config)#int ag 5
ruijie(config-if-AggregatePort 5)#mls
ruijie(config-if-AggregatePort 5)#mls qos trust ip-precedence ===》接口配置信任配置
内功秘籍
这套“四两拨千斤”的武功秘籍教给你们了,祝大家早日修炼成为功夫大师!
相关阅读
这些防火墙命令都爱说大实话,让排障少走弯路 |运维实战家
冲出传统广域网的牢笼,带你走进SD-WAN的世界
你不知道的BGP新特性:“ADD-PATH” |运维实战
系统蓝屏的背后究竟是谁在搞鬼?| 运维实战家
新技能get√ 你知道谁在攻击你的Wi-Fi吗? | 运维实战家
负载均衡:浅谈常用场景锐捷设备的优化方法 | 运维实战家