无法访问网站故障案例分析报告 科来

       某单位部分网段无法访问网站故障案例分析报告故障描述故障环境某单位客户端要访问服务器端，会先经过核心交换机，然后由核心交换机传到多业务交换机，多业务交换机与防火墙相连，经过防火墙后再经过加速器和加密机传，通过专网传到服务器。并且在传输的过程中，防火墙是处于透明模式的。具体网络拓扑如下所示：
 

故障现象
客户端是一个X.X.8.0/23网段的地址，无法访问总部的网站，网页打不开，但是ping该网站地址却可以ping通。而且除了该网段的地址外，其它网段地址都可以正常访问。

故障分析
捕包前分析
通过对故障现象的了解知道，客户端可以ping通服务器，所以客户端到服务器这条链路的连通性没有问题。
那么造成该故障的原因很可能就是网络的中间设备造成的，有可能是中间设备没有转发请求的数据包，造成了数据包丢失从而没有成功的建立连接，所以有以下几处可疑的故障点：
 

捕包分析
为了找到故障的具体原因我们通过捕获通信数据包来进行具体的分析，防火墙本身通常都带有捕包功能，而客户端和服务器进行通信必定要经过防火墙，所以在防火墙上开启抓包功能，查看数据包的具体交互过程，通过测试、抓包得到如下的数据包：
 

如上图所示，eth3端口是与内网相连的端口，eth5是与外网相连的端口，通过捕获到的数据包可以发现，eth3收到了X.X.8.57发送的数据包并且防火墙也将该数据包转发到了外网口eth5，所以防火墙转发了数据包！

但是通过上面的数据包分析可以看到，服务器方在返回确认数据包时，服务器的响应端口变成了135，其交互的过程如下所示：
 

异常的访问过程
在正常的交互过程中应该是没有135端口，但是为什么在故障出现的地址段进行访问的时候却出现端口变化的现象？

造成这种故障的原因可能是几个可疑的故障点在数据传输时对数据包进行了一些更改造成的，从上面的数据包可以看出端口变化应该是发生在防火墙前面的设备上。

在防火墙前面的设备有加速器和加密机，从上面的分析可以看出，应该是加密机或者是加速器中有某些设置或者是设备本身有Bug导致出现了这种故障，本来应该是80端口的响应变成了135端口的响应，所以网络连接无法建立，导致正常的访问无法进行！

可以通过对比分析的方法来查找到具体的故障点，在可疑的故障点处进行捕包，通过比较捕获到的数据包，确定到底是哪个中间设备造成的故障。

具体方法如下：
1、先在故障点处部署上抓包工具—科来网络分析系统，见下图：
 

2、如上图，让故障网段做访问测试，并且同时抓取加速器前后交互的数据包。

3、对比分析捕获到的数据包，如果发现服务器响应的数据包在进入加速器时就已经发生了端口改变，那么可以确定造成该故障的原因就不是加速器造成的；如果发现服务器的响应包在进入加速器时端口没有发生改变，但是在出加速器时端口发生改变，那么可以确定造成该故障的原因就是加速器本身造成的。

但是在分析故障的过程中，我们登录到加速器的管理界面对加速器进行管理，发现一旦关闭加速器的加速服务，可以进行正常的访问；一旦打开加速服务，又无法进行正常的访问。至此可以得出造成该故障的原因就是加速器。

分析结论
经过检测发现是由于加速器的原因引起的故障，在加速器中一旦开启加速服务，就无法进行访问，网页打不开！可是关闭加速服务，就可以正常的进行访问。所以是加速器本身或者是策略设置的问题导致出现了该故障。

总结
加速器的作用应该是通过某些策略，对网络中通信的数据进行优化或者存储一些站点信息等，使得访问速度得到一定的提高，可能会对数据包的结构进行一定的更改，所以为了彻底解决该故障，应该找加速器厂家工程师对整个加速器的策略配置、产品性能等做一个全面的排查，以便找到故障原因彻底解决故障。