openVPN unter Stretch IMO viel zu langsam - was tun?

[dirk11]

Guten Abend liebe Leute!

Ich habe hier leider ein großes Geschwindigkeits-Problem mit dem openVPN-Server auf meinem Heimserver, auf welchen mobile Clients Zugriff haben, um Daten abzuspeichern oder herunterzuladen. Ich versuche mich mal in einer strukturierten Beschreibung, vielleicht weiß ja jemand Rat:

Gegeben:
- 50/10 MBit DSL-Leitung der Telekom (Sync passt, die nominellen Geschwindigkeiten werden prinzipiell auch erreicht)
- openVPN aus Debian Stretch auf Debian Stretch (sprich kein BPO o.ä.)
- diverse mobile Endgeräte (Smartphones und Tablets) unter Android

Auf dem Server ist in iptables Port 1194 "offen", auf dem openWRT-Router (Buffalo Airstation) wird Port 1194 UDP durchgeleitet zum Heimserver.

Die mobilen Devices (ganz selten mehr als drei gleichzeitig) verbinden sich via UDP TUN auf dem Standard-Port 1194 mit dem Heimserver. Die Verbindung selbst funktioniert auch grundsätzlich einwandfrei.

Problem:
Die Geschwindigkeit, um etwas vom Heimserver auf das Mobildevice zu bekommen, ist viel zu gering. Hinterlege ich auf dem Server eine "normale" Datei zum Download (wget oder was auch immer), so bekomme ich 1-1,15MB/s als Datenrate hin, wenn ich mir die von dort herunterlade. Probiere ich dasselbe über VPN, komme ich häufig (also nicht immer) nur auf 50kB/s!

Ich habe schon ziemlich viel gelesen und ausprobiert, aber irgendwie komme ich auf keinen grünen Zweig, sprich es wird und wird nicht dauerhaft schneller!

Gibt es vielleicht noch Optimierungs-Möglichkeiten, oder mache ich etwas grundlegend falsch?

Die einzigen zwei Fehler- Warn-Meldungen, die zur Zeit im syslog erscheinen, sind IMHO vernachlässigbar:

Code: Alles auswählen

Nov 13 08:06:01 server ovpn-server-udp[3532]: fon/101.162.141.11:39542 WARNING: 'link-mtu' is used inconsistently, local='link-mtu 1557', remote='link-mtu 1524'
Nov 13 08:06:01 server ovpn-server-udp[3532]: fon/101.162.141.11:39542 WARNING: 'cipher' is used inconsistently, local='cipher AES-256-CBC', remote='cipher AES-256-GCM'
Nov 13 08:06:01 server ovpn-server-udp[3532]: fon/101.162.141.11:39542 Data Channel Encrypt: Cipher 'AES-256-GCM' initialized with 256 bit key

Die zweite Meldung sollte in Zukunft obsolet sein, da ich mittlerweile in Client- und Server-Config auf AES-256-GCM gewechselt habe.

Server-Config:

Code: Alles auswählen

port 1194
proto udp
dev tun0
ca /etc/openvpn/easy-rsa/keys/ca.crt
cert /etc/openvpn/easy-rsa/keys/server.crt
key /etc/openvpn/easy-rsa/keys/server.key
dh /etc/openvpn/easy-rsa/keys/dh2048.pem
server 10.2.0.0 255.255.255.0
push "route 192.168.1.0 255.255.255.0"
client-config-dir ccd
client-to-client
keepalive 10 120
tls-auth ta.key 0
cipher AES-256-GCM
max-clients 10
persist-key
persist-tun
status openvpn-status.log
verb 3
topology subnet
push "topology subnet"
tls-server
remote-cert-tls client
script-security 2
auth-user-pass-verify /etc/openvpn/auth-new.pl via-file

fast-io
sndbuf 0
rcvbuf 0
push "sndbuf 393216"
push "rcvbuf 393216"

Ohne die beiden letzten Zeilen sndbuf und rcvbuf hat es überhaupt nie in ausreichender Geschwindigkeit funktioniert, überhaupt funktioniert alles erst akzeptabel, seitdem ich von TCP auf UDP umgestellt habe und die Zeilen ab "fast-io" in der Server-Config hinzugefügt habe.

