Lägg till privat IPv6 i ett OpenVPN-lab, en kontrollpunkt i taget

Du har redan en klient som ansluter över IPv4 och når en privat IPv4-arbetsbelastning bakom servern. Målet är att nå en privat IPv6-arbetsbelastning genom samma tunnel utan att röra den yttre transporten. Den ordningen spelar roll: den yttre vägen förblir IPv4, och bara den inre adressplanen, klientens rutt och returvägen från server till LAN ändras. Fem kontrollpunkter, var och en med något konkret att titta på innan du går vidare.

Kontrollpunkt ett: anslutningen som redan fungerar

Anslut klienten och bekräfta IPv4-vägen innan du lägger till något. En tunnel som fungerar ger dig en baslinje som skiljer ett nytt IPv6-fel från ett gammalt anslutningsproblem. Den berättar också vilken serverinstans du faktiskt redigerar.

Anteckna poolen, topologin och de pushade rutter du redan förlitar dig på. IPv6-arbetet utökar den konfigurationen; det ersätter den inte.

Kontrollpunkt två: välj de inre prefixen

Välj en ULA /48 för platsen och skär ut två /64 ur den: en för tunnelklienter, en för LAN-segmentet som har IPv6-arbetsbelastningen. Generera det 40-bitars globala ID:t i stället för att kopiera ett exempelprefix, och kontrollera båda subnäten mot varje nätverk som platsen redan routar:

Outer transport: IPv4 OpenVPN UDP
IPv4 pool:       10.90.0.0/24
IPv6 VPN pool:   fd73:93bc:b6e9:77::/64
IPv6 LAN:        fd73:93bc:b6e9:60::/64
Server LAN IPv6: fd73:93bc:b6e9:60::1

Två oberoende /64 hindrar klientpoolen från att skäras ut ur LAN-segmentet, vilket spelar roll senare när du skriver returrutten. Värdena ovan är ett genomarbetat exempel, inte ett prefix att återanvända.

Kontrollpunkt tre: lägg till hjälparen och rutepushen

Läs serverns nuvarande konfiguration innan du lägger till något. En andra kopia av ett befintligt direktiv smälter inte samman med det första, och felet som uppstår namnger direktivet, inte IPv6. Med den befintliga IPv4-hjälparen på plats utökar två rader den. Var och en svarar på en annan fråga:

server-ipv6 fd73:93bc:b6e9:77::/64
push "route-ipv6 fd73:93bc:b6e9:60::/64"

Den första är en bekvämlighetshjälpare som ställer in gränssnittet och klientpoolen. Den andra namnger LAN-målet som klienten ska nå. Att ge en klient en IPv6-adress talar inte om vilka nätverk som finns bakom servern, så båda raderna behövs.

Hjälparen samexisterar inte med en statisk IPv6-pool eller med nopool. Om driftsättningen medvetet tilldelar adresser statiskt, behåll den policyn och designa IPv6-motsvarigheten uttryckligen i stället för att radera policyn för att passa ett exempel.

Kontrollpunkt fyra: vidarebefordran och svarvägen

Slå på IPv6-vidarebefordran på servern via systemets egen konfigurationsägare, inte med en engångsskrivning under körning som du glömmer. Körningsformen är användbar för ett snabbt test. Beständig konfiguration hör hemma i en drop-in-fil som distributionens nätverksägare läser:

sysctl -w net.ipv6.conf.all.forwarding=1

Vidarebefordran ändrar värdens IPv6-beteende utöver att routa paket. En värd som accepterade routerannonser som klient slutar göra det på samma sätt när den börjar vidarebefordra. En maskin vars IPv6-uplink beror på RA behöver därför en uttrycklig plan för den uplinken.

Ge sedan LAN:et en rutt tillbaka till tunnelpoolen. Arbetsbelastningens IPv6-gateway är LAN-routern, inte VPN-servern, så rutten hör på den routern och pekar på serverns LAN-adress:

ip -6 route add fd73:93bc:b6e9:77::/64 via fd73:93bc:b6e9:60::1

Behåll de ICMPv6-typer som länken behöver, inklusive återkoppling om path-MTU. En IPv4-brandväggsregel innebär inte en IPv6-regel, och en total IPv6-blockering bryter granndetekteringen på sätt som ser ut som ett routingfel.

Kontrollpunkt fem: läs klienten, testa sedan

Anslut klienten igen och läs de adresser den faktiskt fick i stället för att härleda dem från serverns hjälparadress. Gränssnittslistan visar båda familjerna på samma enhet:

ip -6 addr show tun0
ip -6 route get fd73:93bc:b6e9:60::20

En rutt som väljer tunneln bevisar att klienten vet vart paketet ska skickas. Den bevisar inte att servern vidarebefordrar det, att LAN-routern har returrutten eller att programmet får svara.

Testa själva programmet över varje familj i tur och ordning och upprepa efter en återanslutning och efter en omstart av värden. En rutt eller sysctl som bara överlever till omstart är ett test, inte en design.

Publicera en AAAA-post först när IPv6-vägen svarar från ände till ände. DNS som frågas över IPv4 kan fortfarande returnera en IPv6-adress, så ett namn som går att slå upp är inte bevis för att något lyssnar. RFC 4193 ULA-vägledningen täcker genereringen av det globala ID som gör dessa prefix till dina i stället för en kopia.