某部队部分网段访问总部网站故障分析案例

作者：易隐者发布于：2012-4-25 22:00 Wednesday 分类：案例讨论

n 故障环境

产生故障的网络拓扑如下所示：

其数据访问流程如下：

客户端经过核心交换机转发，再经过防火墙的访问控制，然后经过加速器的加速处理和加密机的加解密后，再通过专网访问服务器。

n 故障现象

网段为X.X.8.0/23的机器全部无法访问总部的网站，网页打不开，但是ping该网站地址却可以ping通。而且除了该网段的地址外，其它网段地址的机器都可以正常访问。

n 故障分析

1 前期分析

通过对故障环境和现象的了解，以及现场的故障现场还原和测试，我们至少可以分析得出以下结论：

1，出问题的网段主机可以ping通服务器，所以客户端到服务器端的网络层连通性没有问题。

2，这是一个部分系统的访问故障，只有固定网段的机器存在问题，这说明很有可能是中间系统针对这个网段的主机的策略设置存在问题。但通过现场检查相关中间设备的策略设置，并未发现明显的异常。

2 深入分析

那么到底是什么原因导致了故障的出现呢？我们希望通过网络分析的方式发现问题的所在，首先，我们在故障环境中确定防火墙、加速器和加密机等三处可能的故障点，如下图所示：

接下来，我们需要在各个可能的故障点前后同时抓包，做对比分析，从而找出导致此故障的真正原因以及设备的位置。

2.1防火墙前后数据报对比分析

我们利用防火墙本身自带的tcpdump捕包功能（关于tcpdump的使用以及如何读懂tcpdump抓取的数据包，请参考《附录》中《常见系统和网关设备自带抓包功能介绍及操作指南》一文），在防火墙的进出口分别同时抓取客户端访问服务器时交互的数据报文。下面为故障时防火墙上进出口的交互报文，其中eth6为防火墙内口，eth5为防火墙外口。

08:08:06.978401 R@eth6 IP X.X.8.57.1544 > X.X.1.2.80: S 2987452938:2987452938(0) win 65535 <mss 1460,nop,wscale 0,nop,nop,timestamp[|tcp]>

//防火墙内口收到客户端X.X.8.57访问服务器X.X.1.2的syn请求报文

08:08:06.978429 X@eth5 IP X.X.8.57.1544 > X.X.1.2.80: S 2987452938:2987452938(0) win 65535 <mss 1460,nop,wscale 0,nop,nop,timestamp[|tcp]>

//防火墙外口转发客户端X.X.8.57访问服务器X.X.1.2的syn请求报文

08:08:09.990289 R@eth6 IP X.X.8.57.1544 > X.X.1.2.80: S 2987452938:2987452938(0) win 65535 <mss 1460,nop,wscale 0,nop,nop,timestamp[|tcp]>

//3秒后，防火墙内口收到客户端X.X.8.57访问服务器X.X.1.2的syn请求重传报文

08:08:09.990304 X@eth5 IP X.X.8.57.1544 > X.X.1.2.80: S 2987452938:2987452938(0) win 65535 <mss 1460,nop,wscale 0,nop,nop,timestamp[|tcp]>

//防火墙外口转发客户端X.X.8.57访问服务器X.X.1.2的syn请求重传报文

08:08:09.991309 R@eth5 IP X.X.1.2.135 > X.X.8.57.1544: S 1710209763:1710209763(0) ack 2987452939 win 5840 <mss 1460,nop,nop,sackOK,nop,wscale 7>

//防火墙外口收到来自服务器X.X.1.2的135端口对客户端syn请求报文的确认

08:08:10.393662 R@eth6 IP X.X.8.57.1543 > 11.104.21.150.80: S 3589718127:3589718127(0) win 65535 <mss 1460,nop,wscale 0,nop,nop,timestamp[|tcp]>

//防火墙内口再次收到客户端X.X.8.57访问服务器X.X.1.2的syn请求重传报文

08:08:10.393674 X@eth5 IP X.X.8.57.1543 > 11.104.21.150.80: S 3589718127:3589718127(0) win 65535 <mss 1460,nop,wscale 0,nop,nop,timestamp[|tcp]>

08:08:10.395085 R@eth5 IP 11.104.21.150.135 > X.X.8.57.1543: S 1707496278:1707496278(0) ack 3589718128 win 5840 <mss 1460,nop,nop,sackOK,nop,wscale 7>

通过上面的分析，我们可以发现：

1，客户端访问服务器TCP 80端口的第一个SYN请求报文被防火墙转发之后，服务器没有响应；

2，客户端重传的SYN请求报文被防火墙转发后，服务器却以TCP 135的源端口响应客户端的SYN请求报文！！！可想而知，该报文在经过防火墙时，并不符合防火墙的安全检测策略，被防火墙丢弃了，因此并未转发给客户端。

3，后续的数据报文基本上都是上面描述的重复，从而导致客户端访问服务器的TCP 80服务出现异常。

下面为客户端与服务器交互报文在防火墙内外口的示意图：

至此，我们定位出了故障产生的原因，但是为什么会出现端口变化的情况？是什么设备导致了服务器回包源端口的变化？我们需要进一步的对比分析。

2.2加速器前后数据报对比分析

我们再在防火墙前端的网络加速器的内口和外口同时捕获故障时客户端与服务器交互的数据报文，并做对比分析，以确定是否是加速器更改了服务器回包的源端口。具体过程如下：

1，先在加速器内口、外口同时抓取故障时客户端与服务器交互的数据报，如下图所示：

2，通过对比分析法，分析加速器内口、外口的数据报文差异，我们发现服务器响应的数据包在进入加速器外口时，其源端口还是TCP 80，但是在出加速器内口时，源端口由TCP 80变为TCP135了（此处数据报由于现场原因未能保存。因此不再分析数据报的详细交互过程了）。至此，我们可以确定造成该故障的原因就是加速器本身造成的。

2.3 故障验证

我们登录到加速器的管理界面对加速器进行管理，发现一旦关闭加速器的加速服务，则故障现象消失；一旦打开加速服务，故障现象再次出现。至此可以完全验证造成该故障的原因就出在网络加速器。

2.4 分析结论

1，该故障为服务器回包端口被加速器更改，从而导致故障网段访问服务器异常。

2，由于在加速器上并未设置针对故障网段的特殊策略，因此，服务器回包源端口改变应该是由加速器本身在特殊环境下的bug导致的。

n 故障解决

由于该故障是中间设备BUG导致的，因此，解决的方式就是先临时暂停加速器的加速功能，保障故障现象消失，再联系厂家技术人员，升级相应的版本和补丁，彻底解决故障根源。

标签: 报文更改 tcpdump 故障