Černá díra MTU: proč malé požadavky fungují, ale nahrávání se zasekne
Malé požadavky skončí, zatímco velké nahrávání visí navěky a odesílatel se nikdy nedozví, že cesta je užší. Změřte přesnou velikost, na které to praskne.
Stránka se načte, malé volání API se vrátí a potom nahrávání souboru visí, dokud to klient nevzdá. Nic v protokolu serveru to nevysvětluje, protože pakety byly zahozeny uprostřed cesty, aniž by byla odeslána užitečná odpověď. Tento vzorec je černá díra MTU: spoj užší, než odesílatel předpokládá, plus tiché odmítnutí to říct. Velikost, na které to selhává, je opakovatelná, a právě to ji činí diagnostikovatelnou.
Co dělá díru černou
Každý spoj má maximální přenosovou jednotku a paket větší než limit dalšího skoku musí být buď fragmentován, nebo odmítnut zprávou ICMP, která to říká. Zjišťování MTU cesty závisí na tom, že tato zpráva dorazí a bude respektována. Filtrování nebo ignorování ponechává odesílatele opakovat paket, který se nikdy nevejde.
Zapouzdření to dělá běžným u VPN, protože tunel přidává vnější hlavičku paketu, který už byl dimenzován pro fyzický spoj. Vnitřní paket je legální při 1500 bajtech a zapouzdřený ne, takže umírá na hranici, zatímco malé pakety proplouvají. Dokončený handshake a fungující přihlašovací stránka dokazují jen to, že malé pakety fungují. Nejdůležitější je největší paket, který se aplikace snaží odeslat.
Najděte velikost, na které to praskne
Binárním vyhledáváním najděte velikost užitečného zatížení testem bez fragmentace, z hostitele na jedné straně tunelu na hostitele na druhé. Největší užitečné zatížení, které projde, je vaše použitelné MTU cesty mínus režie hlavičky.
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
Užitečné zatížení 1472 bajtů projde na čisté cestě Ethernet o 1500 bajtech, jakmile se přidá 28 bajtů hlaviček IPv4 a ICMP. Když stejný test projde jen s menším zatížením poté, co je tunel nahoře, je rozdílem režie zapouzdření a hranice tunelu je místem, kde měla být vygenerována zpráva o odmítnutí. Zapište obě čísla, před připojením a po něm, protože tato dvojice je důkaz. Zopakujte test pro IPv6, pokud ho aplikace používá, protože hlavička je větší a práh selhání se posouvá.
Přečtěte si důkazy, než obviníte tunel
Chyby vzdálených aplikací, zahlcení a běžné ztráty také zasekávají nahrávání, takže jeden neúspěšný přenos černou díru neidentifikuje. Odděluje je vztah velikostí: opakovatelný úspěch při 1200 bajtech a opakovatelné zaseknutí při 1400 bajtech, stejným směrem, přes stejný koncový bod.
Snímek na obou koncích ukazuje velké pakety odcházet a nikdy nedorazit, bez odmítnutí mezi nimi. To je okamžik podívat se na hraniční zařízení místo na server, který odpovídá na každý požadavek, který skutečně obdrží. Zahlcení také zasekává, ale zasekává různé velikosti v různých časech, což je jiný podpis.
Ověřte opravu na obou transportech
Podporovanou opravou je nechat hranici hlásit skutečný limit, nebo tam omezit maximální velikost segmentu TCP, aby se nezkoušel žádný nadměrný segment. Snižování každého MTU v síti nebo vypnutí firewallu skrývá symptom a zanechává konfiguraci, o níž nikdo později nedokáže uvažovat.
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
Ověřte stejným testem velikosti, potom aplikací, která selhala, a zkontrolujte druhý protokol, protože aplikace UDP nikdy nedostanou korekci velikosti segmentu TCP. Ponechte původní hodnoty v tiketu, protože oprava, kterou nelze vrátit, je druhý problém čekající na vznik. Pokud test velikosti projde a nahrávání se stále zasekává, černá díra nebyla příčinou a vyšetřování má pokračovat, místo aby se změna rozšiřovala.