Čierna diera MTU: prečo malé požiadavky fungujú, ale nahrávanie sa zasekne

Malé požiadavky sa dokončia, kým veľké nahrávanie visí navždy, a odosielateľ sa nikdy nedozvie, že cesta je užšia. Zmerajte presnú veľkosť, pri ktorej to praskne.

Stránka sa načíta, malé volanie API sa vráti a potom nahrávanie súboru visí, kým to klient nevzdá. Nič v protokole servera to nevysvetľuje, pretože pakety boli zahodené uprostred cesty bez odoslania užitočnej odpovede. Tento vzor je čierna diera MTU: spoj užší, než odosielateľ predpokladá, plus tiché odmietnutie to povedať. Veľkosť, pri ktorej to zlyhá, je opakovateľná, a práve to ju robí diagnostikovateľnou.

Čo robí dieru čiernou

Každý spoj má maximálnu prenosovú jednotku a paket väčší ako limit ďalšieho skoku musí byť buď fragmentovaný, alebo odmietnutý správou ICMP, ktorá to hovorí. Zisťovanie MTU cesty závisí od toho, či tá správa dorazí a bude rešpektovaná. Filtrovanie alebo ignorovanie ponecháva odosielateľa opakovať paket, ktorý sa nikdy nezmestí.

Zapuzdrenie to robí bežným okolo VPN, pretože tunel pridáva vonkajšiu hlavičku paketu, ktorý už bol dimenzovaný pre fyzický spoj. Vnútorný paket je legálny pri 1500 bajtoch a zapuzdrený nie, takže umiera na hranici, kým malé pakety prechádzajú. Dokončený handshake a fungujúca prihlasovacia stránka dokazujú len to, že malé pakety fungujú. Najdôležitejší je najväčší paket, ktorý sa aplikácia snaží odoslať.

Nájdite veľkosť, pri ktorej to praskne

Binárnym vyhľadávaním nájdite veľkosť užitočného zaťaženia testom bez fragmentácie, z hostiteľa na jednej strane tunela na hostiteľa na druhej. Najväčšie užitočné zaťaženie, ktoré prejde, je vaše použiteľné MTU cesty mínus réžia 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žitočné zaťaženie 1472 bajtov prejde na čistej ceste Ethernet s 1500 bajtmi, keď sa pridá 28 bajtov hlavičiek IPv4 a ICMP. Keď ten istý test prejde len s menším zaťažením po zdvihnutí tunela, rozdielom je réžia zapuzdrenia a hranica tunela je miesto, kde mala byť vygenerovaná správa o odmietnutí. Zapíšte obe čísla, pred pripojením a po ňom, pretože tá dvojica je dôkaz. Zopakujte test pre IPv6, keď ho aplikácia používa, pretože hlavička je väčšia a prah zlyhania sa posúva.

Prečítajte si dôkazy, skôr než obviníte tunel

Chyby vzdialených aplikácií, preťaženie a bežné straty tiež zasekávajú nahrávanie, takže jeden neúspešný prenos neidentifikuje čiernu dieru. Oddeľuje ich vzťah veľkostí: opakovateľný úspech pri 1200 bajtoch a opakovateľné zaseknutie pri 1400 bajtoch, rovnakým smerom, cez ten istý koncový bod.

Snímka na oboch koncoch ukazuje veľké pakety odchádzať a nikdy nedoraziť, bez odmietnutia medzi nimi. To je okamih pozrieť sa na hraničné zariadenie namiesto servera, ktorý odpovedá na každú požiadavku, ktorú skutočne dostane. Preťaženie tiež zasekáva, ale zasekáva rôzne veľkosti v rôznych časoch, a to je iný podpis.

Overte opravu na oboch transportoch

Podporovaná oprava je nechať hranicu hlásiť skutočný limit, alebo tam obmedziť maximálnu veľkosť segmentu TCP, aby sa neskúšal žiadny nadmerný segment. Znižovanie každého MTU v sieti alebo vypnutie firewallu skrýva symptóm a zanecháva konfiguráciu, o ktorej neskôr nikto nedokáže uvažovať.

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

Overte tým istým testom veľkosti, potom aplikáciou, ktorá zlyhala, a skontrolujte druhý protokol, pretože aplikácie UDP nikdy nedostanú korekciu veľkosti segmentu TCP. Ponechajte pôvodné hodnoty v tikete, pretože oprava, ktorú nemožno vrátiť, je druhý problém čakajúci na vznik. Ak test veľkosti prejde a nahrávanie sa stále zasekáva, čierna diera nebola príčinou a vyšetrovanie má pokračovať, namiesto rozširovania zmeny.

Súvisiace články