Sehr geringer TCP OpenVPN-Durchsatz (100-Mbit-Port, geringe CPU-Auslastung)

Ich habe extrem langsame OpenVPN-Übertragungsraten zwischen zwei Servern. Bei dieser Frage rufe ich die Server Server A und Server B an.

Sowohl auf Server A als auch auf Server B wird CentOS 6.6 ausgeführt. Beide befinden sich in Rechenzentren mit einer 100-Mbit-Leitung, und die Datenübertragung zwischen den beiden Servern außerhalb von OpenVPN erfolgt mit ca. 88 Mbit / s.

Wenn ich jedoch versuche, Dateien über die von mir eingerichtete OpenVPN-Verbindung zwischen Server A und Server B zu übertragen, erhalte ich einen Durchsatz von ungefähr 6,5 Mbit / s.

Testergebnisse von 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

Abgesehen von diesen OpenVPN-Iperf-Tests sind beide Server mit null Last praktisch vollständig inaktiv.

Server A wird die IP 10.0.0.1 zugewiesen und es ist der OpenVPN-Server. Server B erhält die IP 10.0.0.2 und ist der OpenVPN-Client.

Die OpenVPN-Konfiguration für Server A lautet wie folgt:

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

Die OpenVPN-Konfiguration für Server B lautet wie folgt:

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

Was mir aufgefallen ist:

1. Mein erster Gedanke war, dass ich einen Engpass bei der CPU auf dem Server hatte. OpenVPN ist Single-Threaded und auf beiden Servern laufen Intel Xeon L5520-Prozessoren, die nicht die schnellsten sind. Ich habe jedoch topwährend eines der iperf-Tests einen Befehl ausgeführt und auf gedrückt 1, um die CPU-Auslastung nach Kern anzuzeigen. Dabei stellte ich fest, dass die CPU-Auslastung auf jedem Kern sehr niedrig war:

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. Die Ping-Zeiten im OpenVPN-Tunnel erhöhen sich erheblich, während iperf ausgeführt wird. Wenn iperf nicht läuft, betragen die Ping-Zeiten über den Tunnel durchgehend 60 ms (normal). Aber wenn iperf rennt und starken Verkehr pusht, werden die Ping-Zeiten unregelmäßig. Sie können unten sehen, wie die Ping-Zeiten bis zum 4. Ping stabil sind, wenn ich den Iperf-Test gestartet habe:

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. Wie oben erwähnt, habe ich iperf außerhalb des OpenVPN-Tunnels ausgeführt und der Durchsatz war normal - ~ 88 Mbit / s durchgehend.

Was ich versucht habe:

1. Ich dachte, die Komprimierung könnte comp-lzoProbleme verursachen. Deshalb habe ich die Komprimierung deaktiviert, indem ich beide Konfigurationen entfernt und OpenVPN neu gestartet habe. Keine Verbesserung.

2. Obwohl ich zuvor festgestellt habe, dass die CPU-Auslastung niedrig ist, dachte ich, dass die Standardverschlüsselung möglicherweise etwas zu intensiv ist, als dass das System mithalten könnte. Also habe ich cipher RC2-40-CBCbeide Configs hinzugefügt (eine sehr leichte Chiffre) und OpenVPN neu gestartet. Keine Verbesserung.

3. Ich habe in verschiedenen Foren darüber gelesen, wie das Optimieren des Fragments, von mssfix und mtu-tun die Leistung verbessern kann. Ich habe mit ein paar Variationen gespielt, wie in diesem Artikel beschrieben , aber auch hier keine Verbesserung.

Irgendwelche Ideen, was solch eine schlechte OpenVPN-Leistung verursachen könnte?

Nach vielen Optimierungen an Googeln und Konfigurationsdateien habe ich die Lösung gefunden. Ich erhalte jetzt anhaltende Geschwindigkeiten von 60 Mbit / s und starte bis zu 80 Mbit / s.Es ist etwas langsamer als die Übertragungsraten, die ich außerhalb des VPN erhalte, aber ich denke, das ist so gut wie es nur geht.

Der erste Schritt bestand darin, sndbuf 0und rcvbuf 0in der OpenVPN-Konfiguration sowohl für den Server als auch für den Client festzulegen.

