Je hebt al een client die via IPv4 verbindt en een privé-IPv4-werkbelasting achter de server bereikt. Het doel is een privé-IPv6-werkbelasting via dezelfde tunnel bereiken zonder het buitenste transport aan te raken. Die volgorde is belangrijk: het buitenste pad blijft IPv4, en alleen het binnenste adresplan, de route van de client en het terugpad van server naar LAN veranderen. Vijf controlepunten, elk met iets concreets om naar te kijken voordat je verdergaat.

Controlepunt één: de verbinding die al werkt

Verbind de client en bevestig het IPv4-pad voordat je iets toevoegt. Een werkende tunnel geeft je een basislijn die een nieuwe IPv6-fout scheidt van een oud connectiviteitsprobleem. Het vertelt je ook welke serverinstantie je werkelijk bewerkt.

Noteer de pool, de topologie en de gepushte routes waarop je al vertrouwt. Het IPv6-werk breidt die configuratie uit; het vervangt hem niet.

Controlepunt twee: kies de binnenste prefixen

Kies een ULA /48 voor de locatie en knip er twee /64 uit: één voor tunnelclients, één voor het LAN-segment met de IPv6-werkbelasting. Genereer de 40-bits globale ID in plaats van een voorbeeldprefix te kopiëren, en controleer beide subnetten tegen elk netwerk dat de locatie al routeert:

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

Twee onafhankelijke /64 voorkomen dat de clientpool uit het LAN-segment wordt geknipt, wat later belangrijk is als je de terugroute schrijft. De waarden hierboven zijn één uitgewerkt voorbeeld, geen prefix om te hergebruiken.

Controlepunt drie: voeg de helper en de route-push toe

Lees de huidige serverconfiguratie voordat je iets toevoegt. Een tweede kopie van een bestaande richtlijn versmelt niet met de eerste, en de resulterende fout noemt de richtlijn, niet IPv6. Met de bestaande IPv4-helper op zijn plaats breiden twee regels hem uit. Elk beantwoordt een andere vraag:

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

De eerste is een gemakshelper die de interface en de clientpool instelt. De tweede noemt de LAN-bestemming die de client moet bereiken. Een client een IPv6-adres geven vertelt hem niet welke netwerken er achter de server zijn, dus beide regels zijn nodig.

De helper bestaat niet samen met een statische IPv6-pool of met nopool. Als de uitrol opzettelijk adressen statisch toewijst, houd dat beleid aan en ontwerp het IPv6-equivalent expliciet in plaats van het beleid te schrappen om bij een voorbeeld te passen.

Controlepunt vier: doorsturen en de antwoordroute

Schakel IPv6-doorsturen op de server in via de eigen configuratiebeheerder van het systeem, niet met een eenmalige runtime-schrijfactie die je vergeet. De runtime-vorm is nuttig voor een snelle test. Permanente configuratie hoort in een drop-in-bestand dat de netwerkbeheerder van de distributie leest:

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

Doorsturen verandert het IPv6-gedrag van de host verder dan het routeren van pakketten. Een host die routeraankondigingen als client accepteerde, stopt daarmee op dezelfde manier zodra hij doorstuurt. Een machine waarvan de IPv6-uplink van RA's afhangt, heeft daarom een expliciet plan voor die uplink nodig.

Geef de LAN daarna een route terug naar de tunnelpool. De IPv6-gateway van de werkbelasting is de LAN-router, niet de VPN-server, dus de route hoort op die router en wijst naar het LAN-adres van de server:

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

Behoud de ICMPv6-typen die de link nodig heeft, inclusief path-MTU-terugkoppeling. Een IPv4-firewallregel betekent geen IPv6-regel, en een algehele IPv6-blokkade breekt buurtdetectie op manieren die op een routeringsfout lijken.

Controlepunt vijf: lees de client, test dan

Verbind de client opnieuw en lees de adressen die hij werkelijk kreeg in plaats van ze af te leiden uit het helperadres van de server. De interfacelijst toont beide families op hetzelfde apparaat:

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

Een route die de tunnel kiest bewijst dat de client weet waar het pakket heen moet. Het bewijst niet dat de server het doorstuurt, dat de LAN-router de terugroute heeft, of dat de applicatie mag antwoorden.

Test de applicatie zelf over elke familie om beurten, en herhaal dat na een herverbinding en na een herstart van de host. Een route of sysctl die alleen tot de herstart overleeft is een test, geen ontwerp.

Publiceer een AAAA-record pas wanneer het IPv6-pad van begin tot eind antwoordt. DNS dat via IPv4 wordt bevraagd kan nog steeds een IPv6-adres teruggeven, dus een oplosbare naam is geen bewijs dat er iets luistert. De RFC 4193-richtlijn voor ULA behandelt het genereren van de globale ID die deze prefixen van jou maakt in plaats van een kopie.

Gerelateerde artikelen