Wireshark TS | 诡异的光猫网络问题

前言

来自于朋友分享的一个案例，最后定位的原因是光猫问题，而类似这类的设备所产生的网络问题，也曾碰到过两三次，但这一次的数据包现象挺特别，分析思路和过程也有所不同，故记录分享一下。

问题背景

用户所反馈的故障现象就是网页打不开，经过现场工程师的初步排查及整理，反馈如下：

1. 用户使用光猫的 Wifi 访问个别公网域名打不开；
2. 用户使用有线网络访问没有问题；
3. 网络拓扑示意：笔记本终端 -> 光猫 -> 交换机 -> 互联网设备；
4. 其中光猫简单看成是无线路由器，Wifi+DHCP+Nat；
5. 捕获数据包的节点：笔记本终端、光猫出口和互联网出口。

问题分析

笔记本终端

既然是笔记本终端打不开域名的故障现象，那么就可以先从笔记本捕获数据包开始入手。客户端 IP 192.168.0.1 和服务器端 IP 222.1.1.1 在标准的 TCP 三次握手和 TLS 握手完成之后，可见正常传输了一段时间后出现了大量的异常，通过专家信息统计，也可以看到出现了包括疑似虚假重传/重传，以及 Dup ACK 等问题。

直接跳转至异常处，可以看见从数据包 No.101 开始至最后，连续出现了 TCP Spurious Retransmission + TCP Dup ACK 的问题组合。

实际上有经验的工程师单从客户端的捕获文件，就已经可以初步判断出现了什么问题，说明如下：

1. 因为是在客户端 192.168.0.1 本地抓包，所以从服务器端发给客户端的数据分段，如果出现 TCP Spurious Retransmission 标识，说明在之前客户端曾经收到过同样 Seq Num 的数据分段，并响应了 ACK ，所以当再次收到相同 Seq Num 的数据分段时，会标记成 TCP 虚假重传（所表达的意思就是：我收到了，也确认过了，但你还发同样的数据，所以我认为是虚假重传，我不需要）；

2. 由于客户端收到了所谓的重复数据分段，因此也不能默默承受不做些什么，所以每收到一个重复数据分段，它就会响应一个 Dup ACK，其中 ACK Num 91925，表明说已经确认收到了 Seq Num 91925 之前的所有数据分段，希望下一次接收 Seq Num 从 91925 开始的数据分段，所以 No.101-106 6 个 TCP 数据分段对应 No.107-112 6 个 TCP Dup ACK，而再往后一样的重复现象，3 个 TCP 数据分段对应 3 个 TCP Dup ACK；
3. 但为什么服务器端会一直重传报文呢？实际上如果能在服务器端上抓包，就会很明显的发现，在这段异常期间，在服务器端是收不到客户端所发送的 ACK 数据包，既然服务器端正常发送了数据分段，在超时时间内没有收到 ACK 确认，因此就会产生重传。

因此故障的根本原因是客户端的 ACK 无法传输至服务器端，导致服务器端无法正常发送之后的数据，因此反映在客户端应用现象上，就是打不开访问的域名。

一般来说类似的问题可能就这样结束了，因为访问公网域名走的互联网环境，很难有中间网络的权限和排障信息，客户端发了，服务器端没收到，丢在中间网络了，丢在哪，无从得知。但由于现场工程师也同时捕获了本地其他两个节点的数据包文件，光猫出口和互联网出口，因此也就可以继续分析一波。

互联网出口

先看互联网出口数据包文件，客户端 IP 111.1.1.1（互联网设备 SNAT）和服务器端 IP 222.1.1.1，仍是在文件最后出现了一堆异常。

根据数据包所显示的异常现象，结合上述客户端分析，说明如下：

1. No.74 为最后一次看到的从客户端发送给服务器端的 ACK ，其 Seq Num 为 63335；
2. 服务器端实际所发送的数据分段，其 Seq Num 已经到了 91925；
3. No.74 客户端 ACK 正常传输到了服务器端，由于没有包括 SACK 以及 3 个 Dup ACK 的支撑，服务器端一直等到 RTO 超时后，才进行了 No.86 Seq Num 63335 至之后的所有数据分段的超时重传。

该数据包文件的异常现象，说明在本地的互联网出口时就已经没有捕获到客户端发给服务器端的 ACK 数据包，ACK 丢失在内部网络，而不是互联网，因此继续研究下一个捕获节点，光猫出口。

光猫出口

光猫出口数据客户端 IP 10.1.1.1（光猫 SNAT）和服务器端 IP 222.1.1.1，直奔异常处，可以看到数据包现象与在客户端上所捕获的数据包现象基本一致，光猫出口有 ACK，而互联网出口 无 ACK，初步说明 ACK 丢失在光猫至互联网出口中间的网络上。

除了已有的三个数据包文件之外，在没有其他输入信息的情况下，需要继续深入光猫出口数据包文件，找寻下可能的问题原因。

大多数情况下的问题，在数据包上都会或多或少有些迹象。通过观察服务器端发送数据分段的重传现象，会发现是从 Seq Num 63335 开始，说明客户端所响应的 ACK 都没有正常返回至服务器端，因此可以过滤源 IP 为客户端 10.1.1.1 的数据包，如下。

可以看到相关的异常数据包现象，说明如下：

1. 同样是客户端源 IP 10.1.1.1 发送的 ACK，但从 No.79 开始，ACK Len 长度由之前的 68 变为了 122，而 TCP Len 均为 0；
2. 最后一个 Len 为 68 的 ACK 是 No.73，它的 ACK Num 即为 63335，所以之后 Len 为 122 的 ACK 都发生了问题，没有正常到达服务器端；
3. 而从 No.107 开始之后的 ACK 数据包，ACK Num 均为 91925，全部标识为 Dup ACK，说明收到了重复的数据分段，也就是上图中的 No.101 开始的 TCP 虚假重传数据分段。

TCP Len 为 0 的纯 ACK ，为什么整个数据包长度会由 68 变成了 122，通过对比 No.73 和 No.79 两个 ACK 数据包详情发现了问题所在，除了正常 ACK 满足数据帧最小长度 64 字节所填充的 Padding 全 0 数据之外，在 No.79 这个异常 ACK 中又多出现了一段 Trailer 全 0 数据，长度为 54 字节。

因此从 No.79 开始所出现的 Len 为 122 的 ACK 异常数据包，也就是被光猫额外填充了 54 字节的全 0 数据，在到达互联网出口设备的这一段路径上，发生了丢弃。

问题总结

将这个现象反馈至现场后，进一步排查，发现在光猫至互联网出口设备之间，还有一个防火墙设备，通过检查和测试，确认了是防火墙设备的包长度检测功能阻断了这些异常 ACK ，至此找到了导致问题发生的根本原因，诡异的光猫，不是嘛 🙄