OpenVPN über PPPoE: link-mtu, tun-mtu oder mssfix verringern?

Pings antworten, DNS löst auf, und jede Seite, die ein volles Segment braucht, hängt. Auf einem Uplink, der eine eigene Kapselung hinzufügt, verliert der Pfad still ein paar Dutzend Bytes Budget, und ein Profil, das für reines Ethernet geschrieben wurde, fordert weiter Pakete an, die die Leitung nicht tragen kann. Die Verbindung ist nicht langsam; sie verwirft genau die Pakete, auf die es ankommt.

Drei Optionen können das beheben, und sie wirken auf verschiedenen Ebenen. Die falsche Wahl bewirkt entweder nichts oder macht den Tunnel auf neue Weise fragil, deshalb beginnt die Entscheidung mit dem, was der Pfad tatsächlich unterstützt.

Drei Stellschrauben, drei verschiedene Ebenen

link-mtu ist das äußere Budget: die verschlüsselte Nutzlast plus OpenVPN-Header, UDP-Header und äußerem IP-Header. Sie beschreibt, was die Maschine verlässt, und deshalb ist sie die Zahl, die der physische Pfad begrenzt.

tun-mtu ist das innere Budget: die Schnittstelle, die Ihr Verkehr sieht. Sie ist genau um den Tunnel-Overhead größer als das, was der Pfad tragen kann, und OpenVPN leitet sie normalerweise ab, statt sie setzen zu lassen.

mssfix ist ein völlig anderer Mechanismus. Es schreibt die maximale Segmentgröße um, die während TCP-Handshakes angekündigt wird, damit TCP-Partner Segmente wählen, die nach der Kapselung passen. Es ändert die Schnittstellen-MTU nicht und hat keine Wirkung auf UDP.

Wenn Sie link-mtu ausdrücklich setzen, zieht OpenVPN seinen eigenen Overhead ab, um die innere MTU abzuleiten. Dieser Overhead ist keine feste Konstante; er hängt von Chiffre und Authentifizierung ab, weshalb ein aus einem Forum kopierter Wert in einem anderen Profil falsch sein kann. Setzen Sie sowohl link-mtu als auch tun-mtu, geben Sie dem Client zwei widersprüchliche Anweisungen.

Den Pfad messen, bevor Sie eine Zahl wählen

Messen Sie von der physischen Schnittstelle aus, nicht aus dem Tunnel heraus, und beachten Sie, dass ping die Nutzlast meldet, nicht die Paketgröße. Addieren Sie 28 Bytes für die IPv4- und ICMP-Header, bevor Sie die Nutzlast mit einem 1500-Byte-Rahmen vergleichen, und behalten Sie diese Korrektur im Kopf, wenn ein Peer eine andere Zahl meldet.

Auf einem Linux-Client verbietet ping -M do -s 1472 die Fragmentierung und schlägt fehl, wenn das Paket zu groß ist. Verringern Sie die Nutzlast, bis es durchgeht, und addieren Sie dann 28, um die Pfad-MTU zu erhalten. PPPoE kostet 8 Bytes, daher sind 1492 bei DSL normal. DS-Lite und einige Mobilfunkpfade kosten 40 oder mehr, und das Ergebnis liegt meist unter dem, was die nominelle Linkgeschwindigkeit vermuten lässt.

Wenn jede Ping-Größe gelingt, aber große Übertragungen weiterhin hängen, verdächtigen Sie ein schwarzes Loch statt einer einfachen Größenbeschränkung. Eine ICMP-Nachricht über benötigte Fragmentierung wird irgendwo auf dem Pfad gefiltert, sodass der Absender nie lernt zu schrumpfen, und nur die Flows, die ein großes Segment brauchen, merken es.

Erst TCP begrenzen, dann den Tunnel verkleinern

TCP-Handshakes sind das Einzige, was mssfix berührt, weshalb es meist die am wenigsten störende Kontrolle ist, die man zuerst versucht. Setzen Sie es etwas unter das reale Budget des Pfads, übertragen Sie denselben Wert vom Server, damit beide Enden übereinstimmen, und testen Sie einen großen Download erneut. Verschwindet der Hänger, war die TCP-Segmentgröße das Problem, und sonst muss sich nichts ändern.

Verringern Sie die innere MTU, wenn der betroffene Verkehr nicht TCP ist. Ein UDP-Dienst, ein Tunnel im Tunnel oder eine Anwendung, die Datagramme in voller Größe sendet, schlägt nach einer MSS-Begrenzung weiterhin fehl, weil nichts ihre Paketgröße umschreibt. Reduzieren Sie für diesen Fall tun-mtu oder setzen Sie link-mtu und lassen den Client den inneren Wert ableiten, aber niemals beides.

Greifen Sie nicht zur alten Fragmentierungsoption. Sie teilte Pakete im Tunnel, fügte Overhead hinzu und ist aus guten Gründen veraltet; modernes OpenVPN erwartet stattdessen eine genaue Beschreibung des Pfads.

Warum kleine Sonden weiter funktionieren

DNS-Abfragen, ICMP-Echos und TCP-Handshakes liegen alle weit unter der fehlschlagenden Größe. Der Tunnel wirkt daher in jedem Schnelltest gesund, während TLS-Handshakes und HTTP-Antworten still fehlschlagen. Genau diese Kombination, ein funktionierender Traceroute und ein Browser, der bei der ersten großen Antwort hängt, ist das Muster, nach dem Sie suchen sollten. Greifen Sie zu einer Sonde in voller Größe, bevor Sie zu einem neuen Profil greifen.

Prüfen Sie mit dem Verkehr, der fehlgeschlagen ist. Rufen Sie eine große Seite ab, senden Sie ein UDP-Datagramm in voller Größe, wenn das der betroffene Dienst ist, und wiederholen Sie das von einem zweiten Client an einem anderen Uplink. Notieren Sie die gemessene Pfad-MTU und den gewählten Wert, denn die nächste Person, die das Profil anfasst, hält die Zahl sonst für willkürlich.

Nehmen Sie die innere MTU nie unter 1280, wenn IPv6 über den Tunnel läuft, denn das ist das Minimum, das jede IPv6-Strecke tragen muss. Eine kleinere MTU ist eine Tatsache über den Pfad, keine Leistungseinstellung, die man nach Gefühl justiert.