Privates IPv6 in ein OpenVPN-Labor einbauen, ein Prüfpunkt nach dem anderen

Den äußeren Transport auf IPv4 lassen und den inneren Plan erweitern. Fünf Prüfpunkte: Präfixe, Helfer, Routen-Push, Weiterleitung und ein Test auf Client-Seite.

Sie haben bereits einen Client, der sich über IPv4 verbindet und eine private IPv4-Arbeitslast hinter dem Server erreicht. Ziel ist, eine private IPv6-Arbeitslast durch denselben Tunnel zu erreichen, ohne den äußeren Transport anzutasten. Diese Reihenfolge zählt: Der äußere Pfad bleibt IPv4, und nur der innere Adressplan, die Client-Route und der Rückweg vom Server ins LAN ändern sich. Fünf Prüfpunkte, jeder mit etwas Konkretem zum Anschauen, bevor es weitergeht.

Prüfpunkt eins: die Verbindung, die schon funktioniert

Verbinden Sie den Client und bestätigen Sie den IPv4-Pfad, bevor Sie etwas hinzufügen. Ein funktionierender Tunnel gibt Ihnen eine Basislinie, die einen neuen IPv6-Fehler von einem alten Konnektivitätsproblem trennt. Er sagt Ihnen auch, welche Serverinstanz Sie tatsächlich bearbeiten.

Notieren Sie Pool, Topologie und die gepushten Routen, auf die Sie sich bereits verlassen. Die IPv6-Arbeit erweitert diese Konfiguration; sie ersetzt sie nicht.

Prüfpunkt zwei: die inneren Präfixe wählen

Wählen Sie eine ULA /48 für den Standort und schneiden Sie zwei /64 daraus: eine für Tunnel-Clients, eine für das LAN-Segment mit der IPv6-Arbeitslast. Generieren Sie die 40-Bit-Global-ID, statt ein Beispielpräfix zu kopieren, und prüfen Sie beide Subnetze gegen jedes Netz, das der Standort bereits routet:

Outer transport: IPv4 OpenVPN UDP
IPv4 pool:       10.90.0.0/24
IPv6 VPN pool:   fd73:93bc:b6e9:77::/64
IPv6 LAN:        fd73:93bc:b6e9:60::/64
Server LAN IPv6: fd73:93bc:b6e9:60::1

Zwei unabhängige /64 verhindern, dass der Client-Pool aus dem LAN-Segment herausgeschnitten wird, was später beim Schreiben der Rückroute zählt. Die Werte oben sind ein durchgerechnetes Beispiel, kein Präfix zum Wiederverwenden.

Prüfpunkt drei: Helfer und Routen-Push hinzufügen

Lesen Sie die aktuelle Serverkonfiguration, bevor Sie etwas anhängen. Eine zweite Kopie einer bestehenden Direktive verschmilzt nicht mit der ersten, und der resultierende Fehler nennt die Direktive statt IPv6. Mit dem vorhandenen IPv4-Helfer erweitern zwei Zeilen ihn. Jede beantwortet eine andere Frage:

server-ipv6 fd73:93bc:b6e9:77::/64
push "route-ipv6 fd73:93bc:b6e9:60::/64"

Die erste ist ein Komfort-Helfer, der Interface und Client-Pool konfiguriert. Die zweite nennt das LAN-Ziel, das der Client erreichen soll. Einem Client eine IPv6-Adresse zuzuweisen sagt ihm nicht, welche Netze hinter dem Server liegen, also braucht es beide Zeilen.

Der Helfer koexistiert nicht mit einem statischen IPv6-Pool oder mit nopool. Wenn das Deployment Adressen bewusst statisch vergibt, behalten Sie diese Politik und entwerfen Sie das IPv6-Äquivalent ausdrücklich, statt die Politik zu löschen, damit sie zu einem Beispiel passt.

Prüfpunkt vier: Weiterleitung und die Antwortroute

Schalten Sie IPv6-Weiterleitung auf dem Server über den eigenen Konfigurationsverwalter des Systems ein, nicht mit einem einmaligen Laufzeitschreibvorgang, den Sie vergessen. Die Laufzeitform ist für einen schnellen Test nützlich. Dauerhafte Konfiguration gehört in eine Drop-in-Datei, die der Netzwerkverwalter der Distribution liest:

sysctl -w net.ipv6.conf.all.forwarding=1

Weiterleitung ändert das IPv6-Verhalten des Hosts über das Routen von Paketen hinaus. Ein Host, der Router Advertisements als Client annahm, hört damit auf dieselbe Weise auf, sobald er weiterleitet. Eine Maschine, deren IPv6-Uplink von RAs abhängt, braucht deshalb einen ausdrücklichen Plan für diesen Uplink.

Geben Sie dem LAN dann eine Route zurück zum Tunnel-Pool. Das IPv6-Gateway der Arbeitslast ist der LAN-Router, nicht der VPN-Server, also gehört die Route auf diesen Router und zeigt auf die LAN-Adresse des Servers:

ip -6 route add fd73:93bc:b6e9:77::/64 via fd73:93bc:b6e9:60::1

Behalten Sie die ICMPv6-Typen, die der Link braucht, einschließlich Path-MTU-Rückmeldung. Eine IPv4-Firewallregel bedeutet keine IPv6-Regel, und ein pauschales IPv6-Blocken zerstört die Nachbarsuche auf Arten, die wie ein Routingfehler aussehen.

Prüfpunkt fünf: den Client lesen, dann testen

Verbinden Sie den Client erneut und lesen Sie die Adressen, die er tatsächlich erhalten hat, statt sie aus der Helferadresse des Servers abzuleiten. Die Interface-Auflistung zeigt beide Familien auf demselben Gerät:

ip -6 addr show tun0
ip -6 route get fd73:93bc:b6e9:60::20

Eine Route, die den Tunnel wählt, beweist, dass der Client weiß, wohin das Paket soll. Sie beweist nicht, dass der Server es weiterleitet, dass der LAN-Router die Rückroute hat oder dass die Anwendung antworten darf.

Testen Sie die Anwendung selbst nacheinander über jede Familie und wiederholen Sie das nach einem Reconnect und nach einem Host-Neustart. Eine Route oder ein sysctl, die nur bis zum Neustart überleben, sind ein Test, kein Entwurf.

Veröffentlichen Sie einen AAAA-Eintrag erst, wenn der IPv6-Pfad Ende-zu-Ende antwortet. Über IPv4 abgefragtes DNS kann weiterhin eine IPv6-Adresse liefern, also ist ein auflösbarer Name kein Beweis, dass etwas lauscht. Die RFC 4193 ULA-Empfehlung behandelt das Erzeugen der Global-ID, die diese Präfixe zu Ihren macht statt zu einer Kopie.

Ähnliche Artikel