Die Aufteilung Ihres /64 leitet IPv6 nicht zu VPN-Clients

Der Client zeigt eine globale IPv6-Adresse, der Handshake ist abgeschlossen, und aus dem Internet kommt nichts zurück. Die Pool-Einstellung sieht korrekt aus, weil sie korrekt ist; die Adresse ist gültig, und der Tunnel trägt sie. Was fehlschlägt, ist die Zustellung, und die Zustellung hängt von einer Entscheidung oberhalb des VPN-Servers ab, die keine clientseitige Konfiguration beeinflussen kann.

Der Mythos: ein Stück Ihres /64 ist bereits erreichbar

Die Erzählung ist verführerisch: Der Server hat ein öffentliches /64, halbieren Sie es, geben Sie die andere Hälfte an den VPN-Pool, und diese Clients sind jetzt im Internet. Das Aufteilen des Präfixes vergibt tatsächlich Adressen ohne Kollisionen. Es ändert aber nichts daran, wie das Upstream-Netz entscheidet, wohin ein Paket für eine dieser Adressen geht.

IPv6 hat keine Standard-Übersetzungsschicht, auf die es zurückfallen könnte, also muss der Rückweg entweder als Routing oder als Zustellung auf Linkebene existieren. Ein Paket an die Tunneladresse eines Clients kommt am Upstream-Router an, und dieser Router trifft eine Weiterleitungsentscheidung aus seiner eigenen Tabelle. Zeigt die Tabelle auf den physischen Link, geht das Paket dorthin, unabhängig davon, was Ihr VPN-Server glaubt.

Das ist der ganze Fehler: Die Hinrichtung funktioniert, weil Ihr Server sie sendet, und die Rückrichtung stirbt einen Hop entfernt, weil das Upstream nie erfahren hat, dass der Client existiert.

Was Zustellung am Link wirklich erfordert

Wenn das Upstream das gesamte /64 als auf dem physischen Link betrachtet, löst es jede Zieladresse über Nachbarerkennung auf. Es sendet eine Anfrage auf diesem Link und erwartet, dass der Inhaber der Adresse antwortet. Ein VPN-Client hinter einem Tunnel ist nicht auf diesem Link und kann nicht antworten, also bleibt die Anfrage unbeantwortet und das Paket wird verworfen.

Ein /65 herauszuschneiden ändert diese Erwartung nicht. Das Upstream behandelt den Bereich weiterhin als am Link, denn das Einzige, was es umstimmen würde, ist eine Route oder ein Proxy, der im Namen des Clients antwortet. Beides erscheint nicht, weil Sie eine VPN-Konfiguration bearbeitet haben. Genau diese Lücke erklärt, warum ein Pool zwischen seinen eigenen Clients perfekt funktionieren und trotzdem von überall sonst unerreichbar sein kann.

Proxy-Nachbarerkennung ist der Mechanismus, der die beiden Welten überbrücken kann. Das Gateway beantwortet Anfragen für die konkreten Client-Adressen, die es besitzt, und leitet den Verkehr in den Tunnel. Es funktioniert, und es muss präzise auf diese Adressen beschränkt werden, mit einem Lebenszyklus, der dem Pool folgt, denn für eine Adresse zu antworten, die Sie nicht mehr bedienen, macht den Verkehr anderer zu einem schwarzen Loch. Manche Upstreams akzeptieren keine Proxy-Antworten, die sie nicht erwartet haben, deshalb braucht dieses Design auch die Zustimmung des Anbieters.

Was geroutete Zustellung erfordert

Das sauberere Design ist eine Zuweisung, die das Upstream tatsächlich zu Ihrem Gateway routet. Das kann ein delegiertes Präfix oder eine statische Route für einen kleineren Block sein, und die Anforderung ist in beiden Fällen dieselbe: Die Tabelle des Upstreams muss für den Clientbereich auf Ihren Server zeigen. Dann kommt der Rückverkehr am Gateway an, und das Gateway leitet ihn in den Tunnel.

Geroutete Zustellung beseitigt die Frage der Nachbarerkennung vollständig, und deshalb lohnt es sich, den Anbieter danach zu fragen, bevor Sie etwas Ausgeklügeltes bauen. Verlangen Sie die Route schriftlich und bestätigen Sie, dass der nächste Hop die Adresse ist, die das Upstream tatsächlich erreichen kann.

Beide Designs benötigen weiterhin aktivierte IPv6-Weiterleitung am Gateway und Firewall-Regeln, die den weitergeleiteten Fluss in beide Richtungen erlauben. Zustellung ist eine Voraussetzung, kein Ersatz für den Rest des Weges. Eine funktionierende Route mit deaktivierter Weiterleitung erzeugt genau dieselbe Stille wie eine fehlende Route, prüfen Sie also beides, bevor Sie etwas umbauen.

Zwei unabhängige Routen, die stimmen müssen

Das Pool-Präfix und die eigene Standardroute des Clients sind getrennte Einstellungen, und ihre Verwechslung erzeugt Teilkonnektivität, die wie ein defekter Tunnel aussieht. Der Pool sagt dem Server, welche Adressen ausgegeben werden sollen. Die Routen des Clients entscheiden, welche Ziele der Client überhaupt in den Tunnel schickt.

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

Das Präfix oben ist Dokumentationsraum, und die Umleitung gilt nur für IPv6, was genau das ist, was ein Dual-Stack-Deployment oft will, während die IPv6-Zustellung noch repariert wird. Eine IPv4-Umleitung begründet keine IPv6-Abdeckung, und keine der Einstellungen setzt die andere voraus.

Halten Sie den Kontrollverkehr, von dem IPv6 abhängt, unter welcher Richtlinie auch immer funktionsfähig. Packet-Too-Big-Nachrichten sind das klassische Opfer einer Firewall, die nur TCP und UDP erlaubt, und ihr Verwerfen erzeugt Verbindungen, die sich aufbauen und dann bei größeren Übertragungen stocken.

Router-Ankündigungen sind der dritte bewegliche Teil. Wenn das Gateway beginnt, auf dem Uplink anzukündigen, kann das ändern, was Clients und Nachbarn über Präfixe am Link glauben, was das gerade dokumentierte Design stillschweigend zunichtemachen kann.

Halten Sie das Design fest, damit ein Neuaufbau es reproduziert

Notieren Sie drei Objekte getrennt: die Client-Zuweisung, die Zielroute des Clients und die Zustellungsmethode des Upstreams für die Zuweisung. Wer alle drei hat, kann das Deployment neu aufbauen; wer nur die Pool-Einstellung hat, wird den ursprünglichen Fehler reproduzieren.

Testen Sie dann die Rückrichtung ausdrücklich mit einem Paket, das von außen zurückkommen muss. Das openvpn(8)-Handbuch behandelt die Optionen server-ipv6 und redirect, und die Routing-Bestätigung Ihres Anbieters deckt die Hälfte ab, die das Handbuch nicht kann.