OpenVPN性能低下。我有MTU问题吗？内部转储

13

我遇到无法达到线速度的OpenVPN隧道的问题。网关是OVH托管的Debian Jessy虚拟服务器。客户端是我的freebsd 10.2家庭服务器（Intel I3 Ivy Bridge）或我的RaspberryPI2。我停用了加密和身份验证。我有一个100mbit / s的对称FTTH连接，但隧道的速度仅为20-40mbit / s。直接连接（不使用隧道）总是可以产生100mbit / s的速度。我使用iperf3测试了性能。我首先尝试使用freebsd homeserver。我尝试了有关mssfix，fragment等的所有推荐设置。没有任何帮助。

然后我想也许这是我的freebsd机器。因此，我在RPI2上安装了新的Raspbian Jessy，并进行了更多的深度测试：

首先，我从OpenVPN配置中删除了所有MTU设置，并让路径MTU（希望）进行处理。由于两台计算机上都没有激活防火墙，因此它应该可以工作。这些是我的vpn配置：

server 10.8.0.0 255.255.255.0
port 1194
proto udp
dev tun
sndbuf 0
rcvbuf 0

user nobody
group nogroup
persist-key
persist-tun
ifconfig-pool-persist ipp.txt
keepalive 10 120
push "redirect-gateway def1"
status openvpn-status.log
verb 3

ca /etc/openvpn/easy-rsa/keys/ca.crt
cert /etc/openvpn/easy-rsa/keys/vpn.theissen.io.crt
key /etc/openvpn/easy-rsa/keys/vpn.theissen.io.key
dh /etc/openvpn/easy-rsa/keys/dh4096.pem
tls-auth /etc/openvpn/easy-rsa/keys/ta.key 0
cipher none
auth none
comp-lzo no



client
proto udp
dev tun12
remote xxx.io 1194
resolv-retry infinite
sndbuf 0
rcvbuf 0

nobind
user nobody
group nogroup
persist-key
persist-tun
verb 3

pkcs12 /etc/openvpn/vpn.theissen.io/alex.p12
tls-auth /etc/openvpn/vpn.theissen.io/ta.key 1
ns-cert-type server
cipher none
auth none
comp-lzo no

首先，在没有隧道的情况下进行测试，以表明与服务器的连接确实接近100mbit / s：

iperf3 -c vpn.theissen.io
Connecting to host vpn.theissen.io, port 5201
[  4] local 192.168.1.253 port 34512 connected to 149.202.58.183 port 5201
[ ID] Interval           Transfer     Bandwidth       Retr  Cwnd
[  4]   0.00-1.00   sec  10.8 MBytes  90.5 Mbits/sec    0    335 KBytes       
[  4]   1.00-2.00   sec  11.4 MBytes  95.7 Mbits/sec    0    335 KBytes       
[  4]   2.00-3.00   sec  11.1 MBytes  93.0 Mbits/sec    0    352 KBytes       
[  4]   3.00-4.00   sec  11.2 MBytes  94.0 Mbits/sec    0    369 KBytes       
[  4]   4.00-5.00   sec  11.5 MBytes  95.9 Mbits/sec    0    390 KBytes       
[  4]   5.00-6.00   sec  11.0 MBytes  92.5 Mbits/sec    0    390 KBytes       
[  4]   6.00-7.00   sec  11.4 MBytes  95.2 Mbits/sec    0    390 KBytes       
[  4]   7.00-8.00   sec  11.2 MBytes  94.3 Mbits/sec    0    390 KBytes       
[  4]   8.00-9.00   sec  11.1 MBytes  93.3 Mbits/sec    0    390 KBytes       
[  4]   9.00-10.00  sec  11.3 MBytes  95.1 Mbits/sec    0    390 KBytes       
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth       Retr
[  4]   0.00-10.00  sec   112 MBytes  93.9 Mbits/sec    0             sender
[  4]   0.00-10.00  sec   112 MBytes  93.5 Mbits/sec                  receiver

iperf Done.

我使用tcpdump在服务器上转储了此连接的数据包。您可以在此处下载它们（您必须解压缩才能使用wireshark打开它们）：dumpraw.cap.xz

这就是“ OK”转储的样子。我发现的最大帧大小是1514。 不带隧道的iperf3转储

现在，我在隧道上进行了测试：

