Vrima e zezë e MTU: pse kërkesat e vogla funksionojnë por ngarkimet ngecin

Një faqe ngarkohet, një thirrje e vogël API kthehet, dhe pastaj një ngarkim skedari varet derisa klienti të dorëzohet. Asgjë në regjistrin e serverit nuk e shpjegon këtë, sepse paketat u hodhën në mes të rrugës pa u kthyer një përgjigje e dobishme. Ky model është një vrimë e zezë MTU: një lidhje më e ngushtë nga sa supozon dërguesi, plus një refuzim i heshtur për ta thënë. Madhësia që dështon është e përsëritshme, dhe kjo është ajo që e bën të diagnostikueshme.

Çfarë e bën vrimën të zezë

Çdo lidhje ka një njësi maksimale transmetimi, dhe një paketë më e madhe se kufiri i hopit tjetër duhet ose të fragmentohet, ose të refuzohet me një mesazh ICMP që e thotë këtë. Zbulimi i MTU-së së rrugës varet nga ardhja e atij mesazhi dhe respektimi i tij. Filtrimi ose injorimi i tij e lë dërguesin të përsërisë një paketë që nuk futet kurrë.

Inkapsulimi e bën këtë të zakonshme rreth VPN-ve, sepse një tunel shton një kokë të jashtme një pakete që ishte dimensjonuar tashmë për lidhjen fizike. Paketa e brendshme është e ligjshme në 1500 bajt dhe ajo e inkapsuluar nuk është, kështu që vdes në kufi ndërsa paketat e vogla kalojnë. Një shtrëngim duarsh i përfunduar dhe një faqe hyrjeje që funksionon vërtetojnë vetëm se paketat e vogla funksionojnë. Paketa më e madhe që aplikacioni përpiqet të dërgojë është ajo që ka rëndësi.

Gjeni madhësinë ku prishet

Kërkoni binarisht madhësinë e ngarkesës me një provë pa fragmentim, nga një host në njërën anë të tunelit në një host në anën tjetër. Ngarkesa më e madhe që kalon është MTU-ja e rrugës që mund të përdorni minus kostot e kokës.

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

Një ngarkesë prej 1472 bajtësh kalon në një rrugë të pastër Ethernet prej 1500 bajtësh pasi shtohen 28 bajtët e kokave IPv4 dhe ICMP. Kur e njëjta provë kalon vetëm me një ngarkesë më të vogël pasi tuneli është ngritur, diferenca është kostoja e inkapsulimit, dhe kufiri i tunelit është vendi ku duhej të ishte krijuar mesazhi i refuzimit. Shënoni të dy numrat, para dhe pas lidhjes, sepse ai çift është prova. Përsëritni provën për IPv6 kur aplikacioni e përdor, pasi koka është më e madhe dhe pragu i dështimit lëviz.

Lexoni provat përpara se të fajësoni tunelin

Gabimet e aplikacioneve në distancë, bllokimi dhe humbja e zakonshme gjithashtu i ngecin ngarkimet, prandaj një transferim i dështuar nuk identifikon një vrimë të zezë. Ajo që i ndan është raporti i madhësive: një sukses i përsëritshëm në 1200 bajt dhe një ngecje e përsëritshme në 1400 bajt, në të njëjtin drejtim, përmes të njëjtit pikë fundore.

Një kapje në të dy skajet tregon paketat e mëdha duke dalë dhe duke mos mbërritur kurrë, pa refuzim në mes. Ai është momenti të shikoni pajisjen e kufirit në vend të serverit, i cili përgjigjet çdo kërkese që merr vërtet. Bllokimi gjithashtu ngec, por ngec madhësi të ndryshme në kohë të ndryshme, dhe kjo është një nënshkrim tjetër.

Verifikoni rregullimin në të dy transportet

Rregullimi i mbështetur është të lejohet kufiri të raportojë kufirin e vërtetë, ose të shtrëngohet atje madhësia maksimale e segmentit TCP që të mos provohet asnjë segment tepër i madh. Ulja e çdo MTU në rrjet, ose çaktivizimi i firewall-it, fsheh simptomën dhe lë një konfigurim për të cilin askush nuk do të mund të arsyetojë më vonë.

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

Verifikoni me të njëjtën provë madhësie, pastaj me aplikacionin që dështoi, dhe kontrolloni një protokoll të dytë, sepse aplikacionet UDP nuk marrin kurrë korrigjimin e madhësisë së segmentit TCP. Ruani vlerat origjinale në tiketë, sepse një rregullim që nuk mund të kthehet është një problem i dytë që pret të ndodhë. Nëse prova e madhësisë kalon dhe ngarkimi ende ngec, vrima e zezë nuk ishte shkaku, dhe hetimi duhet të vazhdojë në vend që të zgjerojë ndryshimin.