IPv6-pakke for stor: kvifor store VPN-overføringar stoppar

Ping verkar, nettlesaren lastar ei lita side, og filoverføringa stoppar, alt over IPv6 gjennom den same tunnelen. Det mønsteret tyder vanlegvis at avsendaren aldri lærte den verkelege storleiken på vegen, ikkje at tunnelen er treg. IPv6 ventar at rutarar rapporterer problemet med ei Packet Too Big-melding, og innkapsling legg til overhead før ein pakke i det heile når det ytre nettet. Viss den meldinga blir filtrert, held avsendaren fram med å gjenta ein storleik som ikkje kan passere.

Små førespurnader, store stopp

Ein tunnel pakkar kvar pakke inn i ein ny header, så den brukbare storleiken inni er mindre enn storleiken utanfor. Ein pakke som vart dimensjonert for den fysiske lenkja før innkapsling, blir for stor etterpå. IPv4-rutarar kan fragmentere undervegs, medan IPv6-rutarar ikkje gjer det på vegner av avsendaren, så avsendaren må tilpasse seg sjølv i staden. Og den tilpassinga er heilt avhengig av å ta imot tilbakemeldinga.

Éi tapt melding er nok til å framkalle det klassiske symptomet: handtrykk og små svar lukkast, og ei katalogliste eller ei opplasting stoppar på same punktet kvar gong. Brukarar skildrar det som ein treg VPN, og loggane viser ingenting gale med autentiseringa. Begge observasjonane er riktige, og ingen av dei finn feilen.

Packet Too Big er tilbakemelding, ikkje trafikk

Ei ICMPv6 Packet Too Big-melding ber storleiken neste hopp kan godta, og avsendaren brukar han til å senke anslaget sitt. Å filtrere henne svarar til å fjerne eit vegskilt og deretter leggje skulda på sjåførane. Ein regel som droppar all ICMPv6 ser streng ut, men øydelegg vegfinning på kvar lenkje som treng det. Meldinga er kontrollinformasjon om vegen, ikkje nyttelast frå applikasjonen.

Selektiv filtrering er framleis rimeleg. Ekko-førespurnader og nabo-oppdaging spelar andre roller enn feilmeldingar, og ein policy kan handsame dei annleis. Følg dei dokumenterte filtreringsrettleiingane til plattforma i staden for å godta eller droppe heile protokollen, fordi RFC 8201 definerer korleis den tilbakemeldinga driv oppdaginga.

Test begge adressefamiliane kvar for seg

Test IPv6 for seg sjølv, fordi ei vellukka IPv4-overføring beviser ingenting om IPv6-vegen. Ta så opp kontrollmeldingar medan den store overføringa stoppar. Dei to opptaka viser saman anten at tilbakemeldinga går ut, eller beviser at ho aldri kom fram.

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'

Sonden sender ein pakke med do-not-fragment-biten sett og rapporterer storleiken der han feilar, og det er talet tunnelen må romme. Rutespurnaden namngir grensesnittet som ville bera destinasjonen, så du veit kva MTU for lenkja som gjeld. Opptaket filtrerer ICMPv6 type 2, Packet Too Big-meldinga, og viser om ho i det heile når denne verten. Viss meldinga viser seg i opptaket og overføringa framleis stoppar, ignorerer avsendaren henne, noko som flyttar granskinga til stakken i staden for nettet.

Endre tunnelstorleiken først etter bevisa

Å senke MTU-en til tunnelen kan skjule ei filtrert melding og få symptomet til å forsvinne, men det kostar meir overhead per pakke. Det er ein omveg og ikkje ein diagnose, og han bør følgje opptaket i staden for å erstatte det. Ein vilkårleg låg verdi øydelegg heller ingenting synleg, og difor overlever han i konfigurasjonar i årevis. Endre han med vilje, noter verdien, og skriv kva måling som rettferdiggjorde han.

Når du styrer gatewayen, gransk regelen som droppar meldinga i staden for å slå av brannmuren. Éin retta regel er smalare enn eit policy-unntak og mykje lettare å forsvare seinare. Same resonnementet gjeld for tidsavbrot: ikkje kvar stopp er eit storleiksproblem, og eit opptak er det som skil dei to.