在这个问题的末尾添加了新的细节；我可能正在关注原因。
我有一个基于 UDP OpenVPN 的 VPN 设置tap模式（我需要，tap因为我需要 VPN 来传递多播数据包，这在tun网络中似乎是不可能的）与互联网上的少数客户端。我在 VPN 上经常遇到 TCP 连接冻结的情况。也就是说，我将建立一个 TCP 连接（例如一个 SSH 连接，但其他协议也有类似的问题），并且在会话期间的某个时刻，流量似乎将停止通过该 TCP 会话传输。
这似乎与发生大数据传输的点有关，例如我是否ls在 SSH 会话中执行命令，或者我是否cat是一个长日志文件。一些 Google 搜索在 Server Fault上找到了许多类似上一个这样的答案，表明可能的罪魁祸首是 MTU 问题：在高流量期间，VPN 试图发送数据包，这些数据包在两个管道之间的某处被丢弃VPN 端点。上面链接的答案建议使用以下 OpenVPN 配置设置来缓解问题：
fragment 1400
mssfix
这应该将 VPN 上使用的 MTU 限制为 1400 字节，并修复 TCP 最大段大小以防止生成任何大于该值的数据包。这似乎稍微缓解了这个问题，但我仍然经常看到冻结。我尝试了许多大小作为fragment指令的参数：1200、1000、576，所有结果都相似。我想不出两端之间有什么奇怪的网络拓扑结构会引发这样的问题：VPN 服务器运行在直接连接到 Internet的pfSense机器上，而我的客户端也在另一个位置直接连接到 Internet。
另一个奇怪的难题：如果我运行该tracepath实用程序，那么这似乎可以解决问题。示例运行如下所示：
[~]$ tracepath -n 192.168.100.91
1: 192.168.100.90 0.039ms pmtu 1500
1: 192.168.100.91 40.823ms …