网络设备（特指 TP-Link）距离正确处理 IPv6 Fragmentation 还有多远

背景

过年在外婆家住了几天，因为这里没有装宽带于是带上了 5G CPE ，以及随便购买了 TP-Link 7DR3630 路由器（现已退货换其他产品） ，为几天后外婆家安装宽带做好准备。由于我的大部分工作数据放在家里的服务器上，出于习惯一般喜欢连接 WireGuard VPN 回家。而连接公共 WiFi 时我一般习惯加上默认路由到 VPN ，结果今天回到外婆家里连着 5G CPE 的网忘删除默认路由发现上网非常卡顿，表现为网页打开缓慢，视频网站移动进度条缓慢，而 iperf 测下行带宽却没有发现任何问题，经过一些随机探索，最后发现问题出在了 MTU 上。而经过调查发现，最终的问题在于经过的 TP-Link 路由器的 IPv6 桥接模式会把 IPv6 Fragmentation 拼接。

环境介绍

CPE: VN007 (软件版本为最新 3.12.0 )
路由器：TP-Link 7DR3630 （软件版本1.0.13，路由模式，IPv6设置为桥模式）
SIM：AS4134 5G 融合 QCI-6 1000Mbps
CPE连线方式：Ethernet
地理位置：福建省南平市
WireGuard Peer：AS9808 福建省厦门市 PPPoE 家庭宽带 IPv6
WireGuard MTU: 1408
TCP congestion control: BBR
5G MTU: 1500

拓扑图：

Mac+RTL8156<->TP-Link 7DR3630<->VN007

一个简单的测试结果

因为发现问题出现在刚开始连接的速度上，经过反复测试发现判断 iperf -t 3 的速率是否大于 >= 10Mbps 可能存在单调性，经过对 WireGuard MTU 进行 binary search，最终找到了最大值：1352

TL; DR.
Upload from 5G to Home:
WireGuard MTU 1352 (5G MTU 1432): 38.8 Mbits/sec
WireGuard MTU 1360 (5G MTU 1440): 3.45 Mbits/sec

 cyy@Yangyus-MacBook-Pro  ~  sudo ip link set utun13 mtu 1360
Executing: /usr/bin/sudo /sbin/ifconfig utun13 mtu 1360

 cyy@Yangyus-MacBook-Pro  ~  iperf3 -c 10.12.2.248 -t 3
Connecting to host 10.12.2.248, port 5201
[  5] local 10.12.3.66 port 50772 connected to 10.12.2.248 port 5201
[ ID] Interval           Transfer     Bitrate
[  5]   0.00-1.00   sec   128 KBytes  1.05 Mbits/sec
[  5]   1.00-2.00   sec   512 KBytes  4.19 Mbits/sec
[  5]   2.00-3.00   sec   768 KBytes  6.28 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate
[  5]   0.00-3.00   sec  1.38 MBytes  3.84 Mbits/sec                  sender
[  5]   0.00-3.04   sec  1.25 MBytes  3.45 Mbits/sec                  receiver

iperf Done.
 cyy@Yangyus-MacBook-Pro  ~  sudo ip link set utun13 mtu 1352
Executing: /usr/bin/sudo /sbin/ifconfig utun13 mtu 1352

 cyy@Yangyus-MacBook-Pro  ~  iperf3 -c 10.12.2.248 -t 3
Connecting to host 10.12.2.248, port 5201
[  5] local 10.12.3.66 port 50790 connected to 10.12.2.248 port 5201
[ ID] Interval           Transfer     Bitrate
[  5]   0.00-1.01   sec  7.12 MBytes  59.5 Mbits/sec
[  5]   1.01-2.00   sec  4.25 MBytes  35.8 Mbits/sec
[  5]   2.00-3.00   sec  4.00 MBytes  33.6 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate
[  5]   0.00-3.00   sec  15.4 MBytes  43.0 Mbits/sec                  sender
[  5]   0.00-3.22   sec  14.9 MBytes  38.8 Mbits/sec                  receiver

