文章总结： 文档通过Wireshark分析一个看似MTU问题的网络故障，揭示了中间设备异常行为导致的连环故障。作者通过分析TCP交互序列、ICMP报文及IPID、TTL等字段，发现一台设备伪造服务器ACK响应，另一台设备错误重组数据包并触发虚假分片告警。结论指出该故障非链路MTU限制，而是安全设备逻辑缺陷所致，展现了深度数据包分析的实战价值。 综合评分： 92 文章分类： 网络安全,实战经验,安全工具

Wireshark TS | MTU 问题？似是而非

原创

7ACE 7ACE

Echo Reply

2026年3月2日 08:08 江苏

看不见的尺寸限制

前言

来自于朋友分享的一个案例，乍看一下，可能是 MTU 问题，但真正细想一些细节，还真的不完全是，极其有意思的一个连环组合故障，分享一下。

问题背景

问题简单描述：电信正常，移动不正常，移动大包过不去。

数据包文件：电信和移动各一个数据包。

首先一观电信正常的数据包文件，确实，一切正常。

注，仅是为了截图方便，示图省略了 No.21-76 数据包。

再转向移动不正常的数据包文件，过滤其中一条 TCP 交互流，如下。

如前所述，可能有些经验的一看到 ICMP Destination unreachable（Fragmentation needed），就认为是运营商线路出现了 MTU 问题，大包过不去，造成访问失败。

但实际上就算没有拿到数据包文件，只有上面这一张数据包截图的情况下，所展示出来的信息就不会是简单的 MTU 问题。

问题分析

纯文字分析版

首先解释下上面所说的，只看截图能分析出什么信息，综述如下：

1. No.1-3 数据包，为 TCP 三次握手数据包，其中通告出来的 MSS，最小为 1360；
2. No.4 数据包，为客户端发送的数据段，长度即为 1360；（如果光看 No.7 的 ICMP 消息，可能就会产生误导，让人认为这个 MSS 1360 的数据段因为 PMTU 的限制并没有正常传输到。）
3. No.5 数据包，为客户端发送的另一个数据段，长度仅为 467；
4. No.6 数据包，为服务器端响应的 ACK 数据包，Ack Num 1361，此处说明服务器收到了 Seq 1:1361 的数据；
5. No.7 数据包，为 ICMP 分片信息数据包，指明说有 MTU 问题；（此时客户端收到后，实际上没起到任何作用，紧接向下分析）
6. No.8 数据包，为客户端进行的超时重传，因为没有对 No.3 数据做确认，自然重传的是 Seq 1361:1828 的数据；
7. No.9 数据包，为服务器端所响应的 ACK 数据包，注意注意，Ack Num 1 SLE=1361 SRE=1828，此处与 No.6 数据包产生了矛盾，之前已经 Ack Num 1361，此时又回退到了 Ack Num 1，另加上 SACK 说明收到了 Seq 1361:1828 的数据。（针对 No.8 数据包，但由于 No.9 的异常 ACK Num，实际上客户端直接忽略丢弃了 ）
8. No.10 数据包，为客户端再次进行的超时重传，仍然是 Seq 1361:1828 的数据；
9. No.11 数据包，为服务器端所响应的 ACK 数据包，此时标记了 DSACK 信息，Ack Num 1 SLE=1361 SRE=1828 SLE=1361 SRE=1828，说明服务器收到了重复数据；
10. No.12-13、No.14-15、No.16-17、No.18-19、No.20-21 数据包，之后的均和 No.10-11 数据包类似，客户端和服务器端各说各话，直至最终客户端达到超时重传上限，RST 连接。

实际上逐个分析数据包，基本上大致的方向也就有了，可以再加上一点点假设，看看问题到底在哪。

对于客户端数据包，如果假设 No.6 是真实且正常的，之后的数据包交互，从逻辑上来说会有很多不合理的地方。

a. 如果 No.6 是服务器端所正常响应的 ACK 数据包 Ack Num 1361，那么就不可能出现 No.7 ICMP 数据包，既然最终端服务器都收到了，因 PMTU 限制问题的 ICMP 数据包才后至来到，结合它俩的时间间隔 48ms，说明也不可能是什么短时间的乱序；

b. 如果 No.6 是服务器端所正常响应的 ACK 数据包 Ack Num 1361，那么也就不可能出现 No.9 及之后的 ACK 数据包，因为既然服务器端已经 Ack Num 1361 ，怎么又会回退到 Ack Num 1 。

如果 No.6 是一个虚假的只是看起来正常的呢，客户端的分析综述仍然如上，那么可以假设服务器端的数据包如下：

