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

Stranica se učita, mali API poziv se vrati, a zatim prijenos datoteke visi dok klijent ne odustane. Ništa u zapisniku poslužitelja 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šiljatelj pretpostavlja, plus nijemo odbijanje da to kaže. Veličina na kojoj puca je ponovljiva, i upravo to je čini dijagnostičkom.

Što rupu čini crnom

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

Enkapsulacija to čini čestim oko VPN-ova, jer tunel dodaje vanjsko zaglavlje paketu koji je već bio dimenzioniran za fizičku vezu. Unutarnji 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 stazi 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 trebala biti generirana. 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 pomiče.

Pročitajte dokaze prije nego okrivite tunel

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

Snimka 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 poslužitelja, koji odgovara na svaki zahtjev koji zaista primi. Zagušenje također zaglavi, ali zaglavi različite veličine u različito vrijeme, što je drugačiji potpis.

Provjerite popravak 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 vatrozida, skriva simptom i ostavlja konfiguraciju o kojoj kasnije nitko 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 dobivaju TCP-ovu korekciju veličine segmenta. Sačuvajte izvorne vrijednosti u tiketu, jer popravka koja se ne može poništiti drugi je problem koji čeka da se dogodi. Ako test veličine prođe, a prijenos se i dalje zaglavljuje, crna rupa nije bila uzrok, i istraga treba ići dalje umjesto da širi promjenu.