欢迎关注:1,欢迎关注本博客,你可点击右手边的【QQ邮件订阅】订阅本博客!2,本博客推出江湖救急计划,主要为工作中遇到疑难杂症的兄弟提供远程技术支持和分析,如有需要,请在江湖救急计划页面给我留言!

某省厅门户网站A市局访问异常应急处置

作者:竹林再遇北极熊 发布于:2017-11-28 21:47 Tuesday 分类:网络分析

1 情况概述

1.1  网络拓扑结构

    梳理省厅网络拓扑结构,了解WEB服务器通过接入交换机、WAF、抗D,经防火墙对外映射对外提供服务,其中交换机、抗D、WAF均为二层部署,如下图所示


1.2 情况简介

    A市局近期有无法访问省厅门户网站的现象,换个IP即可正常访问,与省厅沟通后发现其他市局和互联网用户均能正常访问。

1.3 分析思...

阅读全文>>

标签: 日志 交换机 TCP wireshark 负载均衡

评论(1) 引用(0) 浏览(1938)

某业务系统访问慢分析

作者:飞鸟 发布于:2017-4-21 15:59 Friday 分类:网络分析

1.    问题描述

一用户内网系统对内提供业务办理业务,其省局和地市都需要访问改业务系统。最近一段时间,经常有地市反映登录较卡及办理业务时也很卡。经过对设备、链路、策略等方面的常规检查,并没有发现问题。近期,由于地市反映卡的现象较严重,用户体验较差,在这种情况下,“捕影”应急响应小组接手处置该问题。

2.    故障现象

经了解与测试,发现在两个方面用户体验较差。

Ø  登录

登录时一直在等待,等一段时间后就提示“连接被重置”

点击查看原图

点击查看原图

Ø  办理业务

根据用户反馈,在填写完相应的表单后,单击“保存”后,需要十多秒才可以保存成功。

3.    网络拓扑

点击查看原图

说明:

1.   负载均衡和防火墙物理上旁路部署,逻辑上串联。

2.   防火墙不仅做网络层的访问控制,同时启用WAFIPS功能

3.   抓包设备对76096509上对相应流量做镜像

4.   Web服务器做负载均衡,用户访问负载均衡虚地址,通过负载均衡后转换为访问实地址,真实服务器有两台10.0.102.1010.0.102.11

5.   客户端访问web服务时,首先经过76096509,然后到防火墙,由防火墙转发到负载均衡,负载均衡再转发到防火墙,然后防火墙转发到真实服务器

客户端到服务器的流量流逻辑相对较复杂,其数据流逻辑如下,其数据包返回时按原路返回:

点击查看原图

4.    故障分析

    由于此故障是应用层面的故障,因此我们怀疑的重点在会对应用层数据包做处理的设备上。防火墙启用了WAFIPS功能,其会对应用层数据包进行过滤,因此其作为怀疑的重点。同时,负载均衡作为代理设备,其负载算法可能会对正常连接造成影响。

    既然怀疑的重点在于防火墙和负载均衡上面,并且用户现场部署有相应的流量镜像设备。因此我们只需要将故障出现时的数据包下载下来分析即可。和用户沟通,其出现故障时间为850左右,客户端IP10.40.44.199,根据用户描述,其在那段时间操作很卡,做个操作需要十多秒的时间。

    过滤相应时间与相应IP的数据包,找到相应的交互数据流。我们来分析交到的数据流。

1.   10.40.44.19910.0.1.10建立完三次握手后(因为抓包设备的原因导致数据包先看到SYN+ACK,序号为163084的包其实为ACK)

2.   10.40.44.199进行一个POST的保存操作,相应POST操作的URL/TopIcis/EntLiaisonsRecordSave.do

点击查看原图

3.   10.0.1.10进行相应的ACK确认,然后10.0.1.10发送了一个Reset报文将连接释放了。

      是不是这个数据包的应用层数据触发了相应的安全策略,才会被reset异常释放掉?我们对其应用层内容进行分析,发现并没有攻击语句,基本上不会触发防火墙的WAF策略。

点击查看原图

既然没有触发相应的安全策略,为什么正常的请求还是被异常释放?肯定是某些机制在起作用或者说某些机制异常导致的。那么我们需要定位到是防火墙、服务器还是负载均衡设备发出的reset包。

由于抓包设备是对相关vlan的流量做镜像的,也就是说服务器、防火墙及负载均衡的数据包都被抓取到。

