OpenVPN: Wie können Probleme mit Pfad-MTUs auf Client-Basis gemindert werden?

Wir haben Dutzende eingebetteter Geräte bei unseren Kunden installiert, die alle unseren OpenVPN-Service nutzen. Das funktioniert im Allgemeinen gut, aber einige unserer Kunden haben ernsthafte Probleme mit der MTU. Unser Einfluss auf die Kunden, ihre Netzwerke zu reparieren, ist begrenzt, daher benötigen wir OpenVPN, um damit umzugehen. Kurz gesagt, meine Frage lautet:

Wie kann ich die Low-Path-MTUs einiger Clients auf Clientbasis verringern, ohne globale Einstellungen zu verwenden, die den Worst-Case für alle Clients berücksichtigen?

Beachten Sie, dass es im schlimmsten Fall ziemlich schlimm ist: Pfad MTU 576, löscht alle Fragmente, fragmentiert sich nicht selbst, beachtet DF-Bit nicht. Sie sehen, warum ich es vorziehen würde, dieses Problem nicht global zu lösen.

Die OpenVPN-Manpage bietet eine Reihe von MTU-bezogenen Optionen, insbesondere --link-mtu, --tun-mtu, --fragment and --mssfix. Aber es heißt auch

--link-mtu [...] Es ist am besten, diesen Parameter nur festzulegen, wenn Sie wissen, was Sie tun.

--tun-mtu [...] Verwenden Sie am besten die Optionen --fragment und / oder --mssfix, um Probleme mit der MTU-Größe zu beheben.

Also habe ich angefangen zu experimentieren --fragmentund --mssfixmusste schnell feststellen, dass erstere nicht nur clientseitig, sondern auch serverseitig gesetzt werden müssen . Ich habe dann in der serverseitigen Konfiguration pro Client über gesucht, --client-config-diraber es heißt

Die folgenden Optionen sind in einem clientspezifischen Kontext zulässig: --push, --push-reset, --iroute, --ifconfig-push und --config.

Keine Erwähnung von MTU-Optionen!

Also hier sind meine spezifischeren Fragen:

Warum genau sind link-mtuund tun-mtuentmutigt? Was sind die potenziellen Probleme mit diesen Optionen? Beachten Sie, dass ich mit Low-Level-IP-Header-Munging ziemlich vertraut bin.
Welche der Optionen link-mtu tun-mtu fragment mssfixmüssen serverseitig gespiegelt werden, um zu funktionieren?
In welcher der Optionen link-mtu tun-mtu fragment mssfixkann verwendet werden client-config-dir?
Falls alle vier Optionen serverseitig gespiegelt werden müssen und im Inneren nicht verwendet werden können client-config-dir: Gibt es Alternativen zur Bekämpfung von MTUs mit geringem Pfad pro Client?

Anmerkungen:

Teile meiner Fragen wurden bereits gebeten , vor 5 Jahren war hier , aber sie haben nicht wirklich damals beantwortet worden, daher wage ich sie zu duplizieren.
Der OpenVPN-Server ist derzeit 2.2.1 unter Ubuntu 12.04. Wir bereiten ein Upgrade auf 2.3.2 auf Ubuntu 14.04 vor
Die OpenVPN-Clients sind 2.2.1 unter Debian 7.6
Gerne bestimme ich die Weg-MTU eines Kunden selbst manuell
Momentan können wir nicht viel serverseitig testen. Wir bauen aber einen kompletten separaten Prüfstand, der demnächst fertig sein soll.

Für hilfreiche Hinweise bin ich dankbar.

ip openvpn mtu ip-fragmentation

— Nils Toedtmann
quelle

576? Lieber Gawd. Ich habe seit den Tagen der Einwahl keine so niedrige MTU mehr gesehen. Geht das über eine alte serielle Verbindung?

— Michael Hampton

