IPv6-pakke for stor: hvorfor store VPN-overførsler går i stå

Ping virker, browseren indlæser en lille side, og filoverførslen går i stå, alt sammen over IPv6 gennem den samme tunnel. Det mønster betyder som regel, at afsenderen aldrig lærte stiens reelle størrelse, ikke at tunnelen er langsom. IPv6 forventer, at routere rapporterer problemet med en Packet Too Big-besked, og indkapsling tilføjer overhead, før en pakke overhovedet når det ydre netværk. Hvis den besked filtreres, bliver afsenderen ved med at gentage en størrelse, der ikke kan komme igennem.

Små anmodninger, store stop

En tunnel pakker hver pakke ind i endnu et headere, så den brugbare størrelse indeni er mindre end størrelsen udenfor. En pakke, der blev dimensioneret til det fysiske led før indkapslingen, bliver for stor bagefter. IPv4-routere må fragmentere undervejs, mens IPv6-routere ikke gør det på afsenderens vegne, så afsenderen må tilpasse sig i stedet. Og den tilpasning afhænger helt af at modtage feedbacken.

En enkelt tabt besked er nok til at fremkalde det klassiske symptom: håndtryk og små svar lykkes, og en mappeliste eller en upload går i stå samme sted hver gang. Brugerne beskriver det som en langsom VPN, og logfilerne viser intet galt med godkendelsen. Begge observationer er korrekte, og ingen af dem finder fejlen.

Packet Too Big er feedback, ikke trafik

En ICMPv6 Packet Too Big-besked bærer den størrelse, det næste hop kan acceptere, og afsenderen bruger den til at sænke sit skøn. At filtrere den svarer til at fjerne et vejskilt og derefter bebrejde bilisterne. En regel, der dropper al ICMPv6, ser streng ud, men ødelægger stifinding på hvert led, der har brug for det. Beskeden er kontrolinformation om stien, ikke applikationsnyttelast.

Selektiv filtrering er stadig rimelig. Ekkoanmodninger og nabo-opdagelse spiller andre roller end fejlmeddelelser, og en politik kan behandle dem forskelligt. Følg platformens dokumenterede filtreringsvejledning i stedet for at acceptere eller droppe hele protokollen, fordi RFC 8201 definerer, hvordan den feedback styrer opdagelsen.

Test begge adressefamilier hver for sig

Test IPv6 for sig selv, fordi en vellykket IPv4-overførsel ikke beviser noget om IPv6-stien. Optag derefter kontrolbeskeder, mens den store overførsel går i stå. De to optagelser viser sammen enten, at feedbacken forlader systemet, eller beviser, at den aldrig nåede 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-bitten sat og rapporterer den størrelse, hvor den fejler, og det er det tal, tunnelen skal kunne rumme. Ruteanmodningen angiver det interface, der ville bære destinationen, så du ved, hvilken MTU for leddet der gælder. Optagelsen filtrerer ICMPv6 type 2, Packet Too Big-beskeden, og viser, om den overhovedet når denne vært. Hvis beskeden optræder i optagelsen, og overførslen stadig går i stå, ignorerer afsenderen den, hvilket flytter undersøgelsen til stakken i stedet for netværket.

Juster tunnelstørrelsen først efter beviserne

At sænke tunnelens MTU kan skjule en filtreret besked og få symptomet til at forsvinde, men det koster mere overhead på hver pakke. Det er en omvej og ikke en diagnose, og den bør følge optagelsen i stedet for at erstatte den. En vilkårligt lav værdi ødelægger heller intet synligt, og derfor overlever den i konfigurationer i årevis. Ændr den bevidst, noter værdien, og skriv, hvilken måling der berettigede den.

Når du styrer gatewayen, skal du undersøge den regel, der dropper beskeden, i stedet for at slå firewallen fra. Én rettet regel er smallere end en politikundtagelse og meget lettere at forsvare senere. Samme ræsonnement gælder for timeouts: ikke hver stagnation er et størrelsesproblem, og en optagelse er det, der skiller de to.