我遇到了与此处描述的问题完全相同的问题，但我无法向作者请求澄清，因为我是新用户，所以我无法对此发表评论，所以我发布了一个新问题（我尝试在同一个帖子下发布这个作为参考答案，但由于它没有提供答案而被删除了......）。
问：有人对如何排除故障和/或确定该线程中描述的 TCP 问题的根本原因有什么建议吗？就好像远程端不接受 VPN 客户端发送的 ACK 消息。
我的设置与原始问题完全相同：CentOS 服务器（拓扑子网）和两个客户端，一个 CentOS 和一个 Ubuntu14.03。当我从 ubuntu 客户端向 centos 客户端执行“ssh cat abc.txt”时，centos 的 vpn 连接会停止。恢复它的唯一方法是重新启动 openvpn 服务器（在 centos 机器上）和 centos 上的 openvpn 客户端 - 仅重新启动 centos 客户端连接并不能使其运行（它将在大约 1-2 分钟后启动 tun0，但我无法再通过 vpn ping 或 ssh 机器）。我还尝试了在其他线程中找到的所有 MTU 调整建议（tun-mtu 1300 / fragment 1100 / mssfix 等），但它们都不起作用。
更奇怪的是，如果我从 Ubuntu 执行相同的 ssh-cat，使用 CentOS 服务器 vpn 连接互联网到 centos-client 的公共 ip 地址（从而绕过 centos-client<->centos-server vpn 段），一切都会正常工作（永远不会停顿）。
更新 1：我发现了解决这个问题的变通方法，但效果非常差。我把它贴在这里，以防有人提出其他想法/提示。当我在 openvpn 服务器上将详细级别设置为 9（不在客户端，仅在服务器上）时，问题再也不会发生。Verb 9 导致 openvpn 服务器记录大量数据，并占用其运行的 100% CPU。然后，这会限制传输速度并使 scp 成功完成，不会出现停顿；scp 现在以 40-50Kb/秒的速度复制，而之前在达到 100Kb/秒以上后就会停顿。
更新2：我认为这是缓冲问题。传输的文件大小（通过 scp 或 ssh cat）非常重要。如果我 scp700KB 文件（或更小），它总会成功，无论我尝试多少次。如果我尝试处理 800KB 的文件，它总是会在 7xxKb+ 之后失败/停止。
答案1
我见过类似的问题，并且能够通过禁用 TCP 窗口缩放来解决这些问题。
sysctl -w net.ipv4.tcp_window_scaling=0
也许这会为您指明问题所在的正确方向。
答案2
我们通过创建 ssh 隧道消除了 openvpn。基本上，我们的远程主机会建立一个通向我们的 ssh 隧道，如果隧道出现故障，它们会再次启动它。我们不得不使用一些 shell 脚本来使其工作，但一旦运行起来，它多年来一直运行良好。允许我们通过隧道 ssh 返回服务器。