直接分析数据包,可以看到其TTL=64,IP10.0.1.10,直接分析是负载均衡发送的reset数据包,但是负载均衡作为代理设备,服务器或防火墙发送的reset数据包转发到负载均衡时,其数据包层面的表象就是上面所看到的

点击查看原图

     因为我们需要分析这个数据是不是服务器或者防火墙发出的?防火墙工作为路由模式,如果是防火墙或服务器发出的reset数据包,那么我们直接通过下面过滤表达式即可过滤出来:

(ip.src == 10.0.102.10 or ip.src == 10.0.102.11) and tcp.flags.reset == 1

    直接过滤,果然发现10.0.102.11发送了一个reset包,难道是防火墙或者服务器发起的?仔细分析了一下时间,上个报文的时间为08:51:02秒,而这个报文的时间为08:50:53秒,reset包作为传输层的一个标识数据包,中间设备转发时肯定不会产生这么大的延迟,因此,个人推断这个数据包肯定不是这个会话的。因此发送这个reset包的正是负载均衡设备本身。

点击查看原图

    分析至此,已定位到是负载均衡发起的reset报文将该连接释放导致的。但是,这个结论与用户描述的现象并不吻合:进行保存操作时比较卡,需要十多秒才可以保存成功。上面我们分析的是负载均衡把连接释放了。如果这样的话,用户的现象应该是连接中断才对。

    如果是这样的话,客户端肯定会存在重传的数据包,我们直接对应用层的数据进行过滤,果然发起客户端在11秒后进行了重传操作。

点击查看原图

    重传相应的保存操作报文后,服务器正常响应。

点击查看原图

    至此,对这次性能慢的分析已形成闭环。用户保存卡的原因为:客户端在向服务器进行保存操作时,被负载均衡异常释放掉;然后客户端在11秒后再次请求,服务器正常响应,负载均衡正常转发。

    关于负载均衡为什么将上一个post报文丢弃并发送reset报文不作为此次分析的重点,感兴趣的小伙伴可以私下讨论。

阅读全文>>

标签: 疑难杂症 负载均衡 reset 丢包 重传 访问慢 故障分析

评论(5) 引用(0) 浏览(2215)

可能的URL超长导致丢包案例

作者:易隐者 发布于:2012-12-10 14:03 Monday 分类:案例讨论

       上周五,有网友兄弟给我发了一个报文,让我帮忙查看是否存在什么异常问题。我查看其TCP会话交互过程,如下图所示: 

点击查看原图

       单从这个报文交互来看,客户端与服务器的TCP连接建立正常,客户端已经向服务器发送过get请求,并得到了服务器的确认,问题出在客户端向服务器发送的第二个get请求:“
http://192.168.0.12/Default_Login.aspxusercode=x6x9&password=81xx9xxx52x04xx20036xxx8313xx055&

MyCurrentCompany=&rdnum=0.5966797953405811”。

       客户端发出这个get请求之后,在37秒的时间内重传了5次,服务器端无应用数据需要主动的发给客户端,因此在这个时间段内我们未见来自于服务器的报文,而如果客户端的发送的这个get请求到达了服务器端,则服务器会根据其请求内容作出应用响应,最起码服务器端会对客户端的TCP报文发送ACK确认。但是这些都没有出现,这能够说明客户端的get请求报文根本未到达服务器端,即客户端的这个get请求报文被中间设备丢弃了,我们查看客户端的发送的第二个get请求报文的解码

点击查看原图

       我们发现这个报文除了其请求的URL长度较长(420字节)外,其他似乎也没什么特别的,因此,个人推测其被中间设备丢弃的原因可能是其URL超出了防火墙/负载均衡/WAF/IPS等设备的限制,或者是URL中包含“uesr”、“password”等敏感字段而被中间设备丢弃了。

阅读全文>>

标签: TCP 负载均衡 解码 ACK确认 防火墙 IPS get URL超长 get请求

评论(3) 引用(0) 浏览(4530)

【转】上网认证页面无法打开案例

作者:易隐者 发布于:2012-11-25 10:40 Sunday 分类:案例讨论

【说在之前】:

1,该案例的确属于疑难故障范畴,若不是通过抓包方式,站在数据包交互的角度进行分析是无法定位、解决该故障的,因此,该案例具有学习参考价值;

2,案例的分析用到了关联分析法和对比分析法,思路非常清晰,但整个文档在图文编辑和措词这块还可以做进一步的加强,考虑到原文的完整性,我不对该文档做任何修改;

