5G CPE 设备距离正确处理 IPv6 Fragment 还有多远
属于CYY自己的世界 (陈泱宇 (Yangyu Chen))背景
过年在外婆家住了几天，因为这里没有装宽带于是带上了 5G CPE ，由于我的大部分工作数据放在家里的服务器上，出于习惯一般喜欢连接 WireGuard VPN 回家。而连接公共 WiFi 时我一般习惯加上默认路由到 VPN ，结果今天回到外婆家里连着 5G CPE 的网忘删除默认路由发现上网非常卡顿，表现为网页打开缓慢，视频网站移动进度条缓慢，而 iperf 测下行带宽却没有发现任何问题，经过一些随机探索，最后发现问题出在了 MTU 上。而经过调查发现，最终的问题在于我的 5G CPE 没有正确处理 IPv6 fragment。
环境介绍
CPE: VN007 (3.12.0)
SIM：AS4134 5G 融合 QCI-6 1000Mbps
地理位置：福建省南平市
WireGuard Peer：福建省厦门市 PPPoE 家庭宽带（AS4134 + AS9808） IPv6
WireGuard MTU: 1408
TCP congestion control: BBR
5G MTU: 1500
一个简单的测试结果
经过对 WireGuard MTU 进行 binary search，最终找到了最大值：1352
TL; DR.
Upload from 5G to Home:
WireGuard MTU 1352 (5G MTU 1432): 41.2 Mbits/sec
WireGuard MTU 1360 (5G MTU 1440): 2.75 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 抓包分析，结果更是震撼了我。
可以看到，我的电脑已经从先前的经验学习到，去往该地址可用的最大 MTU 为 1432 ，于是 WireGuard 已经将 UDP 进行了 Fragment ，去除 14 Bytes Ethernet Frame 后仅发出了 1432 大小的包。
然而，处于同一 /64 下的我的 5G CPE 却依然不断地在向我的电脑发送 ICMPv6 Packet too Big 。许多数据包最终也正确送达了我家里的 WireGuard Server ， 但可能由于软件分片的处理流程复杂导致网络缓慢。
至此，我已经认为是 5G CPE 对 IPv6 Fragment 处理存在问题了，似乎有一种神秘的力量在 CPE 里把这些 Fragmented Packet 又组合了一遍 ，然后向我电脑发出了 Packet too big 的警告，又继续软件进行 Fragmentation 将这些碎片通过 5G 发送到了互联网。
实在是离谱！
iPhone 热点对比
于是我又使用 iPhone 热点进行了测试，这多么正常啊：
由于我的电脑和 WireGuard Peer 处理 Fragment 速度足够快，实测起来也没有明显速度差异。
解决方法
最终将我的所有 Client 性质的 WireGuard VPN 都改为了 MTU 1280，来应对这些倒闭网络设备的错误情况。
结论
我的 5G CPE 没有正确处理 IPv6 Fragment 导致了我连回家的 WireGuard VPN 出现了巨大的性能损失。而该问题在使用 iPhone 开热点时并不存在。
Generated by RSStT. The copyright belongs to the original author.