IPv6-Präfixdelegation über ein Site-to-Site-VPN: Checkliste

Den Tunnel aufzubauen ist die leichte Hälfte. Ich habe erlebt, dass eine Site-to-Site-Verbindung tagelang standhielt, während jeder Host im entfernten LAN nur Stille zurückbekam, weil das delegierte Präfix hinter diesem Gateway zwar auf einer Schnittstelle konfiguriert, aber nie in den Tunnel geroutet war. Die Tunneladressen antworteten die ganze Zeit auf Pings, und genau deshalb hat niemand das Präfix angeschaut. Hier ist die Reihenfolge, die ich prüfe, wenn ein delegiertes IPv6-Präfix ein Site-VPN queren muss: der Präfixplan, die Traffic-Selektoren, Weiterleitung und Firewall, dann der Rückweg.

Schreiben Sie den Präfixplan, bevor Sie den Tunnel anfassen

Präfixdelegation übergibt einen Block an den Router, der ihn angefordert hat. Sie installiert keine Route beim Peer, dehnt den Block nicht on-link aus und teilt dem entfernten Gateway nicht mit, was hinter dem anfordernden Router liegt. Diese drei Dinge konfigurieren Sie selbst, und sie gehören in einen Adressplan, bevor sich irgendeine Konfigurationsdatei ändert.

Notieren Sie je Standort das delegierte Präfix, das tatsächlich im LAN genutzte /64, die Tunneladressen und den Eigner jeder Route. Der Provider delegiert 2001:db8:a1::/56 an Standort A, der 2001:db8:a1:10::/64 in seinem LAN bedient; Standort B behält 2001:db8:b2::/64. Wenn Standort A nur dieses eine /64 bedient, sollten beide Enden 2001:db8:a1:10::/64 nennen statt des ganzen /56.

Zwei Fehler tauchen fast jedes Mal auf. Der eine ist, das entfernte Präfix als on-link zu behandeln, es zu bridgen oder auf die Tunnelschnittstelle zu legen, damit das Gateway die Nachbarschaftsanfrage für Hosts beantwortet, die es nicht erreichen kann. Der andere ist, das ganze /56 anzukündigen, wenn nur ein /64 konfiguriert ist: Die Routentabelle behauptet, der Block sei erreichbar, und die meisten Adressen fallen in ein schwarzes Loch.

Gleichen Sie die Traffic-Selektoren beider Seiten mit den Routen ab

IKEv2 und WireGuard lehnen beide unpassenden Verkehr ab, leise genug, dass der Tunnel weiterhin gesund aussieht.

In strongSwan sind die Selektoren explizit. Auf Standort A:

conn a-to-b
    left=2001:db8:ff::1
    leftsubnet=2001:db8:a1:10::/64
    right=2001:db8:ff::2
    rightsubnet=2001:db8:b2::/64
    auto=start

Die conn von Standort B spiegelt die beiden Subnetze. Wenn sie nicht übereinstimmen, weist der Responder die CHILD_SA mit TS_UNACCEPTABLE zurück, sodass die Child-SA nie hochkommt, obwohl die IKE_SA es tat. Auf beiden Seiten muss das konfigurierte Subnetz dem entsprechen, was der lokale Kernel in den Tunnel routet.

WireGuard trägt dieselbe Information in AllowedIPs, mit einer Wendung: AllowedIPs ist ein Quellfilter beim Empfang und zugleich eine Route beim Senden. Fehlt im Peer-Eintrag von Standort B für Standort A das 2001:db8:a1:10::/64, kommen Pakete von Standort A bei gültigem Handshake an und werden als nicht erlaubt verworfen. Das ergibt das vertraute Muster eines Handshakes, der sich ständig erneuert, während nie eine Antwort hinausgeht. Vergleichen Sie beide Enden mit wg show wg0 allowed-ips. Prüfen Sie die Liste bei jeder Änderung der Delegation erneut; ein veraltetes /64 hält die Sitzung oben und das neue Präfix unerreichbar.

Schließen Sie zuerst Weiterleitung, Firewall und MTU aus

Bevor Sie eine weitere Logzeile lesen, bestätigen Sie, dass die Gateways überhaupt weiterleiten. sysctl net.ipv6.conf.all.forwarding muss auf beiden 1 zurückgeben, auch auf den Tunnel- und LAN-Schnittstellen angewendet. Eine Falle hängt daran: Sobald die Weiterleitung an ist, hört eine Schnittstelle mit accept_ra=1 auf, Router-Advertisement vom Provider anzunehmen, sodass die Kiste ihre Upstream-Default-Route verlieren kann, während sie im Tunnel einwandfrei routet. Setzen Sie accept_ra=2, wo ein Provider-RA noch nötig ist.

