IPv6 gjennom en IPv4 VPN-server trenger fortsatt en IPv6-utgang

Tunnelen kommer opp, klienten får en IPv6-adresse fra poolen, og likevel går hver IPv6-destinasjon ut på tid. Ingenting er ødelagt i tunnelen: IPv6 går helt fint inne i IPv4-transporten, og det var aldri den vanskelige delen. Adressen du delte ut, er et løfte serveren ikke kan holde, fordi utgangen ikke har noen IPv6-upstream å sende den inn i. Reparasjonen hører til ved utgangen, ikke i klientprofilen.

Symptomet: en adresse og ingen vei

En sjekk på klientsiden viser en IPv6-adresse som ser global ut på tunneleenheten og en rute som peker inn i den, og derfor blir dette feiltolket som en klientfeil. Trafikken går inn i tunnelen, serveren dekapsulerer den, og deretter lander pakken på en vert hvis rutetabell ikke har noen standardrute for IPv6 til noe virkelig sted. Avhengig av stacken får du umiddelbar utilgjengelighet eller en stille dropp, og i begge tilfeller ser klienten en timeout som ser lik ut som en brannmur.

Les serverens egen rutetabell før du rører klienten, for det er der den manglende halvdelen av veien bor. En server med én standardrute for IPv4 har allerede gitt deg svaret.

Følg pakken etter dekapsuleringen

Inne i tunnelen er pakken vanlig IPv6, og klientens adresse er kilden. Serveren fjerner transportinnkapslingen og sitter da med en opprinnelig IPv6-pakke som må videresendes til neste IPv6-hopp. En standardrute for IPv4 kan ikke bære den, og å oversette den til IPv4 er en annen funksjon som ingen har rullet ut. Det er hele feilen, og den har ingenting å gjøre med om VPN-lytteren svarte over IPv4.

Mekanikken for IPv6-over-IPv4-innkapsling er beskrevet i RFC 4213, og den viktige detaljen der er at endepunktene fortsatt trenger ekte IPv6-tilkobling på den andre siden av tunnelen. Å pakke inn en header tryller ikke fram en upstream.

To tunnellag, to uavhengige sjekker

Bekreft hvert lag for seg, fordi en fungerende ytre tunnel skjuler en ødelagt indre. Sjekk den ytre veien med en IPv4-ping fra klienten til serveren, og bekreft porten du bruker. Sjekk deretter den indre veien på serveren, der ip -6 route må vise en standardrute eller en konkret rute lært fra en ekte upstream, og ip -6 addr må vise et kilde-prefiks som upstreamen godtar. Alt mindre er pynt på grensesnittet.

En unik-lokal adresse, eller et prefiks som ser globalt ut og som ingenting ruter tilbake til, dukker gjerne opp på et grensesnitt og går ingen steder. Offentlig tilgjengelighet gis av upstreamen, ikke av adressens form.

Det samme gjelder på klienten: ip -6 route get 2001:4860:4860::8888 bør navngi tunneleenheten, og hvis den navngir den fysiske, bruker klienten ikke VPN for IPv6 i det hele tatt.

Kilde-prefiks, størrelse og ICMPv6

Spør upstreamen hvilke kilde-prefikser den godtar for videresending, og bruk ett av dem til klientpoolen. En leverandør som gir deg et /64 for serverens eget grensesnitt, ruter ikke nødvendigvis et andre /64 eller en større blokk til deg, og forskjellen er en ettermiddag med feilsøking som en støtteticket avgjør med ett spørsmål. Spør skriftlig og ta vare på svaret sammen med konfigurasjonen.

Budsjetter for den ekstra innkapslingen stacken din faktisk bruker, og hold ICMPv6 i gang, inkludert Packet Too Big. En ekstra header krymper nyttelasten, så en vei som svarer på små ping, kan fortsatt feile ved en filoverføring, og en brannmur som slipper alle ICMPv6, gjør et reparerbart størrelsesproblem om til et svart hull. Test én stor overføring før du annonserer tjenesten.

Hva som er et helt annet problem

Å nå en applikasjon som bare er IPv4 fra en klient som bare er IPv6 er oversettelse, ikke tunnellering, og trenger noe som en bevisst utrullet NAT64-ordning. Destinasjonen vil ikke forstå en ekstra tunnelheader bare fordi du la til en. Historiske overgangstjenester fortjener samme omhu: RFC 7526 avviklet 6to4-anycast-relémodellen, så en veiledning skrevet rundt den beskriver noe som ikke lenger har et vedlikeholdt offentlig relé.

Hvis serveren ikke har noen brukbar IPv6-upstream, er valgene en støttet upstream, en annen utgang eller en dokumentert beslutning om at IPv6 blir utenfor tunnelen. Det som ikke er akseptabelt, er å fortelle klienter at en IPv6-tjeneste finnes, mens deres vanlige IPv6-tilkobling stille omgår VPN.