IPv6 gennem en IPv4 VPN-server kræver stadig en IPv6-udgang

Tunnellen kommer op, klienten får en IPv6-adresse fra poolen, og alligevel udløber hver IPv6-destination. Intet er i stykker i tunnellen: IPv6 kører ganske fint inde i IPv4-transporten, og det har aldrig været den svære del. Den adresse, du uddelte, er et løfte, som serveren ikke kan holde, fordi udgangen ikke har nogen IPv6-upstream at sende den ind i. Reparationen hører til ved udgangen, ikke i klientprofilen.

Symptomet: en adresse og ingen vej

Et tjek på klientsiden viser en IPv6-adresse, der ser global ud, på tunneleenheden og en rute, der peger ind i den, og derfor bliver dette fejltolket som en klientfejl. Trafikken går ind i tunnellen, serveren dekapsulerer den, og derefter lander pakken på en vært, hvis routingtabel ikke har nogen IPv6-standardrute til noget virkeligt sted. Afhængigt af stacken får du en øjeblikkelig uopnåelighed eller et stille drop, og i begge tilfælde ser klienten en timeout, der ligner en firewall til forveksling.

Læs serverens egen routingtabel, før du rører klienten, for det er der, den manglende halvdel af vejen bor. En server med én IPv4-standardrute har allerede givet dig svaret.

Følg pakken efter dekapsuleringen

Inde i tunnellen er pakken almindelig IPv6 med klientens adresse som kilde. Serveren fjerner transportindkapslingen og står derefter med en native IPv6-pakke, som skal videresendes til et IPv6-næstehop. En IPv4-standardrute kan ikke bære den, og at oversætte den til IPv4 er en anden funktion, som ingen har implementeret. Det er hele fejlen, og den har intet at gøre med, hvorvidt VPN-lytteren svarede over IPv4.

Mekanikken i IPv6-over-IPv4-indkapsling er beskrevet i RFC 4213, og den vigtige detalje der er, at endepunkterne stadig har brug for rigtig IPv6-forbindelse på den anden side af tunnellen. At pakke et header ind frembringer ikke en upstream.

To tunnellag, to uafhængige tjek

Bekræft hvert lag for sig, for en fungerende ydre tunnel skjuler en brudt indre. Tjek den ydre vej med en IPv4-ping fra klienten til serveren, og bekræft den port, du bruger. Tjek derefter den indre vej på serveren, hvor ip -6 route skal vise en standardrute eller en konkret rute lært fra en rigtig upstream, og ip -6 addr skal vise et kilde-prefix, som upstreamen accepterer. Alt mindre er pynt på interfacet.

En unik-lokal adresse, eller et globalt udseende prefix som intet ruter tilbage til, dukker helt glad op på et interface og ender ingen steder. Offentlig tilgængelighed gives af upstreamen, ikke af adressens form.

Det samme gælder på klienten: ip -6 route get 2001:4860:4860::8888 bør navngive tunneleenheden, og hvis den navngiver den fysiske, bruger klienten overhovedet ikke VPN til IPv6.

Kilde-prefix, størrelse og ICMPv6

Spørg upstreamen, hvilke kilde-prefixer den accepterer til videresendelse, og brug en af dem til klientpoolen. En udbyder, der giver dig et /64 til serverens eget interface, ruter ikke nødvendigvis et andet /64 eller en større blok til dig, og forskellen er en eftermiddags fejlfinding, som en supportbillet afgør med ét spørgsmål. Spørg skriftligt, og gem svaret sammen med konfigurationen.

Afstem budgettet til den ekstra indkapsling, som din stack faktisk bruger, og hold ICMPv6 kørende, inklusive Packet Too Big. Et ekstra header krymper den brugbare nyttelast, så en vej, der svarer på små pings, kan stadig fejle ved en filoverførsel, og en firewall, der dropper al ICMPv6, gør et reparerbart størrelsesproblem til et sort hul. Test én stor overførsel, før du annoncerer tjenesten.

Hvad er et helt andet problem

At nå en applikation, der kun kører IPv4, fra en klient, der kun kører IPv6, er oversættelse, ikke tunellering, og kræver noget i retning af et bevidst udrullet NAT64-arrangement. Destinationen forstår ikke et ekstra tunnel-header, bare fordi du tilføjede et. Historiske overgangstjenester fortjener samme omhu: RFC 7526 afskaffede 6to4-anycast-relæmodellen, så en guide skrevet omkring den beskriver noget, der ikke længere har et vedligeholdt offentligt relæ.

Hvis serveren ikke har nogen brugbar IPv6-upstream, er valgene en understøttet upstream, en anden udgang eller en dokumenteret beslutning om, at IPv6 bliver uden for tunnellen. Det, der ikke er acceptabelt, er at fortælle klienter, at IPv6-tjenesten findes, mens deres almindelige IPv6-forbindelse stille omgår VPN.