我们有一个（通常）可以正常工作的 OpenVPN 安装。服务器版本是“2.6.3-1+deb12u2”，运行在 Debian 12 Bookworm VM 中。客户端是 OpenVPN 社区 2.6.10+ Windows 10（Linux 客户端数量非常少）。
多年来，它一直有效，事实上，它现在对我和大多数同事都有效。然而，最近有几位同事开始报告他们“在家”时遇到的问题。他们似乎没有在酒店遇到问题。
同事们连接成功，但无法访问 Windows Server 的共享驱动器（嗯，据说在极少数情况下可以工作...），无法通过 VPN 隧道从设备加载 https 页面（http 是可能的！），无法通过 TLS/SSL（IMAP、SMTP）下载或发送邮件，并且某些软件报告与 Microsoft SQL 服务器的连接错误。无法openssl s_client查询任何 TLS/SSL 端点。
此问题仅在使用 UDP（端口 1194）时发生。通过 TCP 443 的解决方法似乎可以解决问题，但并不是真正的解决方案。
我似乎无法在“verb 4”日志中找到相关错误:-(我经常看到的唯一消息是
MULTI：来自客户端的错误源地址 []，数据包被丢弃
据我所知，这应该被忽略。有时只有一个
PID_ERR 重放窗口回溯发生
这可能是网络延迟暂时增加的迹象，因此也是不重要的和不相关的。
客户端和服务器日志中报告的 MTU 参数如下
数据通道 MTU 参数 [ mss_fix:1400 max_frag:0 tun_mtu:1500 tun_max_mtu:1600 headroom:136 payload:1768 tailroom:562 ET:0 ]
默认，我明白了。正如我之前所说，它通常有效。Windowsnetsh interface ipv4 show interfaces显示所有非本地接口（包括 OpenVPN）的 MTU 为 1500，无论是否连接。
我不知道该去哪里寻找更多信息或解决方案。有什么想法吗？
编辑：来自评论：
我有一个同事，我通过 ping ( ping server -f -l size) 测试了 MTU。最大尺寸是 1380，但它与“mssfix 1430”一起工作。1380 和 1430 有何关系？
还有另一位同事。他的成功 ping 大小为 1472，与我的一样。但是，他遇到了 SSL 阻塞问题。我使用“mssfix 1450”解决了该问题。
不幸的是，我绝对不能尝试 tun-mtu，因为看起来它必须在两边都进行更改。如果我暂时能得到一个有效的值，那么它可能不一定总是有效。
而且，在我看来，在我们知道真正的问题是什么之前，使用 tun-mtu 真的没有任何意义。对此有什么建议吗？
发生的情况本质上是路径 MTU 发现被阻止，原因是某些行为不当，例如丢弃 ICMP。
常见的端到端MTU 为 1500B，您永远无法假设更大的值。要通过 VPN 传输 1500B 的数据包，必须对其进行封装，因此最终数据包的大小会大于 1500B，因此必须进行拆分。
路由器将丢弃这样的数据包，并使用 ICMP 包回复，告知发送方进行分段。
这会影响 SSL 的原因可能是 SSL 使用了带有证书的大型数据包。