1. No.1-3 数据包，为 TCP 三次握手数据包，其中通告出来的 MSS，最小为 1360；
2. No.4 数据包，为客户端发送的第一个数据段，Seq 1361:1828 的数据； — 对应客户端数据包文件中的 No.8
3. No.5 数据包，为服务器端所响应的 ACK 数据包，Ack Num 1 SLE=1361 SRE=1828;  — 对应客户端数据包文件中的 No.9
4. No.6 数据包，为客户端再次进行的超时重传，仍然是 Seq 1361:1828 的数据；— 对应客户端数据包文件中的 No.10
5. No.7 数据包，为服务器端所响应的 ACK 数据包，DSACK ，Ack Num 1 SLE=1361 SRE=1828 SLE=1361 SRE=1828，服务器反馈收到了重复数据； — 对应客户端数据包文件中的 No.11
6. 之后按照 No.6-7 类推…

虽然说只是假设，如果在服务器端同时进行数据包捕获的信息如上，但实际对比并细想一下，这不就是真相嘛，No.6 是个什么鬼玩意，从哪乱入来的。

数据包辅助版

眼见不一定为实，有数据包才有真相，为了验证 No.6 到底是什么，只能再打开数据包再好好琢磨琢磨，Seq 及 Ack Num 如下。

再通过多个有效的分析字段展开分析，如 TimeDelta、TTL、ID，你就会发现，No.6 果然就不是个正经数据包。

1. IRTT 约 103ms，但 No.6 数据包，仅仅在 No.4 发出后不到 38ms 就能从服务器端响应返回了，它从哪来的？
2. 服务器 TTL 47，但 No.6 数据包，TTL 为 59，它从哪来的？
3. 客户端 IP ID 0x9f9c，逐步递增，但 No.6 数据包，IP ID 0x9fa0，和客户端一样（抄袭的嘛），它从哪来的？

种种迹象说明了，第一个问题：No.6 为伪造，非服务器产生的数据包，推断是一个安全类的设备，但是啥工作原理呢。

到此问题结束了嘛，还没，回想一下，还有一个 ICMP 分片的消息呢，就算 No.6 是伪造的，但真实发送的数据段，到底到达真实服务器没有。

扩展分析

展开 No.7 ICMP 数据包，详细信息如下：

由 100.1.2.1 这个设备所产生的 ICMP Type Destination unreachable ，Code 4（Fragmentation needed）数据包，携带的几个字段值也挺奇怪，不是嘛。

1. MTU of next hop：1500，正常来说如果下一跳 MTU 偏小，都是小于 1500 的，这里还提示一个正常标准的 MTU 1500，可见对于这个设备 100.1.2.1 收到的数据包，是一个大于 MTU 1500 的不可分片的数据包;
2. 收到了一个多大的数据包呢，在第二层 IP 首部字段 Total Length 1867 说明了这个值为 1867 字节，1867 又是从何而来；
3. 重组后的数据包 IP ID 0x9fa1，这还用的是 No.5 而不是 No.4 数据包的 IP ID，也是奇怪。

对于 1867 字节长度的数据包，首先肯定不会是客户端产生的，在这个环境下高于标准 MTU 1500 也是无法传输的，而它的大小实际正好是 No.4 和 No.5 的合并，TCP Len 1360 + 467 = 1827，再加上 IP 首部 20 + TCP 首部 20，一共 1867 字节。

那么第二个问题：说明 100.1.2.1 这个设备在入口收到 No.4 和 No.5 后进行了重组，由于重组后不能分片的数据包大小 1867 字节，又超过了自己的下一跳 MTU 1500 字节，所以产生了一个 ICMP 需要分片的消息给客户端，妥妥的自己玩死自己，推断可能是一个代理类的设备，但同样的疑问，这又是啥工作原理呢。

问题总结

伪造服务器 ACK 的 A 设备以及无端重组卡自己的 B 设备，连环问题的乱入，数据包的世界总是这么奇奇怪怪。

往期推荐

1. Wireshark 提示和技巧 | 捕获点之 TCP 三次握手

2. Wireshark 提示和技巧 | a == ${a} 显示过滤宏

3. Wireshark TS | 当超时或快速重传遇到零窗口

4. Wireshark TS | 防火墙空闲会话超时问题

5. 网络设备 MTU MSS Jumboframe 全解

后台回复「TT」获取 Wireshark 提示和技巧系列 合集

后台回复「TS」获取 Wireshark Troubleshooting系列 合集

如需交流，可后台直接留言，我会在第一时间回复，谢谢！

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：Echo Reply 7ACE 7ACE《Wireshark TS | MTU 问题？似是而非》