iperf Done.
 cyy@Yangyus-MacBook-Pro  ~ 

继续探索

打开 WireShark 抓包分析 WireGuard MTU 1360 时的通信 ， 结果更是震撼了我。

可以看到，我的电脑已经从先前的经验学习到，去往该地址可用的最大 MTU 为 1432 ，于是 WireGuard 已经将 UDP 进行了 Fragment ，去除 14 Bytes Ethernet Frame 后仅发出了 1432 大小的包。由此看出， CPE 的 5G WWAN 接口的 MTU 应该为 1432 。

然而，处于同一 /64 下的我的 5G CPE 却依然不断地在向我的电脑发送 ICMPv6 Packet too Big 。最终我发现，在 TCP 送出去的数据包约 2s 也没有得到 ACK 后，macOS 会自动将 MSS clamp 到 MTU 1280，这就使得几乎所有首个 Segment 套上 WireGuard 与 IPv6 后超过了 1432 的 TCP 连接增加了 2s 握手延迟，而在几乎所有网站都是 https 的当下， TLS Server Hello 的 Segment 通常符合该特征。这也就解释了 iperf -t 3 看到的速率低下以及网页打开缓慢的原因，必须要等待实在收不到 ACK 了降低 MSS 才能正常通信。

至此，我已经认为是某个设备对 IPv6 Fragmentation 处理存在问题了，似乎有一种神秘的力量在链路上把这些 Fragmented Packet 又组合了一遍 ，然后 CPE 看到这些包超过了 5G 口的实际 MTU 因此拒绝了转发。

实在是离谱！

iPhone 热点对比

于是我又使用 iPhone 热点进行了测试，这多么正常啊：

由于我的电脑和 WireGuard Peer 处理 Fragment 速度足够快， 5G 的带宽相对较低，实测起来相比手动降 MTU 也没有明显速度差异。

离奇的发现

在 twd2 的指点下，我继续进行了一些测试，最后发现，这一现象仅出现在我连着 TP-Link 路由器的时候，而使用 Wi-Fi 直连 CPE 时并不存在，如图所示：

于是我又将电脑 Wi-Fi 关闭，用网线跳过 TP-Link 路由器，直连 CPE 的有线网口，发包一切正常，和我直连 CPE Wi-Fi 的情况相同。至此，我们可以确定，TP-Link 7DR3630 的 IPv6 桥接模式会自动进行分片重组，损坏了 narrow MTU 的上游的 UDP 发送功能。

解决方法

最终将我的所有 Client 性质的 WireGuard VPN 都改为了 MTU 1280，来应对这些倒闭网络设备的错误情况。

结论

TP-Link 7DR3630 路由器居然会错误地将 IPv6 桥接模式下的分片重组，导致任何必须分片的数据包经过这个路由器都发不出去，作为直接影响它导致了我的 WireGuard VPN 里每一条 TCP 连接都得等待 2s 左右内核自动降 TCP MSS 才能正确传递数据。而该问题在使用 iPhone 开热点以及直接使用 VN007 5G CPE 时并不存在。

反思

如今，骨干网 MTU 一般在 1500 以上， MTU 的下降通常只出现在最后一公里的接入中，因此大部分情况我们依赖 TCP MSS Clamp 解决了大多数情况下的 MTU 协商问题。而由于在过去的 IPv4 + NAT 的时代，许多 NAT 路由器对于 UDP Fragmentation 的处理采用了直接 Drop 的方式 （ 想想为什么？因为通常只有一个 Fragmentation 能看到端口，网络设备必须先组包再查 NAT 表，对于硬件 Flow Table 等实现而言，做起来实在困难 ） ，导致了大部分 UDP 应用都 assume 了网络不会为自己过大的 Packet 负责。导致在 NAT 时代习惯了之后， IPv6 时代这样的问题导致现实应用出现性能问题的概率也相当低，如果设备厂商没有足够的验证 coverage 很容易忽视这样的问题。但这样的问题或许也需要得到更多的重视，并研究更多的自动化方法来及时发现和解决。