MTU-svart hål: varför små förfrågningar fungerar men uppladdningar fastnar

En sida laddas, ett litet API-anrop kommer tillbaka, och sedan hänger en filuppladdning tills klienten ger upp. Inget i serverloggen förklarar det, eftersom paketen släpptes mitt på vägen utan att ett användbart svar skickades tillbaka. Det mönstret är ett MTU-svart hål: en länk som är smalare än avsändaren antar, plus en tyst vägran att säga det. Storleken som misslyckas är repeterbar, och det är vad som gör den diagnostiserbar.

Vad som gör hålet svart

Varje länk har en maximal överföringsenhet, och ett paket som är större än nästa hopps gräns måste antingen fragmenteras eller avvisas med ett ICMP-meddelande som säger det. Upptäckten av vägens MTU beror på att det meddelandet kommer fram och respekteras. Att filtrera eller ignorera det låter avsändaren upprepa ett paket som aldrig får plats.

Inkapsling gör detta vanligt kring VPN, eftersom en tunnel lägger ett yttre huvud på ett paket som redan var dimensionerat för den fysiska länken. Det inre paketet är lagligt vid 1500 byte och det inkapslade är det inte, så det dör vid gränsen medan små paket glider igenom. Ett slutfört handskakning och en fungerande inloggningssida bevisar bara att små paket fungerar. Det största paketet som applikationen försöker skicka är det som spelar roll.

Hitta storleken där det brister

Sök binärt efter nyttolastens storlek med ett test utan fragmentering, från en värd på ena sidan tunneln till en värd på den andra. Den största nyttolasten som går igenom är din användbara väg-MTU minus huvudets 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 nyttolast på 1472 byte går igenom på en ren Ethernet-väg på 1500 byte när de 28 byten för IPv4- och ICMP-huvudena läggs till. När samma test bara lyckas med en mindre nyttolast efter att tunneln rests, är skillnaden inkapslingens overhead, och tunnelgränsen är där avvisningsmeddelandet borde ha genererats. Anteckna båda talen, före och efter anslutning, eftersom det paret är beviset. Upprepa testet för IPv6 när applikationen använder det, eftersom huvudet är större och feltröskeln flyttar sig.

Läs bevisen innan du skyller på tunneln

Fel i fjärrapplikationer, trängsel och vanlig förlust stoppar också uppladdningar, så en misslyckad överföring identifierar inte ett svart hål. Det som skiljer dem är storleksförhållandet: en repeterbar framgång vid 1200 byte och ett repeterbart stopp vid 1400 byte, i samma riktning, genom samma slutpunkt.

En inspelning i båda ändar visar de stora paketen gå ut och aldrig komma fram, utan avvisning emellan. Det är ögonblicket att titta på gränsenheten i stället för servern, som svarar på varje förfrågan den faktiskt tar emot. Trängsel fastnar också, men den fastnar vid olika storlekar vid olika tider, och det är en annan signatur.

Kontrollera reparationen på båda transporterna

Den stödda reparationen är att låta gränsen rapportera den verkliga gränsen, eller att klämma TCP:s maximala segmentstorlek där så att inget överdimensionerat segment försöks. Att sänka varje MTU i nätverket, eller att stänga av brandväggen, döljer symtomet och lämnar en konfiguration som ingen senare kan resonera 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

Verifiera med samma storlekstest, sedan med applikationen som misslyckades, och kontrollera ett andra protokoll, eftersom UDP-applikationer aldrig får TCP:s segmentstorlekskorrigering. Behåll de ursprungliga värdena i ärendet, eftersom en reparation som inte kan återställas är ett andra problem som väntar på att hända. Om storlekstestet går igenom och uppladdningen fortfarande fastnar, var det svarta hålet inte orsaken, och utredningen bör gå vidare i stället för att bredda ändringen.