我的CSNA认证专家文档-某地税网上申报业务系统故障分析报告

作者：易隐者发布于：2012-7-6 9:34 Friday 分类：案例讨论

虽然我个人一直认为证书对于自己的真实水平没有什么意义，但是每想到我搞网络分析这些年，做科来做了这些年，连我带的徒弟10年初都已经拿到CSNA认证专家证书了，自己却没拿个分析专家证书，一时冲动，直接想飞到成都参加科来的培训拿下证书，还好高总让直接发个分析文档，鉴定一下，就通过了，在此感谢科来高总的信任，顺便把我的分析案例在此共享！

故障环境
1 网络拓扑
故障环境大体的网络拓扑如下图所示：

说明：
1，网上申报服务器的地址是192.168.1.1，经过网闸后转换为X.X.16.73；
2，前置机的IP地址为X.X.16.56，征管服务器的IP地址为X.X.16.200。
2 业务访问流程
1，纳税人通过互联网登陆网上申报服务器，提交相关纳税信息；
2，网上申报服务器将这些纳税信息转发给前置机的同时，将相关信息写入征管服务器数据库；
3，网上申报服务器与前置机的数据交互出现问题，那么网上申报服务器会将征管服务器数据库相关的信息锁死。
故障现象
1，网上申报业务系统运行时，每天总有一部分纳税人的申报表单数据无法正常上传，可以通过征管服务器的业务软件看到这些用户的申报数据处于锁状态；
2，在没有网闸的情况下，网上申报服务器与前置机直接通讯，则故障现象消失，网上纳税全部正常。
故障分析
1 前期分析
1，结合故障现象与业务流程，我们可以清晰的发现，问题应该就是出现在网上申报服务器经过网闸的地址转换后与前置机交互的过程。
2，在网上申报服务器不通过网闸的地址转换而是直接与前置机交互的时候，业务应用一切正常，那么，是网闸在做地址转换的时候对某些数据报文做了修改或者是网闸直接丢弃了某些业务报文导致的故障吗？
3，网闸是最为可疑的故障关键点，我们决定在网闸前后部署网络分析系统（在此环境下，可直接在申报服务器上和前置机上分别安装网络分析系统），对网上申报业务数据交互过程分别进行抓包，如下图所示：

抓取数据报文后，可以为下一步的深入分析或对比分析提供原始数据。
2 数据包分析
1，我们通过科来网络分析系统捕获前置机交互的数据包，一段时间后，我们在“TCP会话” 视图中，发现有几个TCP会话持续的时间比一般的TCP会话长很多（这是跟正常情况下的业务会话持续时间做对比发现的，属于对比分析法应用方式的一种），如下图所示：

2，我们双击其中一个TCP会话，打开其详细的数据包视图，以查看其具体交互过程，如下图所示：

在上面的视图，我们发现这些TCP会话中，存在大量的TCP重置报文；而且第一个发送reset报文的是网闸的IP地址。
3，网闸为什么会突然给前置机发送RESET报文呢？我们双击打开这个RESET报文的详细解码视图，如下所示：

我们发现，这个数据报文的源MAC地址并非网闸的MAC，真实的网闸MAC地址是00:40:63:EF:43:DF，而这个数据报文的源MAC地址却是00:21:5E:82:AF:86，难道是网内存在某些设备针对该业务数据进行会话劫持攻击？
4，通过进一步的分析，我们发现，在这个reset报文之前，是前置机发送给网闸地址的确认报文，这个报文的封装的目的MAC地址就是00:21:5E:82:AF:86。如下如所示：

5，前置机为什么会在数据交互的过程中，突然出现了这种状况呢？一般而言，主机是根据其ARP表项来封装要发送的数据报文的目的MAC地址，那么，这里前置机发往网闸数据报文的目的MAC地址出现改变是否是因为前置机的ARP表项内容变化了呢？我们在前置机的DOS窗口下，使用arp –a命令查看异常时的arp表项内容，发现网闸IP对应的MAC地址的确变成了00:21:5E:82:AF:86。

6，能够导致ARP表项更新的只可能是ARP报文，是前置机收到ARP欺骗报文导致了ARP表项的更新吗？由于前面都是针对TCP层面的数据交互来分析的，看不到ARP报文，因此我们决定在科来网络分析系统的“数据包”视图查看交互过程的所有数据报文，如下图所示：

我们发现，在网闸向前置机发送连接请求之后，前置机立即向网络中发送ARP请求，请求网闸IP对应的MAC；在网闸响应了前置机的ARP请求之后，前置机开始与网闸进行TCP三次握手交互；这是，来自MAC地址为00-21-5E-82-AF-86的ARP响应到达了前置机，前置机更新其ARP表项，以后，前置机在收到来自网闸的数据报文之后，都向00-21-5E-82-AF-86地址发送确认报文。
为了便于大家理解，我们将这个交互过程中，网闸、前置机以及未知设备的数据交互情况和状态变化做一个图示，如下：

       通过上面的图示，我们可以清楚的看到，导致该业务故障的原因是网络内有一台设备使用了和网闸一样的IP地址。
       另外，我们分析前置机的状态，可以知道，前置机之所以会在交互的过程中向网络内发送目的IP为网闸的ARP请求报文，是因为前置机ARP表中网闸IP的ARP表项老化了。在前置机ARP表中网闸IP的ARP表项未老化之前，网闸与前置机交互数据时是正常的，而网闸与前置机的业务数据交互间隔时间是随机的（这决定于网上纳税用户登录网上申报服务器提交纳税信息的时间），这就可以解释为什么是部分网上申报业务表单出现异常了。
7，网络内有2台设备使用了同一个IP地址，应该很容易被发现，为什么一直没有被发现呢？其实，这是因为网闸的这个IP只有网上申报业务使用，而那个未知的网络设备设置的这个IP，很可能仅仅是用来管理的，这个设备长期在线，又很少有人管理（至少信息中心的人都不知道该设备的存在），因此不会主动向网络中发送ARP报文，不会影响到网络内其他主机和应用的正常运行。但是，它会响应其他主机对它IP地址的ARP请求。我们可以通过交换机的MAC地址表找到这个设备所在的位置。
3 分析结论
       通过上面的综合的分析，我们得出以下结论：
此次业务故障的原因完全跟网闸无关，是由于内网一台MAC地址为00:21:5E:82:AF:86的设备和网闸映射的地址冲突导致的。

故障解决
问题原因定位之后，我们至少可以通过以下三种方式解决该故障：
1，由于是ARP表更新导致的，我们可以手动绑定网闸的ARP，或者修改注册表，将前置机的ARP表老化时间调大。
2，找出使用了网闸映射IP的设备，修改该设备的IP地址；
3，修改网上申报服务器通过网闸后映射的IP地址。
4，还可以让该业务系统在应用层面设置一个检测模块，当发现有表单提交异常时，等待一段时间，重新向前置机提交表单。
总结
在刚接触到这个故障时，以为是网闸的原因导致的故障，但是通过数据包分析后我们发现是由于网络中有IP地址冲突导致的故障，所以在接触到故障时，不要主观的臆测故障原因，而是要通过分析的手段找到根本的原因，以便提高故障解决的效率。