iperf3 -c 10.8.0.1
Connecting to host 10.8.0.1, port 5201
[  4] local 10.8.0.14 port 36388 connected to 10.8.0.1 port 5201
[ ID] Interval           Transfer     Bandwidth       Retr  Cwnd
[  4]   0.00-1.00   sec  5.96 MBytes  50.0 Mbits/sec  127    133 KBytes       
[  4]   1.00-2.00   sec  5.19 MBytes  43.5 Mbits/sec    6    120 KBytes       
[  4]   2.00-3.00   sec  5.80 MBytes  48.7 Mbits/sec    0    151 KBytes       
[  4]   3.00-4.00   sec  4.27 MBytes  35.9 Mbits/sec   23   96.5 KBytes       
[  4]   4.00-5.00   sec  4.89 MBytes  41.0 Mbits/sec    0    129 KBytes       
[  4]   5.00-6.00   sec  6.11 MBytes  51.2 Mbits/sec   26    111 KBytes       
[  4]   6.00-7.00   sec  5.50 MBytes  46.1 Mbits/sec    0    143 KBytes       
[  4]   7.00-8.00   sec  5.25 MBytes  44.1 Mbits/sec   15    126 KBytes       
[  4]   8.00-9.00   sec  5.80 MBytes  48.7 Mbits/sec    0    158 KBytes       
[  4]   9.00-10.00  sec  3.97 MBytes  33.3 Mbits/sec   22    105 KBytes       
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth       Retr
[  4]   0.00-10.00  sec  52.7 MBytes  44.2 Mbits/sec  219             sender
[  4]   0.00-10.00  sec  52.3 MBytes  43.8 Mbits/sec                  receiver

iperf Done.

哎呀 不再那么好了。特别是此“ Retr”列看起来不太好。我假设这是tcp重传，然后转储中应该有一些东西。我们会发现并非如此：/。CPU在这里不是瓶颈，因为我取消了加密和身份验证。在测试期间，服务器上的CPU占20％，PI的CPU占50％。

测试的OpenVPN流量如下所示： 物理接口上的OpenVPN流量

对我来说，这看起来还不错。但是我不知道要寻找什么。请通过wireshark看一下转储：dump_physical.cap.xz

隧道接口上的流量对我来说也很好。看来他正确地降低了帧大小（看起来好像是1444）： 隧道接口上的iperf3流量

这是转储文件：dump_tunnel.cap.xz

在我看来，这一切都很好，但我真的不知道要寻找什么。我真的使用OpenVPN设置测试了所有内容。也许有人可以告诉我交通状况是否还好。

我期望的答案

至少可以解释一下这里发生的情况以及为什么它似乎与我使用的VPN软件无关。我在互联网上发现的所有内容都与MTU问题有关，但是应该通过减少隧道MTU或OpenVPN的其他参数轻松解决。对我来说，这变化不大。当您查看转储时，您会看到它减小了tcp段的大小，并且数据包未分段。肯定还有别的东西。我真的想知道什么。

更新资料

我用Strongswan甚至Softether进行了测试。这实际上是相同的问题（可比的速度，没有CPU瓶颈）。我真的很困惑这里是什么问题。我还尝试了另一个网关（朋友100/100家庭连接上的RaspberryPi2）。

更新2

我注意到iperf3报告了tcp重传（retr），但转储中没有重传（Wireshark应该突出显示它们）。到底是怎么回事？

我什至在本地网络（从RaspberryPi2到FreebsdServer）上尝试了OpenVPN。即使在那里，我也有很多转发（在局域网上？！）：

Connecting to host 192.168.222.11, port 5201
[  4] local 192.168.222.10 port 46196 connected to 192.168.222.11 port 5201
[ ID] Interval           Transfer     Bandwidth       Retr  Cwnd
[  4]   0.00-1.00   sec  9.19 MBytes  77.0 Mbits/sec    8    141 KBytes       
[  4]   1.00-2.00   sec  8.71 MBytes  73.1 Mbits/sec    3    130 KBytes       
[  4]   2.00-3.00   sec  8.59 MBytes  72.0 Mbits/sec    3    120 KBytes       
[  4]   3.00-4.00   sec  8.65 MBytes  72.5 Mbits/sec    4    108 KBytes       
[  4]   4.00-5.00   sec  8.65 MBytes  72.5 Mbits/sec    4   95.6 KBytes       
[  4]   5.00-6.00   sec  8.52 MBytes  71.5 Mbits/sec    2   80.5 KBytes       
[  4]   6.00-7.00   sec  8.83 MBytes  74.1 Mbits/sec    0    141 KBytes       
[  4]   7.00-8.00   sec  8.59 MBytes  72.0 Mbits/sec    7    106 KBytes       
[  4]   8.00-9.00   sec  8.71 MBytes  73.1 Mbits/sec    3   94.2 KBytes       
[  4]   9.00-10.00  sec  8.59 MBytes  72.0 Mbits/sec    3   79.2 KBytes       
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth       Retr
[  4]   0.00-10.00  sec  87.0 MBytes  73.0 Mbits/sec   37             sender
[  4]   0.00-10.00  sec  86.8 MBytes  72.8 Mbits/sec                  receiver

