IPv6 via een IPv4-VPN-server vraagt nog steeds om een IPv6-uitgang

De tunnel komt op, de client krijgt een IPv6-adres uit de pool, en toch verlopen alle IPv6-bestemmingen. In de tunnel is niets kapot: IPv6 rijdt prima in het IPv4-transport, en dat was nooit het moeilijke deel. Het adres dat je uitdeelde is een belofte die de server niet kan houden, want de uitgang heeft geen IPv6-upstream om het naartoe te sturen. De reparatie hoort bij de uitgang, niet in het clientprofiel.

Het symptoom: een adres en geen pad

Een controle aan de clientkant toont een wereldwijd lijkend IPv6-adres op het tunnelapparaat en een route die erin wijst, en daarom wordt dit ten onrechte als een clientbug gelezen. Verkeer gaat de tunnel in, de server decapsuleert het, en dan belandt het pakket op een host waarvan de routingtabel geen IPv6-standaardroute naar een echte plek heeft. Afhankelijk van de stack krijg je onmiddellijke onbereikbaarheid of een stille drop, en in beide gevallen ziet de client een timeout die er hetzelfde uitziet als een firewall.

Lees de eigen routingtabel van de server voordat je de client aanraakt, want daar woont de ontbrekende helft van het pad. Een server met één IPv4-standaardroute heeft je het antwoord al gegeven.

Volg het pakket na de decapsulatie

In de tunnel is het pakket gewone IPv6 en het adres van de client is de bron. De server trekt de transportencapsulatie eraf en houdt dan een native IPv6-pakket vast dat naar een volgende IPv6-hop moet worden doorgestuurd. Een IPv4-standaardroute kan het niet dragen, en het naar IPv4 vertalen is een andere functie die niemand heeft uitgerold. Dat is de hele storing, en ze heeft niets te maken met de vraag of de VPN-listener over IPv4 heeft geantwoord.

De mechanica van IPv6-over-IPv4-encapsulatie staat beschreven in RFC 4213, en het belangrijke detail daar is dat de eindpunten nog steeds echte IPv6-connectiviteit aan de andere kant van de tunnel nodig hebben. Een header inpakken tovert geen upstream tevoorschijn.

Twee tunnellagen, twee onafhankelijke controles

Controleer elke laag afzonderlijk, want een werkende buitenste tunnel verbergt een kapotte binnenste. Controleer het buitenste pad met een IPv4-ping van de client naar de server en bevestig de poort die je gebruikt. Controleer daarna het binnenste pad op de server, waar ip -6 route een standaardroute of een concrete route moet tonen die van een echte upstream is geleerd, en ip -6 addr een bronprefix moet tonen dat de upstream accepteert. Alles minder dan dat is versiering op de interface.

Een uniek-lokaal adres, of een wereldwijd lijkend prefix waar niets naartoe terugrouteert, verschijnt vrolijk op een interface en gaat nergens heen. Publieke bereikbaarheid wordt door de upstream gegeven, niet door de vorm van het adres.

Hetzelfde geldt bij de client: ip -6 route get 2001:4860:4860::8888 zou het tunnelapparaat moeten noemen, en als het het fysieke noemt, gebruikt de client de VPN helemaal niet voor IPv6.

Bronprefix, grootte en ICMPv6

Vraag de upstream welke bronprefixen hij voor doorsturen accepteert, en gebruik er een van voor de clientpool. Een provider die je een /64 geeft voor de eigen interface van de server, routeert niet noodzakelijk een tweede /64 of een groter blok naar je toe, en het verschil is een middag debuggen die een supportticket met één vraag beslecht. Vraag het schriftelijk en bewaar het antwoord bij de configuratie.

Begroot de extra encapsulatie die je stack echt gebruikt, en houd ICMPv6 aan de praat, inclusief Packet Too Big. Een tweede header verkleint de bruikbare payload, dus een pad dat kleine pings beantwoordt, kan alsnog falen bij een bestandsoverdracht, en een firewall die alle ICMPv6 weggooit, maakt van een herstelbaar grootteprobleem een zwart gat. Test één grote overdracht voordat je de dienst aankondigt.

Wat een heel ander probleem is

Een toepassing bereiken die alleen IPv4 is vanaf een client die alleen IPv6 is, is vertaling, geen tunneling, en vraagt iets als een bewust uitgerolde NAT64-opstelling. De bestemming begrijpt een extra tunnelheader niet alleen omdat je er een hebt toegevoegd. Historische overgangsdiensten verdienen dezelfde zorg: RFC 7526 heeft het 6to4-anycast-relaymodel afgeschaft, dus een handleiding die eromheen is geschreven, beschrijft iets dat geen onderhouden openbare relay meer heeft.

Als de server geen bruikbare IPv6-upstream heeft, zijn de keuzes een ondersteunde upstream, een andere uitgang of een gedocumenteerde beslissing dat IPv6 buiten de tunnel blijft. Wat niet acceptabel is, is clients vertellen dat er een IPv6-dienst bestaat terwijl hun gewone IPv6-verbinding de VPN stil voorbijgaat.