Client-Config:

Code: Alles auswählen

dev tun
proto udp
remote meinserver.de
client
ifconfig 10.2.0.88 10.2.0.1
cipher AES-256-GCM
auth-user-pass
persist-tun
persist-key
verb 3
remote-cert-tls server
ns-cert-type server
tls-client
fast-io

[unitra]

Das ist kritisch:

Code: Alles auswählen

Nov 13 08:06:01 server ovpn-server-udp[3532]: fon/101.162.141.11:39542 WARNING: 'link-mtu' is used inconsistently, local='link-mtu 1557', remote='link-mtu 1524'

Das wird einer der Gründe sein um die Perfomanceeinbußen. Ohne langes Gerede, MTU 1557 oder MTU 1524 ist außerhalb des Standard-Ethernetframes. Ethernetrahmen haben per default 1518 Byte, IP Packete im WAN haben eine maximale MTU Size von 1500 Byte, in 99% der Fälle, auf die Sonderfälle der IP MTU gehe ich hier nicht ein denn es trifft ganz sicher in Deiner Konfiguraton nicht zu.
Bei TCP Segmenten, sollte die MSS (Maximum Segment Size) gesetzt werden zwischen 1300 und 1400 Byte. Da UDP eingesetzt wird, erst einmal bei UDP bleiben. Wenn es nichts bringt, ändere es auf TCP.

Weitere Lektüre bezüglich IP MTU und TCP MSS size:
https://forums.openvpn.net/viewtopic.php?t=25039

Weiter Lektüre bezüglich der verfügbaren Optionen.
https://community.openvpn.net/openvpn/w ... n24ManPage

Und hier gibt es auch die

Code: Alles auswählen

--mtu-test

um die MTU zu testen.

Zusätzlich wenn die MTU Meldungen weg sind und Perfomanceeinbußen weiterhin bestehen, wenn der Tunnelendpunkt schwachbürstig und/oder der OpenVPN Client und die Verschlüsselung zu hart ist, wird das auch zu Perfomanceinbußen führen.

Wichtig beim debuggen, ändere immer nur eine einzige Option, dann Testen. Nicht alle Knöpfe auf einmal ändern, dann weisst Du nicht was wozu geführt hat.

Verzeihe ich kann nur Ethernet, IP und TCP Konfigurationen verifizieren, bezüglich spezifischer OpenVPN Konfigurationen bin ich überfragt, da können bestimmt ander im Forum mehr dazu sagen.

Viel Erfolg.

[dirk11]

Das ist kritisch:

Code: Alles auswählen

Nov 13 08:06:01 server ovpn-server-udp[3532]: fon/101.162.141.11:39542 WARNING: 'link-mtu' is used inconsistently, local='link-mtu 1557', remote='link-mtu 1524'

Das wird einer der Gründe sein um die Perfomanceeinbußen. Ohne langes Gerede, MTU 1557 oder MTU 1524 ist außerhalb des Standard-Ethernetframes. Ethernetrahmen haben per default 1518 Byte, IP Packete im WAN haben eine maximale MTU Size von 1500 Byte, in 99% der Fälle, auf die Sonderfälle der IP MTU gehe ich hier nicht ein denn es trifft ganz sicher in Deiner Konfiguraton nicht zu.
Bei TCP Segmenten, sollte die MSS (Maximum Segment Size) gesetzt werden zwischen 1300 und 1400 Byte. Da UDP eingesetzt wird, erst einmal bei UDP bleiben. Wenn es nichts bringt, ändere es auf TCP.

Vielen Dank schonmal!
Ehrlich gesagt verstehe ich das mit der optimalen link-mtu aber nicht wirklich. Auf die Client-seitige Verbindung habe ich sowieso nie Einfluss, die ist immer unterschiedlich: diverse Mobilfunkprovider, unterschiedlichste WLANse.
Ich kann also nur die Server-Seite sicher beeinflussen. Da habe ich jetzt mal

Code: Alles auswählen

ping -s 1464 -c 4 -M do google.com

