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

服务器经网关地址映射访问时的注意事项

作者:易隐者 发布于: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:31
34287530(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 地址转换 网关 来回路径不一致 映射

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

某业务系统由于连接数限制导致间歇性访问慢故障分析案例

作者:易隐者 发布于:2012-9-26 18:05 Wednesday 分类:网络分析

【说在之前】:

1,该案例为端系统设置连接数限制导致的应用间歇性缓慢故障,在实际工作环境下,我们更容易遇到的是中间系统对连接数限制导致的一些范访问异常,令人头疼的是,并不是所有开启连接数限制功能的中间系统在丢包后都会向源主机发送ICMP差错报文,这会给大家分析定位带来难度,大家在实际工作中需要留意;

2,该案例涉及到的知识点主要为“ICMP主机管理性禁止差错报文”和“连接数限制”,关于ICMP主机管理性禁止差错报文,大家可参考本博客《ICMP通讯管理性过滤禁止差错报文(type 3,code 13)》一文,虽然“type 3,code 10”与“type3,code 13”有些差异,但是差别不大,可以借鉴;关于连接数相关知识点,大家可参考本博客《连接数相关知识》一文;

【我的案例】:

1 故障环境

网络拓扑:

点击查看原图


说明:
1,内部办公机器都是192.168.1.0/24段的,内部办公主机通过防火墙做NAT,转换为X.X.X.138访问互联网;
2,内部办公服务器的地址为192.168.1.191,其通过防火墙映射为公网地址X.X.X.139对外提供6888端口的web服务。
业务访问流程:
       内部办公机器都是通过NAT后的公网地址X.X.X.138访问办公服务器的公网地址X.X.X.139。其流程如下图所示: 

点击查看原图


2 故障现象

       故障现象主要表现为:
1,部分内网办公主机经常出现打开主页慢、登录慢或者某些页面不显示的情况,如下图所示: 

点击查看原图

打开主页时的长时间等待页面截图 

点击查看原图

登录时长时间等待页面截图

2,这些故障现象间歇性出现,有时多刷新几次页面后,打开的速度会恢复正常。
3,外网用户访问业务系统一直正常,该故障已经持续数月。

3 故障分析

       通过故障现象,我们可以看出,这是比较典型的部分系统出现问题的案例,由于其不具备全体的故障特征,又是间歇性的发生,因此,此类故障按照常规的分析方法很难找到真正的故障原因,我们还是先在客户端抓取一下故障时交互的数据包,站在数据包的角度来分析一下可能的原因。
1,找一台出现故障的主机192.168.1.167,捕获其打开主页面缓慢时的数据包。
2,查看缓慢时的数据交互情况,如下图所示: 

点击查看原图

       我们通过delta tima值可以看到,这个交互的过程存在较大的延时,并且我们发现,在交互的过程中存在数个“ICMP主机通讯管理性禁止”的差错报文,这些报文都是X.X.X.139发给故障主机192.168.1.167的。
3,我们双击其中一个ICMP主机通讯管理性禁止报文,查看其封装的被过滤的原报文相关信息,如下图所示:

点击查看原图

       我们发现,被X.X.X.139管理性过滤掉的报文是192.168.1.167以源端口4075发往X.X.X.139的6888端口的TCP SYN请求报文。
4,我们再结合上下数据包交互的情况,我们可以发现,这个ICMP主机通讯管理性禁止报文的前一个报文正是192.168.1.167以源端口4075发往X.X.X.139的6888端口的TCP SYN请求报文,如下图所示: 

点击查看原图

       这充分说明当故障主机192.168.1.167的4075端口向服务器的6888端口尝试TCP连接请求时,被服务器管理性过滤禁止了。
5,那么服务器为什么会管理性禁止故障主机192.168.1.167的4075端口向服务器的6888端口尝试TCP连接请求报文呢?难道服务器上设有针对源端口为4075的禁止访问策略吗?服务器显然没有做这种针对源端口过滤的必要,另外,我们还发现除了故障主机以源端口4075访问服务器的SYN报文被管理性禁止外,还有其他源端口的SYN请求报文被服务器管理性禁止,如下图所示: 

点击查看原图

       这里被服务器禁止的报文的源端口有4078、4083、4086等。
       另外,通过上图中的“delta time”值,我们也可以发现正是这些报文导致了故障主机在建立新的TCP连接之前花费了数秒的连接建立尝试时间(SYN重传时间,大家可参考本博客《TCP重传》一文),从而导致了页面打开缓慢的现象出现。
6,这个现象具有明显的针对TCP的随机性的过滤特性,因此,我们很容易就可以联想到是否是服务器在TCP传输层存在某些检测过滤机制?而在传输层最为常见的就是TCP连接数限制了。
       一般而言,在服务器上实现针对单IP访问服务器的TCP连接数进行限制是一件简单的事情,一个独立的IP只允许与服务器建立少量的TCP连接,这对于那些对外提供服务的服务器来说是一种较为常见的防护措施,在正常情况下,单个客户端与服务器的正常交互所需要的TCP连接数并不是很多,而限制的数值一般都会高于正常的需求,但是在有些情况(如经过NAT或代理后对业务的访问)下,这将导致问题的产生。
7, 上述推理非常合理,我们通过检查服务器的相关设置,验证了我们的分析和推论结果。
8, 分析结论:
       这个故障是由于业务服务器端设置了针对单IP访问连接数限制功能,而内部办公网主机都是通过防火墙NAT地址转换后对业务服务器进行访问,这直接导致在业务访问高峰时,出口NAT IP地址访问业务服务器的连接数超出限制,业务服务器对后续的TCP连接建立请求发出ICMP差错报文,等一些TCP连接释放后,才允许新建TCP连接,这导致访问业务系统非常缓慢。并且这种特性决定了故障现象表现为间歇性发生。

4 故障解决

       通过修改服务器Apach对单一IP地址的连接数的限制后,故障得到解决。

阅读全文>>

标签: 疑难故障 TCP icmp差错 SYN 连接数 NAT 地址转换 业务慢 连接数限制 ICMP主机管理性禁止差错报文 Type 3 Code 13 type 3 code 10

评论(2) 引用(0) 浏览(7600)

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