IPv6-pakke for stor: hvorfor store VPN-overføringer stopper

Ping virker, nettleseren laster en liten side, og filoverføringen stopper, alt over IPv6 gjennom den samme tunnelen. Det mønsteret betyr vanligvis at avsenderen aldri lærte den reelle størrelsen på banen, ikke at tunnelen er treg. IPv6 forventer at rutere rapporterer problemet med en Packet Too Big-melding, og innkapsling legger til overhead før en pakke i det hele tatt når det ytre nettet. Hvis den meldingen filtreres, fortsetter avsenderen å gjenta en størrelse som ikke kan passere.

Små forespørsler, store stopp

En tunnel pakker hver pakke inn i en ny header, så den brukbare størrelsen inni er mindre enn størrelsen utenfor. En pakke som ble dimensjonert for den fysiske linken før innkapsling, blir for stor etterpå. IPv4-rutere kan fragmentere underveis, mens IPv6-rutere ikke gjør det på vegne av avsenderen, så avsenderen må tilpasse seg selv i stedet. Og den tilpasningen avhenger helt av å motta tilbakemeldingen.

Én tapt melding er nok til å fremkalle det klassiske symptomet: håndtrykk og små svar lykkes, og en katalogliste eller en opplasting stopper på samme punkt hver gang. Brukere beskriver det som en treg VPN, og loggene viser ingenting galt med autentiseringen. Begge observasjonene er riktige, og ingen av dem finner feilen.

Packet Too Big er tilbakemelding, ikke trafikk

En ICMPv6 Packet Too Big-melding bærer størrelsen neste hopp kan godta, og avsenderen bruker den til å senke anslaget sitt. Å filtrere den er det samme som å fjerne et veiskilt og deretter legge skylden på sjåførene. En regel som dropper all ICMPv6 ser streng ut, men ødelegger banefinning på hver link som trenger det. Meldingen er kontrollinformasjon om banen, ikke nyttelast fra applikasjonen.

Selektiv filtrering er fortsatt rimelig. Ekko-forespørsler og nabo-oppdagelse spiller andre roller enn feilmeldinger, og en policy kan behandle dem annerledes. Følg plattformens dokumenterte filtreringsveiledning i stedet for å godta eller droppe hele protokollen, fordi RFC 8201 definerer hvordan tilbakemeldingen driver oppdagelsen.

Test begge adressefamiliene hver for seg

Test IPv6 for seg selv, fordi en vellykket IPv4-overføring beviser ingenting om IPv6-banen. Ta deretter opp kontrollmeldinger mens den store overføringen stopper. De to opptakene viser sammen enten at tilbakemeldingen går ut, eller beviser at den aldri kom frem.

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 en pakke med do-not-fragment-biten satt og rapporterer størrelsen der den feiler, og det er tallet tunnelen må romme. Rutespørringen navngir grensesnittet som ville bære destinasjonen, så du vet hvilken MTU for linken som gjelder. Opptaket filtrerer ICMPv6 type 2, Packet Too Big-meldingen, og viser om den i det hele tatt når denne verten. Hvis meldingen vises i opptaket og overføringen fortsatt stopper, ignorerer avsenderen den, noe som flytter undersøkelsen til stakken i stedet for nettet.

Endre tunnelstørrelsen først etter bevisene

Å senke tunnelens MTU kan skjule en filtrert melding og få symptomet til å forsvinne, men det koster mer overhead per pakke. Det er en omvei og ikke en diagnose, og den bør følge opptaket i stedet for å erstatte det. En vilkårlig lav verdi ødelegger heller ingenting synlig, og derfor overlever den i konfigurasjoner i årevis. Endre den bevisst, noter verdien, og skriv hvilken måling som rettferdiggjorde den.

Når du styrer gatewayen, undersøk regelen som dropper meldingen i stedet for å slå av brannmuren. Én rettet regel er smalere enn et policy-unntak og mye lettere å forsvare senere. Samme resonnement gjelder for tidsavbrudd: ikke hver stopp er et størrelsesproblem, og et opptak er det som skiller de to.