OpenVPN zu langsam?

[herrhannes]

Moin,

Da das Routing von KabelBW nicht immer das beste zu sein scheint, habe ich mir auf meinem Root-Server in einem OpenVZ-Container einen OpenVPN-Server eingerichtet.
Nun habe ich da aber das Problem, dass ich nun nur noch 25MBit statt der vollen 32MBit, die meine Leitung schafft, übertragen bekomme.
Woran kann das liegen? Konfigurationsfehler? Oder muss ich damit leben?

Gruß
herrhannes

 

[UsAs]

Also ich kann mir schwerlich vorstellen, dass dieser Verlust alleine der Config geschuldet ist.

 

[herrhannes]

Aber woran liegt es? Overhead? Das müsste ich ja dann mit iftop sehen? Da ist aber nichts.
Manche berichten, dass KabelBW udp (zumindest auf dem Port 1194) drossele. Dafür erscheint es mir aber noch zu schnell.
CPU-Limit sollte ja auch noch nicht erreicht sein.

 

[UsAs]

Ich hätte jetzt auch Richtung Drosselung getippt. Hast du Vergleichwerte anderer User (in Zahlen)?

 

[herrhannes]

Nö, habe ich nicht.

 

[herrhannes]

Jetzt gerade ist es auch wieder etwas schneller:

(Der Upload ist natürlich Quatsch, habe nur 1MBit)
Der Speedtest ohne VPN war aber auch gestern Abend normal schnell (DL noch etwas höher, UL 1MBit).
Vielleicht wirklich eine Drosselung. Aber wieso so "hoch"?

 

[icebeer]

Es ist gibt für OpenVPN bei KabelBW keine Drosselung. Der Upload-Speed lässt eher darauf schließen, dass Du die Kompression eingeschaltet hast. Das bringt bei Leistungen <1 Mbit/s was, darüber eher nicht und erzeugt insb. auf Seiten des Servers nur mehr CPU-Last. Du bekommst sonst per OpenVPN mühelos auch 100 MBit/s ohne große Verluste durch (wie ich sie von KabelBW habe). Ich bezweifle aber, dass es sinnvoll ist auf das bessere Routing von Hetzner zu setzen. Die sind kaum besser bzw. eher schlechter als KabelBW selbst...

Ein richtig gutes Netzwerk und günstige Server haben übrigens Server4you und mit leichten Abstrichen auch OVH.

 

[ara1]

erwartest du ernsthaft dass du ne Verschlüsselung drüberlegst und die Performance zu 100% gleich bleibt? 30,5 von 32 ist doch ein sehr guter Wert (ja, ich habs schon nachgerechnet).

 

[herrhannes]

Meistens erreiche ich aber nur die 25MBit oder gar weniger.
Verschlüsselung, keine Ahnung ob die aktiv ist, habe die Standardconfig von OpenVPN leicht angepasst.
Könnte ich noch deaktivieren. Server ist ein i7 mit 8GB Ram, der sonst nicht viel zu tun hat. Der sollte auch mit Verschlüsselung 32MBit packen.
Dass die Latenz leidet, kann ich mir vorstellen aber wieso die Übertragungsrate?

 

[FLiNTx]

Ich mag mich jetzt vertuen, aber eigentlich ists doch ganz logisch...
Beispiel:
Du hast ein Förderband auf dem laufen 200 Kisten die Stunde durch - jede bepackt mit 1kg irgendwas... Durchsatz: 200 Kilo/Stunde...
Wenn du jetzt den Abstand zwischen den Kisten erhöhst (Latenz), sind das logischerweise weniger als 200 Kisten/Stunde - folglich sinkt effektiv dein Durchsatz ebenfalls auf unter 200kilo/Stunde...

 

[herrhannes]

Jein. Aber du erhöhst ja durch die Verschlüsselung nicht unbedingt den Abstand der Kisten, sondern packst die meinetwegen alle in eine große, versiegelte Kiste.
Bis der Kram ankommt dauert es also, es geht aber nicht unbedingt langsamer.
Es wird ja nicht jedes einzelne Paketchen einzeln da durch gejagt.

 

[FLiNTx]

Eben nicht - Du packst jede einzelne Kiste in eine Folie ein (verschlüsseln) und packst sie am andren Ende wieder aus (entschlüsseln)...

Wenn jetzt derjenige, der die Kisten einpackt mit dem verpacken und Abschicken der zweiten Kiste noch warten muss, bis du die erste Kiste ausgewickelt, die Antwort eingewickelt und zu ihm geschickt hast, kannst du dir ausmalen, dass so ein System doch irgendwie "träger" sein muss als ohne...

Mir fehlen die Erfahrungswerte um sagen zu können "25mbit/s VPN auf einer 32mbit Leitung sind okay" oder eben nicht - aber für mich klingt es völlig logisch und selbstverständlich, dass hier merklich weniger durch geht als durch die "nackige" Leitung...

 

[herrhannes]

Aber das tut er doch nicht? Falls ja, dann wäre es klar. Vermutlich würde da trotzdem der Overhead mehr ausmachen als die Latenzen.
(Bin kein Informatiker ) Aber auch dann sollte es ja keine 7-8Mbit fressen.
Falls doch, wäre es auch nicht so schlimm, dann könnte ich ja bequem resignieren.

 

[FLiNTx]

Aber das tut er doch nicht?

Jedes einzelne Datenpaket, dass du über die Leitung schickst, wird für das VPN verschlüsselt und am andren Ende wieder entschlüsselt - das ist ja der Sinn hinter der ganzen Übung...
Und dieses "Warten bis die nächste Kiste los geht" ist auch - ich sag mal - üblich... zwar stark vereinfacht ausgedrückt, aber prinzipiell korrekt - Kannst du hier nachlesen: TCP

 

[herrhannes]

Deswegen übertrage ich es ja schon einmal per UDP. Da habe ich den Quark mit Quittung etc. nämlich nicht.

 

[FLiNTx]

Du baust das VPN via UDP auf - aber das was da durch den Tunnel huscht kann ja trotzdem TCP sein...

 

[herrhannes]

Jo, und das muss es ja auch. Aber das wird dann doch nicht einzeln noch einmal "verpackt", wenn wir schon bei der Metapher sind.

 

[ara1]

doch, und das meinte ich mit meiner Andeutung "ich hab's ausgerechnet".

Siehe: Re: [Openvpn-users] Overhead added to each packet by OpenVPN?

> 3) Finally, and most importantly, how much overhead is
> added to each encrypted packet by OpenVPN? (i.e. How much additional per
> packet overhead is there for using OpenVPN?)

It varies depending on options. With a TUN-style tunnel over UDP using
the default TLS options, the per-packet overhead is:

41 bytes security layer overhead (includes packet tag (1), HMAC-SHA1
signature (20), initialization vector (16), sequence number (4))

28 bytes tunneling overhead (includes IP + UDP header)

Total: 69 bytes per packet

69 bytes pro Paket von 1500 bytes macht einen Overhead von 4,6%.

Die "fehlenden" 1,5mbit deiner Messung sind 4,68% der 32mbit, also genau wie zu erwarten war.

PS: Und das ist natürlich der Best Case. Wenn die MTU deiner Leitung < 1500 ist steigt natürlich der prozentuale Overhead an.

 

[herrhannes]

Ah. Prima, vielen Dank.
Dann scheint ja alles zu funktionieren.