eingegeben (und natürlich vorher mit ein paar anderen Werten rumprobiert und mich an diesen Wert herangetastet). Diese "1464" ist offensichtlich für meinen Anschluss die korrekte Paketgröße, denn wenn man da die "üblichen" 28byte draufrechnet, kommt man auf 1492, welche laut kurzer Recherche wohl bei der Telekom bei derartigen Anschlüssen korrekt sind.

Nur:
trage ich jetzt in die Server-Config link-mtu 1464 ein? Oder muss ich da noch was runter- oder draufrechnen? Und muss ich andere Werte auch noch anpassen? Ich habe mal einfach probehalber link-mtu 1464 eingetragen und den Server restartet, damit kommt dann eine neue Warning-Meldung:

Code: Alles auswählen

WARNING: normally if you use --mssfix and/or --fragment, you should also set --tun-mtu 1500 (currently it is 1343)

Und jetzt habe ich mal probehalber eine Verbindung von einem Smartphone via 4G aufgebaut, da bekomme ich dann folgende Warn-Meldungen im syslog des Server:

Code: Alles auswählen

WARNING: normally if you use --mssfix and/or --fragment, you should also set --tun-mtu 1500 (currently it is 1343)
WARNING: 'link-mtu' is used inconsistently, local='link-mtu 1464', remote='link-mtu 1557'
WARNING: 'tun-mtu' is used inconsistently, local='tun-mtu 1343', remote='tun-mtu 1500'

Ich muss also wohl doch auf Server- und Client-Seite gleiche Werte in die Config eintragen, nur: was nehme ich da? Ich habe ja wie gesagt keinerlei Einfluss auf die Client-Verbindung.

[dirk11]

Soo, guten Morgen!

Bitte einfach das letzte posting nicht beachten, ich habe mir mal Augenringe produziert und mal wieder "etwas" länger davorgesessen...

Ergebnis bis jetzt:

Auf Server und Client cipher AES-128-CBC eingetragen. Aus mir vollkommen unverständlichen Gründen wird damit zwar beim Verbindungsaufbau dennoch

Code: Alles auswählen

Nov 14 02:53:12 server ovpn-server-udp[20357]: fon/101.162.141.11:38928 Data Channel Encrypt: Cipher 'AES-256-GCM' initialized with 256 bit key

gemeldet, aber dafür gibt es keinerlei Fehler- oder Warnmeldungen diesbezüglich mehr.
Außerdem, wenn die Verbindung mal automatisch neu aufgebaut werden muss:

Code: Alles auswählen

Nov 14 04:23:37 server ovpn-server-udp[20357]: 101.162.141.11:39064 Control Channel: TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 2048 bit RSA

Warum mir dennoch AES-256-GCM gemeldet wird, verstehe ich nicht, ist aber auch fast egal, so lange alles fehlermeldungsfrei funktioniert.


Auf dem Server noch link-mtu 1464 in die Config eingetragen, auf dem Client hingegen tun-mtu 1407.
Das bewirkt, daß die Fehlermeldung

Code: Alles auswählen

Nov 14 02:08:09 server ovpn-server-udp[20357]: 101.162.141.11:30034 WARNING: 'link-mtu' is used inconsistently, local='link-mtu 1464', remote='link-mtu 1549'

[/color] vollständig verschwindet und es nur noch eine Fehlermeldung bzgl. der tun-mtu gibt:

Code: Alles auswählen

Nov 14 02:13:20 server ovpn-server-udp[20357]: 101.162.141.11:42396 WARNING: normally if you use --mssfix and/or --fragment, you should also set --tun-mtu 1500 (currently it is 1343)
Nov 14 02:24:25 server ovpn-server-udp[20357]: 101.162.144.91:39122 WARNING: 'tun-mtu' is used inconsistently, local='tun-mtu 1343', remote='tun-mtu 1407'

Die erste Warnmeldung kommt eigentlich sowieso immer. Bitte die Timestamps nicht beachten.

Was mir aber aufgefallen ist: keine großartigen Verbesserungen in der Performance.

[eggy]

Warum stellst Du unterschiedliche MTU ein? Nimm mal den kleineren der beiden Werte.

[dirk11]

Warum stellst Du unterschiedliche MTU ein? Nimm mal den kleineren der beiden Werte.

Das habe ich doch geschrieben - ist das in dem Wust der Meldungen untergegangen!?
Weil dann die eine Fehlermeldung

