IPv6 door een OpenVPN-tunnel: een rondgang langs de thuisrouter

De laptop heeft een IPv6-adres, de tunnel staat over IPv4 omhoog en toch faalt elke IPv6-test. Of erger: de test slaagt en het verkeer verliet het pad van de provider zonder ooit de tunnel in te gaan. Beide uitkomsten gaan terug op één ontbrekende beslissing: niemand gaf de router een prefix die hij naar de clients kon routeren. Wie het pad van de client naar buiten afloopt, vindt welk stuk ontbreekt.

Begin waar de client zit

Kijk naar de client voordat je de server aanraakt. ip -6 addr hoort een tunneladres uit de pool te tonen, en ip -6 route hoort de gepushte prefix te tonen die naar het tunnelapparaat wijst. Als het adres er is maar de route niet, ontbreekt de push of heeft de client die genegeerd. Als geen van beide er is, heeft de server helemaal niets toegewezen.

Controleer daarna wat de client over de buitenwereld denkt. Een standaardroute via de tunnel claimt al het IPv6-verkeer, terwijl een route voor 2000::/3 alleen globale unicast claimt. Beide kunnen juist zijn, en ze beantwoorden verschillende vragen over lekken.

Een client zonder enige IPv6-standaardroute faalt op elke publieke test terwijl de tunnel zelf volledig gezond is. Dat is een gat in het beleid, geen kapotte tunnel.

Controleer de pool die de server echt kan routeren

Een server kan alleen toewijzen uit een prefix die hij echt beheert. Als de provider een /56 delegeert, reserveer dan één /64 voor de tunnel en laat de rest voor de LAN. Waar de provider op de WAN maar één /64 overhandigt en verder niets routeert, laat de LAN-prefix met rust en geef de tunnel een uniek lokaal bereik, met de aanvaarding dat de clients geen globale uitgang hebben.

De pool en de push horen bij elkaar. server-ipv6 2001:db8:80:10::/64 wijst adressen toe, en push "route-ipv6 2000::/3" vertelt de clients wat ze de tunnel in moeten sturen. 2000::/3 pushen dekt globale unicast en laat link-local- en multicast-bereiken buiten de tunnel.

Schrijf de gekozen prefix in het uitrolverslag. Wie de volgende keer de overdracht van de provider wijzigt, moet weten welke /64 de tunnel al bezet.

Zet doorsturen aan voor de tweede familie

IPv4-doorsturen betekent niet automatisch IPv6-doorsturen. Stel net.ipv6.conf.all.forwarding=1 in en spiegel alles wat het IPv4-FORWARD-beleid al toestaat. Op een router waarvan de FORWARD-keten standaard dropt, ziet een ontbrekende regelset er precies zo uit als een dode tunnel.

De handdruk slaagt, de client krijgt een adres en er komt niets terug. Voeg regels toe voor beide richtingen en voor het WAN-stuk, want een tunnel die de LAN haalt maar niet het internet, faalt op de derde test. Kijk na een mislukte poging naar de tellers van de keten, want een regel die nooit matchte is een ander probleem dan een die matchte en dropte.

ip6tables -A FORWARD -i br0 -o tun0 -j ACCEPT
ip6tables -A FORWARD -i tun0 -o br0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
ip6tables -A FORWARD -i tun0 -o wan0 -j ACCEPT

Eén bijwerking vangt de mensen die uiteindelijk de tunnel de schuld geven. Doorsturen aanzetten laat de kernel de adresconfiguratie via Router Advertisement overslaan tenzij je anders zegt, en een standaardroute die zo is geleerd verdwijnt ermee. Ofwel pin je een expliciete standaardroute op de WAN-interface, ofwel zet je accept_ra daar bewust op 2. Bevestig na beide wijzigingen dat de router nog steeds een bruikbaar IPv6-pad naar buiten heeft voordat je de clients opnieuw test.

Antwoord op buurdetectie wanneer de bovenkant niet routeert

Apparatuur bovenstrooms behandelt de gedelegeerde /64 soms als deel van zijn eigen link en weigert enige subprefix naar de VPN-box te routeren. Als dat gebeurt, moet iets de buurverzoeken voor elk clientadres afzonderlijk beantwoorden.

OpenVPN stelt het toegewezen adres beschikbaar aan een client-connect-hook, zodat vermeldingen de echte pool kunnen volgen in plaats van een met de hand bijgehouden lijst. De hook voegt ip -6 neigh add proxy $ifconfig_pool_remote_ip6 dev eth0 toe, en een bijpassende client-disconnect-hook haalt die weer weg. Zonder dat weghalen veroudert de proxytabel en kan een latere client een vermelding erven voor een adres dat hij nooit kreeg. Bevestig de toestand met ip -6 neigh show proxy.

Behandel proxy als een omweg. Een statische route voor de tunnel-/64 naar de router overleeft clientwisselingen en heeft helemaal geen bevoorrechte shell-hook nodig.

Volg het pad naar buiten, hop voor hop

Test naar buiten in drie stappen: eerst het tunneladres van de router, dan een LAN-host en ten derde een openbare bestemming via traceroute6. De pool wordt bewezen door de eerste, het doorsturen en de LAN-firewall door de tweede, en het retourpad via de bovenkant door de derde. Elke fout vernauwt de zoektocht tot één apparaat in plaats van het hele ontwerp opnieuw te openen.

Let op de MTU van de tunnel, want de IPv6-routers op het pad fragmenteren niet voor je. Een te grote MTU komt naar voren als een packet-too-big-fout en vastgelopen TLS in plaats van een schone fout. Stel die expliciet in en test met een lading dicht bij de limiet.