MTU zulo beltza: zergatik eskaera txikiek funtzionatzen duten eta igotzeek blokeatzen diren

Orrialde bat kargatzen da, API dei txiki bat itzultzen da, eta gero fitxategi igotze bat zintzilik geratzen da bezeroak amore eman arte. Zerbitzariaren erregistroan ezerk ez du hori azaltzen, paketeak bidearen erdian bota baitziren, erantzun erabilgarririk bidali gabe. Eredu hori MTU zulo beltza da: bidaltzaileak uste duena baino estuagoa den esteka bat, gehi hori esateari uko egite isila. Huts egiten duen tamaina errepikakorra da, eta horrek egiten du diagnostikagarri.

Zer egiten du zuloa beltz

Esteka bakoitzak transmisio-unitate maximoa du, eta hurrengo jauziaren muga baino handiagoa den paketea zatikatu edo hori dioen ICMP mezu batekin baztertu behar da. Bidearen MTU aurkikuntzak mezu hori iristea eta errespetatzea du baldintza. Hori iragazteak edo ezikusteak bidaltzailea inoiz sartuko ez den paketea errepikatzen uzten du.

Kapsulatzeak ohiko egiten du hau VPN-en inguruan, tuneleak kanpoko goiburua gehitzen baitio jada esteka fisikoarako dimentsionatuta zegoen paketeari. Barneko paketea legezkoa da 1500 bytekin eta kapsulatutakoa ez, beraz mugan hiltzen da pakete txikiak aurrera egiten duten bitartean. Amaitutako handshake batek eta funtzionatzen duen saio-hasierako orrialdeak pakete txikiek funtzionatzen dutela baino ez dute frogatzen. Aplikazioak bidaltzen saiatzen den paketerik handiena da garrantzitsua.

Aurkitu tamaina, non hausten den

Bilatu bitarrez karga-tamaina zatikatu gabeko proba batekin, tunelearen alde bateko ostalaritik beste aldera. Arrakasta lortzen duen karga handiena zure bide-MTU erabilgarria da ken goiburuaren gainkarga.

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 byteko karga batek arrakasta lortzen du 1500 byteko Ethernet bide garbi batean, IPv4 eta ICMP goiburuen 28 byteak gehituta. Proba berak karga txikiagoarekin baino arrakasta lortzen ez duenean tunela altxatu ondoren, aldea kapsulatzearen gainkarga da, eta tunelaren muga da errefusatze-mezua sortu behar zen lekua. Idatzi bi zenbakiak, konektatu aurretik eta ondoren, bikote hori baita froga. Errepikatu proba IPv6rako aplikazioak erabiltzen duenean, goiburua handiagoa baita eta hutsegite-ataria mugitzen baita.

Irakurri frogak tunela errudun egin aurretik

Urrutiko aplikazioen erroreek, kongestioak eta galera arruntak igotzeak ere blokeatzen dituzte, beraz transferentzia huts batek ez du zulo beltzik identifikatzen. Hauek bereizten dituena tamainen erlazioa da: arrakasta errepikakorra 1200 bytekin eta blokeo errepikakorra 1400 bytekin, norabide berean, amaiera-puntu beretik.

Bi muturretako kapturak erakusten du pakete handiak irteten eta inoiz iristen ez direla, tartean errefusatzerik gabe. Hori da zerbitzariari beharrean muga-gailuari begiratzeko unea, zerbitzariak jasotzen duen eskaera bakoitzari erantzuten baitio. Kongestioak ere blokeatzen du, baina tamaina desberdinak blokeatzen ditu une desberdinetan, eta hori sinadura desberdina da.

Egiaztatu konponketa bi garraioetan

Onartutako konponketa muga-gailuak benetako muga jakinaraztea da, edo han TCPren segmentu-tamaina maximoa finkatzea, segmentu handiegirik saia ez dadin. Sareko MTU guztiak jaisteak, edo suebakia desgaitzeak, sintoma ezkutatzen du eta geroago inork arrazoitu ezingo duen konfigurazioa uzten du.

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

Egiaztatu tamaina-proba berarekin, gero huts egin zuen aplikazioarekin, eta egiaztatu bigarren protokolo bat, UDP aplikazioek ez baitute inoiz TCPren segmentu-tamainaren zuzenketa jasotzen. Gorde jatorrizko balioak txartelean, alderantzikatu ezin den konponketa gertatzeko zain dagoen bigarren arazoa baita. Tamaina-probak gainditzen badu eta igotzeak oraindik blokeatzen badu, zulo beltza ez zen arrazoia, eta ikerketak aurrera egin behar du aldaketa zabaldu beharrean.