在反向模式下，我有一个非常奇怪的拥塞窗口（wtf？）：

Accepted connection from 192.168.222.10, port 46197
[  5] local 192.168.222.11 port 5201 connected to 192.168.222.10 port 46198
[ ID] Interval           Transfer     Bandwidth       Retr  Cwnd
[  5]   0.00-1.00   sec  8.90 MBytes  74.7 Mbits/sec    3   1.48 GBytes       
[  5]   1.00-2.00   sec  8.45 MBytes  70.9 Mbits/sec    2   1.59 GBytes       
[  5]   2.00-3.00   sec  8.66 MBytes  72.7 Mbits/sec  518    214 MBytes       
[  5]   3.00-4.00   sec  7.96 MBytes  66.8 Mbits/sec   37    703 MBytes       
[  5]   4.00-5.00   sec  8.09 MBytes  67.9 Mbits/sec    0    719 MBytes       
[  5]   5.00-6.00   sec  8.04 MBytes  67.5 Mbits/sec    0    734 MBytes       
[  5]   6.00-7.00   sec  8.07 MBytes  67.7 Mbits/sec    1    703 MBytes       
[  5]   7.00-8.00   sec  8.07 MBytes  67.7 Mbits/sec    1    703 MBytes       
[  5]   8.00-9.00   sec  7.99 MBytes  67.1 Mbits/sec    2    693 MBytes       
[  5]   9.00-10.00  sec  8.06 MBytes  67.6 Mbits/sec    1    693 MBytes       
[  5]  10.00-10.09  sec   684 KBytes  64.5 Mbits/sec    0    695 MBytes       
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth       Retr
[  5]   0.00-10.09  sec  83.0 MBytes  69.0 Mbits/sec  565             sender
[  5]   0.00-10.09  sec  0.00 Bytes  0.00 bits/sec                  receiver

更新3

将ipf与udp一起使用会导致ovh临时阻塞该端口（它们向我发送电子邮件通知攻击）和大量数据包丢失：

