Črna luknja MTU: zakaj majhne zahteve delujejo, nalaganja pa se ustavijo

Stran se naloži, majhen klic API se vrne, nato pa nalaganje datoteke visi, dokler odjemalec ne obupa. Nič v dnevniku strežnika tega ne pojasni, ker so bili paketi spuščeni na sredini poti, ne da bi bil poslan nazaj koristen odgovor. Ta vzorec je črna luknja MTU: povezava, ožja, kot domneva pošiljatelj, skupaj s tihim odklanjanjem, da bi to povedal. Velikost, pri kateri spodleti, je ponovljiva, in prav zato jo je mogoče diagnosticirati.

Kaj naredi luknjo črno

Vsaka povezava ima največjo prenosno enoto, in paket, večji od omejitve naslednjega skoka, mora biti bodisi razdrobljen bodisi zavrnjen s sporočilom ICMP, ki to pove. Odkrivanje MTU poti je odvisno od tega, ali to sporočilo prispe in je upoštevano. Filtriranje ali ignoriranje pusti pošiljatelja, da ponavlja paket, ki se nikoli ne bo prilegal.

Enkapsulacija naredi to pogosto okoli VPN, ker tunel doda zunanjo glavo paketu, ki je bil že dimenzioniran za fizično povezavo. Notranji paket je zakonit pri 1500 bajtih, enkapsulirani pa ne, zato umre na meji, medtem ko majhni paketi zdrsnejo skozi. Dokončan rokovanje in delujoča prijavna stran dokažeta le, da majhni paketi delujejo. Največji paket, ki ga aplikacija poskuša poslati, je tisti, ki šteje.

Poiščite velikost, pri kateri se zlomi

Binarno poiščite velikost koristnega tovora s preskusom brez drobljenja, z gostitelja na eni strani tunela na gostitelja na drugi. Največji tovor, ki gre skozi, je vaš uporabni MTU poti minus stroški glave.

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

Tovor 1472 bajtov gre skozi na čisti poti Ethernet 1500 bajtov, ko se doda 28 bajtov glav IPv4 in ICMP. Ko isti preskus uspe le pri manjšem tovoru po dvigu tunela, je razlika strošek enkapsulacije, meja tunela pa je kraj, kjer bi moralo nastati sporočilo o zavrnitvi. Zapišite obe številki, pred in po povezavi, ker je ta par dokaz. Ponovite preskus za IPv6, ko ga aplikacija uporablja, saj je glava večja in prag napake se premakne.

Preberite dokaze, preden obtožite tunel

Napake oddaljenih aplikacij, zastoji in običajna izguba tudi ustavijo nalaganja, zato en neuspešen prenos ne prepozna črne luknje. Loči jih razmerje velikosti: ponovljiv uspeh pri 1200 bajtih in ponovljiva ustavitev pri 1400 bajtih, v isti smeri, skozi isto končno točko.

Posnetek na obeh koncih pokaže velike pakete, ki odhajajo in nikoli ne prispejo, brez zavrnitve vmes. To je trenutek, ko pogledate mejno napravo namesto strežnika, ki odgovarja na vsako zahtevo, ki jo dejansko prejme. Zastoj tudi ustavi, vendar ustavi različne velikosti ob različnih časih, in to je drugačen podpis.

Preverite popravek na obeh transportih

Podprti popravek je, da mejna naprava poroča resnično omejitev, ali da se tam omeji največja velikost segmenta TCP, da se ne poskuša prevelik segment. Zniževanje vsakega MTU v omrežju ali izklop požarnega zidu skrije simptom in pusti konfiguracijo, o kateri pozneje nihče ne bo mogel razmišljati.

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

Preverite z istim preskusom velikosti, nato z aplikacijo, ki je spodletela, in preverite drugi protokol, ker aplikacije UDP nikoli ne prejmejo popravka velikosti segmenta TCP. Shranite izvirne vrednosti v zahtevku, ker popravek, ki ga ni mogoče razveljaviti, je druga težava, ki čaka, da se zgodi. Če preskus velikosti uspe in se nalaganje še vedno ustavi, črna luknja ni bila vzrok, in preiskava mora iti naprej, namesto da bi razširila spremembo.