Könnten Sie zwei OpenVPN-Server ausführen? Möglicherweise können Sie beide Server mit derselben öffentlichen IP-Adresse betreiben und die Portweiterleitung (oder eine Routing-Richtlinie) verwenden, um Clients an einen anderen OpenVPN-Server weiterzuleiten, je nachdem, ob sie sich in einem bekannten problematischen Netzwerk befinden oder nicht (wie anhand einer Liste von Clients bestimmt) IP-Adressen).

— Kasperd

@MichaelHampton fragte ich mich auch. Es ist> 600kbit / s und RTT ~ 30ms, sieht für mich nicht nach einer alten Serie aus. Angesichts der Tatsache, dass sie andere dumme Einstellungen haben (z. B. nicht auf DF mit 'Fragmentierung erforderlich' reagieren), denke ich, dass dies nur eine andere ist. Wir sagten es ihnen, haben es aber noch nicht gehört.

— Nils Toedtmann

@kasperd interessante Idee. Ich könnte mehrere OpenVPN-Serverinstanzen ausführen. Müsste vielleicht 3 oder 4 haben, für unterschiedliche MTU-Reichweiten. Server-seitiges Pro-Client-NAT würde nicht funktionieren (ich kann die dynamischen öffentlichen Client-IP-Adressen nicht vorhersagen), aber ich müsste die Client-Konfiguration trotzdem für die MTU-Einstellungen ändern (richtig?), Also würde ich einfach den anderen Port direkt konfigurieren in den Client. - Aber es wäre ein Wartungsalptraum, den ich lieber vermeiden würde!

— Nils Toedtmann

@NilsToedtmann Welche Kriterien würden Sie verwenden, um festzustellen, welche Kunden betroffen sind? Ein anderer Ansatz könnte darin bestehen, ein Skript auf dem Server auszuführen, nachdem sich ein Client verbunden hat. Das Skript kann versuchen, die Client-IP-Adresse mit unterschiedlichen Paketgrößen zu pingen, um herauszufinden, welche funktionieren und welche nicht. Anschließend können iptablesRegeln eingefügt werden, um die MSS für alle SYN-Pakete von oder zu dieser Client-IP-Adresse zu reduzieren.

— Kasperd

Ich habe das Problem auf der Client-Seite gelöst, indem ich mssfix 1300der Konfigurationsdatei die Option hinzugefügt habe .

Aus der openvpn-Manpage:

--mssfix max
    Announce to TCP sessions running over the tunnel that they should limit their send packet sizes such that after OpenVPN has encapsulated them, the resulting UDP packet size that OpenVPN sends to its peer will not exceed max bytes.

Die ursprüngliche Idee für meine Lösung kam von personalvpn.org

— Oz123
quelle

So mssfixkann nur eingestellt Client-Seite werden? Nun, das ist zumindest etwas. Es hilft zwar nicht bei UDP-Paketen (weshalb ich mich für die anderen Optionen interessierte, aber zumindest die empfohlenen fragmentmüssen auch serverseitig eingestellt werden)

— Nils Toedtmann

mssfix kann sowohl auf dem Server als auch auf dem Client hinzugefügt werden. Der kleinere Wert wird jedoch in den Verhandlungen verwendet

— Ahmed

Angesichts des Mangels an Antworten poste ich jetzt eine Lösung, die nicht sehr elegant, aber einfach ist: Führen Sie eine andere OpenVPN-Instanz auf TCP für "schlechte Clients" aus.

proto tcp

und senken Sie die TCP-MSS auf dem Client, z

iptables -t mangle -A POSTROUTING -p tcp --tcp-flags SYN,RST SYN -o ${OUT_DEV} -j TCPMSS --set-mss ${PATH-MTU-MINUS-40}

Ein Vorteil dieser Lösung ist, dass jeder Client seine individuelle MSS einstellen kann.

Dies ist zwar TCP-over-TCP, dies sollte jedoch in vielen Szenarien ausreichend funktionieren .

Beachten Sie, dass ich immer noch sehr interessierte Lösungen bin, die keine erfordern proto tcp, und ich werde sie als gültige Antwort markieren, wenn sie mehr oder weniger meinen umrissenen Anforderungen entsprechen.

— Nils Toedtmann
quelle