服务器经网关地址映射访问时的注意事项
作者:易隐者 发布于:2013-6-20 22:05 Thursday 分类:网络分析
有朋友在用户现场遇到一个故障无法定位,网上找我帮忙,大概情况是某内网用户将一台服务器端口映射出去供互联网访问,内部主机通过互联网地址进行访问测试时,发现无法正常连接。我让其在服务器区域前端防火墙上抓客户端与服务器交互的报文,如下:
10:33:28.747771 R@eth3 IP 172.16.7.68.8525 > 172.16.2.146.3389: S 3134287530:3134287530(0) win 58400 <mss 1460,nop,wscale 0,nop,nop,sackOK>
//客户端发起SYN请求
10:33:28.747786 X@eth4 IP 172.16.7.68.8525 > 172.16.2.146.3389: S 3134287530:313
4287530(0) win 58400 <mss 1460,nop,wscale 0,nop,nop,sackOK>
//防火墙内口转发客户端的SYN请求
10:33:28.748165 R@eth4 IP 172.16.2.146.3389 > 172.16.7.68.8525: S 3568427973:356
8427973(0) ack 3134287531 win 16384 <mss 1460,nop,wscale 0,nop,nop,sackOK>
//服务器响应客户端的SYN报文
g10:33:28.748172 X@eth3 IP 172.16.2.146.3389 > 172.16.7.68.8525: S 3568427973:356
8427973(0) ack 3134287531 win 16384 <mss 1460,nop,wscale 0,nop,nop,sackOK>
//防火墙转发服务器响应报文
10:33:28.749519 R@eth3 IP 172.16.7.68.8525 > 172.16.2.146.3389: R 3134287531:313
4287531(0) win 0
10:33:28.749523 X@eth4 IP 172.16.7.68.8525 > 172.16.2.146.3389: R 3134287531:313
4287531(0) win 0
//客户端发送RST报文
客户端发起SYN连接请求,防火墙转发,服务器响应SYN/ACK报文,这个过程都是正常的,但是紧接着却是客户端发送RST报文,异常释放了这个TCP连接。单从这个数据包交互的过程来看,大部分的人都会认为是客户端的问题。
但是其实跟客户端完全无关。我很早以前在天融信做工程师时曾今在用户 处遇到过同类型的问题,当时解决完之后曾打算将其作为一个经典案例写下来供大家分享,后来由于时间问题,拖时间长了,原始报文找不到了,只能作罢,今天就 这个案例,我来做一个简单的分析和说明,以供大家参考。
我们在用户现场经常会遇到这样的客户需求:
1,用户希望通过通过防火墙等设备的端口映射/地址映射功能实现内网服务器对互联网访问者提供服务的需求;2,为了使用方便,用户一般都会同时要求内部客户端也可以直接通过服务器映射后的互联网地址进行访问。
第一点需求非常容易实现,在防火墙上做一个常规的地址映射/端口映射,再将服务器对外提供服务的端口放行即可。但是在实现用户第二点需求时,我们需要注意一个关键的问题,那就是客户端与服务器端的报文来回路径不一致问题。
我们先将故障发生时的报文交互过程跟大家一起分析一下,其交互过程大致如下图所示:这个交互的过程具体描述如下:
1) 客户端访问经网关设备映射出去的服务器的互联网地址,向其发送SYN报文;
2) 客户端访问的目的地址经网关转换为内网服务器真实地址之后,转发至内网服务器,此时报文的源IP地址是真实的内网地址(另外一种处理情况为出口网关将该报 文经NAT后至转发出互联网接口,然后再匹配识别为内网服务器的映射的策略,再次将该报文转发至内网服务器,此时报文的原IP、目的IP地址均发生变化 了,此种情况下由于报文原IP地址已经改变为NAT后的互联网地址,因此不在我们的讨论的范畴之内,这个跟网关设备对数据报文处理的流程有关,在此不详细 讨论,有兴趣的同学可仔细思考思考。);
3) 内网服务器在接受到这个报文之后,直接向客户端内网IP发送SYN/ACK报文;
4) 内网客户端接收到服务器的SYN/ACK报文,但是客户端的TCP连接表中并没有与之相应的信息(因为客户端是与服务器映射后的互联网地址发送SYN请求报文的),因此,客户端向服务器发送RST报文。
5) 服务器端收到这个RST报文之后,其会将这个TCP连接释放,因此客户端连接服务器失败。
那么,在这种情况下,我们如何解决这个问题呢?其实,解决的方式就是在网关处增加一条源地址转换策略,将访问服务器的客户端地址转换为一个互联网地址或网关内部接口地址,如此巧妙的让服务器回包给网关(防火墙),从而保证客户端、服务器的报文来回路径一致。
NAT在很多复杂环境下的确能够帮助我们巧妙的解决很多令人头疼的问题,我在博客文章《某公司业务系统经ISA防火墙访问正常而经硬件防火墙访问慢故障分析解决案例》中曾今在文章后面留下一个思考问题,至今无人应答,我也没给出答案,其实答案就是NAT。有兴趣的兄弟自行去查看那篇文章吧,在此我不做展开了,当然NAT也可能会带来一些意想不到的问题,以前遇到过一个案例,等我有空的时候再整理发布吧。
这个用户现场案例,我们通过在防火墙中增加一条源地址转化策略之后,再次以互联网地址访问服务器,正常,数据包交互如下:
10:37:54.637923 R@eth3 IP 172.16.5.253.9182 > 172.16.2.146.3389: S 223750126:223750126(0) win 58400 <mss 1460,nop,wscale 0,nop,nop,sackOK>
10:37:54.637943 X@eth4 IP 172.16.5.253.9182 > 172.16.2.146.3389: S 223750126:223
750126(0) win 58400 <mss 1460,nop,wscale 0,nop,nop,sackOK>
//客户端发起SYN报文
10:37:54.638373 R@eth4 IP 172.16.2.146.3389 > 172.16.5.253.9182: S 892121112:892
121112(0) ack 223750127 win 16384 <mss 1460,nop,wscale 0,nop,nop,sackOK>
10:37:54.638379 X@eth3 IP 172.16.2.146.3389 > 172.16.5.253.9182: S 892121112:892
121112(0) ack 223750127 win 16384 <mss 1460,nop,wscale 0,nop,nop,sackOK>
//服务器响应SYN报文
10:37:54.639048 R@eth3 IP 172.16.5.253.9182 > 172.16.2.146.3389: . ack 1 win 584
00
10:37:54.639052 X@eth4 IP 172.16.5.253.9182 > 172.16.2.146.3389: . ack 1 win 584
00
//客户端确认,连接建立
标签: TCP RST SYN 防火墙 NAT 地址转换 网关 来回路径不一致 映射
Linux,我来了。
作者:易隐者 发布于:2013-5-31 7:30 Friday 分类:系统主机
Linux,这个曾经多次令我望而却步的系统,总让像我这样的初学者觉得深不可测,但是Linux的开放和知识共享的精神实在是令我折服,从今年开始,我将为之制定逐步的学习计划,从基础开始学起。Linux,我来了!标签: Linux
wireshark过滤器使用注意事项
作者:易隐者 发布于:2013-4-26 15:23 Friday 分类:网络分析
以前一直认为各个网络分析产品的过滤器工作机制应该都是一样的,今天在协助分析定位一个故障的时候,我使用wireshark进行分析,用HTTP作为过滤条件,想仅查看HTTP交互的报文,其过滤后显示的内容如下图所示:单看上图的显示内容,我们很容易的认为,这就是纯粹的HTTP交互,但是未看见三次握手连接建立的过程,一开始我心里是有点疑惑,但是并未往心里去,后来在合作伙伴的提醒下,我再尝试使用TCP作为过滤条件,方才看到大量的SYN报文,如下图所示:
实在想不通,难道HTTP的三次握手过程不属于HTTP报文????不知道wireshark在这一块是如何设计和考虑的,总之个人认为这个设计不合常理。我们以后在使用wireshark过滤器的时候稍微注意一下,避免出现误解。
策略误报导致应用保存失败的分析案例
作者:易隐者 发布于:2013-4-20 14:13 Saturday 分类:案例讨论
查看这个交互的过程,我们可以非常清晰的看到,客户端与服务器TCP三次握手正常,问题出在客户端提交POST请求的报文被中间设备丢弃了。比较有趣的是,客户端在尝试两次重传之后,较为聪明的将这个POST请求字段(长度为859B)拆分为两个长度分别为536B和323B的字段,并先将长度为536B的应用字段重传给服务器,我们清楚的看到服务器对这个应用字段作出了确认,这说明这个长度的应用字段正常到达了应用服务器,但是后续长度为323B的应用字段一直被丢弃,这很容易想到是中间设备策略误报一直丢弃某些固定报文导致的,我们来看一下这个应用字段里到底封装的是什么应用数据,我们首先看这个报文的应用字段解码如下:
标签: 应用故障 IPS 策略误报 POST WAF SQL注入
《某公司QQ掉线分析案例》之我见
作者:易隐者 发布于:2013-4-14 17:52 Sunday 分类:案例讨论
大致看了分析过程之后,觉得其中存在一些疑问,特地找时间针对这个案例做一个大致的分析,以便大家讨论参考。原本准备做相关交互图示的,由于个人时间问题,这次就免了,还望各位见谅。
1, QQ多人同时掉线,大约1秒就自动连上,浏览网页和其他应用没有问题
QQ属于一种终端的应用,一般情况下,局域网内某应用出现同时掉线、缓慢等问题,基本上可以排除是单个终端的问题,因为从这个现象上来看,这是一个全局问题,可能是业务应用本身、业务服务器或者承载业务的网络系统出现了问题。在此故障分析案例中,作者提到QQ同时掉线但是浏览网页和其他应用没有问题。通过这个故障现象的描述,我个人首先可能会想到整个互联网出口是否会出现网络瞬间中断的情况?这是我个人的猜想,因为如果真是互联网出口出现网络瞬间中断,那么HTTP等基于TCP的应用由于TCP的重传机制,在出口网络中断1秒左右的时间内,终端使用者不会有明显的异常感受,而基于UDP等应用,可能会出现掉线等现象,在网络出口恢复正常之后,QQ再次自动上线。这个猜想的原因至少可以很好的解释该案例作者一开始描述的故障现象。
2, QQ掉线是QQ服务器主动RST连接导致的,腾讯给出的解释是由于用户端IP地址出现了变化。
1),QQ大部分情况下应该是使用UDP协议的,少数情况下使用TCP协议。
QQ是一个较为复杂的应用,其为了满足使用者在各种复杂的环境对QQ的正常使用,其会存在多种模式和网络交互行为,大部分情况下,QQ默认会使用UDP协议进行交互,少数情况下会使用TCP甚至TCP的80端口、443端口进行交互,特殊情况下,根据需要和设置,其还可以通过代理的方式进行交互。
在该案例中,测试机的QQ似乎使用的是TCP443端口进行交互的,但其实绝大部分情况下,QQ都是基于UDP协议进行交互的。因此在此案例中,按照我个人较为严谨的分析习惯,测试机的选择非常值得做进一步的商榷。
2),就算这个客户网络中所有使用的QQ都是基于TCP协议的,如果真是如腾讯所说,是由于QQ服务器发现用户IP出现了变化,才向客户端发送RST报文的,那么:
该RST报文ACK位是置一的,因此这个RST报文并不是如作者想象的情况下产生的。
其三,我们再来看另外一张截图:
3,如果真的是防火墙的NAT出现了这种低级的错误和BUG,那么对用户影响最大的应该是HTTP等基于TCP应用。因为很多HTTP应用的动态口令、验证码等都需要通过数个不同的TCP连接与服务器进行交互,一旦出现该案例作者所说的防火墙处理BUG,将导致这些应用出现访问故障。而不会仅仅是无关紧要的QQ应用出现问题。
4,QQ掉线而其他TCP应用正常,很可能是防火墙的UDP会话保持时间过短导致的。
因为很多人挂QQ并不一直与好友聊天。而一般情况下,防火墙等为节约设备资源,会将UDP的会话超时时间设置为一个较短的数值,如60秒,那么如果用户在这个超时时间内无任何数据交互的话,防火墙会将这个UDP会话从防火墙连接表中删除,当QQ客户端再次尝试与QQ服务器交互时,其发送的QQ状态更新报文就会被防火墙丢弃,导致QQ客户端掉线。QQ掉线后,客户端会再次发起新的连接,此时防火墙将其作为一个新建的UDP连接进行处理,QQ因此再次成功上线。当然这个很难解释QQ同时掉线的现象。
5,在NAT POOL情况下,NAT设备会根据不同的算法(基于源IP的、基于连接的等)实现NAT POOL的地址复用,大部分算法应该都是基于源IP等计算的,如果是基于数据包、连接等进行计算,则很可能会导致各种问题的产生,我以前有一个非常经典的案例——《移动无线VPN客户端隧道建立故障分析》,下次我发布到我的博客,大家可去参考。
简单总结:
日历
最新日志
链接
分类
最新碎语
- 如果一个人想要做一件真正忠于自己内心的事情,那么往往只能一个人独自去做"——理查德·耶茨
2019-06-25 21:34
- 日后我们知道,真正的人生道路是由内心决定的。不论我们的道路看上去如此曲折、如此荒谬地背离我们的愿望,它终归还是把我们引到我们看不见的目的地。(茨威格《昨日世界》)
2019-03-16 21:27
- 如果你渴望得到某样东西,你得让它自由,如果它回到你身边,它就是属于你的,如果它不会回来,你就从未拥有过它。——大仲马《基督山伯爵》
2018-10-09 22:07
- 人生有两大悲剧:一个是没有得到你心爱的东西;另一个是得到了你心爱的东西。人生有两大快乐:一个是没有得到你心爱的东西,于是可以寻求和创造;另一个是得到了你心爱的东西,于是可以去品味和体验。——弗洛伊德
2018-09-25 18:06
- 一个人越有思想,发现有个性的人就越多。普通人是看不出人与人之间的差别的——布莱兹·帕斯卡尔
2018-08-30 18:44
存档
- 2020年11月(2)
- 2018年1月(1)
- 2017年12月(1)
- 2017年11月(6)
- 2017年6月(1)
- 2017年5月(1)
- 2017年4月(1)
- 2017年3月(1)
- 2016年11月(1)
- 2016年4月(1)
- 2015年7月(2)
- 2015年6月(1)
- 2015年5月(5)
- 2014年12月(1)
- 2014年11月(1)
- 2014年10月(1)
- 2014年8月(1)
- 2014年7月(1)
- 2014年6月(1)
- 2014年5月(1)
- 2014年4月(3)
- 2014年2月(2)
- 2014年1月(2)
- 2013年12月(1)
- 2013年11月(1)
- 2013年10月(2)
- 2013年9月(1)
- 2013年8月(1)
- 2013年7月(3)
- 2013年6月(2)
- 2013年5月(1)
- 2013年4月(3)
- 2013年3月(1)
- 2013年2月(2)
- 2013年1月(2)
- 2012年12月(11)
- 2012年11月(12)
- 2012年10月(12)
- 2012年9月(26)
- 2012年8月(29)
- 2012年7月(18)
- 2012年6月(2)
- 2012年5月(25)
- 2012年4月(16)
- 2012年3月(13)
- 2012年2月(6)