最近几个月都在折腾 wireguard ，从之前的小盒子，变成了 RouterOS 7 内置，一些经验总结下来，MTU 参数的设置值得一提，写下来供参考:
首先要了解，wireguard 协议增加的开销是 16 字节头加 16 字节尾，一共 32 字节。
如果你的 wireguard 两端都是 IPv4 地址连接，一个包（假设长度为 x Bytes ）到达对方的 wireguard 虚拟网卡之后：
如果我们是直接在两台 LAN 连接的电脑上架设 wireguard ，考虑到以太网卡的 MTU 是 1500, 这时候可以选择的 wireguard MTU 就是
1500 - 32 - 8 - 20 = 1440
如果是通过 PPPoE 上网的，本身 PPPoE 的协议开销会占掉 8 个字节，所以上述数据要再减 8 。
1500 - 32 - 8 - 8 = 1432
如果你中间使用了 IPv6 协议连接两端，因为 v6 的地址长，协议开销变大，这时候在以太网和 PPPoE 下的最大 MTU 分别成了
1500 - 32 - 8 - 40 = 1420
1500 - 8 - 32 - 8 - 40 = 1412
缺省情况下，Linux 的 wg-quick 脚本会按照使用了 IPv6 的最大包络，从系统中各个网卡的 MTU 找到一个最小的，减去 80, 作为缺省 MTU 。这也就是 Linux 上常见到 wireguard 接口的 MTU 是 1420 的缘故。
实质上你用这个在纯 v4 网络上是有一点浪费的，但无所谓了，更保险。
这个时候还应该想到：你在本地是 PPPoE 连接，但是你的海外 VPS 人家可是 LAN 连接，所以会发生你这里 1492-80=1412 人家那里 1500-80=1420 的情况。好在这个-80 是按照 IPv6 最大包罗万象来选的，对于 IPv4 线路而言还有足够的余量，不至于产生影响。
核心是承载 wireguard 流量的 UDP 数据包不能被分包。
但是为了安全起见，还是应该在两端的配置文件里都指定同一个 MTU 数值为好（这种情况下 1412 是一个合理的选择）。
因为 wireguard 是走 UDP 协议的，会受到运营商 QoS 策略的限制，一段时间后断线或者限流，于是出现了一些把 UDP 伪装成 TCP 的办法。这些办法的配置各有不同，但重点是：它们都会添加额外的协议开销字节数，减少了 wireguard 的有效 MTU ，所以在使用了这些手段之后，必须要减少 wireguard 接口 MTU 配置。
对于最常用的两种伪装手段而言，udp2raw 是 44 字节，phantun 是 12 字节。于是，在普通 PPPoE 宽带上使用的 wireguard 接口 MTU 就应该是 udp2raw : 1412 - 44 = 1368 phantun: 1412 - 12 = 1400
最后，更戏剧性的来了，笔者丧心病狂购买了所谓的"国际精品网"，还是 PPPoE 拨号，然而 MTU 却大幅度缩水成了 1442, 被电信内部的网络白白吃掉了 50 个字节（恐怖的是 MTU 小了，MRU 还是 1492 ）。那么可怜的 wireguard MTU 就变成了：
UDP：1442 - 32 - 8 - 40 = 1362
所以，这时候你就需要按照自己的情况，选择合适的 MTU ，保证网络畅通了。
在下有段时间心血来潮，想着既然 VPS 和本地都已经有 IPv6 地址，那么顺序切换 IPv4 和 IPv6 地址来建立 wireguard 连接应该是一个有希望的方案。然而当时没有仔细考虑这个 MTU 设置，设成 IPv6 连接后各种不舒服……
再加上发现精品网只是 IPv4 部分，IPv6 走的路由依旧是普通的 163 线路，延迟巨大，所以彻底打消了这个念头。
但如果你一直是用普通的 163 线路或者其他运营商，那倒是可以一试。163 线路的 PPPoE MTU 还是 1492 呢。
总结一下：
正常普通 PPPoE 宽带：1412 正常普通 PPPoE 宽带套 phantun: 1400
精品网: 1362 精品网套 phantun: 1350 像我一样的洁癖强迫症：1280 + 32 + 32 = 1344 （算是个整数？）
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。