IPv6-paket för stort: varför stora VPN-överföringar stoppar

Ping fungerar, webbläsaren laddar en liten sida och filöverföringen hänger sig, allt över IPv6 genom samma tunnel. Det mönstret betyder oftast att avsändaren aldrig lärde sig den verkliga storleken på vägen, inte att tunneln är långsam. IPv6 förväntar sig att routrar rapporterar problemet med ett Packet Too Big-meddelande, och inkapslingen lägger till overhead innan ett paket ens når det yttre nätet. Om det meddelandet filtreras fortsätter avsändaren att upprepa en storlek som inte kan passera.

Små förfrågningar, stora stopp

En tunnel packar in varje paket i ytterligare en rubrik, så den användbara storleken inuti är mindre än storleken utanför. Ett paket som dimensionerades för den fysiska länken före inkapslingen blir för stort efteråt. IPv4-routrar får fragmentera längs vägen, medan IPv6-routrar inte gör det för avsändarens räkning, så avsändaren måste anpassa sig själv i stället. Och den anpassningen beror helt på att få återkopplingen.

Ett enda förlorat meddelande räcker för det klassiska symptomet: handskakningar och små svar lyckas, och en kataloglistning eller en uppladdning fastnar alltid på samma punkt. Användare beskriver det som en långsam VPN, och loggarna visar inget fel i autentiseringen. Båda observationerna stämmer, och ingen av dem hittar felet.

Packet Too Big är återkoppling, inte trafik

Ett ICMPv6 Packet Too Big-meddelande bär storleken som nästa hopp kan acceptera, och avsändaren använder den för att sänka sin uppskattning. Att filtrera det är som att ta bort en vägskylt och sedan skylla på förarna. En regel som släpper all ICMPv6 ser sträng ut men bryter vägupptäckten på varje länk som behöver den. Meddelandet är styrinformation om vägen, inte programmets nyttolast.

Selektiv filtrering är fortfarande rimlig. Eko-förfrågningar och granndetektering spelar en annan roll än felmeddelanden, och en policy kan behandla dem annorlunda. Följ plattformens dokumenterade filtreringsvägledning i stället för att acceptera eller släppa hela protokollet, eftersom RFC 8201 definierar hur återkopplingen driver upptäckten.

Testa båda adressfamiljerna var för sig

Testa IPv6 för sig självt, eftersom en lyckad IPv4-överföring inte bevisar något om IPv6-vägen. Fånga sedan styrmeddelanden medan den stora överföringen hänger sig. De två fångsterna visar tillsammans antingen att återkopplingen lämnar värden eller bevisar att den aldrig 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 skickar ett paket med do-not-fragment-biten satt och rapporterar storleken där det misslyckas, det är talet som tunneln måste rymma. Rutfrågan namnger gränssnittet som skulle bära destinationen, så du vet vilken MTU för länken som gäller. Fångsten filtrerar ICMPv6 typ 2, Packet Too Big-meddelandet, och visar om det ens når den här värden. Om meddelandet visas i fångsten och överföringen fortfarande hänger sig ignorerar avsändaren det, vilket flyttar undersökningen till stacken i stället för nätet.

Ändra tunnelns storlek först efter bevisen

Att sänka tunnelns MTU kan dölja ett filtrerat meddelande och få symptomet att försvinna, men det kostar mer overhead per paket. Det är en kringgång och inte en diagnos, och den bör följa fångsten i stället för att ersätta den. Ett godtyckligt lågt värde bryter inte heller något synligt, och därför överlever det i konfigurationer i åratal. Ändra det medvetet, anteckna värdet och notera vilken mätning som motiverade det.

När du styr gatewayen ska du granska regeln som släpper meddelandet i stället för att stänga av brandväggen. En rättad regel är smalare än ett policyundantag och mycket lättare att försvara senare. Samma resonemang gäller för tidsgränser: inte varje stopp är ett storleksproblem, och fångsten är det som skiljer de två.