VPN-MTU-Mythen: Warum Ihre Pakete schrumpfen und wohin der Platz geht

Jemand sagt Ihnen, das VPN „verliere Pakete wegen MTU“, Sie setzen den Tunnel auf 1400, und die Übertragung läuft wieder. Dieses Ergebnis fühlt sich wie eine Diagnose an. Meist ist es ein Zufall der Arithmetik: Sie haben eine Zahl gewählt, die klein genug ist, um unter ein Limit zu passen, das Sie nie identifiziert haben, und Sie werden demselben Limit auf dem nächsten Netz mit einem anderen Budget wieder begegnen.

Zwei Mythen verursachen das meiste davon. Der erste ist, dass der MTU der Tunnel-Schnittstelle der MTU des Pfades ist. Der zweite ist, dass Kapselung „einen Header“ kostet und PPPoE nichts, was zu zählen lohnt. Beide sind falsch auf eine Weise, die die gewählte Zahl willkürlich aussehen lässt, obwohl sie tatsächlich bestimmt ist.

Mythos eins: Der MTU des Tunnels ist der Pfad-MTU

Der Wert, den Sie an einer Tunnel-Schnittstelle setzen, ist ein lokales Versprechen über das größte innere Paket, das die Implementierung nach unten weitergibt. Die tatsächliche Kapazität des Pfades ist eine Eigenschaft jeder Strecke zwischen Ihnen und dem fernen Ende, und sie kann sich ändern, wenn sich eine Route ändert, wenn eine Mobilfunkverbindung übergeben wird oder wenn der Verkehr ein anderes Peering nimmt. Ein konfigurierter 1500 sagt Ihnen, was Ihr Host baut, nicht was das Netz trägt.

Pfad-MTU-Erkennung existiert, um beides in Einklang zu bringen, und sie hängt von Rückmeldung ab. Bei IPv4 soll ein Router, der ein Paket voller Größe nicht weiterleiten kann, eine ICMP-Nachricht „fragmentation needed“ senden, und der Sender senkt seine Schätzung. Bei IPv6 ist das Gegenstück eine Packet-Too-Big-Nachricht, und Router fragmentieren im Transit überhaupt nicht. Wird diese Rückmeldung gefiltert, erzeugt der Sender weiter Pakete, die der Pfad nicht tragen kann, und nichts sagt ihm, warum.

Mythos zwei: Kapselung kostet einen Header

Zählen Sie die äußeren Schichten ehrlich. Ein äußerer IP-Header ist 20 Bytes bei IPv4 oder 40 bei IPv6. UDP-Kapselung für NAT-Traversal fügt 8 hinzu. Das Tunnelprotokoll fügt seinen eigenen Header hinzu, einen Initialisierungsvektor oder Nonce, Padding bis zur Block- oder Ausrichtungsgrenze der Chiffre, einen Trailer und einen Integritätsprüfwert. Je nach Protokoll und Chiffre liegt die Summe locker im Bereich von Dutzenden Bytes, bevor das innere Paket überhaupt beginnt.

Dann ziehen Sie erneut die eigenen Header des inneren Pakets ab. Ein TCP-Segment im Tunnel trägt seinen eigenen 20-Byte-IP-Header und 20-Byte-TCP-Header, und die MSS von TCP leitet sich vom MTU ab, nicht von der nominalen Nutzlast des Tunnels. Deshalb kann ping mit kleinerer Nutzlast gelingen, während eine Dateiübertragung stockt: Die Werkzeuge testen unterschiedliche Dinge, und nur eines davon übt ein TCP-Segment voller Größe aus.

ip link show tun0
ping -M do -s 1472 192.0.2.10
ping -M do -s 1400 192.0.2.10

Der erste Befehl meldet den konfigurierten Tunnel-MTU. Die beiden Sonden senden eine Nutzlast von 1472 Bytes, was mit 28 Bytes IPv4- und ICMP-Headern ein Paket von 1500 Bytes ergibt, dann eine kleinere. Scheitert die große Sonde ganz und gelingt die kleine, haben Sie einen größabhängigen Fehler und kein allgemeines Routingproblem.

Mythos drei: PPPoE liefert Ihnen noch immer saubere 1500

Eine herkömmliche PPPoE-Zugangsstrecke trägt kein IP-Paket von 1500 Bytes. Der PPPoE-Header plus das PPP-Protokollfeld verbrauchen 8 Bytes innerhalb des Ethernet-Rahmens, was 1492 für das IP-Paket übrig lässt. Das ist die traditionelle Grenze aus RFC 2516. Betreiben Sie ein VPN über eine solche Strecke, kommt der Overhead des Tunnels aus diesen 1492, nicht aus 1500.

RFC 4638 definiert einen Weg, eine größere PPP-Nutzlast auszuhandeln, wenn sowohl der Zugangskonzentrator als auch die Kundengeräte es unterstützen, weshalb „diese Verbindung nutzt PPPoE“ allein keine bestimmte Zahl beweist. Eine lokale Einstellung kann ein Zwischengerät nicht dazu bringen, ein Paket zu akzeptieren, für das es nie konfiguriert wurde, also ist die nützliche Frage, was die Strecke tatsächlich ausgehandelt hat, nicht was das Etikett sagt.

Warum der Fehler selektiv wirkt

Dass kleine Anfragen gelingen und große Übertragungen stocken, ist die klassische Signatur eines Pfad-MTU-Schwarzen Lochs. Der Handshake, die DNS-Abfrage und der API-Aufruf passen alle; die Massenübertragung erzeugt Segmente voller Größe, die an einer Strecke sterben, und die ICMP-Nachricht, die das Problem hätte melden sollen, kommt nie an. Die Verbindung sieht in Ordnung aus und der Download hängt, was Leute auf den Server statt auf den Pfad schauen lässt.

Ein zweiter, verwandter Fehler ist, drei Zahlen zu verwechseln: den Schnittstellen-MTU, die TCP-MSS und die eigene Fragmentierungs- oder Padding-Einstellung des Protokolls. MSS-Clamping auf einem Router schreibt die angekündigte MSS um, damit der Sender kleinere Segmente baut; es ändert den Tunnel-MTU nicht und hilft UDP-Verkehr nicht. Allen drei dieselbe Zahl zu geben, weil sie verwandt aussehen, ist der Weg, wie eine gut gemeinte Änderung ein funktionierendes Setup zerstört.

Was in welcher Reihenfolge zu ändern ist

Beginnen Sie mit Belegen. Bestätigen Sie mit den Sonden oben, dass der Fehler größabhängig ist, und finden Sie dann die kleinste Größe, die durchgeht, und die größte, die scheitert. Prüfen Sie den tatsächlichen MTU der Zugangsstrecke, bevor Sie den Tunnel beschuldigen; eine PPPoE-Strecke begrenzt das Budget, bevor Ihr VPN sie berührt. Notieren Sie die ursprünglichen Werte, damit die Änderung rückgängig gemacht werden kann.

Dann wenden Sie die kleinste Anpassung an, die der Client dokumentiert. Viele Clients bieten einen Tunnel-MTU plus eine MSS-Fix-Option, und die MSS-Option ist für TCP oft der bessere Hebel, weil sie den Sender erreicht, ohne jedes Paket zu verkleinern. Testen Sie dasselbe Ziel und dieselbe Übertragung erneut und notieren Sie die Zahlen, auf die Sie sich festgelegt haben. Ein Tunnelwert, der in einem Zugangsnetz funktioniert, ist keine universelle Konstante, und der nächste Standort hat sein eigenes Budget.