如何解决部分用户无法访问应用问题
当应用出现不能访问时，我们通常会怀疑是某个网络设备或端点设备的问题，然而本案例的分析过程告诉我们，经验往往是不准确的。
14.1 问题描述
某单位的网上申报业务系统运行时，每天总有一部分用户的申报表单数据无法正常上传，通过征管服务器的业务软件看到这些用户的申报数据处于锁死状态；而在没有网闸的情况下，网上申报服务器与前置机直接通讯，故障现象消失，业务运行全部正常。
故障环境的网络拓扑如下图所示。
图 14-1
用户通过登录网上申报服务器，提交相关申报信息。网上申报服务器将这些申报信息转发给前置机，并将相关信息写入征管服务器的数据库。如果网上申报服务器与前置机的数据交互出现问题，那么网上申报服务器就会将征管服务器相关的数据库信息锁死。
说明：
- 网上申报服务器的地址是X.1.1，经过网闸后转换为X.X.16.73
- 前置机的IP地址为X.16.56，征管服务器的IP地址为X.X.16.200
14.2 分析过程
14.2.1 前期分析
结合故障现象与业务流程，我们可以清晰的发现，问题出现在网上申报服务器经过网闸的地址转换后与前置机交互的过程。在网上申报服务器不通过网闸的地址转换而是直接与前置机交互的时候，业务应用一切正常，那么，是网闸在做地址转换的时候对某些数据报文做了修改或者是网闸直接丢弃了某些业务报文导致的故障吗？
网闸是最为可疑的故障关键点，我们决定在网闸前后部署科来网络回溯分析系统（在此环境下，可直接在申报服务器上和前置机上分别安装网络分析系统），对该业务数据交互过程分别进行抓包，为下一步的深入分析或对比分析提供原始数据，如下图所示。
图 14-2
14.2.2 对数据包进行分析
我们通过科来网络回溯分析系统捕获前置机交互的数据包，在TCP会话视图中，可以发现有几个TCP会话持续的时间比一般的TCP会话长很多（这是跟正常情况下的业务会话持续时间做对比发现的，属于对比分析法应用方式的一种），如下图所示。
图 14-3
上图中标注的TCP会话持续时间远超出其他会话，查看其中一个TCP会话，打开其详细的数据包视图，以查看其具体交互过程，如下图所示。
图 14-4
我们发现这些TCP会话中，存在大量的TCP重置报文；而且第一个发送reset报文的是网闸的IP地址。网闸为什么会突然给前置机发送RESET报文呢？我们双击打开这个RESET报文的详细解码视图，如下所示。
图 14-5
这个数据报文的源MAC地址并非网闸的MAC，真实的网闸MAC地址是00:40:63:EF:43:DF，而这个数据报文的源MAC地址却是00:21:5E:82:AF:86，难道是网内存在某些设备针对该业务数据进行会话劫持攻击？
通过进一步的分析，发现reset之前的报文，是前置机发送给网闸地址的确认报文，这个报文封装的目的MAC地址就是00:21:5E:82:AF:86，如下图所示。
图 14-6
前置机为什么会在数据交互的过程中，突然出现了这种状况呢？一般而言，主机是根据其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报文，因此我们决定在科来网络分析系统的“数据包”视图查看交互过程的所有数据报文，如下图所示。
图 14-7
图 14-8
我们发现，在网闸向前置机发送连接请求后，前置机立即向网络中发送ARP请求，请求网闸IP对应的MAC；在网闸响应了前置机的ARP请求之后，前置机开始与网闸进行TCP三次握手交互；这时来自MAC地址为00-21-5E-82-AF-86的ARP响应到达了前置机，前置机更新其ARP表项，之后前置机每次收到来自网闸的数据报文，都会向00-21-5E-82-AF-86地址发送确认报文。
为了便于大家理解，我们将这个交互过程中，网闸、前置机以及未知设备的数据交互情况和状态变化做一个图示，如下图所示。
图 14-9
通过上面的图示，我们可以清楚的看到：导致该业务故障的原因是网络内有一台设备使用了和网闸一样的IP地址。
另外，我们分析前置机的状态可以知道：前置机之所以会在交互的过程中向网络内发送目的IP为网闸的ARP请求报文，是因为前置机ARP表中网闸IP的ARP表项老化了。在该表项未老化之前，网闸与前置机的交互数据是正常的，而网闸与前置机的业务数据交互间隔时间是随机的（这决定于用户登录网上申报服务器提交申报信息的时间），因此可以解释为什么是部分网上申报业务表单出现异常。
应该很容易发现网络中有2台设备使用了同一个IP地址，但为什么一直没有被发现呢？这是因为网闸的IP只有网上申报业务使用，而那个未知的设备由于长期在线，又很少有人管理，因此不会主动向网络发送ARP报文，也不会影响网络内其他主机和应用的正常运行。但由于它会响应其他主机对它IP地址的ARP请求，所以导致本例故障发生。该设备的所在位置可以通过交换机的MAC地址表找到。
14.3 分析结论及建议
通过上面的综合的分析，我们得出以下结论：
此次业务故障的原因完全跟网闸无关，是由于内网一台MAC地址为00:21:5E:82:AF:86的设备和网闸映射的地址冲突导致的。
定位问题原因之后，我们可以通过以下三种方式解决该故障：
- 由于故障是由ARP表更新导致的，我们可以手动绑定网闸的ARP，或者修改注册表，将前置机的ARP表老化时间调大。
- 找出使用了网闸映射IP的设备并修改设备的IP地址，或者修改网上申报服务器通过网闸后映射的IP地址。
- 在该业务系统的应用层面设置检测模块，当发现有表单提交异常时，等待一段时间，重新向前置机提交表单。
14.4 价值
用户在分析此故障时，根据经验判断可能是网闸的原因导致应用异常，但通过网络分析技术进行深入分析，发现是由于网络中存在IP地址冲突导致的故障。
仅仅通过经验判断网络故障存在一定的局限性，而网络分析技术能够为用户提供数据包级的深入分析能力，做到有理有据的准确定位。