MTU crna rupa: zašto mali zahtjevi rade, a uploadi se zaglave

Mali zahtjevi završe dok veliki upload visi zauvijek, a pošiljalac nikada ne sazna da je put uži. Izmjerite tačnu veličinu na kojoj puca.

Stranica se učita, mali API poziv se vrati, a zatim upload datoteke visi dok klijent ne odustane. Ništa u serverskom logu to ne objašnjava, jer su paketi ispušteni na sredini puta bez ikakvog korisnog odgovora. Taj obrazac je MTU crna rupa: veza uža nego što pošiljalac pretpostavlja, plus nijemo odbijanje da to kaže. Veličina na kojoj puca je ponovljiva, i upravo to je čini dijagnostikovanom.

Šta rupu čini crnom

Svaka veza ima maksimalnu jedinicu prenosa, a paket veći od ograničenja sljedećeg skoka mora biti ili fragmentiran, ili odbijen ICMP porukom koja to kaže. Otkrivanje MTU puta zavisi od toga da ta poruka stigne i da se poštuje. Filtriranje ili ignorisanje ostavlja pošiljaoca da ponavlja paket koji nikada ne može stati.

Enkapsulacija to čini čestim oko VPN-a, jer tunel dodaje vanjsko zaglavlje paketu koji je već bio dimenzioniran za fizičku vezu. Unutrašnji paket je legalan na 1500 bajtova, a enkapsulirani nije, pa umire na granici dok mali paketi prolaze. Završen handshake i radna stranica za prijavu dokazuju samo da mali paketi rade. Najveći paket koji aplikacija pokušava poslati je onaj koji je bitan.

Pronađite veličinu na kojoj puca

Binarnim pretraživanjem pronađite veličinu payloada testom bez fragmentacije, od hosta na jednoj strani tunela do hosta na drugoj. Najveći payload koji uspije je vaš upotrebljivi MTU puta minus overhead zaglavlja.

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

Payload od 1472 bajta uspijeva na čistoj Ethernet putanji od 1500 bajtova kada se dodaju 28 bajtova IPv4 i ICMP zaglavlja. Kada isti test uspijeva samo pri manjem payloadu nakon podizanja tunela, razlika je overhead enkapsulacije, a granica tunela je mjesto gdje je poruka o odbijanju trebalo da bude generisana. Zapišite oba broja, prije i poslije povezivanja, jer je taj par dokaz. Ponovite test za IPv6 kada ga aplikacija koristi, jer je zaglavlje veće i prag kvara se pomjera.

Pročitajte dokaze prije nego okrivite tunel

Greške udaljenih aplikacija, zagušenje i običan gubitak takođe zaglave uploade, pa jedan neuspjeli prenos ne identifikuje crnu rupu. Razlikuje ih odnos veličina: ponovljiv uspjeh na 1200 bajtova i ponovljivo zaglavljivanje na 1400 bajtova, u istom smjeru, kroz istu krajnju tačku.

Snimak na oba kraja pokazuje velike pakete kako odlaze i nikada ne stižu, bez odbijanja između. To je trenutak da pogledate granični uređaj umjesto servera, koji odgovara na svaki zahtjev koji zaista primi. Zagušenje takođe zaglavi, ali zaglavi različite veličine u različito vrijeme, što je drugačiji potpis.

Provjerite popravku na oba transporta

Podržana popravka je da granica prijavi stvarno ograničenje, ili da se tu stisne TCP-ova maksimalna veličina segmenta kako se ne bi pokušavao preveliki segment. Snižavanje svakog MTU-a na mreži, ili isključivanje firewall-a, skriva simptom i ostavlja konfiguraciju o kojoj kasnije niko ne može 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

Provjerite istim testom veličine, zatim aplikacijom koja nije uspjela, i provjerite drugi protokol, jer UDP aplikacije nikada ne dobijaju TCP-ovu korekciju veličine segmenta. Sačuvajte originalne vrijednosti u tiketu, jer popravka koja se ne može poništiti je drugi problem koji čeka da se dogodi. Ako test veličine prođe, a upload se i dalje zaglavljuje, crna rupa nije bila uzrok, i istraga treba da ide dalje umjesto da širi promjenu.

Povezani članci