IPv6 genom en IPv4 VPN-server kräver fortfarande en IPv6-utgång

Tunneln kommer upp, klienten får en IPv6-adress från poolen, och ändå tar varje IPv6-destination slut på tid. Ingenting är trasigt i tunneln: IPv6 färdas alldeles utmärkt inuti IPv4-transporten, och det var aldrig den svåra delen. Adressen du delade ut är ett löfte som servern inte kan hålla, eftersom utgången inte har någon IPv6-upstream att skicka den till. Reparationen hör hemma vid utgången, inte i klientprofilen.

Symtomet: en adress och ingen väg

En kontroll på klientsidan visar en IPv6-adress som ser global ut på tunnelenheten och en rutt som pekar in i den, och därför läses detta felaktigt som en klientbugg. Trafiken går in i tunneln, servern dekapsulerar den, och sedan landar paketet på en värd vars routingtabell inte har någon IPv6-standardrutt till någon verklig plats. Beroende på stacken får du omedelbar oåtkomlighet eller ett tyst tapp, och i båda fallen ser klienten en timeout som ser identisk ut med en brandvägg.

Läs serverns egen routingtabell innan du rör klienten, för det är där den saknade halvan av vägen bor. En server med en enda IPv4-standardrutt har redan gett dig svaret.

Följ paketet efter dekapsuleringen

Inuti tunneln är paketet vanlig IPv6 och klientens adress är källan. Servern tar bort transportinkapslingen och håller då ett inhemskt IPv6-paket som måste vidarebefordras till nästa IPv6-hopp. En IPv4-standardrutt kan inte bära det, och att översätta det till IPv4 är en annan funktion som ingen har rullat ut. Det är hela felet, och det har ingenting att göra med om VPN-lyssnaren svarade över IPv4.

Mekaniken för IPv6-over-IPv4-inkapsling beskrivs i RFC 4213, och den viktiga detaljen där är att ändpunkterna fortfarande behöver riktig IPv6-anslutning på andra sidan tunneln. Att packa in en rubrik trollar inte fram en upstream.

Två tunnellager, två oberoende kontroller

Verifiera varje lager separat, eftersom en fungerande yttre tunnel döljer en trasig inre. Kontrollera den yttre vägen med en IPv4-ping från klienten till servern och bekräfta porten du använder. Kontrollera sedan den inre vägen på servern, där ip -6 route måste visa en standardrutt eller en konkret rutt inlärd från en riktig upstream, och ip -6 addr måste visa ett källprefix som upstreamen accepterar. Allt mindre är dekoration på gränssnittet.

En unik-lokal adress, eller ett prefix som ser globalt ut och som ingenting routar tillbaka till, dyker glatt upp på ett gränssnitt och går ingenstans. Offentlig nåbarhet ges av upstreamen, inte av adressens form.

Samma sak gäller på klienten: ip -6 route get 2001:4860:4860::8888 bör namnge tunnelenheten, och om den namnger den fysiska använder klienten inte VPN för IPv6 alls.

Källprefix, storlek och ICMPv6

Fråga upstreamen vilka källprefix den accepterar för vidarebefordran, och använd ett av dem för klientpoolen. En leverantör som ger dig ett /64 för serverns eget gränssnitt routar inte nödvändigtvis ett andra /64 eller ett större block till dig, och skillnaden är en eftermiddag av felsökning som en supportbiljett avgör med en fråga. Fråga skriftligt och spara svaret tillsammans med konfigurationen.

Budgetera för den extra inkapsling som din stack faktiskt använder, och håll ICMPv6 igång, inklusive Packet Too Big. En andra rubrik krymper den användbara nyttolasten, så en väg som svarar på små ping kan ändå misslyckas vid en filöverföring, och en brandvägg som släpper all ICMPv6 förvandlar ett reparerbart storleksproblem till ett svart hål. Testa en stor överföring innan du annonserar tjänsten.

Vad som är ett helt annat problem

Att nå en applikation som bara är IPv4 från en klient som bara är IPv6 är översättning, inte tunnling, och kräver något som en medvetet utrullad NAT64-lösning. Destinationen kommer inte att förstå en extra tunnelrubrik bara för att du lade till en. Historiska övergångstjänster förtjänar samma omsorg: RFC 7526 avskaffade 6to4-anycast-relämodellen, så en guide skriven kring den beskriver något som inte längre har ett underhållet offentligt relä.

Om servern inte har någon användbar IPv6-upstream är valen en stödd upstream, en annan utgång eller ett dokumenterat beslut att IPv6 stannar utanför tunneln. Det som inte är acceptabelt är att berätta för klienter att en IPv6-tjänst finns medan deras vanliga IPv6-anslutning tyst förbigår VPN.