非常に低いTCP OpenVPNスループット（100Mbitポート、低CPU使用率）

2台のサーバー間でOpenVPNの転送速度が極端に遅くなっています。この質問では、サーバーをサーバーAおよびサーバーBと呼びます。

サーバーAとサーバーBの両方がCentOS 6.6を実行しています。どちらも100Mbit回線のデータセンターにあり、OpenVPN外の2台のサーバー間のデータ転送は約88Mbps近くで実行されます。

ただし、サーバーAとサーバーBの間に確立したOpenVPN接続を介してファイルを転送しようとすると、スループットが6.5 Mbps前後になります。

iperfのテスト結果：

[  4] local 10.0.0.1 port 5001 connected with 10.0.0.2 port 49184
[  4]  0.0-10.0 sec  7.38 MBytes  6.19 Mbits/sec
[  4]  0.0-10.5 sec  7.75 MBytes  6.21 Mbits/sec
[  5] local 10.0.0.1 port 5001 connected with 10.0.0.2 port 49185
[  5]  0.0-10.0 sec  7.40 MBytes  6.21 Mbits/sec
[  5]  0.0-10.4 sec  7.75 MBytes  6.26 Mbits/sec

これらのOpenVPN iperfテストは別として、両方のサーバーはゼロ負荷で実質的に完全にアイドル状態です。

サーバーAにはIP 10.0.0.1が割り当てられており、これがOpenVPNサーバーです。サーバーBにはIP 10.0.0.2が割り当てられ、OpenVPNクライアントです。

サーバーAのOpenVPN構成は次のとおりです。

port 1194
proto tcp-server
dev tun0
ifconfig 10.0.0.1 10.0.0.2
secret static.key
comp-lzo
verb 3

サーバーBのOpenVPN構成は次のとおりです。

port 1194
proto tcp-client
dev tun0
remote 204.11.60.69
ifconfig 10.0.0.2 10.0.0.1
secret static.key
comp-lzo
verb 3

私が気づいたこと：

1.最初に考えたのは、サーバーのCPUのボトルネックになっていたことです。OpenVPNはシングルスレッドであり、これらのサーバーはどちらもIntel Xeon L5520プロセッサを実行しますが、これは最速ではありません。ただし、topiperfテストの1つでコマンドを実行し、1コアごとのCPU使用率を表示するように押したところ、各コアのCPU負荷が非常に低いことがわかりました。

top - 14:32:51 up 13:56,  2 users,  load average: 0.22, 0.08, 0.06
Tasks: 257 total,   1 running, 256 sleeping,   0 stopped,   0 zombie
Cpu0  :  2.4%us,  1.4%sy,  0.0%ni, 94.8%id,  0.3%wa,  0.0%hi,  1.0%si,  0.0%st
Cpu1  :  0.0%us,  0.0%sy,  0.0%ni,100.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu2  :  0.0%us,  0.0%sy,  0.0%ni, 99.7%id,  0.0%wa,  0.0%hi,  0.0%si,  0.3%st
Cpu3  :  0.3%us,  0.0%sy,  0.0%ni, 99.7%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu4  :  0.0%us,  0.0%sy,  0.0%ni,100.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu5  :  0.0%us,  0.0%sy,  0.0%ni,100.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu6  :  0.0%us,  0.0%sy,  0.0%ni,100.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu7  :  0.0%us,  0.0%sy,  0.0%ni,100.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu8  :  0.0%us,  0.0%sy,  0.0%ni,100.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu9  :  0.0%us,  0.0%sy,  0.0%ni,100.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu10 :  0.0%us,  0.0%sy,  0.0%ni,100.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu11 :  0.0%us,  0.0%sy,  0.0%ni,100.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu12 :  0.0%us,  0.0%sy,  0.0%ni,100.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu13 :  0.0%us,  0.0%sy,  0.0%ni,100.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu14 :  0.0%us,  0.0%sy,  0.0%ni,100.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu15 :  0.0%us,  0.0%sy,  0.0%ni,100.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Mem:    946768k total,   633640k used,   313128k free,    68168k buffers
Swap:  4192188k total,        0k used,  4192188k free,   361572k cached