Code: Alles auswählen

Nov 14 02:08:09 server ovpn-server-udp[20357]: 101.162.141.11:30034 WARNING: 'link-mtu' is used inconsistently, local='link-mtu 1464', remote='link-mtu 1549'

komplett verschwindet! Mache ich das nicht, habe ich diese Fehlermeldung (bzw. Warn-Meldung) mehr, woraus ich den logischen Schluss ziehe, dass meine Idee richtiger ist als Deine.

[eggy]

Nö, untergegangen ist es nicht. Nur hilft planloses rumdoktern auch nicht viel. Du stellst hier auf dem einen Gerät für Stellschraube A nen Wert x ein und auf dem anderen Gerät an der Stellschraube B dann y ein. Klar hängen die zusammen, trotzdem wäre es sinnvoller einen der beiden Werte auf beiden Seiten richtig zu setzen. Zur Info: link-mtu != tun-mtu, auch wenn zumindest die eine von der anderen abhängt.

[dirk11]

Nur hilft planloses rumdoktern auch nicht viel.

Absolute Zustimmung, aber es gibt wenig wirklich aussagekräftige Hilfestellung dazu im Netz (genau genommen überhaupt keine). Zumindest habe ich keine gefunden, die zu Ende gedacht wurde.
Und es ist ja auch kein vollkommen "planloses rumdoktern", sondern zumindest systematische Vorgehensweise.

Du stellst hier auf dem einen Gerät für Stellschraube A nen Wert x ein und auf dem anderen Gerät an der Stellschraube B dann y ein. Klar hängen die zusammen,

Und genaus deshalb habe ich das so gehandhabt. Mir ist aufgefallen, daß ich auf dem Server link-mtu setze und wenn ich dann auf dem Client tun-mtu setze, die vom Client gewählte link-mtu davon abhängt, wie ich den tun-mtu-Wert wähle. Und mit ein wenig Probieren kommt man dann eben an die Stelle, wo link-mtu von Server und Client miteinander korrelieren.
Ich bin mir noch nichtmal sicher, ob meine Annahme, daß ich auf meinem Heimserver (hinter VDSL-Modem und Router) 1464 als link-mtu setzen muss, um die maximale mtu von 1492 zu erreichen, korrekt ist, oder ob ich dabei LAN-Protokoll-overhead übersehe. Aber da der ping-Befehl bei genau dem Wert nicht mehr fragmentiert, war meine Schlussfolgerung, dass das wohl so korrekt ist.

trotzdem wäre es sinnvoller einen der beiden Werte auf beiden Seiten richtig zu setzen.

Ja, feine Idee. Mögest Du mir einfach erklären, welche Werte ich wo korrekt zu setzen habe, damit ich gar keine Fehlermeldung mehr bekomme und die mtu-Werte optimal sind, dann mache ich das freilich sofort, denn das ist ja auch mein Ziel und deshalb habe ich ja mein Problem hier im Forum geschildert!

Zur Info: link-mtu != tun-mtu, auch wenn zumindest die eine von der anderen abhängt.

Das ist beides bekannt und trivial, denn wenn link-mtu=tun-mtu wäre, wäre ja einer der Parameter obsolet.

[Livingston]

... aber es gibt wenig wirklich aussagekräftige Hilfestellung dazu im Netz (genau genommen überhaupt keine). Zumindest habe ich keine gefunden, die zu Ende gedacht wurde.

Stimmt doch gar nicht: http://tcpipguide.com/
Wenn Du die grundlegenden Kapitel durch hast, wirst Du auch verstehen, was eine MTU ist, und dass die MTU für VPN-Links kleiner sein muss als die des nackten Interfaces.

[dirk11]

Wie witzig. Nicht.

Ich habe mein Problem nicht hier vorgestellt, um links auf nicht-hilfreiche englischsprachige allgemeingültige Webseiten-tutorials zu bekommen, sondern um konkrete Hilfe für mein konkret benanntes Problem zu bekommen. Hättest Du z.B. hierhin verlinkt, wäre das hilfreicher gewesen, obgleich mir diese Zusammenhänge durchaus schon bekannt sind.

