Ein zweites Subnetz zu einem Site-to-Site-VPN hinzufügen: zwei Wege

Ein zweites Subnetz zu einem funktionierenden Site-to-Site-Tunnel hinzuzufügen dauert beim einen Design fünf Minuten und beim anderen fast den ganzen Nachmittag. Wenn der Tunnel Routen für die genannten Präfixe installiert, fügen Sie eine Route hinzu, und der Verkehr folgt ihr. Wenn er ein festes Selektorpaar aushandelt, bleibt das neue Präfix ungeschützt, bis beide Seiten sich auf ein passendes Paar einigen. Drei Dinge entscheiden: was die Konfiguration jeder Seite wirklich beschreibt, ob der ausgehandelte Verkehr auf das kleinste passende Paar verengt wird und wem der Rückweg für den neuen Bereich gehört.

Den Kernel lesen, nicht das Statusetikett

Ein Tunnel, der Verbindung meldet, hat mindestens eine Kind-Assoziation installiert, aber nicht unbedingt die erwartete. Unter Linux zeigt der Kernel, was angewendet wird: ip xfrm policy listet die Selektorpaare, und swanctl --list-sas (oder das ältere ipsec statusall) zeigt, was ausgehandelt wurde, einschließlich der Traffic-Selektoren je Richtung. Fehlt das neue Präfix in beiden, ist es ungeschützt, egal was die Konfigurationsdatei sagt.

Vergleichen Sie das mit der Routentabelle. Bei einem routenbasierten Aufbau ist das Tunnelgerät der nächste Hop für die geschützten Präfixe. Ein richtlinienbasierter Aufbau hat oft keine eigene Route für das entfernte Subnetz, nur die Standardroute, weil die Richtlinie den Verkehr auswählt und nicht die Tabelle.

Richtlinienbasierte Tunnel: beide Seiten müssen das neue Präfix listen

In strongSwan-Begriffen sitzt der Selektor in local_ts und remote_ts unter der Kind-Konfiguration, den Nachfolgern von leftsubnet und rightsubnet. Das neue Präfix muss auf beiden Seiten gespiegelt erscheinen: was Standort A lokal nennt, nennt Standort B entfernt. Eine Abweichung erzeugt selten einen klaren Fehler. Die Seiten verengen sich auf die Schnittmenge, das alte Präfix funktioniert weiter, und nur das neue scheitert still.

swanctl --load-conns
swanctl --initiate --child <child-name>
swanctl --list-sas
ip xfrm policy

Bei pfSense oder OPNsense bedeutet das einen zweiten Phase 2-Eintrag, der das neue lokale Subnetz mit dem neuen entfernten paart, danach ein Anwenden. Behalten Sie den alten Eintrag; ein Ersetzen verschiebt das ursprüngliche Subnetz statt es zu ergänzen. Deckt ein vorhandener Phase 2 bereits ein Supernetz wie 0.0.0.0/0 oder einen zusammengefassten Bereich ab, fügen Sie keinen engeren Eintrag daneben ein: überlappende Selektoren installieren konkurrierende Richtlinien, und die Auswertungsreihenfolge entscheidet, wer gewinnt.

IKEv1 macht jedes Subnetzpaar zu einem eigenen Phase 2, und eine Seite, die ein Paar pro Austausch annimmt, verwirft den Rest. IKEv2 kann mehrere Selektorpaare in einem Kind tragen, aber nur wenn beide Implementierungen sie akzeptieren. Die Liste aus swanctl --list-sas ist die Wahrheit; was Sie getippt haben, ist ein Wunsch.

Routenbasierte Tunnel: die Route ist die Richtlinie

Eine XFRM-Schnittstelle oder ein VTI-Gerät trägt Verkehr gemäß der Routentabelle. Sie zeigen das neue Präfix an beiden Standorten auf das Gerät, und der an die Transformation der Schnittstelle gebundene Zustand greift. Es gibt kein Selektorpaar zu synchronisieren, deshalb skaliert dieses Design besser, wenn Subnetze zunehmen. Der strongSwan-Leitfaden zur Weiterleitung geht auf die Kernelseite genauer ein.

ip route add 192.168.60.0/24 dev xfrm0
ip route get 192.168.60.10