2. iperfの実行中、OpenVPNトンネル上でPing時間は大幅に増加します。iperfが実行されていない場合、トンネルを介したping時間は常に60ミリ秒（通常）です。しかし、iperfが実行され、大量のトラフィックをプッシュしている場合、ping時間は不安定になります。iperfテストを開始した4番目のpingまで、ping時間はどのように安定しているかを確認できます。

PING 10.0.0.2 (10.0.0.2) 56(84) bytes of data.
64 bytes from 10.0.0.2: icmp_seq=1 ttl=64 time=60.1 ms
64 bytes from 10.0.0.2: icmp_seq=2 ttl=64 time=60.1 ms
64 bytes from 10.0.0.2: icmp_seq=3 ttl=64 time=60.2 ms
** iperf test begins **
64 bytes from 10.0.0.2: icmp_seq=4 ttl=64 time=146 ms
64 bytes from 10.0.0.2: icmp_seq=5 ttl=64 time=114 ms
64 bytes from 10.0.0.2: icmp_seq=6 ttl=64 time=85.6 ms
64 bytes from 10.0.0.2: icmp_seq=7 ttl=64 time=176 ms
64 bytes from 10.0.0.2: icmp_seq=8 ttl=64 time=204 ms
64 bytes from 10.0.0.2: icmp_seq=9 ttl=64 time=231 ms
64 bytes from 10.0.0.2: icmp_seq=10 ttl=64 time=197 ms
64 bytes from 10.0.0.2: icmp_seq=11 ttl=64 time=233 ms
64 bytes from 10.0.0.2: icmp_seq=12 ttl=64 time=152 ms
64 bytes from 10.0.0.2: icmp_seq=13 ttl=64 time=216 ms

3.前述のように、OpenVPNトンネルの外側でiperfを実行しましたが、スループットは正常でした（一貫して〜88Mbps）。

私が試したこと：

1.圧縮は物事を汚すのではないかと思ったのでcomp-lzo、両方の設定から削除してOpenVPNを再起動することで圧縮をオフにしました。改善なし。

2. CPU使用率が低いことが以前にわかっていたとしても、デフォルトの暗号はシステムが追い付かないほど少なすぎるかもしれないと思いました。そこでcipher RC2-40-CBC、両方の設定（非常に軽量な暗号）に追加し、OpenVPNを再起動しました。改善なし。

3.さまざまなフォーラムで、フラグメント、mssfix、mtu-tunの調整がパフォーマンスにどのように役立つかについて読みました。この記事で説明したように、いくつかのバリエーションを試しましたが、改善はありませんでした。

このようなOpenVPNのパフォーマンスの低下の原因についてのアイデアはありますか？

グーグルと設定ファイルを何度も調整した後、解決策を見つけました。私は現在、60 Mbpsの持続速度と80 Mbpsまでのバーストを取得しています。VPNの外部で受け取る転送速度よりも少し遅いですが、これは得られるのと同じくらい良いと思います。

最初のステップは、セットにしたsndbuf 0し、rcvbuf 0サーバーとクライアントの両方のためのOpenVPNの設定で。

ここで引用する公開フォーラムの投稿（ロシア語の元の投稿の英語の翻訳です）でそうする提案を見た後、私はその変更を行いました：

2004年7月です。先進国での通常のホームインターネット速度は256〜1024 Kbit / sで、後進国では56 Kbit / sです。Linux 2.6.7は少し前にリリースされており、TCP Windowsサイズスケーリングがデフォルトで有効になっている2.6.8は1か月だけでリリースされます。OpenVPNはすでに3年間活発に開発されており、2.0バージョンがほぼリリースされています。開発者の1人がソケットバッファーにコードを追加することを決定しました。OS間のバッファーサイズを統一すると思います。Windowsでは、カスタムバッファーサイズが設定されている場合、アダプターのMTUで問題が発生するため、最終的に次のコードに変換されます。

#ifndef WIN32
o->rcvbuf = 65536;
o->sndbuf = 65536;
#endif

