Je /64 splitsen routeert IPv6 niet naar VPN-clients

De client toont een globaal IPv6-adres, de handshake is voltooid en er komt niets terug van internet. De poolinstelling ziet er correct uit omdat die correct is; het adres is geldig en de tunnel draagt het. Wat faalt is de aflevering, en de aflevering hangt af van een beslissing die boven de VPN-server wordt genomen en waarop geen enkele configuratie aan de clientzijde invloed kan hebben.

De mythe: een deel van je /64 is al bereikbaar

Het verhaal is aantrekkelijk: de server heeft een publieke /64, deel die in tweeën, geef de andere helft aan de VPN-pool, en die clients staan nu op internet. Het splitsen van het prefix wijst inderdaad adressen toe zonder botsingen. Het verandert echter niet hoe het upstream-netwerk bepaalt waar een pakket voor een van die adressen naartoe moet.

IPv6 heeft geen standaardvertaallaag om op terug te vallen, dus het retourpad moet bestaan als routering of als aflevering op linkniveau. Een pakket dat aan het tunneladres van een client is geadresseerd, komt aan bij de upstream-router, en die router neemt een doorstuur-beslissing uit zijn eigen tabel. Als de tabel naar de fysieke link wijst, gaat het pakket daarheen, ongeacht wat je VPN-server gelooft.

Dat is de hele fout: de heenweg werkt omdat je server hem verstuurt, en de terugweg sterft één hop verder omdat de upstream nooit heeft geleerd dat de client bestaat.

Wat aflevering op de link echt vereist

Wanneer de upstream de hele /64 als op de fysieke link beschouwt, lost hij elk bestemmingsadres op met buurdetectie. Hij stuurt een verzoek op die link en verwacht dat de eigenaar van het adres antwoordt. Een VPN-client achter een tunnel staat niet op die link en kan niet antwoorden, dus het verzoek blijft onbeantwoord en het pakket wordt weggegooid.

Een /65 uitknippen verandert die verwachting niet. De upstream behandelt het bereik nog steeds als op de link, want het enige dat hem van gedachten zou doen veranderen is een route of een proxy die namens de client antwoordt. Geen van beide verschijnt omdat je een VPN-configuratie hebt bewerkt. Juist die kloof verklaart waarom een pool perfect kan werken tussen zijn eigen clients en toch van elders onbereikbaar kan zijn.

Proxy-buurdetectie is het mechanisme dat de twee werelden kan overbruggen. De gateway beantwoordt verzoeken voor de specifieke clientadressen die hij bezit en stuurt het verkeer de tunnel in. Het werkt, en het moet precies tot die adressen beperkt blijven met een levenscyclus die de pool volgt, want antwoorden voor een adres dat je niet meer bedient, maakt het verkeer van iemand anders tot een zwart gat. Sommige upstreams accepteren geen proxy-antwoorden die ze niet verwachtten, dus dit ontwerp vereist ook de instemming van de provider.

Wat gerouteerde aflevering vereist

Het schonere ontwerp is een toewijzing die de upstream daadwerkelijk naar je gateway routeert. Dat kan een gedelegeerd prefix zijn of een statische route voor een kleiner blok, en de eis is in beide gevallen dezelfde: de tabel van de upstream moet voor het clientbereik naar je server wijzen. Dan komt het retourverkeer aan bij de gateway en de gateway stuurt het de tunnel in.

Gerouteerde aflevering verwijdert de vraag naar buurdetectie volledig, en daarom loont het de moeite om de provider erom te vragen voordat je iets slims bouwt. Vraag de route schriftelijk aan en bevestig dat de volgende hop het adres is dat de upstream echt kan bereiken.

Beide ontwerpen vereisen nog steeds ingeschakelde IPv6-doorsturing op de gateway en firewallregels die de doorgestuurde stroom in beide richtingen toestaan. Aflevering is een voorwaarde, geen vervanging, voor de rest van het pad. Een werkende route met uitgeschakelde doorsturing levert precies dezelfde stilte op als een ontbrekende route, dus controleer beide voordat je iets herontwerpt.

Twee onafhankelijke routes om goed te krijgen

Het poolprefix en de eigen standaardroute van de client zijn afzonderlijke instellingen, en ze verwarren levert gedeeltelijke connectiviteit op die op een kapotte tunnel lijkt. De pool vertelt de server welke adressen moeten worden uitgegeven. De routes van de client bepalen naar welke bestemmingen de client überhaupt verkeer de tunnel in stuurt.

server-ipv6 2001:db8:42:100::/64
push "redirect-gateway ipv6 !ipv4"

Het prefix hierboven is documentatieruimte, en de omleiding geldt alleen voor IPv6, wat precies is wat een dual-stack-implementatie vaak wil terwijl de IPv6-aflevering nog wordt gerepareerd. Een IPv4-omleiding vestigt geen IPv6-dekking, en geen van beide instellingen impliceert de andere.

Houd het controleverkeer waarvan IPv6 afhankelijk is werkend onder welk beleid je ook toepast. Packet Too Big-berichten zijn het klassieke slachtoffer van een firewall die alleen TCP en UDP toestaat, en ze weggooien levert verbindingen op die tot stand komen en dan bij grotere overdrachten vastlopen.

Routeradvertenties zijn het derde bewegende onderdeel. Als de gateway op de uplink begint te adverteren, kan dat veranderen wat clients en buren geloven over prefixen op de link, wat het ontwerp dat je zojuist documenteerde stilletjes ongedaan kan maken.

Leg het ontwerp vast zodat een herbouw het reproduceert

Schrijf drie objecten apart op: de toewijzing van de client, de bestemmingsroute van de client en de afleveringsmethode van de upstream voor de toewijzing. Een lezer die alle drie heeft, kan de implementatie herbouwen; een lezer die alleen de poolinstelling heeft, zal de oorspronkelijke bug reproduceren.

Test daarna de terugweg expliciet, met een pakket dat van buitenaf terug moet komen. De openvpn(8)-handleiding behandelt de opties server-ipv6 en redirect, en de routeringsbevestiging van je provider behandelt de helft die de handleiding niet kan.