Frage Sehr niedriger TCP OpenVPN Durchsatz (100Mbit Port, geringe CPU Auslastung)


Ich habe extrem langsame OpenVPN-Übertragungsraten zwischen zwei Servern. Für diese Frage rufe ich die Server Server A und Server B an.

Sowohl auf Server A als auch auf Server B läuft CentOS 6.6. Beide befinden sich in Datencentern mit einer 100-Mbit-Leitung, und Datenübertragungen zwischen den zwei Servern außerhalb von OpenVPN liegen in der Nähe von ~ 88 Mbit / s.

Wenn ich jedoch versuche, Dateien über die OpenVPN-Verbindung zu übertragen, die ich zwischen Server A und Server B eingerichtet habe, erhalte ich einen Durchsatz von rund 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 praktisch vollständig im Leerlauf und ohne Last.

Server A hat die IP-Adresse 10.0.0.1 und ist der OpenVPN-Server. Server B hat die IP-Adresse 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 ich bemerkt habe:

1. Mein erster Gedanke war, dass ich die CPU auf dem Server knapp machte. OpenVPN ist single-threaded und beide dieser Server laufen Intel Xeon L5520-Prozessoren, die nicht die schnellsten sind. Allerdings lief ich ein top Befehl während eines der iperf Tests und gedrückt 1 um die CPU-Auslastung nach Kern anzuzeigen, und festgestellt, 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. Ping-Zeiten erhöhen sich beträchtlich während des OpenVPN-Tunnels, während iperf läuft. Wenn iperf nicht läuft, sind die Ping-Zeiten über den Tunnel konstant 60ms (normal). Aber wenn Iperf läuft und starken Verkehr schiebt, werden Ping-Zeiten unberechenbar. 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, lief ich iperf außerhalb des OpenVPN-Tunnels und der Durchsatz war normal - ~ 88Mbps konsistent.

Was ich versucht habe:

1. Ich dachte, die Komprimierung könnte Probleme verursachen, also habe ich die Komprimierung ausgeschaltet, indem ich entfernt habe comp-lzo von beiden Konfigurationen und Neustart von OpenVPN. Keine Verbesserung.

2. Obwohl ich zuvor festgestellt habe, dass die CPU-Auslastung niedrig ist, dachte ich, dass die Standardchiffre etwas zu intensiv sein könnte, damit das System mithalten kann. Also fügte ich hinzu cipher RC2-40-CBC in beiden Konfigurationen (eine sehr leichte Chiffre) und OpenVPN neu gestartet. Keine Verbesserung.

3. Ich lese in verschiedenen Foren darüber, wie das Optimieren des Fragments, mssfix und mtu-tun bei der Performance helfen könnte. Ich habe mit einigen Variationen gespielt, wie in Dieser Beitragaber wieder keine Verbesserung.

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


20
2018-04-28 21:43


Ursprung


Haben Sie Links, Kommentare von hier helfen? forums.openvpn.net/topic10593.html - Matt
Die meisten der darin enthaltenen Vorschläge sind Dinge, die ich bereits ausprobiert habe: 1. CPU-Engpässe prüfen, 2. Übertragungsgeschwindigkeiten ohne VPN prüfen, 3. Komprimierung umschalten, 4. schnellere Chiffre wählen usw. Kein Glück mit irgendwelchen noch: - / Es ist bizarr. Abgesehen von der langsamen Geschwindigkeit und den hohen / flüchtigen Ping-Zeiten sehe ich keinen anderen Hinweis darauf, wo der Engpass sein könnte. - Elliot B.
Sind beide Maschinen im selben Datencenter? 60 ms im selben Rechenzentrum sind ziemlich hoch. Ich könnte versucht sein, es zu versuchen cipher none obwohl ich bezweifle, dass es helfen wird. - Zoredache
@Zoredache Es tut mir leid - ich war mir nicht sicher über die Standorte der Server - Server A ist in Dallas und Server B ist in Seattle. - Elliot B.
Hast du die MTU überprüft? Esp: tun-mtu, Fragment und msfix Parameter? Dokumentation - Lenniey


Antworten:


Nach vielen Optimierungen der Googling- und Konfigurationsdateien habe ich die Lösung gefunden. Ich bekomme jetzt dauerhafte Geschwindigkeiten von 60 Mbit / s und platze bis zu 80 Mbit / s. Es ist ein bisschen langsamer als die Übertragungsraten, die ich außerhalb des VPN empfange, aber ich denke, das ist so gut wie es wird.

Der erste Schritt war zu setzen sndbuf 0 und rcvbuf 0 in der OpenVPN-Konfiguration für den Server und den Client.

Ich habe diese Änderung gemacht, nachdem ich einen Vorschlag gesehen habe, dies auf einer Website zu tun öffentlicher Forenbeitrag (was eine englische Übersetzung von a ist Russischer Originalbeitrag) Ich zitiere hier:

Es ist Juli, 2004. Übliche Internet-Geschwindigkeit zu Hause in den entwickelten Ländern ist 256-1024 Kbit / s, in weniger entwickelten Ländern ist 56 Kbit / s. Linux 2.6.7 wurde vor kurzem veröffentlicht und 2.6.8, wo TCP Windows Size Scaling standardmäßig aktiviert ist, wird nur in einem Monat veröffentlicht. OpenVPN ist bereits seit 3 ​​Jahren in der aktiven Entwicklung, Version 2.0 ist fast freigegeben.   Einer der Entwickler beschließt, Code für den Socket-Puffer hinzuzufügen, um die Puffergrößen zwischen den Betriebssystemen zu vereinheitlichen. In Windows geht mit der MTU des Adapters etwas schief, wenn benutzerdefinierte Puffergrößen festgelegt werden, sodass es schließlich in den folgenden Code umgewandelt wird:

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