OpenVPNを使用した場合、TCPおよびUDPを介して動作できることを知っておく必要があります。カスタムTCPソケットバッファー値を64 KBに設定すると、TCPウィンドウサイズスケーリングアルゴリズムはウィンドウサイズを64 KBを超えて調整できません。どういう意味ですか？つまり、長いファットリンク（米国からロシアへのpingが約100ミリ秒）で他のVPNサイトに接続している場合、デフォルトのOpenVPNバッファー設定では5.12 Mbit / sを超える速度は得られません。そのリンクで50 Mbit / sを取得するには、少なくとも640 KBのバッファーが必要です。UDPはウィンドウサイズがないため高速に動作しますが、非常に高速に動作しません。

すでに推測されているように、最新のOpenVPNリリースは依然として64 KBのソケットバッファーサイズを使用しています。この問題をどのように修正する必要がありますか？最良の方法は、OpenVPNがカスタムバッファーサイズを設定できないようにすることです。サーバーとクライアントの両方の構成ファイルに次のコードを追加する必要があります。

sndbuf 0
rcvbuf 0

作成者は、クライアント設定を自分で制御できない場合に、バッファサイズの調整をクライアントにプッシュする方法について説明します。

これらの変更を行った後、スループットレートが最大20 Mbpsに上がりました。次に、シングルコアのCPU使用率が少し高いことがわかったのでcomp-lzo、クライアントとサーバーの両方の構成から削除（圧縮）しました。ユーレカ！転送速度は、最大60 Mbpsの持続速度と80 Mbpsのバーストまで跳ね上がりました。

これにより、他の誰かがOpenVPNの速度低下に関する問題を解決できることを願っています。

いくつかの試みの後、私は良い解決策に到達しました。私の場合、@ Elliotの返信は役に立ちませんでした。さらにグーグルで、私はこのスニペットを見つけて、仕事をしたサーバーの構成を追加しました

sndbuf 393216
rcvbuf 393216
push "sndbuf 393216"
push "rcvbuf 393216"

Raspberry PI3で実行している小さなOpenVPNサーバーがあり、今では71 Mbpsのダウンリンクと16 Mbpsのアップリンクを取得しています。CPUのパワーのため、ダウンロードは制限されています。現在、私の構成は次のとおりです。

client-to-client
duplicate-cn
keepalive 10 120
cipher AES-128-CBC
#cipher AES-256-CBC <<<---- lowers the speed to around 50Mbps, still not bad
comp-lzo
user nobody
group nogroup
persist-key
persist-tun
tun-mtu 9000

OpenVPN 2.4.0 arm-unknown-linux-gnueabihfとOpenSSL 1.0.2l

バッファのデフォルト設定に関するこのような問題がまだ存在するのはとても奇妙に感じます。

[編集] client.ovpnファイルは次のように構成されています。

client
dev tun
proto tcp
remote SERVER.IP.ADDRESS.HERE
resolv-retry infinite
nobind
persist-key
persist-tun
mute-replay-warnings
ns-cert-type server
tun-mtu 9000
key-direction 1
cipher AES-128-CBC
comp-lzo
verb 1
mute 20
<ca>
-----BEGIN CERTIFICATE-----
[...]
-----END CERTIFICATE-----
</ca>
<cert>
-----BEGIN CERTIFICATE-----
[...]
-----END CERTIFICATE-----
</cert>
<key>
-----BEGIN RSA PRIVATE KEY-----
[...]
-----END RSA PRIVATE KEY-----
</key>
<tls-auth>
-----BEGIN OpenVPN Static key V1-----
[...]
-----END OpenVPN Static key V1-----
</tls-auth>

構成によると、トンネルのトランスポートとしてTCPを使用しています。スタックされたTCP接続はパケット損失の状況で問題を引き起こすため、TCPではなくUDPの使用を検討してください。

参照として、TCP over TCPが悪い考えである理由を参照してください。

相互にリンクしている2つの大陸間サーバーがあり、それらの間の速度は約220メガビット/秒です。

ただし、（UDP）OpenVPNトンネル内では、速度は平均で21メガビット/秒になり、およそ10倍遅くなります。

（サーバー間には大きな遅延があります：約130ミリ秒、TCPモードでIperf3を使用して転送を測定しました。）