Kleiner Hinweis: wenn Du nichts konkretes zur Problemlösung beitragen kannst oder möchtest, dann zwingt Dich auch niemand, etwas zu schreiben...

[eggy]

@dirk11: Dein Tonfall motiviert nicht grade Wissen mit Dir zu teilen.

[mat6937]

Server-Config:

Code: Alles auswählen

fast-io
sndbuf 0
rcvbuf 0
push "sndbuf 393216"
push "rcvbuf 393216"

Client-Config:

Code: Alles auswählen

fast-io

Versuch trotzdem noch mal ohne die Zeilen:

Code: Alles auswählen

fast-io
push "sndbuf 393216"
push "rcvbuf 393216"

auf dem Server und ohne die Zeile:

Code: Alles auswählen

fast-io

auf dem Client.

EDIT:

Teste mal auch mit iperf (oder mit iperf3) zwischen Server und Client.

[dirk11]

@dirk11: Dein Tonfall motiviert nicht grade Wissen mit Dir zu teilen.

@eggy: das resultiert daraus, dass Du eben gerade kein Wissen "geteilt" hast, sondern Dich nur dazu herabgelassen hast, mir einen wahllosen link zu einem TCP/IP-Tutorial vorzuwerfen. Googeln kann ich auch so leidlich...
Anders gesagt: das ist eine direkte Reaktion auf Deinen "Inhalt".

Ach ja: "Tonfall" gibt es im Schriftlichen nicht. Das entspricht Deiner Interpretation. Vielleicht auch mal drüber nachdenken, ob die Interpretation korrekt ist, wenn man selbst in so einem "Tonfall" schreibt.

[dirk11]

Versuch trotzdem noch mal ohne die Zeilen:

Code: Alles auswählen

fast-io
push "sndbuf 393216"
push "rcvbuf 393216"

auf dem Server und ohne die Zeile:

Code: Alles auswählen

fast-io

auf dem Client.

Vielen Dank! Ohne die Zeilen habe ich schon hinter mir, ich bekomme überhaupt erst hinreichend schnelle Verbindungen, wenn ich diese Zeilen nutze (die habe ich vor einigen Monaten schon gefunden und damit ausgiebige Tests gemacht, vorher hatte ich grundsätzlich nie über 100kB/s).

BTW:

Teste mal auch mit iperf (oder mit iperf3) zwischen Server und Client.

Ich kenne kein iperf für Android?

[eggy]

@dirk11: Dein Tonfall motiviert nicht grade Wissen mit Dir zu teilen.

@eggy: das resultiert daraus, dass Du eben gerade kein Wissen "geteilt" hast, sondern Dich nur dazu herabgelassen hast, mir einen wahllosen link zu einem TCP/IP-Tutorial vorzuwerfen. Googeln kann ich auch so leidlich...
Anders gesagt: das ist eine direkte Reaktion auf Deinen "Inhalt".

Abgesehen davon, dass ich KEINEN Link gepostet habe.
Willkommen auf meiner Ignoreliste.

[mat6937]

Ich kenne kein iperf für Android?

Dann hast Du nicht gesucht:

https://apkpure.com/iperf-for-android/c ... apps.iperf

BTW: Wenn Du diese Zeilen brauchst, dann ist das ein Android-Problem, denn mit einem Linux-OpenVPN-Server und einem Linux-OpenVPN-Client gibt es überhaupt kein Problem bzgl. Bandbreite via VPN-Tunnel, ohne diese Zeilen.

[dirk11]

Abgesehen davon, dass ich KEINEN Link gepostet habe.

Ups, entschuldige bitte, da habe ich tatsächlich etwas verwechselt! Mal davon abgesehen, dass Dein "geteiltes Wissen" sich auf eine Gegenfrage beschränkt hat... Aber das bekommst Du ja sowieso nicht mehr mit...

Willkommen auf meiner Ignoreliste.

Irgendwie merkwürdig, daß es immer der gleiche Typ "Forist" ist, der zwar exakt gar nix zum Thema beitragen kann, aber meint, über einen (selbst intendierten) "Ton" meckern zu können...

[dirk11]

Dann hast Du nicht gesucht:

Korrekt. Ich schrieb ja, ich kenne kein iperf für Android.

