MTU-svart hull: hvorfor små forespørsler virker, men opplastinger stopper

En side lastes, et lite API-kall kommer tilbake, og deretter henger en filopplasting til klienten gir opp. Ingenting i serverloggen forklarer det, fordi pakkene ble droppet midt på stien uten at et nyttig svar ble sendt tilbake. Det mønsteret er et MTU-svart hull: en forbindelse som er smalere enn avsenderen antar, pluss en stille nektelse av å si det. Størrelsen som feiler, er repeterbar, og det er det som gjør den diagnostiserbar.

Hva gjør hullet svart

Hver forbindelse har en maksimal overføringsenhet, og en pakke som er større enn grensen for neste hopp, må enten fragmenteres eller avvises med en ICMP-melding som sier det. Oppdagelse av stiens MTU avhenger av at den meldingen kommer frem og respekteres. Å filtrere eller ignorere den lar avsenderen gjenta en pakke som aldri kan passe.

Innkapsling gjør dette vanlig rundt VPN-er, fordi en tunnel legger en ytre header på en pakke som allerede var dimensjonert for den fysiske forbindelsen. Den indre pakken er lovlig på 1500 byte, og den innkapslede er ikke, så den dør ved grensen mens små pakker glir gjennom. En fullført håndtrykk og en fungerende innloggingsside beviser bare at små pakker virker. Den største pakken applikasjonen prøver å sende, er den som betyr noe.

Finn størrelsen der det bryter

Søk binært etter nyttelaststørrelsen med en test uten fragmentering, fra en vert på den ene siden av tunnelen til en vert på den andre. Den største nyttelasten som går gjennom, er din brukbare sti-MTU minus 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

En nyttelast på 1472 byte går gjennom på en ren 1500-byte Ethernet-sti når de 28 bytene med IPv4- og ICMP-headere legges til. Når den samme testen bare lykkes med en mindre nyttelast etter at tunnelen er oppe, er forskjellen innkapslingens overhead, og tunnelgrensen er der avvisningsmeldingen skulle ha blitt generert. Noter begge tallene, før og etter tilkobling, fordi det paret er beviset. Gjenta testen for IPv6 når applikasjonen bruker det, siden headeren er større og feilterskelen flytter seg.

Les bevisene før du klandrer tunnelen

Feil i eksterne applikasjoner, overbelastning og vanlig tap stopper også opplastinger, så én mislykket overføring identifiserer ikke et svart hull. Det som skiller dem, er størrelsesforholdet: en repeterbar suksess på 1200 byte og en repeterbar stopp på 1400 byte, i samme retning, gjennom samme endepunkt.

En opptak i begge ender viser de store pakkene gå ut og aldri komme frem, uten avvisning imellom. Det er øyeblikket for å se på grenseenheten i stedet for serveren, som svarer på hver forespørsel den faktisk mottar. Overbelastning stopper også, men den stopper ulike størrelser til ulike tider, og det er en annen signatur.

Kontroller reparasjonen på begge transportene

Den støttede reparasjonen er å la grensen rapportere den ekte grensen, eller å klemme TCPs maksimale segmentstørrelse der, slik at ingen overdimensjonert segment blir forsøkt. Å senke hver MTU på nettverket, eller å slå av brannmuren, skjuler symptomet og etterlater en konfigurasjon ingen senere kan resonnere om.

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

Bekreft med den samme størrelsestesten, deretter med applikasjonen som feilet, og sjekk en andre protokoll, fordi UDP-applikasjoner aldri mottar TCPs segmentstørrelseskorreksjon. Behold de opprinnelige verdiene i saken, fordi en reparasjon som ikke kan reverseres, er et andre problem som venter på å skje. Hvis størrelsestesten består og opplastingen fortsatt stopper, var det svarte hullet ikke årsaken, og undersøkelsen bør gå videre i stedet for å utvide endringen.