3,难能可贵的是作者在找到故障原因并解决故障之后,没有像大部分人那样将这个故障束之高阁, 而是将自己的分析思路、过程整理成文档,分享给大家,另外,发现其中难以解释的、存在疑问的地方,供大家一起讨论,这正是我一直倡导的“自我总结、无私分享、共同探讨、共同进步”的学习方式;

4,针对该案例后面的疑问,我就我的理解作出相关解答,供大家参考。

     针对第一个疑问:AC在此处工作在透明模式下,正常情况下其对报文的干预和处理根本不需要经过路由,也就是说,AC在做HTTP重定向的时候,根本不需要根据路由表,将这个HTTP重定向报文转发给PIX防火墙,而应该直接构造相应HTTP重定向报文发往核心交换机,因此,此处出现这样的问题,我个人认为如果AC是按照路由方式处理的话,其应该有相应的转发表,转发表中会有下一跳、转发接口等相关信息,而出现此案例中的问题,说明AC的转发表出现了异常,可能是其上联口和下联口是属于同一网段,而AC转发表未对其进行区分导致的;

     针对第二个疑问:这里需要明确,AC的管理口和业务口是否是完全独立的,如果是,那么所谓的两条默认路由是完全分开的,没有任何问题,如果不是,那么根据不同的系统处理方式,负载均衡(根据报文或其他)或者选择其中一条都是有可能的,多年前我曾写过一篇《供电局调度所前置机故障解决说明》的文档,就是两条默认路由导致异常的案例,过段时间我把这个案例共享到我的博客供大家参考。

5,该案例作者肖鉴为我以前推出《合肥网络分析技术团队招募学徒》的第一个学员。他不远千里从福建专程请假几十天跟随我学习相关知识,当我第一眼看到他时,我就被他的这种对技术执着追求的行为所感动,他基础不错,学习踏实认真,我个人认为我真正给他的帮助不在于具体技术的成长和进步,而在于影响他对技术的自信、清晰的职业发展方向规划以及行事的风格,在他身上我能看到我以前的影子,他现在深信服的总代,刚获得深信服深信服华南区技术大比武冠军,看到他的成长,我的内心是无比的欣慰。

【原文全文】

1. 网络环境

        故障网络环境如下图所示: 

点击查看原图

说明:
1. 出口防火墙工作在路由模式做NAT代理内网上网,E1口IP地址192.168.247.1/24。
2. 上网行为管理工作的网桥模式下,为其网桥IP地址配置192.168.247.3/24、网关IP地址为192.168.247.1用于设备管理,下联三层交换机IP地址为192.168.247.2/24。由于,前置PIX防火墙为阻止192.168.247.0/24网段上网,所以为了上网行为管理能够更新内置规则库,上网行为管理口下联三层核心交换机为其配置IP地址192.168.20.250网关IP地址192.168.20.1。
3.上网行为管理对内网部分网段实行认证上网。

2. 故障现象

       内网无须进行认证PC机访问互联网正常,需进行认证网段PC机上网在正常情况必须得先进行认证输入用户名和密码后方可访问互联网,故障表现为认证网段PC机无法正常跳转至认证界面输入用户名和密码。如下图所示: 

点击查看原图

3. 故障分析

3.1 常规分析

       在PC上访问网络时无法跳出登陆界页时,我们手动输入http://192.168.247.3认证登陆页面是正常,如下图所示,并且,输入完认证用户名和密码后可以正常访问互联网。说明网络中并不存在路由问题。那么是否可能是设备本身处理机制出现问题呢?还是,PC机与上网行为管理设备通信出现了其它的异常导致PC机无法正常弹出认证页面?。 

点击查看原图

阅读全文>>

标签: 交换机 团队 疑难故障 TCP 网络分析 负载均衡 抓包 深信服 上网行为管理 HTTP重定向 AC 路由表 转发表

评论(0) 引用(0) 浏览(10513)

F5负载均衡报文处理流程

作者:易隐者 发布于:2012-11-17 11:59 Saturday 分类:参考资料

       F5负载均衡报文处理流程,由于版面较大,我无法截取全图,大家如有需要的请下载附件。

点击查看原图

阅读全文>>

附件下载:
F5_BigIP_Path_Graph_v1_5d.zip 502KB

标签: 负载均衡 F5 报文处理流程 BIG-IP

评论(0) 引用(0) 浏览(5688)

Powered by 易隐者 基于emlog 皖ICP备12002343号-1