Wenn Sie OpenVPN verwendet haben, sollten Sie wissen, dass es über TCP und UDP funktionieren kann. Wenn Sie den benutzerdefinierten TCP-Socket-Pufferwert auf 64 KB beschränken, kann der TCP-Algorithmus für die Größenbestimmung der Fenstergröße die Fenstergröße nicht auf mehr als 64 KB einstellen. Was bedeutet das? Das bedeutet, dass wenn Sie eine Verbindung zu einer anderen VPN-Site über eine langatmige Verbindung herstellen, z. B. USA nach Russland mit Ping über 100 ms, keine Geschwindigkeit von mehr als 5,12 Mbit / s mit standardmäßigen OpenVPN-Puffereinstellungen. Sie benötigen mindestens 640 KB Puffer, um über diese Verbindung 50 Mbit / s zu erhalten.   UDP würde schneller arbeiten, da es keine Fenstergröße hat, aber auch nicht sehr schnell funktioniert.

Wie Sie bereits erraten haben, verwendet die neueste OpenVPN-Version immer noch 64 KB   Socket-Puffergröße. Wie sollten wir dieses Problem beheben? Der beste Weg ist es   verbieten Sie OpenVPN, um benutzerdefinierte Puffergrößen festzulegen. Sie sollten das hinzufügen   folgender Code in Server- und Client-Konfigurationsdateien:

sndbuf 0
rcvbuf 0

Der Autor fährt fort, zu beschreiben, wie Puffergrößenanpassungen an den Client vorgenommen werden, wenn Sie nicht selbst die Kontrolle über die Client-Konfiguration haben.

Nachdem ich diese Änderungen vorgenommen hatte, stieg meine Durchsatzrate auf 20 Mbps. Ich sah dann, dass die CPU-Auslastung auf einem einzelnen Kern etwas hoch war, also entfernte ich comp-lzo (Komprimierung) von der Konfiguration auf dem Client und dem Server. Eureka! Übertragungsgeschwindigkeiten sprangen auf bis zu 60 Mbit / s und 80 Mbit / s auf.

Ich hoffe, dass dies jemand anderem hilft, ihre eigenen Probleme mit OpenVPN-Langsamkeit zu lösen!


21
2018-04-29 21:47





Nach einigen Versuchen habe ich eine gute Lösung gefunden. In meinem Fall hat @ Elliots Antwort nicht geholfen. Googeln mehr, fand ich dieses Snippet, um in der Serverkonfiguration hinzuzufügen, die den Job machte

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 seit der CPU-Leistung begrenzt. Im Moment ist meine Konfiguration folgende:

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 existiert.


3
2017-12-16 13:50



Ich frage mich, warum eine funktionierende Lösung abgelehnt wurde. - Kernel
Die Einstellung der Puffergrößen hat mir geholfen. - Rolf
Erstaunlich, du hast meinen Tag gerettet ... Vielen Dank! - ℛɑƒæĿ


Gemäß den Configs verwenden Sie TCP als Transport für den Tunnel. Ziehen Sie die Verwendung von UDP anstelle von TCP in Betracht, da die gestapelten TCP-Verbindungen Probleme in Paketverlustsituationen verursachen.

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


1
2018-04-28 22:28



Leider ist UDP für uns keine Option. Wir müssen sicherstellen, dass die Datenpakete, die wir übertragen, wie erwartet ankommen. Trotzdem haben wir früher mit UDP experimentiert und die schlechten Übertragungsraten waren immer noch ein Problem. - Elliot B.
We need to ensure that the data packets we transmit arrive as expected. und wird das nicht durch das Protokoll gehandhabt, das getunnelt wird? Warum denkst du, dass dein Tunnel das sein muss, was das erzwingt? - Zoredache
Das ist wahrscheinlich der Fall, aber wir verwenden OpenVPN für eine asynchrone DRBD-Implementierung über große Entfernungen (z. B. Dateisystemreplikation). Datenintegrität ist Ja wirklich wichtig, obwohl DRBD wahrscheinlich interne Mechanismen zur Überprüfung der Übertragungsintegrität hat, würde ich es lieber auf TCP behalten. Wie auch immer, als wir UDP hatten, hatten wir immer noch den niedrigen Durchsatz. - Elliot B.
@EliotB. Da DRBD selbst TCP für die Replikation verwendet, wird es erneut übertragen, falls das OpenVPN UDP-Paket verloren geht. Wenn Sie TCP benutzen, werden Sie in diesem Fall zwei Retransfers anstelle von einem durchführen, von denen einer weggeworfen wird. Und möglicherweise erstellen Sie ein ziemlich langes Fenster ohne DRBD-Datenverkehr (aus diesem Grund erhalten Sie sogar eine fehlerhafte Replikation). Sobald Sie einen Paketverlust auf der Route bekommen, werden Sie sehen, wie schlecht das ist. - Fox
@ Fox Danke für die Klärung! In der Tat verwendet DRBD TCP (drbd.linbit.com/users-guide/s-prepare-network.html). Der frühere Vorschlag von Lairsdragon, zu UDP zu wechseln, war zu dieser Zeit nicht relevant, da UDP auch extrem niedrige Übertragungsraten aufwies, aber seit der Implementierung der oben beschriebenen Lösung haben wir den Wechsel zu UDP vorgenommen und einen weiteren Leistungszuwachs von einigen Mbps erfahren. - Elliot B.