Ich habe diese Änderung vorgenommen, nachdem ich einen Vorschlag in einem öffentlichen Forumsbeitrag (der eine englische Übersetzung eines russischen Originalbeitrags ist ) gesehen habe, den ich hier zitiere:

Es ist Juli 2004. Die übliche Internetgeschwindigkeit zu Hause in Industrieländern beträgt 256-1024 Kbit / s, in weniger entwickelten Ländern 56 Kbit / s. Linux 2.6.7 wurde vor nicht allzu langer Zeit veröffentlicht, und 2.6.8, bei dem die TCP-Windows-Größenanpassung standardmäßig aktiviert ist, wird erst in einem Monat veröffentlicht. OpenVPN befindet sich bereits seit 3 ​​Jahren in der aktiven Entwicklung, die 2.0-Version ist fast erschienen. Einer der Entwickler beschließt, Code für den Socket-Puffer hinzuzufügen. Ich denke, die Puffergrößen zwischen den Betriebssystemen zu vereinheitlichen. In Windows tritt bei der MTU von Adaptern ein Fehler auf, wenn benutzerdefinierte Puffergrößen festgelegt wurden. Schließlich wurde der Code in den folgenden Code umgewandelt:

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

Wenn Sie OpenVPN verwendet haben, sollten Sie wissen, dass es über TCP und UDP funktioniert. Wenn Sie einen benutzerdefinierten TCP-Socket-Pufferwert von 64 KB festlegen, kann der TCP-Fenstergrößenskalierungsalgorithmus die Fenstergröße nicht auf mehr als 64 KB anpassen. Was bedeutet das? Das bedeutet, dass Sie bei einer Verbindung zu einer anderen VPN-Site über eine lange, fette Verbindung, z. B. USA nach Russland, mit einem Ping von ca. 100 ms eine Geschwindigkeit von nicht mehr als 5,12 Mbit / s mit den standardmäßigen OpenVPN-Puffereinstellungen erzielen können. Sie benötigen mindestens 640 KB Puffer, um 50 Mbit / s über diese Verbindung zu erhalten. UDP würde schneller arbeiten, da es keine Fenstergröße hat, aber auch nicht sehr schnell arbeitet.

Wie Sie vielleicht bereits erraten haben, verwendet die neueste OpenVPN-Version immer noch 64 KB Socket-Puffergröße. Wie sollen wir dieses Problem beheben? Am besten ist es, OpenVPN das Festlegen benutzerdefinierter Puffergrößen zu verweigern. Sie sollten den folgenden Code sowohl in die Server- als auch in die Clientkonfigurationsdateien einfügen:

sndbuf 0
rcvbuf 0

Der Autor beschreibt weiter, wie Sie die Anpassung der Puffergröße auf den Client übertragen können, wenn Sie nicht die Kontrolle über die Client-Konfiguration haben.

Nachdem ich diese Änderungen vorgenommen hatte, stieg meine Durchsatzrate auf 20 Mbit / s. Ich sah dann, dass die CPU-Auslastung auf einem einzelnen Kern ein wenig hoch war, also entfernte ichcomp-lzo (Komprimierung) von der Konfiguration sowohl auf dem Client als auch auf dem Server. Eureka! Die Übertragungsgeschwindigkeit stieg kontinuierlich um bis zu 60 Mbit / s und der Burst um 80 Mbit / s.

Ich hoffe, dass dies jemand anderem hilft, seine eigenen Probleme mit der Langsamkeit von OpenVPN zu lösen!

Nach einigen Versuchen habe ich eine gute Lösung erreicht. In meinem Fall hat @ Elliots Antwort nicht geholfen. Wenn ich mehr google, habe ich dieses Snippet herausgefunden, um es in die Serverkonfiguration einzufügen, die den Job gemacht hat

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

Ich habe einen kleinen OpenVPN-Server auf einem Raspberry PI3 und jetzt bekomme ich 71 Mbps Downlink und 16 Mbps Uplink . Der Download ist begrenzt, da die CPU-Leistung begrenzt ist. Im Moment ist meine Konfiguration wie folgt:

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 mit OpenSSL 1.0.2l

Es fühlt sich so seltsam an, dass ein solches Problem bezüglich der Standardkonfiguration eines Puffers immer noch besteht.

