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

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

　　3、网上申报服务器的地址是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地址发送确认报文。