WireGuard führt den Gedanken weiter. AllowedIPs ist zugleich die Krypto-Erlaubnisliste und über wg-quick der Eintrag in der Routentabelle. Setzen Sie das Präfix nur auf einer Seite, erhalten Sie einen Handshake, ausgehende Pakete und Stille, weil die Gegenseite Pakete verwirft, deren Quelle nicht auf ihrer Liste steht. Die Form wg set ersetzt die ganze Liste, also wiederholen Sie die bereits funktionierenden Präfixe, sonst schneiden Sie sie ab:

wg set wg0 peer <PUBKEY> allowed-ips 192.168.10.0/24,192.168.60.0/24
ip route add 192.168.60.0/24 dev wg0

Dieser zweite Befehl ist nicht optional, wenn Sie wg set statt wg-quick verwendet haben. Der Kernel übernimmt die neue Erlaubnisliste sofort, aber nichts fügt eine Route dafür hinzu, sodass lokal erzeugter Verkehr weiter über das Standard-Gateway hinausgeht. Das ist der häufigste Grund, warum ein neues WireGuard-Subnetz vom Tunnelhost und nicht vom Laptop funktioniert.

Der Rückweg scheitert häufiger als der Tunnel

Hosts im neuen entfernten Subnetz müssen Antworten über das VPN-Gateway zurückschicken. Ist dieses Gateway nicht ihr Standardrouter, geht die Antwort an den LAN-Router, der sie verwirft oder mit privater Quelladresse ins Internet weiterleitet. Testen Sie von einem Host auf der Gegenseite statt vom Gateway: ip route get 10.30.20.15 unter Linux oder Find-NetRoute -RemoteIPAddress 10.30.20.15 in PowerShell zeigt den nächsten Hop, den der Host wirklich nutzt. Ist die Antwort nicht der Tunnelendpunkt, fügen Sie dort eine statische Route für das neue Präfix hinzu.

Quell-NAT an dem Standort, dem die Rückroute fehlt, ist eine legitime Alternative und der Weg, wie viele Hub-and-Spoke-Installationen jeden Server unangetastet lassen. Wenden Sie es auch auf das neue Präfix am Gateway der Zielseite an:

iptables -t nat -A POSTROUTING -s 10.30.20.0/24 -d 192.168.60.0/24 -j MASQUERADE

Der Preis ist real. Entfernte Protokolle zeigen keine einzelnen Quelladressen mehr, und Firewall-Regeln für das ursprüngliche Subnetz fallen zu einer Regel für das Gateway zusammen. Wählen Sie das bewusst, nicht weil eine Route fehlte.

Firewalls sind die andere Hälfte des Rückwegs. Zonenbasierte Geräte erweitern die Zone einer bestehenden Tunnelschnittstelle nicht automatisch auf ein neues Subnetz, und eine Regel für das alte Präfix passt nicht mehr. Fügen Sie das neue Subnetz der Zone oder dem Regelpaar in beide Richtungen hinzu, bevor Sie IPsec beschuldigen.

Mit drei Fragen entscheiden, dann mit Verkehr prüfen

Die Kurzfassung: nennt die Konfiguration der Seite Präfixe (richtlinienbasiert), oder wird Verkehr in eine Schnittstelle geroutet (routenbasert)? Listen beide Enden das neue Präfix? Gibt es einen Weg zurück vom neuen Subnetz zum ursprünglichen Quellbereich?

Die Prüfung ist der Punkt, an dem die meisten Änderungen zu früh geschlossen werden. Ein Ping vom Gateway beweist wenig, weil das Gateway von sich aus sendet und oft einer anderen Richtlinie entspricht als ein Host. Pingen Sie von einem Host im neuen Subnetz, starten Sie dann die Anwendung, die die Änderung ausgelöst hat, und beobachten Sie Zähler statt eines Statussymbols.

tcpdump -ni any host 192.168.60.10 and (esp or udp port 4500)
ip xfrm state
wg show

Bei einem richtlinienbasierten Tunnel sollten die ip xfrm state-Zähler in beide Richtungen steigen; flache Zähler bedeuten, dass das Paket geroutet, aber nicht ausgewählt wird. Bei WireGuard meldet wg show den Transfer je Seite, und ein Handshake ohne empfangene Bytes deutet auf die Erlaubnisliste der Gegenseite oder deren Rückroute.

Schließen Sie ab, indem Sie Präfix, Selektor oder Route der Seite, die Entscheidung zum Rückweg und den Firewall-Eintrag mit dem übrigen Tunnel-Inventar festhalten. Starten Sie dann ein Gateway neu und testen Sie erneut: eine von Hand gesetzte Route verschwindet, und die nächste Person sollte das nicht erneut entdecken müssen.