Zbulimi i MTU-së së rrugës përmes VPN: madhësia dhe boshllëku ICMP

Një tunel përfundon shtrëngimin e duarve, kërkesat e vogla kthehen, dhe transferimi i parë i madh ngec. Ky model tregon MTU-në e rrugës shumë më herët sesa tregon xhiron. Çdo lidhje përgjatë rrugës kufizon madhësinë e paketës, dhe kapsulimi shpenzon një pjesë të asaj lejeje për titujt e jashtëm, kështu që paketa e brendshme duhet të jetë më e vogël sesa do të sugjeronte rruga e papërpunuar. Dështimi është i heshtur, dhe kjo është ajo që e bën të shtrenjtë diagnostikimin.

Çfarë mat në të vërtetë MTU-ja e rrugës

MTU-ja e rrugës është MTU-ja më e vogël e lidhjes në rrugën mes dy hosteve, jo MTU-ja e shtypur në ndërfaqen tuaj lokale. Vlera lokale është pika ku fillon vlerësimi, dhe rruga vendos ku duhet të përfundojë. Kjo është arsyeja pse një tunel identik mund të funksionojë në një rrjet aksesi dhe të ngecë në një tjetër: ndryshoi rruga, jo konfigurimi. Të matësh një herë dhe të supozosh kudo është gabimi që e mban këtë problem gjallë.

Për një tunel, numri që ka rëndësi është MTU-ja e brendshme, që është leja e rrugës së jashtme minus atë që konsumon kapsulimi. WireGuard shton një titull IP të jashtëm dhe një titull UDP; transportet e tjera shtojnë të vetat. Vendosni madhësinë e brendshme shumë lart dhe çdo paketë me madhësi të plotë do të ketë nevojë për fragmentim që ndoshta nuk ndodh kurrë.

Pse një tunel e zvogëlon paketën e përdorshme

Nëse ndërfaqja e tunelit mban MTU-në e lidhjes fizike, çdo paketë e madhe varet nga fakti se dikush më poshtë është i gatshëm ta fragmentojë. IPv4 e lejon këtë në parim, por një ruter që i është thënë të mos fragmentojë kthen një gabim. Ruterët IPv6 nuk fragmentojnë kurrë në tranzit, kështu që e njëjta cilësim sillet ndryshe sipas familjes së adresave. Në çdo rast, dërguesi nuk mëson asgjë derisa diçka të raportojë mbrapsht.

Pasojë praktike është një madhësi që hyn në shtrëngimin e duarve dhe jo në ngarkesën e dobishme. Një TLS ClientHello ose një pyetës DNS është mjaft i vogël për të kaluar një rrugë të zvogëluar pa u prekur, ndërsa një transferim masiv nuk është. Prandaj simptomat grumbullohen rreth operacioneve të caktuara dhe jo hosteve të caktuara.

Zbulimi funksionon vetëm kur arrin reagimi

Zbulimi IPv4 mbështetet në bitin don't-fragment: një ruter që nuk mund ta përçojë paketën kthen ICMP fragmentation-needed me MTU-në e hopit tjetër, dhe dërguesi ul vlerësimin e tij. IPv6 përdor në vend të kësaj mesazhe Packet Too Big, sepse ruterët nuk fragmentojnë në tranzit. Të dy mekanizmat supozojnë se mesazhi e gjen rrugën përsëri te dërguesi, përmes tunelit dhe përtej çdo muri zjarri në rrugën e kthimit. Kur ky supozim dështon, dërguesi vazhdon të provojë përsëri një madhësi që rruga nuk mund ta mbajë.

Një mur zjarri që lejon echo request dhe echo reply nuk ka lejuar domosdoshmërisht ato lloje gabimesh. ICMP është një familje, dhe anëtarët që kanë rëndësi këtu janë gabimet, jo çifti i jehonës. Kontrolloni politikën e trafikut të kontrollit në të dy skajet e tunelit dhe në rrugën mes tyre, dhe ndiqni udhëzimin e mbështetur të platformës në vend që të lejoni çdo lloj ICMP kudo.

I njëjti filtrim mund të jetë brenda tunelit. Nëse rruga e brendshme e hedh gabimin, por rruga e jashtme e mbart atë, dërguesi mund të përshtatet me një kufi që trafiku i kapsuluar nuk e sheh kurrë me të vërtetë.

Provo rrugën në vend që të hamendësosh një numër

Mbaj destinacionin, rrjetin e aksesit dhe tunelin fiks, pastaj ndrysho vetëm madhësinë e paketës. Një provë don't-fragment që dështon me një aluzion MTU ju jep kufirin e hopit tjetër; përsëritni derisa të kalojë një madhësi, dhe regjistroni si madhësinë ashtu edhe familjen e adresave.

ping -M do -s 1400 10.60.20.10
ping -M do -s 1300 10.60.20.10
ping -6 -M do -s 1300 2001:db8::10

Një ping që hyn nuk provon se segmentet me madhësi të plotë të një aplikacioni real hyjnë, prandaj përsëritni testin me transferimin që dështoi vërtet. Krahasoni provën më të madhe që funksionoi me MTU-në e tunelit që konfiguruat, dhe mbajini dy numrat të ndarë në shënimet tuaja. Nëse ndryshojnë me rreth një titull, keni gjetur mbikosto të kapsulimit dhe jo një defekt.

PLPMTUD, i përshkruar në RFC 4821, provon lart dhe përdor konfirmime transporti në vend që të besojë gabimet e dorëzuara. Ndihmon në rrugët që filtrojnë ICMP, por mbështetja ndryshon sipas stakut dhe aplikacionit. Një rrjedhë TCP mund të rimëkëmbet vetë, ndërsa një aplikacion UDP me madhësi fikse të datagramit vazhdon të dështojë.

Zgjidh një vlerë dhe regjistro arsyetimin

Ulja e MTU-së së tunelit është njëkohësisht diagnozë dhe rregullim legjitim sapo ta njihni rrugën. Nuk zëvendëson njohjen e asaj se cila rrugë dhe cili mekanizëm reagimi ishin të përfshirë, sepse një vlerë e akorduar për një lidhje mobile do të jetë e panevojshme e vogël në një lidhje fibri. Regjistroni madhësinë e zgjedhur, provën që e justifikoi dhe hapin e kthimit.

Mekanizmi IPv4 përshkruhet në RFC 1191 dhe udhëzimi i paketizimit IPv6 në RFC 8201; përmendja e të dyjave e pengon inxhinierin tjetër të nxjerrë përsëri supozimin. Nëse transferimi ende ngec në madhësinë që zgjodhët, ndaloni uljen e numrit dhe shikoni shtresën tjetër. Një rrugë që dështon në çdo madhësi nuk është problem MTU.