基于科来网络分析技术定位税务系统网上申报业务故障

案例背景

业务访问流程

• 纳税人通过互联网登陆网上申报服务器，提交相关纳税信息；
• 网上申报服务器将这些纳税信息转发给前置机的同时，将相关信息写入征管服务器数据库；
• 网上申报服务器与前置机的数据交互出现问题，那么网上申报服务器会将征管服务器数据库相关的信息锁死。

故障现象

• 网上申报业务系统运行时，每天总有一部分纳税人的申报表单数据无法正常上传，通过征管服务器的业务软件可发现这些用户的申报数据处于锁状态；
• 在没有网闸的情况下，网上申报服务器与前置机直接通讯，则故障现象消失，网上纳税全部正常。

网上申报服务器的地址是192.168.1.1，经过网闸后转换为X.X.16.73，前置机的IP地址为X.X.16.56，征管服务器的IP地址为X.X.16.200。网络拓扑图如下：

案例分析

结合故障现象与业务流程，我们可以清晰的发现，问题应该出现在网上申报服务器经过网闸的地址转换后与前置机交互的过程中。网闸是最为可疑的故障关键点，遂在网闸前后部署网络分析系统（在此环境下，可直接在申报服务器上和前置机上分别安装网络分析系统），对网上申报业务数据交互过程分别进行抓包。

通过科来网络分析系统捕获前置机交互的数据包，一段时间后，我们在“TCP会话” 视图中，发现某些TCP会话持续时间比一般TCP会话长很多（这是跟正常情况下的业务会话持续时间对比发现，属于对比分析法应用方式的一种）。打开其中一个TCP会话，查看其详细的数据包视图，以了解其具体交互过程。

网闸地址73首先发送reset报文，后网闸地址向前置机发送（重传）报文，前置机直接发送reset报文重置连接。这个过程，导致该TCP会话持续时间很长。我们还发现这些TCP会话中，存在大量的TCP重置报文，且第一个发送reset报文的是网闸的IP地址。

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

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

Internet Address        Physical Address         Type

    X.X.16.73            00-21-5E-82-AF-86     dynamic

能够导致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表项未老化之前，网闸与前置机交互数据时是正常的，而网闸与前置机的业务数据交互间隔时间是随机的（这决定于网上纳税用户登录网上申报服务器提交纳税信息的时间），这就可以解释为什么是部分网上申报业务表单出现异常。

网络内有2台设备使用了同一个IP地址，应该很容易被发现，为什么一直没有被发现呢？其实，这是因为网闸的这个IP只有网上申报业务使用，而那个未知的网络设备设置的这个IP，很可能仅仅是用来管理的，这个设备长期在线，又很少有人管理（至少信息中心的人都不知道该设备的存在），因此不会主动向网络中发送ARP报文，不会影响到网络内其他主机和应用的正常运行。但是，它会响应其他主机对它IP地址的ARP请求。我们可以通过交换机的MAC地址表找到这个设备所在的位置。

分析结论及解决方法

ü  此次业务故障的原因完全跟网闸无关，是由于内网一台MAC地址为00:21:5E:82:AF:86的设备和网闸映射的地址冲突导致的。

ü  问题原因定位之后，我们至少可以通过以下三种方式解决该故障：

1、 由于是ARP表更新导致的，我们可以手动绑定网闸的ARP，或者修改注册表，将前置机的ARP表老化时间调大。

2、 找出使用了网闸映射IP的设备，修改该设备的IP地址；修改网上申报服务器通过网闸后映射的IP地址。

3、 还可以让该业务系统在应用层面设置一个检测模块，当发现有表单提交异常时，等待一段时间，重新向前置机提交表单。

总结：在刚接触到这个故障时，以为是网闸的原因导致的故障，但是通过数据包分析后我们发现是由于网络中有IP地址冲突导致的故障，所以在接触到故障时，不要主观臆测故障原因，而是要通过分析的手段找到根本的原因，以便提高故障解决的效率。