Danach müssen Firewall-Regeln das Präfix in beide Richtungen erlauben, und ICMPv6 muss überleben: Nachbarschaftserkennung, Paket-zu-groß und Ziel-nicht-erreichbar sind nicht optional. Werfen Sie sie weg, bricht die Pfad-MTU-Erkennung, und Sie bekommen Verbindungen, die sich öffnen und dann bei der ersten großen Antwort hängen bleiben. Ein minimales Regelpaar sieht so aus:

nft add rule inet filter forward ip6 saddr 2001:db8:a1:10::/64 ip6 daddr 2001:db8:b2::/64 accept
nft add rule inet filter forward ip6 saddr 2001:db8:b2::/64 ip6 daddr 2001:db8:a1:10::/64 accept
nft add rule inet filter forward icmpv6 type { packet-too-big, nd-neighbor-solicit, nd-neighbor-advert } accept

Die MTU steht dahinter. Ein Tunnel schrumpft die nutzbare MTU unter 1500, und IPv6 verlangt, dass jede Strecke mindestens 1280 trägt. Kleine Pings gehen durch, eine SSH-Sitzung friert bei einem großen Schub ein, und /proc/net/snmp6 zeigt Paket-zu-groß-Meldungen, die nie zurückkommen. Setzen Sie die Tunnel-MTU explizit oder klemmen Sie TCP MSS in der mangle-Tabelle, und lassen Sie das ICMPv6, das die kleinere MTU meldet, zurückkehren.

Testen Sie den Rückweg, nicht die Tunneladresse

Der Fehler, der am meisten Zeit kostet, ist Einweg-Routing. Jedes Gateway routet das entfernte Präfix in den Tunnel, aber die Hosts antworten über ihr eigenes Standard-Gateway, weil dort ihr /64 lebt. Ein Paket zum Ziel zu bringen ist nur der halbe Weg.

Zwei Befehle klären das meiste. Auf Standort A zeigt ip -6 route get 2001:db8:b2::53 from 2001:db8:a1:10::5, welche Schnittstelle eine Antwort von dieser Quelle nutzen würde; führen Sie die Spiegelprüfung auf Standort B aus. Erzeugen Sie dann Verkehr von einem Host statt vom Gateway und vergleichen Sie die Zähler an beiden Enden.

Wenn die Nachbarschaftsanfrage für das entfernte Präfix im Tunnel auftaucht, ist dieses Präfix on-link an einer Stelle, wo es nicht sein sollte; beheben Sie das, bevor Sie Routen anpassen. Proxy NDP deckt Fälle ab, in denen Bridging wirklich nötig ist, und ist kein Ersatz für eine Route.

Planen Sie ein, dass das Präfix unter Ihnen wechselt

Präfixdelegation ist ein Leasing zwischen delegierendem und anforderndem Router, und eine Erneuerung kann einen anderen Block zurückgeben: ein anderes /56 nach einer Provider-Migration oder ein kürzeres Leasing, als der Tunnel oben ist. Jede Stelle, die das alte Präfix nennt, wird auf einmal veraltet: Routen, Selektoren, AllowedIPs, Firewall-Regeln, DNS-Einträge und jede Überwachung, die wörtliche Adressen fest codiert. Der Nachrichtenfluss steht in RFC 8415.

Wo erwartet wird, dass das Präfix wandert, halten Sie einen internen Adressplan, der nicht davon abhängt, und übersetzen Sie an der Grenze. NPTv6 ist die zustandslose Option und hält die interne Policy lesbar, aber es ist Präfixübersetzung, keine magische Schicht: /64-Grenzen müssen übereinstimmen, Prüfsummen werden angepasst, und Anwendungen, die wörtliche Adressen einbetten, brechen weiterhin. Wenn Sie Provider-Adressen durchgängig behalten, halten Sie das Leasingverhalten und ein Änderungsverfahren im Adressplan fest.

Schließen Sie mit einem Test ab, der die Zeit übersteht: Ein erlaubter Host in jedem LAN erreicht einen Dienst im anderen LAN, die Antwort kommt durch den Tunnel zurück, und dasselbe Paar funktioniert noch nach einem Tunnel-Neustart und einer Erneuerung der Delegation. Scheitert der letzte Teil, hängt das Design von Zustand ab, der die Woche nicht überlebt.