MTU juodoji skylė: kodėl mažos užklausos veikia, o įkėlimai sustoja

Puslapis įkeliamas, mažas API iškvietimas grįžta, o tada failo įkėlimas kabo, kol klientas pasiduoda. Serverio žurnale niekas to nepaaiškina, nes paketai buvo numesti kelio viduryje, nesiunčiant naudingo atsakymo. Šis modelis yra MTU juodoji skylė: siauresnė už siuntėjo prielaidą jungtis, be to, tylus atsisakymas tai pasakyti. Nepavykstantis dydis yra kartojamas, ir būtent tai leidžia jį diagnozuoti.

Kas padaro skylę juodą

Kiekviena jungtis turi didžiausią perdavimo vienetą, o paketas, didesnis už kito šuolio ribą, turi būti suskaidytas arba atmestas su tai sakantį ICMP pranešimą. Maršruto MTU aptikimas priklauso nuo to, ar tas pranešimas atkeliaus ir bus gerbiamas. Jį filtruojant ar ignoruojant siuntėjas kartoja paketą, kuris niekada netilps.

Įkapsuliavimas daro tai įprasta aplink VPN, nes tunelis prideda išorinę antraštę prie paketo, jau pritaikyto fizinei jungčiai. Vidinis paketas yra teisėtas ties 1500 baitų, o įkapsuliuotas ne, todėl jis miršta ties riba, kol maži paketai praslysta. Užbaigtas rankos paspaudimas ir veikiantis prisijungimo puslapis įrodo tik tai, kad maži paketai veikia. Didžiausias paketas, kurį programa bando siųsti, yra tas, kuris svarbus.

Raskite dydį, kai jis lūžta

Dvejetaine paieška raskite naudingosios apkrovos dydį su neskaidymo testu, nuo hosto vienoje tunelio pusėje iki hosto kitoje. Didžiausia praeinanti apkrova yra jūsų naudojamas maršruto MTU atėmus antraštės sąnaudas.

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

1472 baitų apkrova praeina švariu 1500 baitų Ethernet keliu, kai pridedami 28 baitai IPv4 ir ICMP antraščių. Kai tas pats testas pavyksta tik su mažesne apkrova po tunelio įjungimo, skirtumas yra įkapsuliavimo sąnaudos, ir tunelio riba yra vieta, kur turėjo būti sugeneruotas atmetimo pranešimas. Užrašykite abu skaičius, prieš prisijungiant ir po to, nes ta pora yra įrodymas. Pakartokite testą IPv6, kai programa jį naudoja, nes antraštė didesnė ir gedimo slenkstis pasislenka.

Perskaitykite įrodymus prieš kaltindami tunelį

Nuotolinių programų klaidos, perkrova ir įprastas praradimas taip pat sustabdo įkėlimus, todėl vienas nepavykęs perdavimas neatpažįsta juodosios skylės. Juos skiria dydžių santykis: kartojama sėkmė ties 1200 baitų ir kartojamas sustojimas ties 1400 baitų, ta pačia kryptimi, per tą patį galinį tašką.

Įrašas abiejuose galuose rodo didelius paketus išeinančius ir niekada neatvykstančius, be atmetimo tarp jų. Tai momentas žiūrėti į ribinį įrenginį, o ne į serverį, kuris atsako į kiekvieną iš tikrųjų gaunamą užklausą. Perkrova taip pat sustabdo, bet ji sustabdo skirtingus dydžius skirtingu metu, ir tai kitas parašas.

Patikrinkite taisymą abiem transportais

Palaikomas taisymas yra leisti ribai pranešti tikrąją ribą arba ten suspausti didžiausią TCP segmento dydį, kad nebūtų bandomas per didelis segmentas. Kiekvieno MTU tinkle mažinimas ar ugniasienės išjungimas paslepia simptomą ir palieka konfigūraciją, apie kurią vėliau niekas negalės samprotauti.

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

Patikrinkite tuo pačiu dydžio testu, tada programa, kuri nepavyko, ir patikrinkite antrą protokolą, nes UDP programos niekada negauna TCP segmento dydžio korekcijos. Išsaugokite pradines reikšmes biliete, nes negrįžtamas taisymas yra antra problema, laukianti įvykti. Jei dydžio testas praeina, o įkėlimas vis dar sustoja, juodoji skylė nebuvo priežastis, ir tyrimas turėtų tęstis, o ne plėsti pakeitimą.