Path-MTU-Erkennung durch ein VPN: Dimensionierung und die ICMP-Lücke

Ein Tunnel schließt seinen Handshake ab, kleine Anfragen kommen zurück, und der erste große Transfer bleibt hängen. Dieses Muster deutet auf die Path-MTU hin, lange bevor es auf den Durchsatz deutet. Jede Strecke entlang der Route begrenzt die Paketgröße, und die Kapselung verbraucht einen Teil dieses Spielraums für äußere Header, sodass das innere Paket kleiner sein muss, als der rohe Pfad vermuten ließe. Der Fehler ist stumm, und genau das macht die Diagnose teuer.

Was die Path-MTU tatsächlich misst

Die Path-MTU ist die kleinste Link-MTU auf der Route zwischen zwei Hosts, nicht die auf Ihrer lokalen Schnittstelle angezeigte MTU. Der lokale Wert ist der Ausgangspunkt der Schätzung, und der Pfad entscheidet, wo sie enden muss. Deshalb kann ein identischer Tunnel in einem Zugangsnetz funktionieren und in einem anderen hängen bleiben: Die Route hat sich geändert, nicht die Konfiguration. Einmal messen und überall annehmen ist der Fehler, der dieses Problem am Leben hält.

Bei einem Tunnel zählt die innere MTU, also der Spielraum des äußeren Pfads abzüglich dessen, was die Kapselung verbraucht. WireGuard fügt einen äußeren IP-Header und einen UDP-Header hinzu; andere Transporte fügen ihre eigenen hinzu. Setzen Sie die innere Größe zu hoch, braucht jedes Paket voller Größe eine Fragmentierung, die vielleicht nie stattfindet.

Warum ein Tunnel das nutzbare Paket verkleinert

Behält die Tunnelschnittstelle die MTU der physischen Strecke, hängt jedes große Paket davon ab, dass jemand weiter unten bereit ist, es zu fragmentieren. IPv4 erlaubt das grundsätzlich, aber ein Router, dem das Fragmentieren untersagt wurde, gibt stattdessen einen Fehler zurück. IPv6-Router fragmentieren im Transit überhaupt nicht, daher verhält sich dieselbe Einstellung je nach Adressfamilie anders. So oder so erfährt der Absender nichts, bis etwas zurückmeldet.

Die praktische Folge ist eine Größe, die zum Handshake passt und nicht zur Nutzlast. Ein TLS ClientHello oder eine DNS-Abfrage ist klein genug, um einen verkleinerten Pfad unberührt zu passieren, ein Massentransfer nicht. Symptome häufen sich daher um bestimmte Vorgänge statt um bestimmte Hosts.

Erkennung funktioniert nur, wenn die Rückmeldung ankommt

Die IPv4-Erkennung beruht auf dem Don't-Fragment-Bit: Ein Router, der das Paket nicht weiterleiten kann, gibt ICMP fragmentation-needed mit der MTU des nächsten Hops zurück, und der Absender senkt seine Schätzung. IPv6 verwendet stattdessen Packet-Too-Big-Nachrichten, weil Router im Transit nicht fragmentieren. Beide Mechanismen setzen voraus, dass die Nachricht den Weg zurück zum Absender findet, durch den Tunnel und an jeder Firewall auf dem Rückweg vorbei. Wenn diese Annahme scheitert, versucht der Absender weiter eine Größe, die der Pfad nicht tragen kann.

Eine Firewall, die Echo Request und Echo Reply erlaubt, hat damit nicht unbedingt diese Fehlertypen erlaubt. ICMP ist eine Familie, und die hier wichtigen Mitglieder sind die Fehler, nicht das Echo-Paar. Prüfen Sie die Richtlinie für Kontrollverkehr an beiden Tunnelenden und auf dem Pfad dazwischen, und folgen Sie der unterstützten Plattformempfehlung, statt jeden ICMP-Typ überall zu erlauben.

Dieselbe Filterung kann im Tunnel liegen. Verwirft der innere Pfad den Fehler, während der äußere ihn trägt, kann sich der Absender an ein Limit anpassen, das der gekapselte Verkehr tatsächlich nie sieht.

Den Pfad prüfen, statt eine Zahl zu raten

Halten Sie Ziel, Zugangsnetz und Tunnel fest und variieren Sie nur die Paketgröße. Eine Don't-Fragment-Sonde, die mit einem MTU-Hinweis scheitert, liefert Ihnen das Limit des nächsten Hops; wiederholen Sie den Vorgang, bis eine Größe durchgeht, und notieren Sie sowohl die Größe als auch die Adressfamilie.

ping -M do -s 1400 10.60.20.10
ping -M do -s 1300 10.60.20.10
ping -6 -M do -s 1300 2001:db8::10

Ein Ping, der passt, beweist nicht, dass die Segmente voller Größe einer echten Anwendung passen; wiederholen Sie den Test daher mit dem Transfer, der tatsächlich gescheitert ist. Vergleichen Sie die größte funktionierende Sonde mit der konfigurierten Tunnel-MTU und halten Sie beide Zahlen in Ihren Notizen getrennt. Weichen sie um etwa einen Header voneinander ab, haben Sie den Kapselungs-Overhead gefunden, keinen Defekt.

PLPMTUD, beschrieben in RFC 4821, sondiert nach oben und nutzt Transportbestätigungen, statt gelieferten Fehlern zu vertrauen. Es hilft auf Pfaden, die ICMP filtern, aber die Unterstützung variiert je nach Stack und Anwendung. Ein TCP-Fluss kann sich selbst erholen, während eine UDP-Anwendung mit fester Datagrammgröße weiter scheitert.

Einen Wert wählen und die Begründung festhalten

Die Tunnel-MTU zu senken ist zugleich Diagnose und legitime Korrektur, sobald Sie den Pfad kennen. Sie ersetzt nicht das Wissen darüber, welcher Pfad und welcher Rückmeldemechanismus beteiligt war, denn ein für eine Mobilfunkstrecke abgestimmter Wert ist auf einer Glasfaserverbindung unnötig klein. Notieren Sie die gewählte Größe, die Sonde, die sie rechtfertigt, und den Rückabwicklungsschritt.

Der IPv4-Mechanismus ist in RFC 1191 beschrieben und die IPv6-Paketierungsempfehlung in RFC 8201; beide zu nennen erspart dem nächsten Ingenieur, die Annahme neu herzuleiten. Wenn der Transfer bei der gewählten Größe weiter hängt, hören Sie auf, die Zahl zu senken, und schauen Sie auf die nächste Schicht. Ein Pfad, der bei jeder Größe scheitert, ist kein MTU-Problem.