Paketa IPv6 shumë e madhe: pse transferimet e mëdha të VPN ngecin

Ping funksionon, shfletuesi ngarkon një faqe të vogël dhe transferimi i skedarit ngec, të gjitha përmes IPv6 në të njëjtin tunel. Ky model zakonisht do të thotë që dërguesi nuk e mësoi kurrë madhësinë reale të rrugës, jo se tuneli është i ngadalshëm. IPv6 pret që ruterat të raportojnë problemin me një mesazh Packet Too Big, dhe kapsulimi shton barrë shtesë përpara se një paketë të arrijë rrjetin e jashtëm. Nëse ai mesazh filtrohet, dërguesi vazhdon të përsëritë një madhësi që nuk mund të kalojë.

Kërkesa të vogla, ngecje të mëdha

Një tunel e mbështjell çdo paketë në një kokë tjetër, kështu që madhësia e përdorshme brenda është më e vogël se madhësia jashtë. Një paketë e dimensionuar për lidhjen fizike përpara kapsulimit bëhet shumë e madhe pas tij. Ruterat IPv4 mund të fragmentojnë në rrugë, ndërsa ruterat IPv6 nuk e bëjnë këtë në emër të dërguesit, prandaj dërguesi duhet të përshtatet vetë. Dhe ky përshtatje varet plotësisht nga marrja e reagimit.

Një mesazh i humbur mjafton për simptomën klasike: shtrëngimet e duarve dhe përgjigjet e vogla ia dalin, dhe një listim drejtorie ose një ngarkim ngec gjithmonë në të njëjtën pikë. Përdoruesit e përshkruajnë si VPN të ngadalshme, dhe regjistrat nuk tregojnë asgjë të gabuar në vërtetim. Të dy vëzhgimet janë të sakta dhe asnjëri nuk e gjen vendin e defektit.

Packet Too Big është reagim, jo trafik

Një mesazh ICMPv6 Packet Too Big mbart madhësinë që hapi tjetër mund të pranojë, dhe dërguesi e përdor atë për të ulur vlerësimin e vet. Filtrimi i tij është e njëjta gjë si të heqësh një shenjë rrugore dhe pastaj të fajësosh shoferët. Një rregull që hedh poshtë të gjithë ICMPv6 duket i rreptë, por thyen zbulimin e rrugës në çdo lidhje që ka nevojë për të. Mesazhi është informacion kontrolli për rrugën, jo ngarkesë e aplikacionit.

Filtrimi selektiv mbetet i arsyeshëm. Kërkesat e ehos dhe zbulimi i fqinjëve luajnë rol të ndryshëm nga mesazhet e gabimit, dhe një politikë mund t'i trajtojë ndryshe. Ndiqni udhëzimet e dokumentuara të filtrimit të platformës në vend që të pranoni ose hidhni poshtë të gjithë protokollin, sepse RFC 8201 përcakton se si ai reagim drejton zbulimin.

Testoni të dy familjet e adresave veçmas

Testoni IPv6 veçmas, sepse një transferim IPv4 i suksesshëm nuk provon asgjë për rrugën IPv6. Më pas kapni mesazhet e kontrollit ndërsa transferimi i madh ngec. Të dy regjistrimet bashkë ose tregojnë se reagimi po del, ose provojnë se ai nuk mbërriti kurrë.

ping -6 -M do -s 1400 host.internal
ip -6 route get 2001:db8:2::10
sudo tcpdump -ni any 'icmp6 and ip6[40] == 2'

Sonda dërgon një paketë me bitin do-not-fragment të vendosur dhe raporton madhësinë në të cilën dështon, që është numri që tuneli duhet të mbajë. Pyetja e rrugës emërton ndërfaqen që do të mbante destinacionin, kështu që e dini cili MTU i lidhjes zbatohet. Kapja filtron ICMPv6 tipin 2, mesazhin Packet Too Big, dhe tregon nëse ai arrin fare në këtë host. Nëse mesazhi shfaqet në kapje dhe transferimi vazhdon të ngecë, dërguesi po e injoron atë, gjë që e zhvendos hetimin te stiva dhe jo te rrjeta.

Ndryshoni madhësinë e tunelit vetëm pas provave

Ulja e MTU-së së tunelit mund të fshehë një mesazh të filtruar dhe ta bëjë simptomën të zhduket, me koston e më shumë barrë për çdo paketë. Është një anashkalim dhe jo një diagnozë, dhe duhet të vijë pas kapjes, jo ta zëvendësojë atë. Një vlerë arbitrare e ulët as nuk thyen asgjë të dukshme, prandaj mbijeton me vite në konfigurime. Ndryshojeni me qëllim, shënoni vlerën dhe vini re cila matje e justifikoi.

Kur kontrolloni portën, shqyrtoni rregullin që e hedh poshtë mesazhin në vend që të çaktivizoni murin e zjarrit. Një rregull i korrigjuar është më i ngushtë se një përjashtim politikë dhe shumë më i lehtë për t'u mbrojtur më vonë. I njëjti arsyetim vlen për afatet kohore: nuk është çdo ngecje problem madhësie, dhe kapja është ajo që i ndan të dyja.