IPv6 über einen IPv4-VPN-Server braucht trotzdem einen IPv6-Ausgang

Der Tunnel kommt hoch, der Client erhält eine IPv6-Adresse aus dem Pool, und trotzdem laufen alle IPv6-Ziele in einen Timeout. Am Tunnel ist nichts kaputt: IPv6 reitet einwandfrei im IPv4-Transport, und das war nie der schwierige Teil. Die Adresse, die du ausgegeben hast, ist ein Versprechen, das der Server nicht halten kann, weil dem Ausgang kein IPv6-Upstream zur Verfügung steht, in den er sie schicken könnte. Die Reparatur gehört an den Ausgang, nicht ins Clientprofil.

Das Symptom: eine Adresse und kein Weg

Eine Prüfung auf Clientseite zeigt eine global wirkende IPv6-Adresse auf dem Tunnelgerät und eine Route, die hineinzeigt, weshalb das fälschlich als Clientfehler gelesen wird. Der Verkehr tritt in den Tunnel ein, der Server entkapselt ihn, und dann landet das Paket auf einem Host, dessen Routingtabelle keine IPv6-Standardroute zu einem realen Ziel hat. Je nach Stack bekommst du sofortige Unerreichbarkeit oder einen stillen Verwerf, und in beiden Fällen sieht der Client einen Timeout, der wie eine Firewall aussieht.

Lies die eigene Routingtabelle des Servers, bevor du den Client anfasst, denn dort lebt die fehlende Hälfte des Weges. Ein Server mit einer einzigen IPv4-Standardroute hat dir die Antwort bereits gegeben.

Verfolge das Paket nach der Entkapselung

Im Tunnel ist das Paket gewöhnliches IPv6, und die Adresse des Clients ist seine Quelle. Der Server zieht die Transportkapsel ab und hält dann ein natives IPv6-Paket, das an einen IPv6-Nexthop weitergeleitet werden muss. Eine IPv4-Standardroute kann es nicht tragen, und es nach IPv4 zu übersetzen ist eine andere Funktion, die niemand ausgerollt hat. Das ist der ganze Fehler, und er hat nichts damit zu tun, ob der VPN-Listener über IPv4 geantwortet hat.

Die Mechanik der Kapselung von IPv6 über IPv4 ist in RFC 4213 beschrieben, und das wichtige Detail dort ist, dass die Endpunkte auf der anderen Seite des Tunnels weiterhin echte IPv6-Konnektivität brauchen. Einen Header einzupacken zaubert kein Upstream herbei.

Zwei Tunnelschichten, zwei unabhängige Prüfungen

Prüfe jede Schicht getrennt, denn ein funktionierender äußerer Tunnel verdeckt einen kaputten inneren. Prüfe den äußeren Weg mit einem IPv4-Ping vom Client zum Server und bestätige den Port, den du verwendest. Prüfe dann den inneren Weg auf dem Server, wo ip -6 route eine Standardroute oder eine konkrete, von einem echten Upstream gelernte Route zeigen muss, und ip -6 addr ein Quellpräfix zeigen muss, das der Upstream akzeptiert. Alles darunter ist Dekoration auf dem Interface.

Eine eindeutige lokale Adresse oder ein global wirkendes Präfix, zu dem nichts zurückroutet, erscheint fröhlich auf einem Interface und führt nirgendwohin. Öffentliche Erreichbarkeit gewährt der Upstream, nicht die Form der Adresse.

Dasselbe gilt beim Client: ip -6 route get 2001:4860:4860::8888 sollte das Tunnelgerät nennen, und wenn es das physische nennt, nutzt der Client das VPN für IPv6 überhaupt nicht.

Quellpräfix, Größe und ICMPv6

Frage den Upstream, welche Quellpräfixe er für die Weiterleitung akzeptiert, und nutze eines davon für den Client-Pool. Ein Anbieter, der dir ein /64 für das Interface des Servers selbst gibt, routet dir nicht zwangsläufig ein zweites /64 oder einen größeren Block, und der Unterschied ist ein Nachmittag Debugging, den ein Support-Ticket mit einer Frage erledigt. Frage schriftlich und bewahre die Antwort bei der Konfiguration auf.

Kalkuliere die zusätzliche Kapselung ein, die dein Stack tatsächlich nutzt, und halte ICMPv6 am Laufen, einschließlich Packet Too Big. Ein zweiter Header verkleinert die nutzbare Nutzlast, sodass ein Weg, der kleine Pings beantwortet, bei einer Dateiübertragung trotzdem scheitern kann, und eine Firewall, die ICMPv6 komplett verwirft, macht aus einem behebbaren Größenproblem ein schwarzes Loch. Teste eine große Übertragung, bevor du den Dienst ankündigst.

Was ein ganz anderes Problem ist

Von einem reinen IPv6-Client eine reine IPv4-Anwendung zu erreichen, ist Übersetzung, nicht Tunneling, und braucht so etwas wie eine bewusst ausgerollte NAT64-Lösung. Das Ziel versteht einen zusätzlichen Tunnel-Header nicht, nur weil du einen hinzugefügt hast. Historische Übergangsdienste verdienen dieselbe Sorgfalt: RFC 7526 hat das 6to4-Anycast-Relay-Modell abgeschafft, eine Anleitung darum herum beschreibt also etwas, das kein gepflegtes öffentliches Relay mehr hat.

Hat der Server kein nutzbares IPv6-Upstream, sind die Möglichkeiten ein unterstütztes Upstream, ein anderer Ausgang oder eine dokumentierte Entscheidung, dass IPv6 außerhalb des Tunnels bleibt. Nicht akzeptabel ist, Clients zu erzählen, es gebe einen IPv6-Dienst, während ihre gewöhnliche IPv6-Verbindung das VPN still umgeht.