IPv6-Planung für einen WireGuard-Hub mit zwei Standorten: Präfix, Peers, Routen

Zwei LANs, ein WireGuard-Hub und ein IPv6-Adressplan, der drei getrennte Fragen beantworten muss: welches Präfix, welche Adresse zu welchem Router gehört und welcher Peer welches Subnetz besitzt. Ist eine davon falsch, entsteht ein Tunnel, der einen Handshake durchführt und nichts routet. Der folgende Plan arbeitet in dieser Reihenfolge ein privates Zwei-Standort-Design durch. Er stellt bewusst keinen Internetzugang über IPv6 bereit.

Entscheiden Sie, wofür das Präfix dient

Ein eindeutig lokales Präfix aus fd00::/8 ist die naheliegende Wahl, wenn das Ziel private Erreichbarkeit zwischen Standorten ist. Es bleibt stabil, unabhängig davon, welcher Provider welchen Standort versorgt, und es wird nicht in die globale Routingtabelle angekündigt, sodass es Ihre interne Nummerierung nicht ins Internet lecken kann.

Dieselbe Eigenschaft ist die Einschränkung. Eine ULA bietet keinen öffentlichen Rückweg, weil kein Upstream weiß, dass er sie zu Ihrem Gateway routen soll. Wenn die Anforderung einen Internetausgang über IPv6 einschließt, brauchen Sie eine Zuweisung von einem Anbieter, der sie zu Ihnen routet, und das ist eine eigene Designentscheidung mit eigener Präfixgröße.

Gehen Sie nicht davon aus, dass jedes Deployment ein /48 braucht. RFC 6177 rückte von einer einzigen verbindlichen Endstandortgröße ab, und die richtige Größe folgt der Anzahl der Netze, die Sie betreiben werden. Erzeugen Sie die ULA mit dem Verfahren aus RFC 4193, statt ein Präfix zu erfinden, das auch eine andere Organisation verwenden könnte. Schreiben Sie das Ergebnis in den Adressplan, bevor ein Gerät konfiguriert wird, denn ein Präfix, das niemand festgehalten hat, ist ein Präfix, das jemand wiederverwenden wird.

Schneiden Sie das Präfix in Rollen

Das folgende Beispiel verwendet fd7c:2e91:4a00::/48, und die Tabelle ist danach geordnet, wo der jeweilige Block geschrieben wird, nicht nach Standort. Behandeln Sie die Werte als Beispiel und erzeugen Sie eigene, bevor Sie irgendetwas ausrollen.

Die LAN-Blöcke sind /64, weil gewöhnliches SLAAC eine 64-Bit-Interface-Kennung erwartet. Ein LAN in einen kleineren Block aufzuteilen bricht diese Annahme auf den meisten Hosts, und der Betriebsaufwand ist die Adresseinsparung in einem privaten Plan nicht wert. Beide LAN-Blöcke stammen aus der Mitte des /48 und lassen den unteren Bereich für spätere Standorte frei.

Die Tunneladressen sind ein administrativer Vorrat, kein On-Link-Netz. Jede Schnittstelle bekommt daraus eine einzelne /128, sodass kein Host ein gemeinsames Subnetz auf dem Tunnel annimmt und keine Nachbarschaftserkennung läuft, wo sie nicht gebraucht wird. Halten Sie die Rollen disjunkt und tragen Sie sie im Adressplan der Organisation ein, damit ein späterer Standort keinen Block wiederverwendet.

Geben Sie jedem Router eine Tunneladresse

Weisen Sie einen /128 pro Router zu und behalten Sie die bestehenden Schlüssel und Endpunkte des funktionierenden Hubs. Die drei Werte unten unterscheiden sich nur im Host-Teil.

Hub:    Address = fd7c:2e91:4a00:ff00::1/128
Site A: Address = fd7c:2e91:4a00:ff00::2/128
Site B: Address = fd7c:2e91:4a00:ff00::3/128

Diese /128 beschreibt die einzelne Adresse, die dieser Schnittstelle zugewiesen ist. Sie sagt nichts darüber, wie viele Ziele der Peer routen darf, denn Erreichbarkeit wird in AllowedIPs ausgedrückt und nicht im Schnittstellenpräfix.