[EDIT] Meine client.ovpn-Datei ist folgendermaßen aufgebaut:

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>

Entsprechend den Konfigs verwenden Sie TCP als Transport für den Tunnel. Erwägen Sie die Verwendung von UDP anstelle von TCP, da die gestapelten TCP-Verbindungen Probleme in Situationen mit Paketverlust verursachen können.

Als Referenz siehe Warum TCP über TCP eine schlechte Idee ist

Wir haben zwei interkontinentale Server, die miteinander verbunden sind. Die Geschwindigkeit zwischen ihnen liegt bei 220 Mbit / s.

Innerhalb des (UDP) OpenVPN-Tunnels würden die Geschwindigkeiten jedoch durchschnittlich 21 Mbit / s betragen - ungefähr 10x langsamer.

(Zwischen den Servern besteht eine erhebliche Latenzzeit: ca. 130 ms, und die Übertragungen wurden mit Iperf3 im TCP-Modus gemessen.)

Versuchte alle Vorschläge auf Antworten hier als dieses Schreiben, und nichts half.

Das einzige, was endlich geholfen hat, war dieses kleine bisschen:

--txqueuelen 4000

Nach dem OpenVPN-Referenzhandbuch:

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

Nachdem ich diesen Parameter auf dem Server und dem Client eingestellt hatte, konnte ich die gleichen Direktverbindungsgeschwindigkeiten (~ 250 Mbit / s) auch unter dem OpenVPN-Tunnel erreichen.

Ich war mit bereits rcvbuf 0und sndbuf 0, zumindest aber allein , sie haben keine Hilfe überhaupt.

Ich habe diese Empfehlungen sowohl auf dieser Seite im OpenVPN-Forum als auch auf dieser Seite im UDPspeeder-Wiki gefunden .

Im Übrigen: Mit UDP-Übertragungen in iperf konnte ich höhere Geschwindigkeiten erreichen, aber dies würde auch einen relativ hohen Paketverlust zur Folge haben.

Wenn Sie zufällig VPN verwenden müssen, um zwei Stellen mit verlustbehafteten Verbindungen zu tunneln, empfiehlt es sich, eine Art FEC-Tunnel (Forward-Error-Correction) unter dem VPN selbst zu verwenden. Die beiden, mit denen ich zusammenarbeiten konnte, sind:

• Der oben erwähnte UDPspeeder , der UDP-Verbindungen tunnelt;
• kcptun , das TCP-Verbindungen tunnelt;

Beides kann beim Paketverlust sehr hilfreich sein (indem zunächst mehr Bandbreite aufgewendet wird) und letztendlich sogar zu einem höheren Datendurchsatz führen, selbst mit dem zusätzlichen Overhead, der wirklich ordentlich ist, wenn Sie mich fragen.

(Dies liegt daran, dass Paketverlust ein Netzwerk , insbesondere TCP, wirklich durcheinander bringen kann . Siehe Seite 6.)

Ich hätte aus den üblichen Gründen OpenVPN unter UDP vorgezogen, aber ich fand es schwierig, mit UDPspeeder umzugehen, wenn Sie beide eine Latenz von mehr als 100 ms und eine Geschwindigkeit von> 10 Mbit / s haben.

kcptun jedoch funktionierte prima mit sehr wenig Gefummel, und eigentlich wirklich erhöhte unseren Server Durchsatz miteinander. =)

In einem erweiterten Hinweis finden Sie hier einige detailliertere Erklärungen zum Optimieren einiger Teile der OpenVPN-Leistung.

Für mich hatte ich einen VPS-Server mit OpenVPN-Server-Setup in Japan und meine Client-Verbindung verwendete ein DDWRT im OpenVPN-Client-Modus in NYC. Ich erhielt nur 1-2mbps auf einer 100mbit-Verbindung. Das Beste, wofür ich es optimieren konnte, waren 5 MBit / s, das war genug für das, was ich brauchte. Es ist so optimiert, wie ich es mir vorstellen kann.

Meine OpenVPN-Servereinstellungen:

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

Meine DDWRT OpenVPN-Clienteinstellungen werden auch in meinem Screenshot angezeigt:

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