Discussion:
openVPN ist langsam
(zu alt für eine Antwort)
Dirk S.
2018-08-14 12:10:02 UTC
Permalink
Hi Leute!

kennt sich hier zufällig jemand mit dem openVPN von Debian richtig gut
aus und hat eventuell ein paar Tipps auf Lager, die mir noch nicht
(durch Googeln) bekannt sind?

Mein Problem:
openVPN ist richtig be..scheiden langsam. Begrenzt wird die
Übertragungsgeschwindigkeit anscheinend immer vom jeweils langsamsten
beteiligten link (remote up- oder Downlink bzw. lokaler Up- oder
Downlink).

Ich habe auf meinem Heimserver (aktuelles Debian 9 Stable) openVPN als
Server installiert. Prinzipiell läuft das. Ziel ist es, mit Clients
(hauptsächlich Android-Smartphones, aber auch mein Laptop) auf den
Server zuzugreifen. Für die Androiden läuft VPN auf 1194 UDP.

Nur mal so als Beispiel:
Der Server ist 50/10Mbit angebunden.
Ich bekomme im eigenen WLAN durch VPN maximal 2,4MB/s Übertragungsrate.
Aus einem befreundeten WLAN (Unitymedia 36/1Mbit) bekomme ich als
upload zum Server gar nur ca. 178KB/s hin. Das ist irgendwie viel zu
wenig.

Mehr habe ich nicht herausbekommen, und das ist bisher schon den
folgenden Optimierungen geschuldet:
- cipher "nur" Blowfish"
- *keine* Kompression (komplett auskommentiert)
link-mtu 1472
mssfix 1472
fast-io
sndbuf 0
rcvbuf 0
push "sndbuf 393216"
push "rcvbuf 393216"

Hat irgendjemand noch weitere Vorschläge/Ideen, mit welchen ich auf
mehr auf bis dato maximal ein Drittel der möglichen Leitungskapazität
komme?


ciao, Dirk
Philipp Vlassakakis
2018-08-14 12:30:01 UTC
Permalink
Hi,

Wie sieht denn die Server-Auslastung während der Übertragung aus? (top, htop etc.)
Hast du ggf. viele iptables-Regeln?

Ich hatte mal aufgrund von vielen iptable-Rules Performanceprobleme.

