标签: ip-fragmentation

我们在客户处安装了数十个嵌入式设备，所有这些设备都可以使用我们的 OpenVPN 服务。一般情况下这很好，但我们的一些客户有严重的路径 MTU 问题。我们对客户修复网络的影响是有限的，因此我们需要 OpenVPN 来处理它。简而言之，我的问题是：

我如何在每个客户端的基础上减轻某些客户端的低路径 MTU，即不使用全局设置来适应所有客户端的最坏情况

请注意，我们的最坏情况非常糟糕：路径 MTU 576，丢弃所有碎片，不对自身进行碎片化，不尊重 DF 位。你明白为什么我不想在全球范围内解决这个问题。

该OpenVPN的联机帮助提供了许多MTU的相关选项，最显着的--link-mtu, --tun-mtu, --fragment and --mssfix。但它也说

--link-mtu [...] 除非您知道自己在做什么，否则最好不要设置此参数。

--tun-mtu [...] 最好使用 --fragment 和/或 --mssfix 选项来处理 MTU 大小问题。

于是我开始尝试用--fragment和--mssfix，但很快就意识到，至少前者必须设置不仅客户端，但也服务器端。然后我查看了服务器端每个客户端的配置，--client-config-dir但它说

以下选项在特定于客户端的上下文中是合法的：--push、--push-reset、--iroute、--ifconfig-push 和 --config。

没有提到 MTU 选项！

所以这里是我更具体的问题：

• 为什么究竟是link-mtu和tun-mtu气馁？这些选项有哪些潜在问题？请注意，我对低级 IP 标头处理非常满意。
• 哪些选项link-mtu tun-mtu fragment mssfix必须在服务器端镜像才能工作？
• 哪些选项link-mtu tun-mtu fragment mssfix可以用于client-config-dir？
• 如果所有四个选项都必须在服务器端镜像，并且不能在内部使用client-config-dir：是否有任何替代方案来对抗每个客户端的低路径 MTU？

笔记：

• 我的部分问题在 5 年前就已经在 …

我发现了很多信息表明情况确实如此，但是，我真的在寻找这背后的原因。为什么有必要？有必要吗？

我有两台主机试图相互建立 IPSec 连接。为此，它们必须在 UDP 端口 500 和 4500 上进行通信，因此我在两端的防火墙中打开了它们（如相关部分所示）：

-A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
-A INPUT -m udp -p udp --dport 500 -j ACCEPT
-A INPUT -m udp -p udp --dport 4500 -j ACCEPT
#.....
-A INPUT -j REJECT --reject-with icmp6-port-unreachable

但是，密钥交换永远不会成功。每一方都不断尝试一遍又一遍地重新传输 UDP 数据包，从不听到响应，直到他们最终放弃。

我从tcpdump一端开始，观察到 UDP 数据包被分片，并且在第二个分片进入后返回了一个 ICMP 端口不可达。

此类失败交换的示例（为保护您而进行了消毒）：

04:00:43.311572 IP6 (hlim 51, next-header Fragment (44) payload length: 1240) 2001:db8::be6b:d879 > 2001:db8:f:608::2: frag (0x5efa507c:0|1232) ipsec-nat-t > ipsec-nat-t: NONESP-encap: isakmp 2.0 msgid 00000001 cookie 55fa7f39522011ef->f8259707aad5f995: …