MTU pro Route unter Linux: drei Größenregler, eine Route

Drei Einstellungen auf einem Linux-Client klingen alle nach „mach die Pakete kleiner“, und sie wirken auf verschiedenen Ebenen. Die Interface-MTU begrenzt jedes Paket, das das Gerät sendet. Eine Routen-MTU begrenzt Pakete, die diese Route nutzen, und das ist oft genau das, was man für ein VPN-Ziel will. Die TCP-MSS-Clamp ändert, was die beiden Enden aushandeln, und für UDP bewirkt sie nichts.

Drei Regler, die wie derselbe Knopf aussehen

Stell sie nebeneinander, bevor du wählst, denn die falsche Zeile erklärt den größten Teil der Ratschläge, die nicht funktionieren:

Die Ethernet-MTU für die ganze Maschine zu senken, ist die grobe Variante dieses Fixes. Er funktioniert, bestraft aber auch jede andere Anwendung auf dem Host, auch die, deren Pfade in Ordnung waren. Ein Wert pro Route drückt dieselbe Absicht ohne die Nebenwirkung aus.

Der Vergleich gilt nur für Verkehr, den der Host selbst erzeugt. Ein Paket für einen anderen Client weiterzuleiten, betrifft dessen eigenen Pfad und das äußere Budget des Tunnels, und eine Routenmetrik auf diesem Host reicht nicht über diese Grenze.

Häng das Budget an die Route, die die Suche gewinnt

Ein beispielhafter IPv4-Routeneintrag sieht so aus:

ip -4 route get 10.60.0.20
ip -4 route add 10.60.0.0/16 dev tun-office src 10.90.0.2 mtu 1380

Lies den Eintrag als Beschreibung der Absicht, nicht als Wert zum Einfügen. Präfix, Gerät und bevorzugte Quelle müssen zur echten Konfiguration passen, und die Zahl muss aus Belegen über den gekapselten Pfad stammen, nicht aus einem Blogbeitrag. Die Routen-MTU begrenzt das innere IP-Paket, was nicht dasselbe ist wie eine TCP-Nutzlast von 1380 Byte oder ein verschlüsseltes äußeres Paket von 1380 Byte.

Schau nach, wo die Suche tatsächlich aufgelöst wird, bevor du etwas hinzufügst. Ein Host mit Policy-Regeln kann ein Ziel über eine andere Tabelle als main routen, und eine Metrik, die nur in main existiert, ist für diese Anfrage unsichtbar. Vergleiche ip -4 route show table all mit der Antwort von ip route get, einschließlich des Mark- oder Namespace-Kontexts, wenn die Regeln sie verwenden. Wenn die beiden nicht übereinstimmen, braucht die Tabelle, die geantwortet hat, die Metrik, nicht die, die ordentlicher aussieht.

mtu ist nicht mtu lock

Standardmäßig kann der Kernel die Pfad-MTU noch aus ICMP-Rückmeldungen aktualisieren, dafür ist die Pfad-MTU-Erkennung da. Das Hinzufügen von lock stoppt das. Es ist eine andere Entscheidung, kein stärkerer Weg, dieselbe Zahl zu sichern, und für IPv4 ändert es den dokumentierten Umgang mit dem Don't-Fragment-Bit.

Sperren ist sinnvoll, wenn du den Pfad gemessen hast und willst, dass der Wert bleibt, egal was ankommt. Es ist ein schlechter Standard, wenn das Netzwerk legitime Größenrückmeldungen sendet, weil der Kernel nicht mehr anpassen kann und der Fehler zu einem anderen Symptom wandert.

Wird ICMP irgendwo auf dem Pfad gefiltert, repariert keine Routeneinstellung das. Die Korrektur gehört zum Filter, und eine kleinere MTU ist ein Workaround, der den echten Fehler verdeckt, bis sich der Pfad ändert.

Tunnelsoftware bringt eigene Größenregler mit

OpenVPN- mssfix passt die TCP-Segmentgröße für seinen dokumentierten UDP-Tunnelfall an. Es wirkt auf die TCP-Verbindung, ist also keine andere Schreibweise der Routen-MTU des Betriebssystems und kann einem UDP-Dienst, der die Aushandlung ignoriert, nicht helfen.

Stapel nicht Routen-MTU, Interface-MTU-Änderung und MSS-Clamp in einem Änderungsfenster. Wenn das Problem verschwindet, weißt du nicht, welches zählte, und die, die du behältst, schränken den Verkehr jahrelang ein, ohne dass sich jemand an den Grund erinnert.

Mach es umkehrbar, dann beweise es

Der eigentliche Besitzer der Route entscheidet, ob die Änderung ein Wiederverbinden überlebt. Ein VPN-Client, der die Route dynamisch einträgt, baut sie meist ohne deine Metrik neu auf, und ein manuelles ip route add sieht dann wie ein Fix aus, der einen Tag später scheiterte. Leg den Wert in die Konfiguration des Managers, und wenn du ein vorübergehendes Experiment brauchst, notiere zuerst die ursprüngliche Route.

Teste mit einer neuen Verbindung, die die hängende Operation ausführt, und bestätige dann, dass die beabsichtigte private Route weiterhin gewinnt und unbeteiligte Ziele unverändert sind. Verbinde den Tunnel neu und lies die Route erneut, denn ein Wert, der beim Wiederverbinden verschwindet, ist kein Fix.

Stützt die Evidenz die Änderung nicht, entferne die Überschreibung über ihren Manager und stelle die ursprünglichen Routenattribute wieder her, statt die Route zu löschen. Notiere dann, was du auf welchem Pfad gemessen hast, damit die nächste Person eine echte Verbesserung von einem laufengelassenen Experiment unterscheiden kann.