MTU-Schwarzes Loch: Warum kleine Anfragen funktionieren, aber Uploads hängen bleiben

Eine Seite lädt, ein kleiner API-Aufruf kehrt zurück, und dann hängt ein Datei-Upload, bis der Client aufgibt. Nichts im Serverprotokoll erklärt das, weil die Pakete mitten auf dem Pfad verworfen wurden, ohne dass eine brauchbare Antwort zurückkam. Dieses Muster ist ein MTU-Schwarzes Loch: eine Strecke, die schmaler ist, als der Sender annimmt, plus eine stille Weigerung, das zu sagen. Die Größe, bei der es scheitert, ist reproduzierbar, und genau das macht es diagnostizierbar.

Was das Loch schwarz macht

Jede Strecke hat eine maximale Übertragungseinheit, und ein Paket, das größer als das Limit des nächsten Hops ist, muss entweder fragmentiert oder mit einer ICMP-Nachricht, die das sagt, abgelehnt werden. Die Pfad-MTU-Erkennung hängt davon ab, dass diese Nachricht ankommt und beachtet wird. Sie zu filtern oder zu ignorieren lässt den Sender ein Paket wiederholen, das nie hineinpasst.

Kapselung macht das rund um VPNs häufig, weil ein Tunnel einen äußeren Header an ein Paket anhängt, das bereits für die physische Strecke bemessen war. Das innere Paket ist bei 1500 Bytes zulässig und das gekapselte nicht, also stirbt es an der Grenze, während kleine Pakete durchrutschen. Ein abgeschlossener Handshake und eine funktionierende Anmeldeseite beweisen nur, dass kleine Pakete funktionieren. Das größte Paket, das die Anwendung zu senden versucht, ist das entscheidende.

Finden Sie die Größe, bei der es bricht

Suchen Sie die Nutzlastgröße binär mit einem Test ohne Fragmentierung, von einem Host auf der einen Seite des Tunnels zu einem Host auf der anderen. Die größte Nutzlast, die durchgeht, ist Ihre nutzbare Pfad-MTU abzüglich des Header-Overheads.

ping -M do -s 1400 -c 2 192.0.2.20
ping -M do -s 1200 -c 2 192.0.2.20
ping -f -l 1372 192.0.2.20

Eine Nutzlast von 1472 Bytes geht auf einem sauberen Ethernet-Pfad mit 1500 Bytes durch, sobald die 28 Bytes der IPv4- und ICMP-Header hinzukommen. Wenn derselbe Test bei einer kleineren Nutzlast erst gelingt, nachdem der Tunnel steht, ist die Differenz der Kapselungs-Overhead, und die Tunnelgrenze ist der Ort, an dem die Ablehnungsnachricht hätte erzeugt werden müssen. Notieren Sie beide Zahlen, vor und nach dem Verbinden, denn dieses Paar ist der Beweis. Wiederholen Sie den Test für IPv6, wenn die Anwendung es nutzt, da der Header größer ist und sich die Fehlerschwelle verschiebt.

Lesen Sie die Beweise, bevor Sie den Tunnel beschuldigen

Fehler entfernter Anwendungen, Überlastung und gewöhnlicher Verlust lassen Uploads ebenfalls hängen, daher identifiziert eine fehlgeschlagene Übertragung kein schwarzes Loch. Was sie trennt, ist die Größenbeziehung: ein reproduzierbarer Erfolg bei 1200 Bytes und ein reproduzierbares Hängen bei 1400 Bytes, in derselben Richtung, über denselben Endpunkt.

Eine Aufzeichnung an beiden Enden zeigt die großen Pakete hinausgehen und nie ankommen, ohne Ablehnung dazwischen. Das ist der Moment, das Grenzgerät statt den Server anzusehen, der jede Anfrage beantwortet, die er tatsächlich erhält. Überlastung hängt ebenfalls, aber sie hängt verschiedene Größen zu verschiedenen Zeiten, was eine andere Signatur ist.

Prüfen Sie die Reparatur auf beiden Transporten

Die unterstützte Reparatur besteht darin, die Grenze das echte Limit melden zu lassen oder dort die maximale Segmentgröße von TCP zu begrenzen, damit kein übergroßes Segment versucht wird. Jede MTU im Netz zu senken oder die Firewall zu deaktivieren, verdeckt das Symptom und hinterlässt eine Konfiguration, über die später niemand mehr nachdenken kann.

ip link show dev tun0
sudo nft list ruleset | grep -i -E 'mtu|mss'
sysctl net.ipv4.tcp_mtu_probing
ping -M do -s 1400 -c 2 192.0.2.20

Prüfen Sie mit demselben Größen-Test, dann mit der Anwendung, die gescheitert ist, und prüfen Sie ein zweites Protokoll, weil UDP-Anwendungen die Segmentgrößen-Korrektur von TCP nie erhalten. Bewahren Sie die ursprünglichen Werte im Ticket auf, denn eine Reparatur, die sich nicht rückgängig machen lässt, ist ein zweites Problem, das darauf wartet zu passieren. Wenn der Größen-Test besteht und der Upload weiterhin hängt, war das schwarze Loch nicht die Ursache, und die Untersuchung sollte weitergehen, statt die Änderung auszuweiten.