回線速度に達しないOpenVPNトンネルに問題があります。ゲートウェイは、OVHでホストされるDebian Jessy仮想サーバーです。クライアントは、freebsd 10.2ホームサーバー（Intel I3 Ivy Bridge）またはRaspberryPI2です。暗号化と認証を無効にしました。100mbit / sの対称FTTH接続がありますが、トンネルの速度は20〜40mbit / sにしか達しません。直接接続（トンネルなし）では、常に100mbit / sが期待されます。iperf3でパフォーマンスをテストしました。私は最初にfreebsdホームサーバーで試しました。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
まず、トンネルなしのテストでは、サーバーへの接続が実際にほぼ100 Mbpsであることを示しています。
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 -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で50％です。
テストのOpenVPNトラフィックは次のようになります。
私にはこれは大丈夫に見えます。しかし、私は何を探すべきかわかりません。wiresharkでダンプを見てください：dump_physical.cap.xz
トンネルインターフェイスのトラフィックも見た目が良いです。彼はフレームサイズを（見たところ1444に）正しく下げたようです：
ダンプは次のとおりです。dump_tunnel.cap.xz
私にはこれはすべて正常に見えますが、正確に何を探すべきか本当に分かりません。OpenVPNの設定ですべてを実際にテストしました。交通量が問題ないかどうかを誰かが教えてくれるかもしれません。
答えとして期待すること
少なくとも、ここで何が起こっているのか、なぜ私が使用しているVPNソフトウェアから独立しているように見えるのかの説明。インターネットで見つけたものはすべてMTUの問題に関するものでしたが、これはトンネルMTUまたはOpenVPNの他のパラメーターを減らすことで簡単に修正できるはずです。私にとってこれはほとんど変わりません。ダンプを見ると、tcpセグメントサイズが減少し、パケットが断片化されていないことがわかります。他に何かあるに違いない。何を知りたいの。
更新
これをstrongswanで、さらにはソフトエーテルでもテストしました。実際には同じ問題です（同等の速度、CPUのボトルネックなし）。ここで何が問題なのか本当に困惑しています。また、別のゲートウェイ（友人の100/100ホーム接続でのRaspberryPi2）も試しました。
更新2
iperf3はtcpの再送信（retr）を報告しますが、ダンプには再送信がないことに気付きました（Wiresharkはそれらを強調表示する必要があります）。何が起こっている？
ローカルネットワーク（RaspberryPi2からFreebsdServerへ）でOpenVPNを試しました。でも、私はたくさんの再送信をしています（LANで！？）：
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
iperfを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
私はすでにそれをテストしています。しかし、私は再びテストしました。何が起こったのかは、同じ速度で始まりますが、接続が停止することです。ところで、OpenVPNパケットフラグメンテーションを無効にすると、常に発生します。このガイドcommunity.openvpn.net/openvpn/wiki/Gigabit_Networksでは、OSで処理する必要があると思われますが、明らかにそうではありません。
—
アレクサンダー・タイセン
ああすごい。私のVPNでもまったく同じ動作が見られ、両端にハードなハードウェアがあり、インターネット接続が遅くなっています。さらに調査します。具体的なものが見つかったら、ここに投稿します。
—
ハラルド
テストをUDP（iperf3 -u -b 25m）に切り替えると、openvpnトンネルの内外で最高速度が得られます。TCPの使用時にフラグメンテーションがないことを確認しました。openvpnは小さなMSSを正しく報告し、トンネル内のTCPパケットはすべて1354バイトであり、UDPパケットはフラグメント化されずに到着します。私はあなたと同じ現象を見ています-トンネル内のCWND値はトンネル外の約半分であり、スループットも半分ですが、理由を説明するのに途方に暮れています。魅力的です。
—
ハラルド
さて、虚偽の希望を作成するための私の謝罪。たくさんの変数を排除しようとして、同じ設定パラメーターでOpenVPNをセットアップし、ローカルLANで実行します。トンネルの外側、750Mbps。トンネル内、117Mbps。しかし-openvpnは、両方のエンドポイントで単一のCPUコアを100％消費していました。そのため、インターネットトンネルのホームエンドポイントを「実際の」サーバーに移動し、トンネルを通過する25 Mbpsを予想しました。両方のエンドポイントのOpenVPNは、約20％のCPUを消費していました。簡単に言えば-私の場合、問題はホーム側のトンネルエンドポイントがCPUにバインドされていることです。ごめんなさい！
—
ハラルド
tun-mtu 9000fragment 0mssfix 0（オプションは、3つの異なる行に追加する必要があります）