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

某公司业务系统经ISA防火墙访问正常而经硬件防火墙访问慢故障分析解决案例

作者：易隐者 发布于：2013-1-25 10:10 Friday 分类：案例讨论

1 故障环境

      这个故障产生的环境较为简单，我们在不影响故障分析的前提下，简化分析网络环境，其故障发生的拓扑结构大致如下所示：

1.1 网络拓扑

       故障发生的拓扑结构如下所示：
 点击查看原图

1，业务服务器的IP为16.66.252.249/24，网关为16.66.252.254；

2，测试客户端的IP为16.66.180.167/24，网关为16.66.180.1；

3，防火墙与服务器相连的接口地址为16.66.252.254，防火墙与测试客户端相连接口的地址为16.66.180.1；

4，防火墙工作在纯路由模式下；

1.2 业务访问流程

1，业务服务器的业务端口为TCP 211；

2，测试客户端将数据报文经过硬件防火墙转发至业务服务器端，业务系统根据测试客户端的相关请求，返回业务应用数据报文经硬件防火墙转发给测试客户端；

2 故障现象

       经过与用户的交流和现场的测试，确定故障现象主要表现为以下几点：

1，客户端经过ISA访问业务服务器，测试连接速度非常快；

2，将ISA换成天融信硬件防火墙，硬件防火墙工作在纯路由模式下，测试发现客户端连接业务服务器的大概需要消耗20秒左右的延时；

3，用户反馈，测试过使用cisco的ASA和H3C的硬件防火墙，均有不同程度的较大的连接延时；

3 故障分析

3.1 分析过程

3.1.1 确认是否是硬件防火墙产生的延时

       经过ISA防火墙，业务系统连接测试一切正常，速度很快，但是经过硬件防火墙（TOPSEC/CISCO/H3C）之后，就产生了较大的延时，那么看起来似乎是硬件防火墙产生的延时，我们先从这个角度入手，在测试客户端与业务服务器端同时抓包做对比分析，用于确认是否是硬件防火墙产生的转发延时。

1，我们分别在服务器、客户端上安装科来网络分析系统，并开启捕获界面；
2，在测试客户端上做应用连接测试，当测试客户端弹出连接成功窗口后，分别停止客户端与服务器端的捕包界面；
3，我们通过科来网络分析系统的“TCP会话”视图分析客户端上的测试连接建立的TCP会话过程，如下图所示：
点击查看原图 
       客户端的这个数据交互过程充分说明了，在测试连接的过程中，产生了17秒左右的延时。
4，通过科来网络分析系统的“TCP会话”视图分析服务器端的应用连接建立的TCP会话交互情况，如下图所示：
 点击查看原图
       上图清晰的反应了服务器端的应用层响应是在延迟了16.34秒后才发出了；
5，对比分析客户端与服务器端的数据交互过程，我们可以得出以下两点结论：
经过硬件防火墙，应用连接的建立花费了17秒左右的时间；

这个延时不是硬件防火墙产生的，而是业务系统应用产生的。

3.1.2 分析经过ISA防火墙时的业务交互情况

       既然这个延时是业务应用本身产生的，跟硬件防火墙完全无关，那么为什么经过ISA访问的时候，连接测试一切正常呢？

       我们还是在业务服务器上捕获客户端与服务器测试应用连接建立交互的数据报文，分析一下经过ISA访问业务系统时的数据交互情况，如下图所示：
 点击查看原图
其连接正常响应时的数据交互情况大致如下所述：
1，客户端与服务器通过TCP三次握手建立连接；
2，连接建立成功后，客户端立即向服务器端发送了应用层连接请求报文，该报文长度为150字节；
3，服务器在收到这个应用请求之后，在0.006645秒内，响应了客户端的应用层连接请求，这个报文长度为74字节，应用层字段长度为16字节；
4，客户端响应了服务器端的应用层响应报文，向服务器端发送应用层字段长度为16字节的报文确认；

5，应用测试连接成功，客户端主动通过TCP四次握手过程，正常释放TCP连接；

       上述过程清晰的展示了客户端在经过ISA访问服务器时，应用连接建立的时间是非常短的，速度非常快。

3.1.3 分析经过硬件防火墙时的业务交互情况

       在确认了经过ISA防火墙的业务系统网络交互行为之后，我们再来分析一下经过硬件防火墙时，业务系统的网络交互行为是怎么样的。
1，我们首先在服务器端开启科来网络分析系统捕获服务器交互的所有数据报文；
2，在测试客户端上做业务应用连接测试，当测试客户端弹出连接成功窗口后，停止服务器端的捕包界面；
3，我们通过科来网络分析系统的“数据包”视图，查看这个过程中业务服务器的数据交互情况，具体如下图所示：
 点击查看原图
  点击查看原图
       交互过程说明：
服务器端在接收到客户端的应用层请求报文后，没有立即向客户端发送带有应用层数据的连接响应报文，而是先向DNS反向解析客户端地址对应的域名；
由于防火墙无法访问互联网，因此，硬件防火墙返回ICMP目的网络不可达差错报文；
服务器端在尝试4次DNS反向解析失败后，发送NBNS名字解析报文；

NBNS解析成功后，服务器端才向客户端发送应用层连接请求响应数据报文；

 4，通过上图的数据交互情况分析，我们可以得出以下两点结论：

服务器端在收到客户端的应用连接建立请求报文后，没有立即发送应用响应报文，而是首先做反向名字解析，解析不成功，再做NBNS解析；

17秒的延时，就是服务器4次DNS反向解析失败产生的。

3.2 分析结论

       通过上面一系列的分析，我们可以确定，导致该故障产生的核心原因是业务系统程序的处理机制异常导致的。

4 故障解决

       我们知道了经过硬件防火墙访问业务系统变慢的原因是因为业务服务器在接收到客户端的应用请求时，需要针对客户端的IP地址做一个反向名字解析，那么我们可以通过在业务服务器的hosts列表中添加客户端的IP对应的主机名，以此来避开服务器的反向DNS名字解析过程，从而解决了业务系统慢的问题。此方法已经现场测试验证有效。

阅读全文>>

标签: 疑难故障 防火墙 DNS ISA

评论(7) 引用(0) 浏览(11587)

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