MTU-zwart gat: waarom kleine verzoeken werken maar uploads vastlopen

Een pagina laadt, een kleine API-aanroep komt terug, en dan blijft een bestandsupload hangen tot de client het opgeeft. Niets in het serverlog verklaart het, omdat de pakketten midden op het pad werden weggegooid zonder dat er een bruikbaar antwoord terugging. Dat patroon is een MTU-zwart gat: een schakel die smaller is dan de afzender aanneemt, plus een stilzwijgende weigering om dat te zeggen. De grootte die faalt is herhaalbaar, en dat is wat het diagnoseerbaar maakt.

Wat het gat zwart maakt

Elke schakel heeft een maximale transmissie-eenheid, en een pakket groter dan de limiet van de volgende hop moet ofwel worden gefragmenteerd, ofwel worden afgewezen met een ICMP-bericht dat dat zegt. Ontdekking van de pad-MTU hangt ervan af dat dat bericht aankomt en wordt gerespecteerd. Het filteren of negeren ervan laat de afzender een pakket herhalen dat er nooit in past.

Encapsulatie maakt dit gebruikelijk rond VPN's, omdat een tunnel een buitenste header toevoegt aan een pakket dat al op de fysieke schakel was afgestemd. Het binnenste pakket is legaal op 1500 bytes en het ingekapselde niet, dus het sterft op de grens terwijl kleine pakketten erdoor glippen. Een voltooide handshake en een werkende inlogpagina bewijzen alleen dat kleine pakketten werken. Het grootste pakket dat de toepassing probeert te versturen is het pakket dat ertoe doet.

Vind de grootte waar het breekt

Zoek binair de payloadgrootte met een test zonder fragmentatie, van een host aan de ene kant van de tunnel naar een host aan de andere kant. De grootste payload die doorkomt is je bruikbare pad-MTU min de header-overhead.

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

Een payload van 1472 bytes komt door op een schoon Ethernet-pad van 1500 bytes zodra de 28 bytes van de IPv4- en ICMP-headers erbij komen. Wanneer dezelfde test pas bij een kleinere payload slaagt nadat de tunnel omhoog is, is het verschil de encapsulatie-overhead, en de tunnelgrens is waar het afwijzingsbericht had moeten worden gegenereerd. Noteer beide getallen, voor en na het verbinden, want dat paar is het bewijs. Herhaal de test voor IPv6 wanneer de toepassing dat gebruikt, omdat de header groter is en de faaldrempel verschuift.

Lees het bewijs voordat je de tunnel de schuld geeft

Fouten van externe toepassingen, congestie en gewoon verlies laten uploads ook vastlopen, dus één mislukte overdracht identificeert geen zwart gat. Wat ze scheidt is de grootteverhouding: een herhaalbaar succes bij 1200 bytes en een herhaalbare stagnatie bij 1400 bytes, in dezelfde richting, via hetzelfde eindpunt.

Een opname aan beide uiteinden laat de grote pakketten vertrekken en nooit aankomen, zonder afwijzing ertussen. Dat is het moment om naar het grensapparaat te kijken in plaats van naar de server, die elk verzoek beantwoordt dat hij werkelijk ontvangt. Congestie loopt ook vast, maar zij loopt verschillende groottes op verschillende momenten vast, en dat is een andere signatuur.

Controleer de reparatie op beide transporten

De ondersteunde reparatie is de grens het echte limiet laten rapporteren, of daar de maximale segmentgrootte van TCP knijpen zodat geen te groot segment wordt geprobeerd. Elke MTU op het netwerk verlagen, of de firewall uitschakelen, verbergt het symptoom en laat een configuratie achter waarover later niemand kan redeneren.

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

Verifieer met dezelfde groottetest, dan met de toepassing die faalde, en controleer een tweede protocol, omdat UDP-toepassingen nooit de segmentgroottecorrectie van TCP ontvangen. Bewaar de oorspronkelijke waarden in het ticket, want een reparatie die niet kan worden teruggedraaid is een tweede probleem dat staat te wachten. Als de groottetest slaagt en de upload nog steeds vastloopt, was het zwarte gat niet de oorzaak, en het onderzoek moet verdergaan in plaats van de wijziging te verbreden.