OpenVPN mssfix: Warum ein Client bei großen Übertragungen hängt

Ein einzelner Laptop hängt bei Uploads durch den Tunnel, während jedes andere Gerät auf demselben Server weiter funktioniert. Dieses Muster deutet auf einen Pfad hin, nicht auf die Serverkonfiguration, und es ist der übliche Einstieg in die mssfix-Frage. Die Option kann helfen, aber nur für die TCP-Verbindungen, die sie tatsächlich umschreibt. Wer ihre Reichweite kennt, ändert keinen funktionierenden Server, um einen Client zu retten.

Was die Option umschreibt

mssfix bearbeitet die maximale Segmentgröße, die in TCP-Handshakes angekündigt wird, die den Tunnel durchlaufen, damit die sendende Seite Segmente wählt, die in das gekapselte Budget passen. Es wirkt auf den Handshake, was bedeutet, dass eine vor der Änderung geöffnete Verbindung den ausgehandelten Wert behält.

Es verkleinert keine UDP-Datagramme und setzt nicht die Tunnel-MTU. Zwei verschiedene Probleme erzeugen dasselbe Symptom: ein TCP-Sender, der das Pfadlimit ignoriert, und ein Pfad, der große Pakete jeder Größe still verwirft. mssfix adressiert das erste und tut nichts für das zweite.

Diese Unterscheidung erklärt die enttäuschenden Experimente. Ein kleinerer Wert auf einem Pfad mit schwarzem Loch ändert die Segmentgröße, aber nicht das darauf folgende Verwerfen, daher scheitert die Übertragung an einer anderen Stelle.

Der Geltungsbereich ist TCP im Tunnel

Nur TCP-Verkehr wird umgeschrieben. Eine QUIC-Sitzung, ein Spiel oder eine Anwendung, die große UDP-Datagramme sendet, behält ihre eigenen Paketgrößen, und wenn genau diese Übertragungen hängen, gehört die Behebung eher an die Tunnel- oder Pfad-MTU. Lesen Sie, welches Protokoll die fehlschlagende Übertragung verwendet, bevor Sie zu einer TCP-Option greifen, denn die falsche Schicht hat ihre eigene Behebung.

Auch die Richtung zählt. Eine Client-Einstellung betrifft den Verkehr, den dieser Client in den Tunnel sendet, während der Server die Ströme abdeckt, die er an die Clients weiterleitet. Wenn nur eingehende Downloads hängen, ist der Wert auf der Clientseite nicht die ganze Geschichte.

Die Zahl und das Schlüsselwort sind nicht portabel

Die Community-Version von OpenVPN 2.6 akzeptiert ein optionales Schlüsselwort nach dem Wert. Mit mtu beschreibt die Zahl die äußere Paketgröße einschließlich IP- und UDP-Headern; ohne es folgt das Argument einer anderen Abrechnungskonvention. Eine zwischen Versionen kopierte Zeile beschreibt daher nicht dasselbe Paketbudget. Prüfen Sie die Handbuchseite, die mit dem Build ausgeliefert wird, das Sie tatsächlich ausführen, statt eines Tutorials für eine andere Version.

Die Syntax sieht so aus:

mssfix 1400 mtu

Behandeln Sie 1400 als Platzhalter, nicht als Empfehlung für Ihren Pfad. Leiten Sie den Wert aus dem gemessenen Pfad und der tatsächlich verwendeten Kapselung ab, und bedenken Sie, dass Clients mit älteren Versionen oder anderen Implementierungen das Schlüsselwort ablehnen oder anders interpretieren können.

Bestätigen Sie es zuerst am einen Client

Messen Sie den Pfad von der fehlerhaften Maschine, bevor Sie etwas ändern. Eine Nutzlast, die der Pfad ohne Fragmentierung tragen kann, ist die Zahl, die Sie suchen:

ping -M do -s 1472 10.8.0.1
ping -M do -s 1400 10.8.0.1

Der erste Test passt in ein Paket von 1500 Byte, sobald die 28 Byte Header hinzukommen. Scheitert er mit einem Fragmentierungsfehler und gelingt der kleinere, liegt die nutzbare Größe irgendwo dazwischen, und der Tunnel-Overhead wird oben abgezogen.

Wiederholen Sie dann die Übertragung, die hängen blieb, auf einer neuen Verbindung, und vergleichen Sie. Wenn sich der einzelne Client verbessert, während die anderen unberührt bleiben, haben Sie die Reichweite des Problems gefunden. Wenn jeder Client hängt, ist der Wert auf der Serverseite derjenige, der zu prüfen ist. Keines der beiden Ergebnisse rechtfertigt eine Änderung an Hardware, die nie auf dem fehlerhaften Pfad lag.