-----------------------------------------------------------
Server listening on 1194
-----------------------------------------------------------
Accepted connection from 185.22.143.160, port 15906
[  5] local 149.202.58.183 port 1194 connected to 185.22.143.160 port 4355
[ ID] Interval           Transfer     Bandwidth       Jitter    Lost/Total Datagrams
[  5]   0.00-1.00   sec  2.89 MBytes  24.2 Mbits/sec  0.727 ms  1017/1387 (73%)  
iperf3: OUT OF ORDER - incoming packet = 1409 and received packet = 1470 AND SP = 5
iperf3: OUT OF ORDER - incoming packet = 1410 and received packet = 1471 AND SP = 5
iperf3: OUT OF ORDER - incoming packet = 1411 and received packet = 1472 AND SP = 5
iperf3: OUT OF ORDER - incoming packet = 1445 and received packet = 1473 AND SP = 5
iperf3: OUT OF ORDER - incoming packet = 1463 and received packet = 1473 AND SP = 5
[  5]   1.00-2.00   sec  3.29 MBytes  27.6 Mbits/sec  0.716 ms  1110/1526 (73%)  
[  5]   2.00-3.00   sec  3.30 MBytes  27.7 Mbits/sec  0.732 ms  1103/1526 (72%)  
[  5]   3.00-4.00   sec  3.27 MBytes  27.4 Mbits/sec  0.717 ms  1108/1526 (73%)  
[  5]   4.00-5.00   sec  1.56 MBytes  13.1 Mbits/sec  0.837 ms  546/746 (73%)  
[  5]   5.00-6.00   sec  0.00 Bytes  0.00 bits/sec  0.837 ms  0/0 (-nan%)  
[  5]   6.00-7.00   sec  0.00 Bytes  0.00 bits/sec  0.837 ms  0/0 (-nan%)  
[  5]   7.00-8.00   sec  0.00 Bytes  0.00 bits/sec  0.837 ms  0/0 (-nan%)  
[  5]   8.00-9.00   sec  0.00 Bytes  0.00 bits/sec  0.837 ms  0/0 (-nan%)  
[  5]   9.00-10.00  sec  0.00 Bytes  0.00 bits/sec  0.837 ms  0/0 (-nan%)  
[  5]  10.00-10.06  sec  0.00 Bytes  0.00 bits/sec  0.837 ms  0/0 (-nan%)  
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth       Jitter    Lost/Total Datagrams
[  5]   0.00-10.06  sec   118 MBytes  98.5 Mbits/sec  0.837 ms  4884/6711 (73%)  
[SUM]  0.0-10.1 sec  4884 datagrams received out-of-order
vpn  performance  openvpn  mtu 
— 亚历山大·泰森
source
1
如果您尚未尝试，可以尝试一下：（tun-mtu 9000 fragment 0 mssfix 0需要在三个不同的行中添加选项）
— Diamant
我已经证明过了。但是我再次测试。发生的是，它以相同的速度开始，但随后连接停滞。顺便说一句，当我禁用OpenVPN数据包分段时，总是会发生这种情况。该指南community.openvpn.net/openvpn/wiki/Gigabit_Networks使您认为OS应该处理它，但显然不行。
— 亚历山大·泰森，2016年
哇哦 我在我的VPN上看到了完全相同的行为，而且两端都有强大的硬件，并且互联网连接速度较慢。我将进一步调查；如果我发现任何具体内容，我会在此发布。
— 哈拉尔德
1
如果将测试切换为UDP（iperf3 -u -b 25m），则在openvpn隧道内部和外部都将获得全速。我已经确认使用TCP时没有碎片-openvpn正确报告了一个小型MSS，我在隧道内的tcp数据包都是1354字节，并且UDP数据包未碎片化。我看到了与您相同的现象-隧道内的CWND值大约是隧道外的CWND值的一半，吞吐量也只有隧道外的一半，但我无所适从地解释了为什么。迷人。
— 哈拉尔德
1
好吧，我为造成虚假的希望而道歉。为了消除一大堆变量，我在本地局域网上运行了具有相同配置参数的OpenVPN。隧道外，750Mbps。在隧道内部，速度为117Mbps。但是-openvpn在两个端点上都消耗了单个CPU内核的100％。因此，然后我将Internet隧道的起始端点移到了“真实”服务器上，并通过隧道看到了预期的25Mbps。两个端点上的OpenVPN消耗约20％的CPU。长话短说-就我而言，问题是我的家庭隧道端点受CPU限制。抱歉!
— 哈拉尔德

Answers:

2

首先，您的“正常”外部隧道iperf运行应该是UDP / 1194，因为它是您遇到问题的流程，而不是TCP / 5201。首先尝试使用-b 100M，但请记住，这将产生最大大小的数据报，该数据报不代表您的VPN流量（数据报的大小应该是随机的）。使用-l选项调整数据报的大小，然后检查结果。如果结果不好（我会说损失> 15或20％），则您可能会怀疑Internet路由器超载正在丢弃您的（可能标记为尽力而为）数据包。

另外，如果将VPN隧道切换到EF类UDP端口（由于RTP，我会说5061，但不能真正确定所有互联网路由器都已正确配置QoS），则看到的性能也会很有趣。 TCP端口。

对我来说，您的设置没有错，诊断程序也没有显示任何奇怪的地方。另外，请尝试其他版本的OpenVPN或其他VPN软件。

— 30gd4n
source
做过某事。看一下update3。等待ovh解除阻塞端口以进行进一步测试。
— AlexanderTheißen16年
噢，抱歉，没有看到最新的更新。在等待OVH时，尝试通过TCP挂载VPN。结果如何？同样关于您的第二次编辑以及从* BSD到PI的重新传输；您玩过iperf的服务器缓冲区吗？它的默认值为8kb，不知道该堆栈是如何在ARM和Linux上制成的，但我想增加它可能会有所帮助。
— 30gd4n
我的意思是我在你告诉我之后添加它:)。tcp上的结果更糟。TCP 443没什么区别。有趣的是，当我使用此github.com/sivel/speedtest-cli进行测试时，它报告下降了95m，上升了75m。我更信任iperf，但看起来确实取决于流量类型。Playstation4还需要更长的时间才能通过隧道下载游戏或补丁。回到家时，我将直接在两个Rbp之间建立一条隧道，这些Rbp位于不同的位置，但是使用相同的isp。我之前做过，结果几乎一样。但是我尝试做进一步的测试。
— AlexanderTheißen16年
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.