MTU-sort hul: hvorfor små anmodninger virker, men uploads går i stå

En side indlæses, et lille API-kald vender tilbage, og derefter hænger en filupload, indtil klienten giver op. Intet i serverloggen forklarer det, fordi pakkerne blev droppet midt på stien uden at der blev sendt et brugbart svar tilbage. Det mønster er et MTU-sort hul: et led, der er smallere, end afsenderen antager, plus en tavs nægtelse af at sige det. Den størrelse, der fejler, er gentagelig, og det er netop, hvad der gør det diagnosticerbart.

Hvad gør hullet sort

Hvert led har en maksimal transmissionsenhed, og en pakke, der er større end næste hops grænse, skal enten fragmenteres eller afvises med en ICMP-besked, der siger det. Opdagelse af stiens MTU afhænger af, at den besked ankommer og respekteres. Filtrering eller ignorering af den får afsenderen til at gentage en pakke, der aldrig kan passe.

Indkapsling gør dette almindeligt omkring VPN’er, fordi en tunnel tilføjer et ydre header til en pakke, der allerede var dimensioneret til det fysiske led. Den indre pakke er lovlig ved 1500 byte, og den indkapslede er det ikke, så den dør ved grænsen, mens små pakker sejler igennem. Et fuldført handshake og en fungerende login-side beviser kun, at små pakker virker. Den største pakke, applikationen forsøger at sende, er den, der betyder noget.

Find størrelsen, hvor det knækker

Binærsøg nyttelaststørrelsen med en test uden fragmentering, fra en vært på den ene side af tunnelen til en vært på den anden. Den største nyttelast, der lykkes, er din brugbare 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 lykkes på en ren 1500-byte Ethernet-sti, når de 28 byte IPv4- og ICMP-headere lægges til. Når den samme test kun lykkes ved en mindre nyttelast, efter tunnelen er oppe, er forskellen indkapslingens overhead, og tunnelgrænsen er dér, hvor afvisningsbeskeden skulle have været genereret. Notér begge tal, før og efter forbindelsen, fordi det par er beviset. Gentag testen for IPv6, når applikationen bruger det, da headeren er større, og fejltærsklen flytter sig.

Læs beviserne, før du bebrejder tunnelen

Fjernapplikationsfejl, overbelastning og almindeligt tab får også uploads til at gå i stå, så en enkelt mislykket overførsel identificerer ikke et sort hul. Det, der adskiller dem, er størrelsesforholdet: en gentagelig succes ved 1200 byte og en gentagelig standsning ved 1400 byte, i samme retning, gennem samme endepunkt.

En optagelse i begge ender viser de store pakker forlade og aldrig ankomme, uden afvisning imellem. Det er øjeblikket til at se på grænseenheden i stedet for serveren, som svarer på hver anmodning, den faktisk modtager. Overbelastning går også i stå, men den går i stå ved forskellige størrelser på forskellige tidspunkter, og det er en anden signatur.

Kontroller reparationen på begge transporter

Den understøttede reparation er at lade grænsen rapportere den reelle grænse eller at fastklemme TCP’s maksimale segmentstørrelse dér, så intet overdimensioneret segment forsøges. At sænke hver MTU på netværket eller deaktivere firewallen skjuler symptomet og efterlader en konfiguration, som ingen senere kan ræsonnere 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

Bekræft med den samme størrelsestest, derefter med applikationen, der fejlede, og kontroller en anden protokol, fordi UDP-applikationer aldrig modtager TCP’s segmentstørrelseskorrektion. Gem de oprindelige værdier i billetten, fordi en reparation, der ikke kan rulles tilbage, er et andet problem, der venter på at ske. Hvis størrelsestesten består, og uploaden stadig går i stå, var det sorte hul ikke årsagen, og undersøgelsen bør fortsætte i stedet for at udvide ændringen.