如何发现由设备机制引发的应用故障

当业务系统中的设备进行切换后,往往业务故障也随即出现。我们通常认为问题的发生是由新旧设备的策略差异导致的。但在实际情况中,往往问题根因在于某些设备自身的机制造成,设备的切换只是让这些潜在的问题展现出来,并对业务产生负面影响,正如本案例所述。

 

4.1 问题描述

 

某集团防火墙切换后,堡垒机(X.X.15.15)访问数据库时连接时断时续;当建议清除相关IP的防火墙会话表后,出现堡垒机访问延迟较大的异常现象,需要1-3秒内才能建立连接。

针对本次故障,我们对防火墙的outside、inside接口和堡垒机进行抓包分析,如下方拓扑图所示。

图 4-1

 

 

4.2 分析过程

 

4.2.1 堡垒机访问数据库异常现象分析

针对inside接口抓包,只抓到5个会话,如下图所示。

图 4-2

针对outside接口抓包,抓到32个会话。其中只有5个会话是完全建立的(红框部分)且与inside方向抓取的会话一致;其余会话都是由堡垒机(X.X.15.15)发起的新建会话,且新建会话数据包内容是1-3个SYN包。说明数据包是丢弃在防火墙的outside接口,如下图所示。

图 4-3

图 4-4

图 4-5

随后观察到堡垒机(X.X.15.15)以源端口45576新建的会话连接成功,并且有会话双向传输数据。说明并非所有新建会话都会被拒绝,防火墙策略是没有任何问题的,如下图所示。

图 4-6

防火墙无论处于何种状态,都会为正常建立连接的TCP会话构建一张会话表(Conn表),在未收到任何断链数据包(FIN、RST)的情况下,该会话表项(源IP、源端口、目的IP、目的端口)会一直保持到防火墙内,直到达到超时时间才会删除。到达防火墙的数据包如果匹配该表则放行,如果是SYN等包则当做异常流量丢弃。

Cisco防火墙该表项的默认超时时间是36个小时,同时观察到故障期间防火墙上堡垒机到数据库间的会话有4000多个。

结合防火墙原理和数据包分析,可以说明:由于防火墙没有收到断链数据包,Conn表中会话一直保持到超时时间点结束。当堡垒机用这些表项中的源端口发起建连会话时,因防火墙安全机制会被丢弃。由于堡垒机的并发较高,源端口复用过快,因此会频繁出现建连不成功的现象。这也就是为什么在outside口上存在大量455xx的源端口建连却只有45576建连成功的原因。

针对上述情况,科来网络分析工程师建议该集团相关负责人清理防火墙、数据库X.X.15.15和X.X.22.16相关的TCP会话表。在清理结束后,经过1个小时的观察,没有发现连接、建连不成功的现象,如下图所示。

图 4-7

4.2.2 针对堡垒机访问延迟现象分析过程

清除相关IP的防火墙会话表后,所有的连接成功建立时间在3秒左右,同堡垒机所报的日志时间相吻合,如下图所示。

图 4-8

但此时发现新的情况,大量会话在建立时发生异常。以下图会话为例:由堡垒机X.X.15.15端口57098发起TCP连接,发起的SYN包序列号为2763703735,数据库X.X.22.16回应的数据包应为序列号2763703736的SYN+ACK,然而数据库回应的却是PUSH+ACK,并且序列号是3748899045。堡垒机认为此现象是异常情况,所以发送reset包重置。由于连接建立不成功,在1秒钟后,堡垒机重新用该序列号发起连接。此时回应收到的数据包依旧不是SYN+ACK,因此堡垒机重复之前的重置动作。直至第三次,得到正确回应后建连成功,如下图所示。

图 4-9

通过分析发现原因:由于数据库端有堡垒机关于该端口的会话列表,数据库端认为发过去的数据包是原有会话。因此按照原有的会话进行回复,直到堡垒机重置掉此会话后建连才恢复正常。

因此,科来网络分析工程师建议维护人员同时清理相关堡垒机、数据库及防火墙的会话。在维护人员操作后,发现该情况仍存在,说明数据库上相关会话并没有清理掉。在确保堡垒机清除的情况下,通过对查看数据库,发现有大量已持续很长时间的会话。该现象从侧面说明堡垒机和数据库的这种会话回收机制有问题,如下图所示。

图 4-10

 

4.3 分析结论及建议

 

4.3.1 结论

诱因:由于堡垒机的并发较高,端口轮询(堡垒机使用的源端口)过快。在防火墙主备切换时,防火墙上的大量会话没有得到正确释放。当安全机制轮询到会话中的记录的源端口后,该部分源端口新建的连接都被拒绝。

数据库中存在大量的会话记录,并且远多于防火墙记录,说明该应用的会话回收机制存在缺陷。之前应该也存在相关现象,只是不明显,防火墙的切换,仅是在平时的基础上加剧了这种情况,放大问题现象。这也说明为什么切换后只有这个应用有问题,其余应用没有影响。

潜在风险:大量的会话没有得到释放,占用会话资源,这种回收机制会造成数据性能问题。

4.3.2 建议

建议优化应用会话资源回收机制,放开源端口的范围。

建议将调整应用的架构,将APP与DB放入同一个安全区域。

在该区域建立具备数据包回溯功能和路径梳理实时告警功能的系统,通过梳理分析便可以发现潜在问题并解决,从而降低故障发生概率。

 

4.4 价值

 

通过网络回溯分析技术,能够实现对完整的对应用数据进行全方位监控。通过故障表象,深入挖掘关键设备对相关数据处理的过程,深层次的展现出产生问题的根本原因。快速定位产生故障的源头,帮助运维人员节省了大量的排障工作事件,更加有效率的解决各种疑难故障。更好的保证业务系统的稳定运行。

免费测试申请及购买咨询

您的名字 :

您的手机 :

您的邮箱 :

公司名称 :

您的职位 :

公司地址 :

网络规模 :

购买用途 :

补充留言:

验证: