我们在一个BGAN卫星链路上运行一个OpenVPN VPN，ping时间约为3秒。 我们在tunconfiguration中使用它，我们在Linux（CentOS）上运行。 这主要是通过链接发送的电子邮件，但只要邮件中包含大量附件，VPN似乎就会停滞不前。
“我可以通过隧道，但任何真正的工作导致它locking，这是一个MTU的问题？ 在OpenVPN常见问题似乎正好描述我的问题，但使用mssfix和fragment似乎并没有太多的改善情况。
我的主要testing是用scp在VPN上复制一个2MB的文件。 它将复制大约192k字节，然后报告一个– 停滞状态。 如果我等了几秒钟，它会再次开始复制，然后在又一个几千字节之后再次失速。
无论是否在OpenVPNconfiguration中设置了fragment或mssfix选项（尽pipe设置fragment 1000似乎减less了停顿但不消除它），都会发生这种拖延。 OpenVPN的mtu-test报告1542作为MTU大小。
我已经在互联网上search了关于如何以及何时使用mssfix和fragment更多build议，但是我只find与FAQ相同的页面，而没有提供关于如何以及何时使用哪些参数的细节。
我的问题是：
mssfix和fragment ？ mssfix和fragment ？ mssfix和fragment是解决scheme， tun-mtu ， link-mtu和mtu-disc参数是什么？ 而且，我一直使用工具iperf来测量带宽。 没有VPN，它不断测量在210Kbits / sec的顺序。
当通过VPN（ $ iperf -c remoteserver -t60 -i5 ）使用iperf时 ，它将以10Kbits / sec开始，然后稳步上升，直到它报告1.2Mbits / sec，然后它会停顿，在那里报告0kb /秒的迭代次数（我认为1.2Mbits / sec可能是因为一些OpenVPN缓冲等）
Iperf是衡量带宽的最好方法吗？
任何有关这种情况的帮助将不胜感激。
1542作为MTU？ 从来没有听说过广域网链接。 通常，MTU是最大有效载荷，IP数据包大小减去IP（20字节）和ICMP（8字节）的报头。 这意味着传统以太网LAN的MTU = 1500。 此外，大多数VPN为数据包封装引入开销。 一个典型的VPN MTU是1400。
在现代networking中，由于入口和出口path可能不同，并且由于自动path重新路由，它们也可能会改变，所以很难总结MTU将在什么时候。 对于这样的networking，在VPN链路两侧的主机（例如576）上设置MTU可能更为有效。
MSS（最大段大小）是MTU减去IP + TCP头（40字节）。 这通常由networking协议进行协商，并且通常不具有与MTU相同的协商问题，除非MTU错误。 （MTU协商通常受阻于ICMP或黑洞路由器）。
我要做的第一件事就是在发送端做一个networking数据包捕获，并按照帧大小对显示进行sorting（可能需要在Wireshark中添加此列）。 你应该确认你没有发送过大的帧，你期望它们是什么。 如果启用大型发送卸载或巨型帧等选项，现代网卡发送超大帧也不是不寻常的。 当这些选项被启用时，我已经看到了30,000多个字节的帧。
出于好奇，你有没有尝试降低networking接口的MTU？ 也许卫星链路严重破坏了碎片。 作为一个反直觉的说明，您可能想要尝试通过TCP进行openvpn更改。 我知道这应该会降低性能，但如果你无法控制沿线的碎片，它可能会帮助你。
当您使用TCP时，增加TCP的窗口大小; 这将有助于“空中数据包的数量”。
已经有一段时间，我不得不玩这个东西，但这里有一个链接谷歌find我。
在我重新阅读你的问题之后，我看到你正在运行BGAN – 我会仔细看看这个 （或者只是谷歌：“BGAN欺骗”）。
至于带宽测量，只要您使用合理的数据包大小，我发现iperf是相当不错的。
我想你可能会在错误的树上吠叫。 任何时候我遇到了错误的MTU问题，stream量在192KB之前就停止了。 我认为它与“飞行中的数据包”窗口中的某些窗口更相关，无论是TCP窗口，还是卫星上行链路本身的一些缓冲区。
绝对做一些长的数据包捕获（VPN的“内部”和“外部”），看看你是否得到所有的ACK