IPv6-prefixdelegatie over een site-naar-site-VPN: checklist

De tunnel omhoog brengen is de makkelijke helft. Ik heb een site-naar-site-verbinding dagenlang stabiel zien staan terwijl elke host op de verre LAN alleen stilte terugkreeg, omdat het gedelegeerde prefix achter die gateway wel op een interface was geconfigureerd maar nooit de tunnel in werd gerouteerd. De tunneladressen antwoordden al die tijd op pings, en precies daarom keek niemand naar het prefix. Dit is de volgorde die ik controleer wanneer een gedelegeerd IPv6-prefix een site-VPN moet oversteken: de prefixkaart, de traffic selectors, doorsturen en firewall, en dan het retourpad.

Schrijf de prefixkaart voordat je de tunnel aanraakt

Prefixdelegatie geeft een blok aan de router die erom vroeg. Het installeert geen route op de peer, breidt dat blok niet on-link uit, en vertelt de verre gateway niet wat er achter de vragende router zit. Die drie moet je zelf configureren, en ze horen in een adresplan voordat er een configuratiebestand verandert.

Noteer per site het gedelegeerde prefix, de /64 die daadwerkelijk op de LAN wordt gebruikt, de tunneladressen en de eigenaar van elke route. De provider delegeert 2001:db8:a1::/56 aan site A, die 2001:db8:a1:10::/64 op zijn LAN bedient; site B houdt 2001:db8:b2::/64. Als site A alleen die ene /64 bedient, moeten beide kanten 2001:db8:a1:10::/64 noemen in plaats van de hele /56.

Twee fouten duiken bijna altijd op. De ene is het verre prefix als on-link behandelen, het bridgen of op de tunnelinterface zetten zodat de gateway antwoordt op buurverzoeken voor hosts die hij niet kan bereiken. De andere is de hele /56 adverteren terwijl er maar één /64 is geconfigureerd: de routetabel beweert dat het blok bereikbaar is en de meeste adressen verdwijnen in een zwart gat.

Stem de traffic selectors aan beide kanten af op de routes

IKEv2 en WireGuard weigeren allebei niet-overeenkomende trafiek, stil genoeg dat de tunnel er nog steeds gezond uitziet.

In strongSwan zijn de selectors expliciet. Op site A:

conn a-to-b
    left=2001:db8:ff::1
    leftsubnet=2001:db8:a1:10::/64
    right=2001:db8:ff::2
    rightsubnet=2001:db8:b2::/64
    auto=start

De conn van site B spiegelt de twee subnetten. Als ze het oneens zijn, weigert de responder de CHILD_SA met TS_UNACCEPTABLE, dus de child SA komt nooit omhoog ook al is de IKE_SA dat wel. Aan beide kanten moet het geconfigureerde subnet gelijk zijn aan wat de lokale kernel richting de tunnel routeert.

WireGuard draagt dezelfde informatie in AllowedIPs, met een twist: AllowedIPs is een bronfilter bij ontvangst en een route bij verzenden. Als de peer-entry van site B voor site A 2001:db8:a1:10::/64 weglaat, komen pakketten van site A binnen op een geldige handshake en worden ze als niet toegestaan weggegooid. Dat geeft het bekende patroon van een handshake die steeds wordt vernieuwd terwijl er nooit een antwoord uitgaat. Vergelijk beide kanten met wg show wg0 allowed-ips. Controleer die lijst opnieuw telkens wanneer de delegatie verandert; een verouderde /64 houdt de sessie in leven en maakt het nieuwe prefix onbereikbaar.

Sluit eerst doorsturen, firewall en MTU uit

Voordat je nog een logregel leest, bevestig dat de gateways überhaupt doorsturen. sysctl net.ipv6.conf.all.forwarding moet op beide 1 teruggeven, ook toegepast op de tunnel- en LAN-interfaces. Er kleeft een valkuil aan: zodra doorsturen aan staat, stopt een interface met accept_ra=1 met het accepteren van routeradvertenties van de provider, zodat de machine zijn upstream-standaardroute kan verliezen terwijl hij binnen de tunnel perfect routeert. Stel accept_ra=2 in waar een provider-RA nog nodig is.

De firewallregels moeten het prefix dan in beide richtingen toestaan, en ICMPv6 moet overleven: buurontdekking, packet-too-big en destination-unreachable zijn niet optioneel. Gooi je ze weg, dan breekt de path-MTU-ontdekking en krijg je verbindingen die opengaan en dan bij het eerste grote antwoord vastlopen. Een minimaal regelpaar ziet er zo uit:

nft add rule inet filter forward ip6 saddr 2001:db8:a1:10::/64 ip6 daddr 2001:db8:b2::/64 accept
nft add rule inet filter forward ip6 saddr 2001:db8:b2::/64 ip6 daddr 2001:db8:a1:10::/64 accept
nft add rule inet filter forward icmpv6 type { packet-too-big, nd-neighbor-solicit, nd-neighbor-advert } accept

De MTU zit hierachter. Een tunnel verkleint de bruikbare MTU tot onder 1500, en IPv6 eist dat elke link minstens 1280 draagt. Kleine pings komen door, een SSH-sessie bevriest bij een grote uitbarsting, en /proc/net/snmp6 toont packet-too-big-berichten die nooit terugkomen. Stel de tunnel-MTU expliciet in, of beperk de TCP-MSS in de mangle-tabel, en laat de ICMPv6 die de kleinere MTU meldt terugkomen.

Test het retourpad, niet het tunneladres

De storing die de meeste tijd kost, is eenrichtingsroutering. Elke gateway routeert het verre prefix de tunnel in, maar hosts antwoorden via hun eigen standaardgateway omdat daar hun /64 woont. Een pakket bij de bestemming krijgen is de halve weg.

Twee commando's lossen het meeste op. Op site A toont ip -6 route get 2001:db8:b2::53 from 2001:db8:a1:10::5 welke interface een antwoord van die bron zou gebruiken; voer de spiegelcontrole uit op site B. Genereer daarna verkeer vanaf een host in plaats van de gateway, en vergelijk de tellers aan beide kanten.

Als het buurverzoek voor het verre prefix op de tunnel verschijnt, is dat prefix on-link ergens waar het niet hoort; los dat op voordat je routes aanpast. Proxy NDP dekt gevallen waarin bridgen echt nodig is, geen vervanging voor een route.

Plan dat het prefix onder je verandert

Prefixdelegatie is een lease tussen de delegerende en de vragende router, en een verlenging kan een ander blok opleveren: een andere /56 na een providermigratie, of een kortere lease dan de tunnel al up is. Elke plek die het oude prefix noemt, veroudert tegelijk: routes, selectors, AllowedIPs, firewallregels, DNS-records en elke monitoring die letterlijke adressen hardcodeert. De berichtenstroom staat in RFC 8415.

Waar het prefix naar verwachting beweegt, houd een intern adresplan aan dat er niet van afhangt en vertaal aan de grens. NPTv6 is de stateless optie en houdt het interne beleid leesbaar, maar het is prefixvertaling, geen magische laag: /64-grenzen moeten op één lijn liggen, checksums worden aangepast, en applicaties die letterlijke adressen insluiten breken nog steeds. Als je provideradressen end-to-end aanhoudt, leg dan het leasegedrag en een wijzigingsprocedure vast in het adresplan.

Sluit af met een test die de tijd doorstaat: een toegestane host op elke LAN bereikt een dienst op de andere LAN, het antwoord komt terug door de tunnel, en hetzelfde paar werkt nog na een tunnelherstart en een delegatieverlenging. Als het laatste deel faalt, hangt het ontwerp af van toestand die de week niet overleeft.