Gruß
Philipp
Post by Dirk S.
Hi Leute!
kennt sich hier zufällig jemand mit dem openVPN von Debian richtig gut
aus und hat eventuell ein paar Tipps auf Lager, die mir noch nicht
(durch Googeln) bekannt sind?
openVPN ist richtig be..scheiden langsam. Begrenzt wird die
Übertragungsgeschwindigkeit anscheinend immer vom jeweils langsamsten
beteiligten link (remote up- oder Downlink bzw. lokaler Up- oder
Downlink).
Ich habe auf meinem Heimserver (aktuelles Debian 9 Stable) openVPN als
Server installiert. Prinzipiell läuft das. Ziel ist es, mit Clients
(hauptsächlich Android-Smartphones, aber auch mein Laptop) auf den
Server zuzugreifen. Für die Androiden läuft VPN auf 1194 UDP.
Der Server ist 50/10Mbit angebunden.
Ich bekomme im eigenen WLAN durch VPN maximal 2,4MB/s Übertragungsrate.
Aus einem befreundeten WLAN (Unitymedia 36/1Mbit) bekomme ich als
upload zum Server gar nur ca. 178KB/s hin. Das ist irgendwie viel zu
wenig.
Mehr habe ich nicht herausbekommen, und das ist bisher schon den
- cipher "nur" Blowfish"
- *keine* Kompression (komplett auskommentiert)
link-mtu 1472
mssfix 1472
fast-io
sndbuf 0
rcvbuf 0
push "sndbuf 393216"
push "rcvbuf 393216"
Hat irgendjemand noch weitere Vorschläge/Ideen, mit welchen ich auf
mehr auf bis dato maximal ein Drittel der möglichen Leitungskapazität
komme?
ciao, Dirk
Dirk S.
2018-08-14 17:10:02 UTC
Permalink
Der dümpelt mit 7 Prozent Last vor sich hin.
Post by Philipp Vlassakakis
Hi,
Wie sieht denn die Server-Auslastung während der Übertragung aus? (top, htop etc.)
Hast du ggf. viele iptables-Regeln?
Ich hatte mal aufgrund von vielen iptable-Rules Performanceprobleme.
Gruß
Philipp
Post by Dirk S.
Hi Leute!
kennt sich hier zufällig jemand mit dem openVPN von Debian richtig gut
aus und hat eventuell ein paar Tipps auf Lager, die mir noch nicht
(durch Googeln) bekannt sind?
openVPN ist richtig be..scheiden langsam. Begrenzt wird die
Übertragungsgeschwindigkeit anscheinend immer vom jeweils langsamsten
beteiligten link (remote up- oder Downlink bzw. lokaler Up- oder
Downlink).
Ich habe auf meinem Heimserver (aktuelles Debian 9 Stable) openVPN als
Server installiert. Prinzipiell läuft das. Ziel ist es, mit Clients
(hauptsächlich Android-Smartphones, aber auch mein Laptop) auf den
Server zuzugreifen. Für die Androiden läuft VPN auf 1194 UDP.
Der Server ist 50/10Mbit angebunden.
Ich bekomme im eigenen WLAN durch VPN maximal 2,4MB/s Übertragungsrate.
Aus einem befreundeten WLAN (Unitymedia 36/1Mbit) bekomme ich als
upload zum Server gar nur ca. 178KB/s hin. Das ist irgendwie viel zu
wenig.
Mehr habe ich nicht herausbekommen, und das ist bisher schon den
- cipher "nur" Blowfish"
- *keine* Kompression (komplett auskommentiert)
link-mtu 1472
mssfix 1472
fast-io
sndbuf 0
rcvbuf 0
push "sndbuf 393216"
push "rcvbuf 393216"
Hat irgendjemand noch weitere Vorschläge/Ideen, mit welchen ich auf
mehr auf bis dato maximal ein Drittel der möglichen Leitungskapazität
komme?
ciao, Dirk
ciao, Dirk
Marc Haber
2018-08-14 15:00:01 UTC
Permalink
On Tue, 14 Aug 2018 13:14:20 +0200, "Dirk S."
Post by Dirk S.
link-mtu 1472
mssfix 1472
Das scheint mir zu groß, dass der Tunelträger fragmentiert wird. Zeig
mal ein paar Zeilen tcpdump während einer größeren Datenübertragung.

Grüße
Marc
--
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber | " Questions are the | Mailadresse im Header
Mannheim, Germany | Beginning of Wisdom " |
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Sven Hartge
2018-08-14 16:20:02 UTC
Permalink
Post by Marc Haber
On Tue, 14 Aug 2018 13:14:20 +0200, "Dirk S."
Post by Dirk S.
link-mtu 1472
mssfix 1472
Das scheint mir zu groß, dass der Tunelträger fragmentiert wird. Zeig
mal ein paar Zeilen tcpdump während einer größeren Datenübertragung.
Das braucht man eigentlich nur, wenn jemand ICMP zwischen zwei
OpenVPN-Knoten kaputt gemacht hat. Sonst findet OpenVPN den besten
Parameter selbst heraus.


