IPv6-Zweigpräfix: iroute-ipv6 oder route-ipv6 auf dem Server?

Zwei Anweisungen mit fast demselben Namen tauchen in jedem funktionierenden Beispiel auf, und wer die eine ohne die andere kopiert, erhält einen Tunnel, der korrekt aussieht und das Zweigpräfix still verwirft. Sie erledigen verschiedene Aufgaben auf verschiedenen Seiten derselben Grenze: die eine lehrt den Kernel des Servers, wo ein Präfix liegt, und die andere sagt OpenVPN, welcher authentifizierte Client es trägt. Sind beide richtig, fließt das Präfix; ist eine richtig, haben die Pakete eine Route, aber keinen Besitzer.

Zwei Anweisungen, zwei verschiedene Aufgaben

route-ipv6 ist eine gewöhnliche Routeninstallation: der Server fügt eine Kernelroute hinzu, die das Präfix auf seine Tunnelschnittstelle zeigt. iroute-ipv6 gehört zu einem clientspezifischen Kontext und erklärt die interne Zuständigkeit, sodass der Daemon weiß, dass Verkehr für dieses Präfix an einen bestimmten Client gehen soll und nicht an den Peer, den eine Kernelroute zufällig nennt.

Die eine betrifft die Weiterleitungstabelle des Kernels, die andere das interne Routingmodell des Daemons. Hält man sie auseinander, erklärt das, warum eine vollständig wirkende Konfiguration das Präfix trotzdem verwerfen kann. Es erklärt auch, warum dasselbe Netzwerk in jedem funktionierenden Beispiel zweimal auftaucht. Keine der beiden Zeilen ist überflüssig.

In der traditionellen Userspace-Einrichtung sind beide nötig, und sie ergänzen sich. Eine Kernelroute allein lässt den Daemon keinen Peer wählen. Ein iroute allein lässt den Kernel ohne Weg zum Tunnel. Hierher kommt auch der meiste Wirrwarr um Dateien pro Client: die Datei ist kein Routentabelleneintrag, und der Routeneintrag ist keine Zuständigkeitserklärung.

ip -6 route show | grep fd00:7a
ip -6 route get fd00:7a::1

Wohin welche gehört

Die Route gehört in die verwaltete Konfiguration des Servers, wo sie für diesen Serverprozess gilt. Der iroute gehört in die clientspezifische Datei, die nach der authentifizierten Identität des Zweigegeräts benannt ist.

Ein Dateiname, der nicht zur tatsächlichen Identität passt, wird nie gelesen, und das Symptom ist identisch mit einem fehlenden iroute. Prüfe die Identität, die der Server authentifiziert hat, und prüfe danach den Dateinamen Zeichen für Zeichen.

# /etc/openvpn/server/server.conf
route-ipv6 fd00:7a::/64
client-config-dir /etc/openvpn/server/ccd

# /etc/openvpn/server/ccd/branch-b
iroute-ipv6 fd00:7a::/64

Halte den Pool und das Zweigpräfix getrennt, denn eine Überlappung schafft ein Rätsel, das keine Anweisung lösen kann.

Was ein anderer Client braucht

Ein zweiter Client, der diesen Zweig erreichen soll, braucht eine Ankündigung, keine Zuständigkeit. Schiebe das Präfix an die Clients, die du meinst, im Client- oder Gruppenkontext, der zu deiner Konfiguration passt.

Sende es nicht an den Zweig selbst, denn dieses Gerät hat das Präfix bereits als angeschlossenes Netzwerk.

Es an alle zu senden ist eine Entscheidung mit Folgen: jeder Client glaubt dann, der Zweig sei über den Tunnel erreichbar, auch Clients, denen du diesen Zugang nie geben wolltest. Eine Ankündigung ist in der Praxis eine Zugangsentscheidung, auch wenn die Anweisung nach Installationsarbeit aussieht. Die Referenz für Serveroptionen dokumentiert iroute-ipv6 als clientspezifische Zuständigkeit, und das ist die Unterscheidung, die man behalten sollte.

Der Rückweg auf dem Zweigegerät

Zuständigkeit hilft nur, wenn der Zweig Pakete weiterleitet und sein LAN weiß, wie es antworten soll. Aktiviere die IPv6-Weiterleitung auf dem Zweigegerät und bestätige, dass Hosts in seinem LAN Verkehr für den VPN-Pool zurück zum Zweig schicken statt zu einer Standardroute, die den Pool nicht kennt.

Dieser Rückweg ist das IPv6-Gegenstück zum Problem der fehlenden Route, das Leute mit IPv4 erleben.

Prüfe es von einem LAN-Host mit einer Abfrage für die Adresse des VPN-Pools, nicht vom Zweig selbst. Eine Abfrage auf dem Router beantwortet eine andere Frage als die deiner Nutzer, und die beiden stimmen oft genug nicht überein, dass sich der zusätzliche Befehl lohnt.

Wenn das Paar noch nicht reicht

Manche Umgebungen nutzen diesen Weg überhaupt nicht. Der Kernel-Datenpfad und produktverwaltete Server haben ihre eigene unterstützte Routenbehandlung, und ein Userspace-Beispiel lässt sich vielleicht nicht direkt übertragen.

Prüfe, welchen Datenpfad dein Build nutzt, bevor du Anweisungen aus einer Anleitung für den anderen übernimmst.

Denke zuletzt an den Adressbereich: ein eindeutiges lokales Präfix wie fd00:7a::/64 ist von Natur aus privat und sagt nichts über öffentliche IPv6-Erreichbarkeit aus. Behandle es als internen Zugang und halte den Internetausgang eine getrennte Frage mit eigener Richtlinie.