防火墙作为重要安全设备普遍部署在网络边界中,为网络与业务的正常运行提供必要的安全保障。然而当防火墙设备出现故障时,即使配置策略正确,也极有可能对正常数据作出非正常操作,阻碍通讯,甚至会影响业务数据传输。
某日凌晨,在单位a与单位b之间的mq业务交互过程中,突然出现会话中断的异常现象。mq业务是系统的关键长连接业务,由于业务所处环境复杂,排查时间紧迫,运维人员经过一系列的排查后,仍不能确定问题原因,于是紧急申请科来应急响应服务。
mq支付系统在本次故障会话的数据流量走向,如下图所示。
图 7-1
因为数据在经过防火墙时,进行了目的ip地址的转换。在交换机2位置,tcp会话为单位b通过随机大端口访问单位a业务系统(2.2.2.2)的1424端口。而在交换机1位置,tcp会话为单位b使用随机大端口访问单位a(3.3.3.3)的1424端口。
科来网络分析工程师从科来业务性能管理系统(upm)中查看该日凌晨时间段的数据,了解到支付系统从单位b到单位a的数据方向有告警提示,如下图所示。
图 7-2
图 7-3
点击告警信息,发现在1点03分30秒时,单位b向单位a方向的mq会话有中断现象,在1点00分20秒时有新建会话的情况。因此下载相应时间区间的通讯数据包,继续深入分析。
图 7-4
在故障时间段,1.1.1.1:50826向3.3.3.3:1424发送了请求报文——载荷长度为1436和69的数据包(如下图位置1标识),然后3.3.3.3:1424回复了ack数据包,表示收到了相关请求报文,紧接着又发送了响应报文——载荷长度为28数据包(如下图位置2标识)。但在3.3.3.3:1424发送响应报文后没有收到对端的ack包,于是进行响应报文的超时重传(如下图位置3标识)。
图 7-5
3.3.3.3:1424在多次重传无回应后发送fin包,断开了本次链接,如下图所示。
图 7-6
在故障时间段1.1.1.1:50826向2.2.2.2:1424发送请求报文——载荷长度为1436和69的数据包(如下图位置1标识)。2.2.2.2:1424回复了ack数据包,表示收到了相关请求报文,随后发送了响应报文——载荷长度为28的数据包(如下图位置2标识)。1.1.1.1:50826没有收到2.2.2.2:1424的响应报文,所以进行请求报文的重传(如下图位置3标识)。
由于本次数据采集点是位于靠近最外侧的ce5810,所以推断下图标识2中的ack包和响应包已经从单位a发出,但是没有被单位b收到。
图 7-7
1.1.1.1:50826向2.2.2.2:1424持续发送数次请求包均未得到响应后,发送了重置包断开连接,如下图所示。
图 7-8
进一步分析,发现在故障发生时间点有一个新的会话:2.2.2.2使用1024端口向1.1.1.1发送响应报文——载荷长度为28,但是1.1.1.1没有响应,如下图所示。
图 7-9
通过对比分析发现新会话中的报文就是1.1.1.1:50826与2.2.2.2:1424会话中没有收到的响应报文。因为2.2.2.2的1024端口属于非合规端口,所以1.1.1.1不会接收他发来的任何一个数据包。对比下列报文的载荷内容,可验证分析结果。
图 7-10
图 7-11
随后在分析3.3.3.3:1424和2.2.2.2:1024分别发送到1.1.1.1:50826的数据包时,发现这些数据包的ip/id是一样的,凭此可以验证这两个会话就是经过防火墙转换后的同一个会话。
图 7-12
图 7-13
观察发现:1.1.1.1:50826与2.2.2.2:1024会话开始的时间为54分29秒,而经过防火墙nat转换的1.1.1.1:50826与2.2.2.2:1424会话在此时间点后没有再做转发,此现象同样印证了导致会话中断异常的原因是防火墙转发出现问题。
图 7-14
单位a与单位b之间的mq业务在交互过程中,由于单位b1.1.1.1:50826没有收到单位a2.2.2.2:1424发出的响应包,从而导致的会话中断。2.2.2.2:1424本该使用原有端口1424进行响应包重传,但是由于nat设备(防火墙)使用新建、非合规端口1024发送响应包,导致1.1.1.1:50826与2.2.2.2:1424会话不能进行正常的通信,mq业务从而出现中断情况。建议与防火墙厂家进行确认,是否存在这类的bug,并进行及时修复。
在本案例中,业务中断故障是突然出现的,而大部分业务故障也都有随机出现的通性。此类问题通常在影响业务前难以被发现,出现故障后又难以复现,这就造成了运维人员要耗费许多精力,并难以从复杂的业务运行环境中定位此类异常现象的原因。科来业务性能管理10bet十博欢迎您的解决方案,能够对业务数据进行实时捕获及长期保存,通过对数据的分析能够快速、准确定位故障原因,帮助用户提升复杂业务系统运维的能力和效率,较低故障排查时间成本。