この記事の執筆時点で、回答に関するすべての提案を試みましたが、何も助けにはなりませんでした。

最終的に助けになったものの1つは、この少しでした。

--txqueuelen 4000

OpenVPNリファレンスマニュアルによると：

–txqueuelen n 
(Linux only) Set the TX queue length on the TUN/TAP interface. Currently defaults to 100.

サーバーとクライアントでこのパラメーターを設定した後、OpenVPNトンネルでも同じ「ダイレクトリンク」速度（〜250Mbit / s）に到達することができました。

私はすでにrcvbuf 0and を使用してsndbuf 0いましたが、少なくとも単独では、まったく役に立ちませんでした。

私は両方でこれらの推奨事項を見つけた：このページをOpenVPNのフォーラムでは、ともに、このページUDPspeederウィキに。

別の注意事項：iperfでUDP転送を使用してより高速に到達できましたが、そうすると、かなり高いパケット損失が発生します。

偶然VPNを使用して損失の多いリンクを持つ2つの場所をトンネリングする必要がある場合は、VPN自体の下にある種のForward-Error-Correction（FEC）トンネルの使用を検討することをお勧めします。私が見つけて一緒に仕事をした2つは次のとおりです。

• UDP接続をトンネリングする前述のUDPspeeder。
• TCP接続をトンネリングするkcptun。

どちらもパケットロスで大いに役立ち（そもそもより多くの帯域幅を消費する）、最終的にはオーバーヘッドを追加してもデータスループットが向上します。

（これは、パケット損失が実際にネットワーク、特にTCPを台無しにする可能性があるためです。6ページを参照してください。）

通常のすべての理由から、UDPでOpenVPNを使用することをお勧めしますが、レイテンシが100ミリ秒以上で速度が10メガビット/秒を超える場合、UDPspeederを扱うのは難しいことがわかりました。

kcptunは、しかし、実際には非常に少しの微調整で素晴らしい仕事をし、本当にお互いにスループット当社のサーバーを増加させました。=）

拡張されたノートで、ここであなたはOpenVPNの性能の一部を微調整に関するいくつかのより詳細な説明を見つけることができます。

私の場合、日本にopenvpnサーバーが設定されたVPSサーバーがあり、クライアント接続はNYCのOpenVPNクライアントモードでDDWRTを使用していました。100mbit接続で1-2mbpsしか得られませんでした。最適化できたのは5mbpsでしたが、これは必要なものに十分であり、信じられる限り最適化されています。

OpenVPNサーバーの設定：

tun-mtu 9000
sndbuf 393216
rcvbuf 393216
push "sndbuf 393216"
push "rcvbuf 393216"
comp-lzo
txqueuelen 4000
######
port 10111
proto udp
dev tun
user nobody
group nobody
persist-key
persist-tun
keepalive 10 120
topology subnet
server x.x.0.0 255.255.255.0
ifconfig-pool-persist ipp.txt
push "dhcp-option DNS 1.0.0.1"
push "dhcp-option DNS 1.1.1.1"
push "redirect-gateway def1 bypass-dhcp"
dh none
ecdh-curve prime256v1
#tls-crypt tls-crypt.key 0
crl-verify crl.pem
ca ca.crt
cert server_IzA1QdFzHLRFfEoQ.crt
key server_IzA1QdFzHLRFfEoQ.key
auth SHA256
#cipher AES-128-GCM
#cipher AES-128-CBC
#ncp-ciphers AES-128-GCM
#ncp-ciphers AES-128-CBC
#tls-server
#tls-version-min 1.2
#tls-cipher TLS-ECDHE-ECDSA-WITH-AES-128-GCM-SHA256
#tls-cipher TLS-DHE-RSA-WITH-AES-128-CBC-SHA
status /var/log/openvpn/status.log
verb 3

私のスクリーンショットにもDDWRT OpenVPNクライアントの設定が表示されています：

tun-mtu 9000
comp-lzo
##########
resolv-retry infinite
nobind
persist-key
persist-tun
remote-cert-tls server
verify-x509-name server_IzA1QdFzHLRFfEoQ name
auth SHA256
auth-nocache
setenv opt block-outside-dns # Prevent Windows 10 DNS leak
verb 3