Ich habe die Verschlüsselung schon von 256 auf 128 runtergesetzt, ohne erkennbaren Erfolg. Sollte ich da noch weiter runtergehen?
Habe den mtu Wert mal auf 1432 reduziert, mit subjektiv leicht erhöhter Geschwindigkeit(ca 1 MB/s). Vielleicht sollte ich diesen Wert noch weiter optimieren? Muss ich den Wert server- sowie clientseitig anpassen?
Bei der Option „fragment“ hatte ich gelesen, dass dann per ios keine Verbindung zum VPN mehr möglich sei, kann das stimmen?
Du schreibst, dass Openvpn generell nicht sehr „performant“ sei, sollte ich darüber nachdenken, einen anderen VPN Dienst zu nutzen? Kannst du da was empfehlen?
Ein PC oder Einplatinencomputer, der AES unterstützt, würde etwaige Prozessorengpässe für OpenVPN besser handeln. Wie stark Deine CPU während eines Datentransfers tatsächlich ausgelastet ist, darüber gibt Dir etwa „top“ Auskunft.
Zur MTU - wenn Du Deine beiden Endpunkte mit gesetztem Don't Fragment Flag pingst, erfährst Du den optimalen Wert: ping -Mdo -s1472 -c1 [openvpn-server-externe-ip] und von dort, soweit möglich, den Client in derselben Weise zu pingen, ermittelt den Maximalwert, den Du für Fragment einstellst. Wenn die Nutzlast von 1472 zu einem Timeout oder einer Antwort „message too big“ führt, pings sonst aber funktionieren, dann ist die MTU geringer als 1500 (1472 + 8 + 20). Da UDP und ICMP-Header gleich lang sind, können die Werte auf diese Weise leicht ermittelt werden.
In der Wildnis häufig anzutreffende Werte für die Nutzlast sind etwa: 1412, 1432, 1452, 1454, 1460, 1462 oder 1464 und eben 1472.
Mssfix in OpenVPN kann einen Sekundärparameter bekommen, benötigt ihn aber nicht zwingend. Afaik ist die MSS typischerweise MTU - 40 Byte.
Die Option wirkt sich allerdings nur auf TCP aus, nicht auf UDP. Siehe: https://de.wikipedia.org/wiki/Maximum_Segment_Size
Zu fragment und ios kann ich nichts sagen, aber, wenn tun-mtu als Parameter verwendet wird, soll laut OpenVPN-Dokumentation stets auch fragment verwendet werden. Man kann alternativ auch mit mtu und mtu-extra arbeiten, aber fragment liefert zuverlässige Ergebnisse, da die ausgehenden Pakete samt Overhead nie größer als das werden.
OpenVPN arbeitet auf dem Application-Layer und hat keine Kernel-Module. D.h. es interagiert auf einem höheren Level, als notwendig wäre. In der Folge leidet es wohl auch eher an Bufferbloat. Zudem benützt es pro Dienst nur einen Prozessorkern, was bei fehlender AES-Unterstützung zusätzlich ins Gewicht fällt. Derzeit wird das zuvor schon erwähnte Wireguard als Lösung angepriesen, es soll aber auch noch ein paar Kinderkrankheiten haben. https://www.wireguard.com/
Die Vorteile von OpenVPN liegen im Verbreitungsgrad der Software und ihrer Vielseitigkeit. Darin liegt aber auch die Komplexität. pmtud funktioniert nicht immer und auf allen Plattformen, die Verwendung von Kompression ist im Moment nicht unbedingt zu empfehlen, wenn zugleich 2.4.x und 2.3.x verwendet werden soll. Wie immer ist es wichtig, Logfiles lesen zu können und auch zu lesen. Irreführend ist oft, dass man glaubt, eine Verbindung seit aufgebaut, nur weil der Dienst im Log als laufend angezeigt wird, oder periodische Einträge aufgrund von ping/ping-restart (Option) aufscheinen. Das ist wertlos, solange nicht „connection initialized“ oder ähnlich geloggt wird. Fehler hingegen stechen mit „error“ auch heraus.
Fragment-Errors - bei Verwendung einer falschen Fragmentgröße (die muss auf beiden Seiten gleichwertig eingestellt sein) - werden indes recht penetrant aufgezeichnet und fallen auf, wenn man sie sieht.