BTW: Wenn Du diese Zeilen brauchst, dann ist das ein Android-Problem, denn mit einem Linux-OpenVPN-Server und einem Linux-OpenVPN-Client gibt es überhaupt kein Problem bzgl. Bandbreite via VPN-Tunnel, ohne diese Zeilen.

Also die sndbuf- und rcvbuf-Zeilen beziehen sich definitiv auf Einstellungen am Server. Das hat wohl was mit dem Kernel zu tun, ich erinnere mich nicht mehr genau, was ich da vor einem Jahr gelesen habe.
Und es kann durchaus sein, daß das Problem auch aus Android stammt - ich nutze dort den "offiziellen" (?) openVPN-Client und importiere die Daten als .ovpn. Wie gesagt, die Verbindung funktioniert auf Anhieb, nur gab bzw. gibt es Geschwindigkeits-Probleme.
Warum z.B. ein mtu-mismatch entsteht, das verstehe ich nicht. Genausowenig verstehe ich aber, warum ich überhaupt eine mtu einstellen muss, ich bin eigentlich davon ausgegangen, dass opnVPN solcherlei Dinge z.B. beim handshake aushandelt. Macht es offensichtlich nicht, wieder was gelernt. Dennoch besteht noch das Problem des mismatch zwischen Server und Client, dessen Entstehung ich nicht verstehe.

[mat6937]

Genausowenig verstehe ich aber, warum ich überhaupt eine mtu einstellen muss, ich bin eigentlich davon ausgegangen, dass opnVPN solcherlei Dinge z.B. beim handshake aushandelt. Macht es offensichtlich nicht, wieder was gelernt.

Doch, macht es. Du musst keine mtu für das tun-Interface einstellen. Z. B. hier die mss beim handshake (ohne Konfiguration der mtu in den config-Dateien):

Code: Alles auswählen

18:21:14.540430 ip: (tos 0x0, ttl 64, id 41270, offset 0, flags [DF], proto TCP (6), length 56)
    10.4.0.6.46742 > 10.4.0.1.5001: Flags [S], cksum 0xa66e (correct), seq 2253365147, win 29200, options [mss 1460,sackOK,TS val 605869 ecr 0], length 0
    
18:21:14.563431 ip: (tos 0x0, ttl 56, id 0, offset 0, flags [DF], proto TCP (6), length 48)
    10.4.0.1.5001 > 10.4.0.6.46742: Flags [S.], cksum 0x474e (correct), seq 4134588235, ack 2253365148, win 29200, options [mss 1358,nop,nop,sackOK], length 0

[dirk11]

Doch, macht es. Du musst keine mtu für das tun-Interface einstellen.

Mhmmja, aber wie passt das zu meinem log? Wieso ist die link-mtu erst dann auf beiden Seiten identisch, wenn ich am Server link-mtu und am Client tun-mtu einstelle? Andere Varianten haben nicht funktioniert.

[mat6937]

Mhmmja, aber wie passt das zu meinem log?

Das passt gar nicht zu deinem log und das ist auch gut so, denn Du hast ja in deinen configs, link-mtu bzw. tun-mtu konfiguriert und ich nicht.

[dirk11]

Vielleicht stehe ich ja gerade auf der Leitung, aber die Antwort verstehe ich nicht.

[mat6937]

Vielleicht stehe ich ja gerade ...

Hast Du zum testen, einen OpenVPN-Linux-Client, statt den Android? Wenn ja, dann teste mal ohne mtu-Eintrag und ohne die Zeilen:

Code: Alles auswählen

fast-io
push "sndbuf 393216"
push "rcvbuf 393216"

in den configs.

[dirk11]

Nein, zur Zeit leider nicht. Würde mir genau was bringen, außer Erkenntnisgewinn zu einer anderen Geräteklasse? Ich benötige das VPN ja genau für die Android-Geräte.

[mat6937]

Würde mir genau was bringen, außer Erkenntnisgewinn zu einer anderen Geräteklasse? Ich benötige das VPN ja genau für die Android-Geräte.

Dann kannst Du explizit darauf hinweisen, dass es _nur_ um Android-Geräte geht und es zwischen 2 Linux-Geräten (bzgl. Bandbreite) keine Probleme gibt.