--
Sigmentation fault. Core dumped.
Marc Haber
2018-08-14 17:10:02 UTC
Permalink
Post by Sven Hartge
Post by Marc Haber
On Tue, 14 Aug 2018 13:14:20 +0200, "Dirk S."
Post by Dirk S.
link-mtu 1472
mssfix 1472
Das scheint mir zu groß, dass der Tunelträger fragmentiert wird. Zeig
mal ein paar Zeilen tcpdump während einer größeren Datenübertragung.
Das braucht man eigentlich nur, wenn jemand ICMP zwischen zwei
OpenVPN-Knoten kaputt gemacht hat. Sonst findet OpenVPN den besten
Parameter selbst heraus.
Das kann ich leider nicht bestätigen :-(

Grüße
Marc
--
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber | " Questions are the | Mailadresse im Header
Mannheim, Germany | Beginning of Wisdom " |
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Sven Hartge
2018-08-14 17:40:02 UTC
Permalink
Post by Marc Haber
Post by Sven Hartge
Post by Marc Haber
On Tue, 14 Aug 2018 13:14:20 +0200, "Dirk S."
Post by Dirk S.
link-mtu 1472
mssfix 1472
Das scheint mir zu groß, dass der Tunelträger fragmentiert wird.
Zeig mal ein paar Zeilen tcpdump während einer größeren
Datenübertragung.
Das braucht man eigentlich nur, wenn jemand ICMP zwischen zwei
OpenVPN-Knoten kaputt gemacht hat. Sonst findet OpenVPN den besten
Parameter selbst heraus.
Das kann ich leider nicht bestätigen :-(
Dann habe ich bisher Glück gehabt.

Wobei ich zugeben muss, dass ich nur innerhalb von AS680 unterwegs bin,
nur Netz-zu-Netz-VPN-Strecken habe und beide Seiten unter Kontrolle
habe.

Also eine eher seltenere Situation, schon gar kein Road-Warrior-Setup.


--
Sigmentation fault. Core dumped.
Dirk S.
2018-08-14 17:10:02 UTC
Permalink
Post by Marc Haber
Das scheint mir zu groß, dass der Tunelträger fragmentiert wird. Zeig
mal ein paar Zeilen tcpdump während einer größeren Datenübertragung.
Das musste ich noch nie machen. was muss ich dafür tun?

Ich hatte die Werte auch schon geringer (1360 und 1300), das hat keine
nennenswerte Verbesserung gebracht. Trotz nicht nennenswerter
Systemlast und keinerlei anderer Belastung der Leitungen ist das immer
so.

ciao, Dirk
Sven Hartge
2018-08-14 16:30:02 UTC
Permalink
Post by Dirk S.
Mehr habe ich nicht herausbekommen, und das ist bisher schon den
- cipher "nur" Blowfish"
Sofern deine CPU nicht aus dem letzten Jahrzehnt ist, ist AES auch nicht
langsamer, teilweise sogar schneller, weil OpenSSL die Berechnungen mit
speziellen CPU-Befehlen machen kann.
Post by Dirk S.
link-mtu 1472
mssfix 1472
Brauchst du das? Wenn nein: Weglassen.
Post by Dirk S.
sndbuf 0
rcvbuf 0
push "sndbuf 393216"
push "rcvbuf 393216"
Wo hast du diese spezifischen Werte her? Der Betriebssystem-Default
sollte sowohl für TCP wie auch UDP korrekt sein, vor allem da zu große
Werte auch wieder den gegenteiligen Effekt haben.

https://community.openvpn.net/openvpn/ticket/461#comment:17

Von welcher OpenVPN-Version reden wir?



--
Sigmentation fault. Core dumped.
Dirk S.
2018-08-14 20:10:01 UTC
Permalink
Post by Sven Hartge
Post by Dirk S.
Mehr habe ich nicht herausbekommen, und das ist bisher schon den
- cipher "nur" Blowfish"
Sofern deine CPU nicht aus dem letzten Jahrzehnt ist, ist AES auch nicht
langsamer, teilweise sogar schneller, weil OpenSSL die Berechnungen mit
speziellen CPU-Befehlen machen kann.
"Gefühlt" bringt das noch ein wenig Geschwindigkeit. Das Problem ist
sicher nicht mein Heimserver, dass ist irgendein Athlon DualCore, der
dümpelt bei einer openVPN-Übertragung mit maximal 7%-Last vor sich hin.
Ich hatte nur den Eindruck, dass das vielleicht auf Client-Seite
(vorwiegend Smartphones mit Android und Snapdragon Prozessor) hilfreich
sein könnte.
Post by Sven Hartge
Post by Dirk S.
link-mtu 1472
mssfix 1472
Brauchst du das? Wenn nein: Weglassen.
Weiss ich nicht. Problem: es gibt kaum spürbare Unterschiede, wenn ich
die Werte ändere. Ich müsste theoretisch ja mindestens 5MB/s
hinbekommen (wenn ich mal den Uplink meiner Leitung als begrenzenden
Faktor nehme), bekomme aber nie mehr als 2,4MB/s hin.
Post by Sven Hartge
Post by Dirk S.
sndbuf 0
rcvbuf 0
push "sndbuf 393216"
push "rcvbuf 393216"
Wo hast du diese spezifischen Werte her? Der Betriebssystem-Default
sollte sowohl für TCP wie auch UDP korrekt sein, vor allem da zu große
Werte auch wieder den gegenteiligen Effekt haben.
Internet. Wenn ich das nicht einsetze, verringert sich die
Übertragungsgeschwindigkeit nochmal rapide um den Faktor 10 (was der
Anlass für meine Problemsuche war). Die "push"-Werte sind wohl nicht
unbedingt notwendig, das Setzen der lokalen Buffer auf Null (was
bewirkt, dass die Kernel-Defaultwerte genommen werden) aber sehr wohl.
Post by Sven Hartge
https://community.openvpn.net/openvpn/ticket/461#comment:17
AES-256 ist hier spürbar langsamer als AES-128. Der Umstieg auf BF
bringt dann nur noch ein Quäntchen.
Ich habe aber leider keine Gigabit-Verbindung, sondern VDSL50
serverseitig und auf den Mobilgeräten das, was gerade zur Verfügung
steht.
Aber: selbst mit quasi kaum begrenzter Bandbreite (sehr schnell
angebundenes free WiFi oder auch 4G) komme ich eben nicht über 2,5MB/s.
Das ist dann auch nur eine "Spitze", der Wert pendelt sich meist bei
ca. 1,6MB/s ein.
Post by Sven Hartge
Von welcher OpenVPN-Version reden wir?
Die, die in stable drin ist; 2.4.0-6+deb9u2
Ich könnte problemlos noch auf die 2.4.4-2~bpo9+1 von backports.org
aufrüsten, aber ob das so viel bringt? Das Problem bestand auch schon
mit oldstable, irgendwie ist die Performance von openVPN einfach
grundlegend "bescheiden".


ciao, Dirk
Sven Hartge
2018-08-14 21:10:02 UTC
Permalink
Post by Dirk S.
Ich könnte problemlos noch auf die 2.4.4-2~bpo9+1 von backports.org
aufrüsten, aber ob das so viel bringt? Das Problem bestand auch schon
mit oldstable, irgendwie ist die Performance von openVPN einfach
grundlegend "bescheiden".
Nicht wirklich.

Ich push $hier knapp 300MBit/s über eine OpenVPN-Strecke, dann ist die
Anbindung des Standortes voll. Allerdings sind auf beiden Seiten Server
und die Latenz liegt nicht über 8ms.


--
Sigmentation fault. Core dumped.
Micha Beyer
2018-08-14 21:10:02 UTC
Permalink
Hallo Dirk,

am 14.08.2018 um 13:14 schriebst Du:

[...]
Post by Dirk S.
Aus einem befreundeten WLAN (Unitymedia 36/1Mbit) bekomme ich als
upload zum Server gar nur ca. 178KB/s hin. Das ist irgendwie viel zu
wenig.
Warum soll denn das zu wenig sein?

Upload aus fremden WLAN - 1MBit / 8 = 128kByte/s
Da sind 178KB/s doch super, oder?

Ich mache Datensicherung per DSL 25/5MBit nach extern und komme auf
einen konstanten Datenstrom von ca.500KByte/s. Auch nach 17GB beim
Full-Backup läuft nichts aus dem Ruder.

Mfg,
Michael

Loading...