OpenVPN性能低下。 我有MTU问题吗？ 在里面转储

我没有达到线速的OpenVPN隧道的问题。 网关是在OVH托pipe的Debian Jessy虚拟服务器。 客户端是我的freebsd 10.2 homeserver（Intel I3 Ivy Bridge）或我的RaspberryPI2。 我停用了encryption和authentication。 我有一个100mbit / s的对称FTTH连接，但隧道只能达到20-40mbit / s的速度。 直接连接（无隧道）总是产生我期望的100mbit / s。 我用iperf3testing了性能。 我第一次尝试使用我的freebsd homeserver。 我尝试了所有关于mssfix，fragment等的推荐设置。没有任何帮助。

然后我想也许这是我的freebsd机器。 所以我在RPI2上安装了一个新的rasbian Jessy，并做了一些更深入的testing：

首先，我从OpenVPNconfiguration中删除了所有的MTU设置，并让pathMTU处理事情（希望）。 由于我在两台机器上都没有防火墙，所以它应该可以工作。 这些是我的VPNconfiguration：

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 

首先testing没有隧道显示，连接到服务器的确是差不多100mbit / s：

• 为什么我们会在响应时间突然激增？
• 在ESXi中将磁盘标记为SSD时实际发生了什么？
• 如何最好地调整Windows开发机器？
• 何时将虚拟化服务器迁移到物理？
• 如何解决2个Linux主机之间的延迟

 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。

现在我对隧道进行了testing：

 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不是这里的瓶颈，因为我停用了encryption和authentication。 在testing期间，CPU在服务器上是20％，在PI上是50％。

这就是testing的OpenVPNstream量的样子：

对我来说这看起来不错。 但我不知道该找什么 请看看wireshark的转储： dump_physical.cap.xz

隧道接口上的stream量对我来说也很好。 他似乎正确地降低了框架的大小（看起来像1444）：

这是转储： dump_tunnel.cap.xz

对我来说，这看起来一切正常，但我真的不知道该找什么。 我真的用OpenVPN设置testing了一切。 也许有人可以告诉我，如果交通看起来没问题。

我期望作为答案

至less有一个解释是什么在这里发生，为什么它似乎是独立于我使用的VPN软件。 我在互联网上发现的一切都是关于MTU问题，但是应该通过减less隧道MTU或OpenVPN的其他参数来轻松修复。 对我来说这个变化不大。 当你看到转储时，你会发现它减小了tcp段的大小，并且数据包没有碎片化。 必须有别的东西。 我真的很想知道什么 。

更新

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

更新2

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

我什至试图在我的本地networking（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

在udp中使用iperf会导致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