循序渐进,才好认清迷障。
前言
-
故障现象是业务使用人员使用系统时，偶发的会出现系统打不开现象，不定时发生； -
业务访问路径是从互联网 DMZ 区域至内网区域； -
同一套业务系统在测试环境中使用正常； -
外购业务系统，技术支持人员不给力，无法提供相关有效信息。
由于网络在重点 DMZ 区域部署有 NPM （刚好是客户端所在接入交换机上的镜像节点），所以根据所提供的故障时间点和业务 IP 通讯对回溯了该流量，进入实质分析。
阶段一
λ capinfos test.pcapngFile name: test.pcapngFile type: Wireshark/... - pcapngFile encapsulation: EthernetFile timestamp precision: nanoseconds (9)Packet size limit: file hdr: (not set)Packet size limit: inferred: 70 bytes - 1518 bytes (range)Number of packets: 6463File size: 2174 kBData size: 1906 kBCapture duration: 5990.797626192 secondsFirst packet time: 2022-11-18 16:45:07.192079642Last packet time: 2022-11-18 18:24:57.989705834Data byte rate: 318 bytes/sData bit rate: 2545 bits/sAverage packet size: 294.95 bytesAverage packet rate: 1 packets/sSHA256: e97bbdffd9f98d0805737cb93d6d8255acd045241aa716a8af3966b0ae5ca76fRIPEMD160: 0329186f9145dcf38fac739077219a3d93298b34SHA1: 9a3f06a04163f388b8800889d46fe3db04453c26Strict time order: TrueCapture comment: Sanitized by TraceWrangler v0.6.8 build 949Number of interfaces in file: 1Interface #0 info:Encapsulation = Ethernet (1 - ether)Capture length = 2048Time precision = nanoseconds (9)Time ticks per second = 1000000000Time resolution = 0x09Number of stat entries = 0Number of packets = 6463
1. 关于 TraceWrangler 匿名化软件简介，可以查看之前的文章《Wireshark 提示和技巧 | 如何匿名化数据包》 2. 另外一个比较特别的地方是 Packet size limit: inferred: 70 bytes - 1518 bytes (range) ，通常来说根据 snaplen 做截断，应该是一个统一的数值，也就是所有的数据包捕获长度应该是一样的，而不是一个范围值，这里是 NPM 回溯分析设备所处理设置的原因。
专家信息如下，有部分协议解析的 Error 问题，以及先前分段未被捕获到、ACK 确认了未被捕获到的分段等 Warning 问题，考虑到
ACKed unseen segment 的现象，更多是包没有捕获到，并不是什么问题。
在业务所提供的故障时间节点 16:45 - 16:48，展开了相关数据包详细信息，如下，会很明显的看到客户端 192.168.0.1 间隔很长时间才会发送数据包。
再增加 TCP 流信息列，可以看到是分属不同的 TCP 数据流（此处和业务应用相关，不做深究），单流之间上下数据包的间隔时间就更多了。
沟通当中，业务又反馈了一次打不开异常，遂向后拉长了数据包捕获时间，根据客户端的源地址进行过滤，同时增加了间隔时间从大到小排序，基本全是大时间间隔。但整体观察规律，一些流中的固定时间间隔（如 60s）更像是 GRPC 调用本身的应用逻辑，貌似不是根本问题所在。
因此基于此阶段的信息，给到研发同事的意见是检查客户端 192.168.0.1 ，因为它在故障时点陷入了沉寂，并无任何数据包发出，疑似问题所在。
Connection timed out。
交换机上的抓包确实在15:09:06-15:09:33没有任何数据包，遂坚持之前的结论，检查客户端应用，并要求在故障发生时点在客户端上直接抓包，用来佐证客户端请求是否有发出来。
阶段三
-
可以看到同一条TCP数据流（以ip.id为联系），在发方向0x3590-0x3592与0x3593-0x3594连续数据包的之间，还存在着另外一条TCP数据流0xc05c-0xc063 存在，但是在收方向则仅有 0x3590-0x3594 的数据包，并没有另外一条 TCP 数据流的数据包存在； -
这条 TCP 数据流仅仅是客户端 192.168.0.1 所发送的 PSH/ACK 数据包，因为服务器并没有收到因此无法返回确认 ACK，所以客户端不断重传共 6 次后，FIN 结束了该连接； -
此后前一条 TCP 数据流才开始 0x3593 之后的数据包传输，整整间隔了将近 20s。
大无语事件，难道真的是啪啪打脸了嘛。。网络交换机丢包？这很不科学，既然有客户端与服务器的数据包这种交互，那么在 NPM 同样回溯分析，是否是同样的现象呢。
此时慢慢理清三个阶段的故障现象以及数据包，得出以下结论：
-
阶段一和二的结论，判断是客户端有问题，发送间隔时间长，疑似系统故障时无请求发出，但实际上当时也忽略了一个重要的问题，并没有看到服务器端的任何回包，因为不管是不是客户端有问题，服务器在收到请求的时候至少会有响应； -
阶段三在客户端、上层交换机以及服务器端的抓包现象来看，确实客户端发送且重传了请求，但服务器没有收到，结合一直偶发的故障现象判断，不可能是网络交换机丢包，因为交换机不会很特定的只丢掉某条 TCP 数据流； -
故障发生的同时必定有另一条数据流开始传输，它并不是凭空产生，而是直接以 PSH/ACK 开始，说明该连接在之前是一直存在，那么该数据流会是怎么样一个交互情况呢？！
-
该系统应用是个长连接应用，但应用层面以及 TCP 层面并没有开启保活机制，在该 TCP 连接空闲了一定时间后，达到了防火墙会话最大空闲时间的限制，因此防火墙拆除了该会话，而客户端和服务器仍保持有该连接，没有一个很好的结束机制； -
对应业务反馈，每天故障最开始发生的时间，都是第一次进系统时就会有异常现象，说明是在原有的长连接上继续发送数据包，但由于防火墙无此会话信息，所以丢弃该数据包，服务器因此无法正常收到，而客户端在不断重传尝试失败后，FIN 关闭连接。 -
业务人员退出系统应用再次登录后，又可正常打开（重新建连），但是如果没有任何操作，也就是再次空闲过久，防火墙仍然会删除会话，系统再次使用就又会打不开，所以这就是业务所反馈的系统访问偶发失败问题。
往期推荐
原文始发于微信公众号（Echo Reply）：Wireshark TS | 循序渐进看系统访问偶发失败
免责声明:文章中涉及的程序(方法)可能带有攻击性，仅供安全研究与教学之用，读者将其信息做其他用途，由读者承担全部法律及连带责任，本站不承担任何法律及连带责任；如有问题可邮件联系(建议使用企业邮箱或有效邮箱,避免邮件被拦截，联系方式见首页)，望知悉。
- 左青龙
- 微信扫一扫
-
- 右白虎
- 微信扫一扫
-
评论