Geschwindigkeitsunterschiede Verschlüsselung OpenVPN vs. HTTPS
Moin-Moin!
Ich habe hier ein Phänomen, für das es vermutlich ein simple Erklärung gibt, die ich aber einfach nicht sehe.
Gegeben ist ein OpenVPN-Client, der auf einem Linux auf einer zugegebenermaßen relativ alten Hardware (Intel Atom 1.8 GHz, kein AES-NI) läuft.
Dieser arbeitet mit AES-128-GCM + SHA256 über UDP. Die inner-Tunnel MTU steht auf 1440 Bytes, so dass nicht fragmentiert werden muss.
Fragmentierung und Kompression sind auch ohnehin auf Client und Server ausgeschaltet.
Der OpenVPN-Server steht im gleichen Netzwerk und hängt am gleichen Switch, hat aber eine moderne CPU mit AES-NI zur Verfügung.
Jetzt baue ich also den Tunnel zum Server auf und stelle fest, dass der Client maximal 70-80 Mbps Datendurchsatz schafft. Die CPU-Last auf dem Client liegt derweil bei knapp 60% auf einem Kern - da wäre also theoretisch noch Luft. Der Server hat gerade einmal maximal 10% CPU-Last.
Ich frage mich also: Warum ist hier OpenVPN so furchtbar langsam?
Mein erster Gedanke war, dass die CPU nicht schnell genug ver- oder entschlüsseln kann.
Lade ich nun aber vom gleichen Server - nur ohne den Tunnel - per HTTPS eine Datei herunter, erreiche ich ca. 900 Mbps.
Der Cipher ist dabei ebenfalls AES-128-GCM und SHA256.
Mein zweiter Gedanke war, dass das mit dem Transport über UDP zu tun hat und da vielleicht anders Ver-/Entschlüsselt wird. So habe ich also testweise den Tunnel via TCP aufgebaut - wenig Überraschend ohne Verbesserung.
Und dann habe ich mal einen anderen Client verwendet: Ein Notebook mit Core i7, erste Generation, 1.6 GHz, ebenfalls ohne AES-NI.
Dieser Client kommt per OpenVPN auf immerhin deutlich über 300 Mbps, dann schlägt ein CPU-Kern auf 100% Last an.
Allerdings kann auch dieser Client mit Quasi-Gigabit per HTTPS problemlos herunterladen.
Und jetzt stehe ich hier und überlege, warum der gleiche Cipher mit gleichem HMAC bei HTTPS schnell genug ist, um das Gigabit-Netzwerk auszulasten - aber bei OpenVPN kaum über 300 Mbps herauskommen.
Bleibt also nur OpenVPN als Schuldiger, wo ich nun einfach vermute, dass ich zu doof bin, das Teil auf Performance zu optimieren.
Oder ich habe einen schlimmen Denkfehler, was die Vergleichbarkeit der Ciphers angeht
Hat hier eventuell jemand einen Tipp, was ihr Server- oder Clientseitig bei OpenVPN so üblicherweise konfiguriert, wenn ihr mehr als die müden 70 Mbps Durchsatz haben wollt?
Danke!
Ich habe hier ein Phänomen, für das es vermutlich ein simple Erklärung gibt, die ich aber einfach nicht sehe.
Gegeben ist ein OpenVPN-Client, der auf einem Linux auf einer zugegebenermaßen relativ alten Hardware (Intel Atom 1.8 GHz, kein AES-NI) läuft.
Dieser arbeitet mit AES-128-GCM + SHA256 über UDP. Die inner-Tunnel MTU steht auf 1440 Bytes, so dass nicht fragmentiert werden muss.
Fragmentierung und Kompression sind auch ohnehin auf Client und Server ausgeschaltet.
Der OpenVPN-Server steht im gleichen Netzwerk und hängt am gleichen Switch, hat aber eine moderne CPU mit AES-NI zur Verfügung.
Jetzt baue ich also den Tunnel zum Server auf und stelle fest, dass der Client maximal 70-80 Mbps Datendurchsatz schafft. Die CPU-Last auf dem Client liegt derweil bei knapp 60% auf einem Kern - da wäre also theoretisch noch Luft. Der Server hat gerade einmal maximal 10% CPU-Last.
Ich frage mich also: Warum ist hier OpenVPN so furchtbar langsam?
Mein erster Gedanke war, dass die CPU nicht schnell genug ver- oder entschlüsseln kann.
Lade ich nun aber vom gleichen Server - nur ohne den Tunnel - per HTTPS eine Datei herunter, erreiche ich ca. 900 Mbps.
Der Cipher ist dabei ebenfalls AES-128-GCM und SHA256.
Mein zweiter Gedanke war, dass das mit dem Transport über UDP zu tun hat und da vielleicht anders Ver-/Entschlüsselt wird. So habe ich also testweise den Tunnel via TCP aufgebaut - wenig Überraschend ohne Verbesserung.
Und dann habe ich mal einen anderen Client verwendet: Ein Notebook mit Core i7, erste Generation, 1.6 GHz, ebenfalls ohne AES-NI.
Dieser Client kommt per OpenVPN auf immerhin deutlich über 300 Mbps, dann schlägt ein CPU-Kern auf 100% Last an.
Allerdings kann auch dieser Client mit Quasi-Gigabit per HTTPS problemlos herunterladen.
Und jetzt stehe ich hier und überlege, warum der gleiche Cipher mit gleichem HMAC bei HTTPS schnell genug ist, um das Gigabit-Netzwerk auszulasten - aber bei OpenVPN kaum über 300 Mbps herauskommen.
Bleibt also nur OpenVPN als Schuldiger, wo ich nun einfach vermute, dass ich zu doof bin, das Teil auf Performance zu optimieren.
Oder ich habe einen schlimmen Denkfehler, was die Vergleichbarkeit der Ciphers angeht
Hat hier eventuell jemand einen Tipp, was ihr Server- oder Clientseitig bei OpenVPN so üblicherweise konfiguriert, wenn ihr mehr als die müden 70 Mbps Durchsatz haben wollt?
Danke!
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 645158
Url: https://administrator.de/contentid/645158
Ausgedruckt am: 02.11.2024 um 20:11 Uhr
18 Kommentare
Neuester Kommentar
hallo
wie testet du den VPN speed?
denke den link kennst du - https://community.openvpn.net/openvpn/wiki/Gigabit_Networks_Linux
wie sieht deine config aus?
speziel folgende werte:
sndbuf +rcvbuf
wie testet du den VPN speed?
denke den link kennst du - https://community.openvpn.net/openvpn/wiki/Gigabit_Networks_Linux
wie sieht deine config aus?
speziel folgende werte:
sndbuf +rcvbuf
Hallo,
manchmal hat Umstellen auf das langsamere TCP geholfen, das Ganze schneller zu machen.
Ich habe aber nie genauer nachgeforscht, was die Provider da machen (Routing?)
Es gab auch auf manchen "Strecken" massive Verbinungsabbruchprobleme bei UDP - TCP hat geholfen und war eben auch schneller.
Nur so ein Suchgedanke ...
Fred
manchmal hat Umstellen auf das langsamere TCP geholfen, das Ganze schneller zu machen.
Ich habe aber nie genauer nachgeforscht, was die Provider da machen (Routing?)
Es gab auch auf manchen "Strecken" massive Verbinungsabbruchprobleme bei UDP - TCP hat geholfen und war eben auch schneller.
Nur so ein Suchgedanke ...
Fred
Nur so ein Suchgedanke ...
Das sind aber typische (MTU) Fragmentierungsprobleme die dann oft planlos versucht wird mit TCP zu "reparieren". Allein wegen des erheblich größeren Paket Overheads bei TCP kann man solche Spekulationen getrost in das Reich der IT Märchen verbannen. Mit "Provider Router" hat sowas auch nicht das Geringste zu tun. Ein Router arbeitet rein auch Layer 3 und was da über ihm im Layer 4 (UDP/TCP usw.) transportiert wird ist ihm vollkommen Wumpe. Eine IP Forwarding Entscheidung hat mit sowas logischerweise nicht das Geringste zu tun. Weis jeder Netzwerker auch selber.Abgesehen davon hat Kollege @LordGurke eine Fragmentierungs Thematik ja sicher ausgeschlossen.
Warum die Unterschiede oben so gravierend sind ist wirklich fraglich. Das Performance Dokument oben hat ja auch keine wirklich schlüssige Antwort.
Spannend wäre mal den Durchsatz des OVPN Tunnels ganz ohne Verschlüsselung zu messen wie es das Dokument macht um mal den genauen Unterschied zu sehen was rein nur durchs Tunneling verloren geht ?!
Hier ist dann sicher die Frage wieviel Performance das reine Enkapsulieren und Dekapsulieren der Frames in den UDP Tunnel ganz ohne Verschlüsselung fordert. Vermutlich treten da schon die gravierensten Verluste auf und die Verschlüsselung an sich ist nur marginal.
Das ist aber jetzt auch erstmal nur geraten, wäre aber für eine weitere Beurteilung mal ganz spannend....
Zitat von @aqui:
Nur so ein Suchgedanke ...
Das sind aber typische (MTU) Fragmentierungsprobleme die dann oft planlos versucht wird mit TCP zu "reparieren". Allein wegen des erheblich größeren Paket Overheads bei TCP kann man solche Spekulationen getrost in das Reich der IT Märchen verbannen.Das wäre auch mein erster Verdacht. Über TCP tunneln ist eher kontraproduktiv. Man soltle eher schauen, wie aqui es vorgeschlagen hat, ob es auch ohne encryption, so schlecht läuft. Wenn ja, dann mit MTU-Anpassungen schauen, ob das besser wird.
Die Umstellung auf TCP wirkt nur auf den ersten Blick geschwindigkeitsfördernd. Na gut, manche (Ärzte) ohne Ahnung doktern ja auch lieber an den Symptomen einer "Krankheit" als an den Ursachen herum.
lks
Hallo,
das liegt an der Enkapsulierung.
Die Daten werden in OpenVPN Paket reingesteckt und OpenVPN Paket selbst muss ja dann in den durch MTU vorgegebene Paketgröße in UDP Frame reinpassen. Folglich hat man ein eine gewisse Unterschied zwischen Brutto und Netto Durchsatz wenn man VPN Tunnel Benutzt.
MfG Heilgecht.
das liegt an der Enkapsulierung.
Die Daten werden in OpenVPN Paket reingesteckt und OpenVPN Paket selbst muss ja dann in den durch MTU vorgegebene Paketgröße in UDP Frame reinpassen. Folglich hat man ein eine gewisse Unterschied zwischen Brutto und Netto Durchsatz wenn man VPN Tunnel Benutzt.
MfG Heilgecht.
Zitat von @heilgecht:
Hallo,
das liegt an der Enkapsulierung.
Die Daten werden in OpenVPN Paket reingesteckt und OpenVPN Paket selbst muss ja dann in den durch MTU vorgegebene Paketgröße in UDP Frame reinpassen. Folglich hat man ein eine gewisse Unterschied zwischen Brutto und Netto Durchsatz wenn man VPN Tunnel Benutzt.
Hallo,
das liegt an der Enkapsulierung.
Die Daten werden in OpenVPN Paket reingesteckt und OpenVPN Paket selbst muss ja dann in den durch MTU vorgegebene Paketgröße in UDP Frame reinpassen. Folglich hat man ein eine gewisse Unterschied zwischen Brutto und Netto Durchsatz wenn man VPN Tunnel Benutzt.
Deswegen muß man die MTU anpassen, damit das nicht passiert..
lks
Fragmentierungs Probleme hat Kollege @LordGurke aber ja oben explizit ausgeschlossen. Das ist also nicht der Punkt hier !!
Bleibt die spannende Frage nach der reinen En- und Dekapsulierungs Performance in das Tunnelframe Protokoll ohne Verschlüsselung und wie da der Durchsatz aussieht im Vergleich zur Verschlüsselung ?! OK, LG war schneller...
Gut 100Mbps ist ja nun auch nicht der Brüller zeigt aber m.E. dann deutlich das der Großteil der Performance dann in der En- und Dekapsulierung verbraten wird und die reine Verschlüsselung an sich marginal ist.
Bleibt die spannende Frage nach der reinen En- und Dekapsulierungs Performance in das Tunnelframe Protokoll ohne Verschlüsselung und wie da der Durchsatz aussieht im Vergleich zur Verschlüsselung ?! OK, LG war schneller...
Gut 100Mbps ist ja nun auch nicht der Brüller zeigt aber m.E. dann deutlich das der Großteil der Performance dann in der En- und Dekapsulierung verbraten wird und die reine Verschlüsselung an sich marginal ist.
Hallo,
ich beobachte Ähnliches, wenn ich z.B. einen reversen Proxy über HTTPS anspreche und der die Daten dann (ebenfalls über HTTPS) von einem internen Webserver zieht.
In dem Zusammenhang wurde mir an allen Ecken und Enden geraten, auf die Verschlüsselung zwischen dem Proxy und dem lokalen Server zu verzichten - was die Performance nahezu verdoppelt hat.
Es hieß immer: "Doppelte Verschlüsselung ist zu vermeiden". Vielleicht ist das hier ebenfalls der Fall?
Gruß,
Jörg
ich beobachte Ähnliches, wenn ich z.B. einen reversen Proxy über HTTPS anspreche und der die Daten dann (ebenfalls über HTTPS) von einem internen Webserver zieht.
In dem Zusammenhang wurde mir an allen Ecken und Enden geraten, auf die Verschlüsselung zwischen dem Proxy und dem lokalen Server zu verzichten - was die Performance nahezu verdoppelt hat.
Es hieß immer: "Doppelte Verschlüsselung ist zu vermeiden". Vielleicht ist das hier ebenfalls der Fall?
Gruß,
Jörg
Hallo,
ich hatte das so verstanden dass er HTTPS Seiten durch einen verschlüsselten Tunnel zieht.
Gruß,
Jörg
ich hatte das so verstanden dass er HTTPS Seiten durch einen verschlüsselten Tunnel zieht.
Gruß,
Jörg
Da es ein Linuxsystem ist, kann man ja mal schön debuggen
perf ich ein schönes tool, mit dem man mal anfangen kann, wobei perf selbst natürlich performance nimmt und dadurch alles langsamer ist
(alles mit root rechnten ausführen) mit:
bekommst du einen high level overview welche lib + function am meisten cpu benötigt, so kann man schonmal sehen ob z.B. eher die crypto oder der netzwerkstack am meisten benötigen bzw. wie das verhältnis ist.
Mit Enter kannst du tiefer in den prozess eintauchen und schauen welche komponenten was wieviel brauchen.
Wenn du am Buffer experementierst hilft sicher ein echtzeitblick auf die UDP buffers, zu finden unter:
Wenn der Filetransfer eine weile geht, könnte man mit dem recht trivialen einzeiler eine art udp buffer task-manager basteln:
(sehr doof, aber should get the job done)
MFG
N-Dude
perf ich ein schönes tool, mit dem man mal anfangen kann, wobei perf selbst natürlich performance nimmt und dadurch alles langsamer ist
(alles mit root rechnten ausführen) mit:
perf top -g
Mit Enter kannst du tiefer in den prozess eintauchen und schauen welche komponenten was wieviel brauchen.
Wenn du am Buffer experementierst hilft sicher ein echtzeitblick auf die UDP buffers, zu finden unter:
cat /proc/net/udp
Wenn der Filetransfer eine weile geht, könnte man mit dem recht trivialen einzeiler eine art udp buffer task-manager basteln:
while :; do cat /proc/net/udp | awk '{print $5 " " $6}';sleep 1; clear; done
MFG
N-Dude