Jumbo-Frames machen einen VPN-Pfad nicht zu einem 9000-Byte-Transport

Sie haben 9000-Byte-Frames im LAN aktiviert und erwartet, dass das VPN schneller wird. Es wurde langsamer oder hörte ganz auf, große Übertragungen durchzulassen. Jumbo-Frames sind eine lokale Link-Vereinbarung; sie vergrößern nicht den Pfad, den der Tunnel überquert.

Das nutzbare Budget bestimmt die kleinste Grenze auf der Route, einschließlich der Kapselung, die der Tunnel hinzufügt.

Was Jumbo-Frames wirklich ändern

Eine MTU ist eine Eigenschaft einer Schnittstelle. Sie auf einem Server und dessen Switch anzuheben bedeutet, dass diese beiden größere Frames ohne Fragmentierung austauschen können. Über den Router hinter dem Switch, den Provider oder die andere Seite eines Tunnels sagt das nichts. Diese Geräte haben ihre eigenen Grenzen, und ein Paket, das eine davon überschreitet, wird nach Regeln verworfen oder fragmentiert, die Sie nicht festgelegt haben.

Lokale Vereinbarung, globale Folgen. Das ist die ganze Verwirrung.

Die Kapselungssteuer

Ein Tunnel packt Ihr Paket in ein anderes. WireGuard über IPv4 UDP fügt rund 60 Byte Overhead hinzu; der UDP-Modus von OpenVPN liegt im selben Bereich, und IPsec variiert je nach Modus und Algorithmen. Diese Bytes kommen aus dem Budget des äußeren Pfads, nicht aus dem Nichts.

Ein äußeres Glied mit 1500 Byte kann also kein inneres Paket mit 1500 Byte befördern, sobald ein Tunnel-Header hinzukommt.

Die Rechnung lohnt sich einmal. Auf einem Pfad mit 1500 Byte möchte ein WireGuard-Interface eine MTU um 1420, damit das gekapselte Paket hineinpasst. Setzen Sie das innere Interface auf 9000, und jedes große Paket braucht eine Fragmentierung, die der Tunnel nicht leisten kann, oder wird verworfen.

Finden Sie das kleinste Glied auf dem Pfad

Gehen Sie die Route ab und suchen Sie die niedrigste MTU. Das LAN liegt meist bei 1500 oder 9000, das WAN meist bei 1500, und eine Mobilfunk- oder PPP-Strecke kann noch niedriger sein. Ziehen Sie dann den Tunnel-Overhead ab. Ist das Ergebnis kleiner als die MTU des inneren Interfaces, haben Sie Ihre Antwort. Die Pfad-MTU-Erkennung kann das automatisch finden, aber nur wenn die ICMP-Nachrichten, auf die sie angewiesen ist, durchgelassen werden.

Gefiltertes ICMP ist der klassische Grund, warum eine große Übertragung hängt, während kleine Anfragen einwandfrei funktionieren.

Testen Sie die Größenabhängigkeit, ohne die Änderung auszuweiten

Nutzen Sie eine repräsentative Übertragung und bewahren Sie die Ausgangswerte auf, damit Sie sie zurückstellen können. ping -M do -s 1472 prüft ein Paket mit 1500 Byte bei gesetztem DF-Bit; verkleinern Sie die Größe, bis es durchgeht. Scheitern nur große Pakete, haben Sie ein Größen- und kein Routingproblem.

Hüten Sie sich beim Lesen von Mitschnitten vor Offload auf Host-Seite. Segmentierungsoffload kann Frames zeigen, die weit größer sind als das, was tatsächlich über die Leitung ging, wodurch ein funktionierender Pfad kaputt und ein kaputter in Ordnung aussieht.

Wann eine große MTU das richtige Design ist

Ein kontrolliertes privates Netz kann größere Frames durchgängig fahren, sofern jedes Gerät auf dem Pfad zustimmt und der Tunnel-Overhead eingerechnet ist. Das ist ein koordiniertes Design mit einem dokumentierten Wert pro Glied, nicht eine große Zahl, die in einen Client getippt wird.

Für einen gewöhnlichen öffentlichen Ausgang nehmen Sie 1500 oder weniger an und lassen den Tunnel eine sichere innere MTU wählen. RFC 8201 behandelt die Pfad-MTU-Erkennung für den IPv6-Fall und ist eine nützliche Referenz dafür, wie die Rückmeldung funktionieren soll.