欢迎关注: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) 浏览(36679)

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