MTU-svart hol: kvifor små førespurnader virkar, men opplastingar stoppar

Ei side blir lasta, eit lite API-kall kjem tilbake, og deretter heng ei filopplasting til klienten gir opp. Ingenting i serverloggen forklarer det, fordi pakkane blei sleppte midt på stien utan at eit nyttig svar blei sendt tilbake. Det mønsteret er eit MTU-svart hol: eit samband som er smalare enn avsendararen reknar med, pluss ei stille nekt av å seie det. Storleiken som feilar, er repeterbar, og det er det som gjer han diagnostiserbar.

Kva gjer holet svart

Kvart samband har ei maksimal overføringseining, og ein pakke som er større enn grensa for neste hopp, må anten fragmenterast eller avvisast med ei ICMP-melding som seier det. Oppdaging av stiens MTU er avhengig av at den meldinga kjem fram og blir respektert. Å filtrere eller ignorere ho lèt avsendararen gjenta ein pakke som aldri kan passe.

Innkapsling gjer dette vanleg rundt VPN-ar, fordi ein tunnel legg ein ytre header på ein pakke som allereie var dimensjonert for den fysiske sambandet. Den indre pakken er lovleg på 1500 byte, og den innkapsla er det ikkje, så han døyr ved grensa medan små pakkar glir gjennom. Eit fullført handtrykk og ei fungerande innloggingsside beviser berre at små pakkar virkar. Den største pakken applikasjonen prøver å sende, er den som betyr noko.

Finn storleiken der det bryt

Søk binært etter nyttelaststorleiken med ein test utan fragmentering, frå ein vert på den eine sida av tunnelen til ein 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

Ein nyttelast på 1472 byte går gjennom på ein rein 1500-byte Ethernet-sti når dei 28 byta med IPv4- og ICMP-headere blir lagde til. Når den same testen berre lukkast med ein mindre nyttelast etter at tunnelen er oppe, er skilnaden overheaden til innkapslinga, og tunnelgrensa er der avvisingsmeldinga skulle ha blitt generert. Noter båe tala, før og etter tilkopling, fordi det paret er beviset. Gjenta testen for IPv6 når applikasjonen brukar det, sidan headeren er større og feilgrensa flyttar seg.

Les prova før du klandrar tunnelen

Feil i eksterne applikasjonar, overbelastning og vanleg tap stoppar også opplastingar, så éin mislukka overføring identifiserer ikkje eit svart hol. Det som skil dei, er storleikstilhøvet: ein repeterbar suksess på 1200 byte og ein repeterbar stopp på 1400 byte, i same retning, gjennom same endepunkt.

Eit opptak i båe endar viser dei store pakkane gå ut og aldri kome fram, utan avvising imellom. Det er augneblinken for å sjå på grenseininga i staden for serveren, som svarar på kvar førespurnad han faktisk mottek. Overbelastning stoppar også, men ho stoppar ulike storleikar til ulike tider, og det er ein annan signatur.

Kontroller reparasjonen på båe transporane

Den støtta reparasjonen er å la grensa rapportere den ekte grensa, eller å klemme den maksimale segmentstorleiken til TCP der, slik at ingen overdimensjonert segment blir forsøkt. Å senke kvar MTU på nettverket, eller å slå av brannmuren, skjuler symptomet og lèt att ein konfigurasjon ingen seinare 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

Stadfest med den same storleikstesten, deretter med applikasjonen som feila, og sjekk ein andre protokoll, fordi UDP-applikasjonar aldri mottek segmentstorleikskorreksjonen til TCP. Hald på dei opphavlege verdiane i saka, fordi ein reparasjon som ikkje kan reverserast, er eit andre problem som ventar på å skje. Viss storleikstesten består og opplastinga framleis stoppar, var det svarte holet ikkje årsaka, og undersøkinga bør gå vidare i staden for å utvide endringa.