4
如何防止OpenVPN网络上的TCP连接冻结？
在此问题末尾添加了新的详细信息；我有可能正在调查原因。 我在Internet上与少数客户端建立了一个基于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 reached 1: 192.168.100.91 19.846ms reached Resume: pmtu 1500 hops 1 back 64 上面的运行是在VPN上的两个客户端之间：我启动了从192.168.100.90到目的地的跟踪192.168.100.91。配置两个客户端fragment 1200; mssfix;以尝试限制链接上使用的MTU。以上结果似乎表明它tracepath能够检测到两个客户端之间的1500字节的路径MTU。我会假设由于OpenVPN配置中指定的分段设置，它会稍微小一些。我发现结果有些奇怪。 但是，甚至更陌生：如果我的TCP连接处于停止状态（例如，SSH会话的目录列表在中间冻结），则执行tracepath上面显示的命令会使连接再次启动！对于这种情况，我无法找到任何合理的解释，但是我觉得这可能指向最终解决该问题的解决方案。 有人对其他尝试有任何建议吗？ 编辑：我回来了，进一步看了一下，发现只有更多令人困惑的信息： 我将OpenVPN连接设置为1400字节分段，如上所示。然后，我从Internet上连接到VPN，并使用Wireshark查看发生停顿时发送到VPN服务器的UDP数据包。没有一个大于指定的1400字节计数，因此碎片似乎正常运行。 为了验证哪怕一个1400字节的MTU也足够，我使用以下（Linux）命令对VPN服务器执行了ping操作： ping <host> -s 1450 -M …