隧道通了但大包失败
隧道建好、ping 能通，但传输文件或打开网页时卡住，这类现象高度指向 MTU 问题。原因在于 IPsec 封装增加了额外头部与尾部开销，隧道内实际可用的最大报文长度比物理链路小；如果发送端仍按物理链路的 MTU 发送大包，一方面需要分片，另一方面 PMTUD 依赖 ICMP 差错报文回流，而这个报文在不少网络里被过滤，于是大包被静默丢弃。定位手段是用带 DF 标志的 ping 逐档加大包长，找出开始失败的分界点，再据此校正隧道 MTU 或在设备上做 TCP MSS 调整。
基本信息
| 探测方法 | ping 指定包长并打开 DF 标志 |
|---|---|
| 常见分界 | 1400 与 1472 附近出现明显分界 |
| PMTUD 依赖 | ICMP 需分片差错报文能回流 |
| 对策一 | 调整隧道接口 MTU |
| 对策二 | 在设备上做 TCP MSS 钳制 |
| 注意 | MSS 只对 TCP 会话有效 |
典型使用场景
- 隧道内网页打开缓慢或大文件传输中断
- 新建隧道验收：验证不同包长的可达性
- 跨运营商链路间歇性大包失败
- 调整隧道封装后复核 MTU 与 MSS 配置
- 排障时区分是 MTU 问题还是真实丢包
分档探测与校正
分档探测与校正
# 逐档探测，找到开始失败的分界
ping 10.2.2.1 size 1400 df-bit
ping 10.2.2.1 size 1470 df-bit
# Linux 侧等效做法
ping -M do -c 3 -s 1372 10.2.2.1
# 定位路径 MTU（部分系统支持）
traceroute --mtu 10.2.2.1
# 校正隧道 MTU 与 MSS
interface Tunnel100
ip mtu 1400
ip tcp adjust-mss 1360探测结果判读
| 结果 | 含义 | 处置 |
|---|---|---|
| 全部通过 | 当前路径 MTU 足够 | 继续加大档位确认上限 |
| 某档起失败 | 该档超过路径可用 MTU | 按失败档位设置隧道 MTU |
| 小包偶发失败 | 可能存在真实丢包 | 按丢包定位流程排查 |
| 仅业务大包失败 | 应用侧报文较大 | 调整该链路的 MSS 或应用设置 |
隧道模式下 IPsec 会额外占用外层 IP 头与 ESP 头尾空间，计算隧道 MTU 时必须把这些开销扣掉，否则仍会在特定包长上失败。
调整 MSS 的做法只影响 TCP，UDP 大包仍需从 MTU 层面解决；业务既有 TCP 又有 UDP 时两种手段要一起评估。