Jeder Standortrouter braucht außerdem eine Adresse in seinem LAN-Block und einen Weg, sie zu verteilen, üblicherweise Router Advertisement für SLAAC. WireGuard versendet diese Ankündigungen nicht für Sie und überbrückt die beiden LANs nicht. Der Standortrouter ist ein Router in beide Richtungen.

Legen Sie die Subnetz-Zugehörigkeit in AllowedIPs ab

Der Peer-Eintrag des Hubs für Standort A besitzt die Tunneladresse von A und das LAN von A, und diese Paarung ist die gesamte Eigentumsaussage. Nichts anderes in diesem Peer-Abschnitt muss den Standort beschreiben.

AllowedIPs = fd7c:2e91:4a00:ff00::2/128, fd7c:2e91:4a00:10::/64

Der Peer-Eintrag für Standort B besitzt das passende Paar, und Symmetrie ist hier wichtiger als Kürze. Lesen Sie beide Zeilen zusammen, dann ist die Aufteilung des Eigentums auf einen Blick sichtbar.

AllowedIPs = fd7c:2e91:4a00:ff00::3/128, fd7c:2e91:4a00:20::/64

Das sind zwei getrennte Peer-Abschnitte, keine zwei Listen, die um einen Peer konkurrieren. WireGuard nutzt AllowedIPs in beide Richtungen: Es wählt den Peer für ein ausgehendes Ziel und verwirft ein eingehendes Paket, dessen Quelle nicht zum Bereich des Peers passt, der es entschlüsselt hat. Würde man beiden Peers das ganze /48 geben, wäre diese zweite Prüfung ausgeschaltet und verwischt, welcher Standort welchen Block besitzt. Genau diese Unterscheidung macht eine falsche Quelladresse sichtbar, statt sie stillschweigend zu akzeptieren.

Jeder Standort braucht nur die Ziele, die über seinen Hub-Peer erreichbar sind: Standort A listet die Hub-Adresse, die Tunneladresse von Standort B und dessen LAN, und Standort B listet die umgekehrte Menge. Die Listen sind absichtlich asymmetrisch, weil jeder Router eine andere Seite der Topologie sieht. Schreiben Sie beide aus dem Adressplan statt aus der Konfiguration des anderen Standorts, denn so überlebt ein veralteter Bereich eine Umnummerierung.

Mit wg-quick erzeugen diese Bereiche auch Routen. Mit systemd-networkd oder einer manuellen Einrichtung müssen Sie die entsprechenden Routen selbst hinzufügen; sonst trägt der Tunnel Pakete, die der Kernel nie hineinschickt.

Vervollständigen Sie die Weiterleitung und testen Sie beide Richtungen

Aktivieren Sie IPv6-Weiterleitung auf dem Hub und auf beiden Standortroutern und erlauben Sie in der Forward-Policy die erforderlichen Dienste zwischen den Standorten. Halten Sie ICMPv6 Packet Too Big nutzbar, denn ihr Verwerfen zerstört die Pfad-MTU-Erkennung und erzeugt Hänger bei großen Übertragungen, die wie Anwendungsfehler aussehen. Ein Hub, der ohne die Firewall-Freigabe weiterleitet, verwirft das Paket zwischen Routing und Tunnel. Dieser Fehlermodus ist es wert, gekannt zu werden, denn der Tunnel bleibt oben und nur einige Flows sterben.

sysctl net.ipv6.conf.all.forwarding
ip -6 route
ping -6 -c 3 fd7c:2e91:4a00:20::1

Testen Sie von einem Host an Standort A zu einem Host an Standort B und dann in die Gegenrichtung. Ein Ping auf die Tunneladresse des Hubs prüft nur den ersten Hop und gelingt selbst dann, wenn die LAN-Routen falsch sind. Der Host-zu-Host-Fluss ist der, der den Plan beweist.

Die äußere WireGuard-Verbindung kann über IPv4 laufen, während der innere Verkehr IPv6 ist, und diese Unabhängigkeit ist während einer Migration nützlich. Wird später ein globaler IPv6-Ausgang ergänzt, überdenken Sie Provider-Zuweisung, Quelladressauswahl und Rückrouting als neuen Designschritt; der obige private Plan bleibt für Verkehr zwischen Standorten gültig.