Zwei Standorte, ein Subnetz, ein WireGuard-Hub: So wird es lauffähig

Beide Standorte nutzen denselben LAN-Bereich, und die Überlappung ist nicht das, was das Design tatsächlich bricht. Der Hub muss einen Standort allein anhand der Zieladresse wählen, und zwei identische Ziele geben ihm nichts, woran er wählen könnte. Ein funktionierendes Büro umzunummerieren, um einen Tunnel zu erfüllen, ist meist ein schlechterer Tausch, als jedem veröffentlichten Dienst eine eigene Adresse zu geben, die der Tunnel tragen kann. Das folgende Design veröffentlicht einen HTTPS-Dienst pro Standort und sonst nichts.

Warum die Überlappung nicht das eigentliche Problem ist

WireGuard leitet nach Ziel weiter: Die AllowedIPs eines Peers entscheiden, welcher Peer ein Paket erhält. Zwei Peers können nicht beide 10.10.7.0/24 ankündigen, ohne dass einer von ihnen jede Suche gewinnt. Das ist eine Eigenschaft der Peer-Tabelle und nicht des Tunnels, deshalb ist die Lösung hier ein Adressplan und kein Routing-Trick.

Der Plan ist, das LAN gar nicht mehr anzukündigen. Kündigen Sie stattdessen einen Alias pro Dienst an, eine Adresse pro Standort, und lassen Sie das Gateway jedes Standorts diesen Alias auf seine echte Anwendung übersetzen.

Der Nutzer routet zwei eindeutige Adressen, sieht nie das mehrdeutige Präfix, und in keinem der beiden Büros ändert sich etwas. Das benennt auch die Grenze ehrlich: Sie veröffentlichen einen HTTPS-Dienst von jedem Standort, nicht zwei Netze verschmelzen. Die folgenden Regeln bleiben klein, weil die Aussage eng ist. Eine weitere Aussage bräuchte weitere Regeln, und genau so werden diese Designs kompliziert.

Geben Sie jedem Standort einen Alias, den der Nutzer routen kann

Wählen Sie Adressen aus einem Bereich, der mit nichts auf dem Rechner des Nutzers, dem Hub oder einem der beiden LANs kollidiert. Hier ist der Hub 10.66.0.1, der Nutzer 10.66.0.10, die Gateways 10.66.0.21 und 10.66.0.22 und die beiden Aliasse 10.77.1.20 und 10.77.2.20. Der Hub veröffentlicht jeden Alias über den Peer, der ihn besitzt, sodass ein ausgehendes Paket an einen Alias nur über den passenden Standort hinausgehen kann:

[Interface]
Address = 10.66.0.1/32
ListenPort = 51820
PrivateKey = HUB_KEY

[Peer]
PublicKey = USER_PUBLIC_KEY
AllowedIPs = 10.66.0.10/32

[Peer]
PublicKey = SITE_A_PUBLIC_KEY
AllowedIPs = 10.66.0.21/32, 10.77.1.20/32

[Peer]
PublicKey = SITE_B_PUBLIC_KEY
AllowedIPs = 10.66.0.22/32, 10.77.2.20/32

Die Nutzerseite braucht nur die beiden Aliasse, was die Client-Konfiguration frei von beiden LAN-Präfixen hält. Nichts in dieser Konfiguration nennt eines der echten LANs:

[Interface]
Address = 10.66.0.10/32
PrivateKey = USER_KEY

[Peer]
PublicKey = HUB_PUBLIC_KEY
Endpoint = hub.example.net:51820
AllowedIPs = 10.77.1.20/32, 10.77.2.20/32
PersistentKeepalive = 25

Jedes Gateway kündigt den Hub und die Quelle des Nutzers an, sonst nichts, sodass ein Standort nie das LAN des anderen kennenlernt. Keepalive hält eine NAT-Zuordnung auf dem Uplink des Standorts aufrecht; es autorisiert keinen Verkehr, und die Firewall entscheidet weiterhin, was zugelassen wird. Die Konfiguration eines Gateways auf das andere zu kopieren ist in Ordnung, solange sich der private Schlüssel, die Interface-Adresse und der Alias alle ändern.

Was der Hub zwischen zwei seiner Peers zulassen muss

Der Hub leitet Pakete zwischen zwei seiner eigenen Peers weiter, was eine Entscheidung in der Forward-Kette und keine Eingangsentscheidung ist. Aktivieren Sie IPv4-Forwarding über den üblichen Mechanismus der Plattform und erlauben Sie dann genau die Paare, die das Design braucht.

Die folgende Regel erlaubt dem Nutzer einen Alias und einen Port und erlaubt Rückverkehr über Connection Tracking. Sie verwirft alles andere im Forward-Pfad, und das ist der Punkt:

nft add table inet hub_transit
nft add chain inet hub_transit forward '{ type filter hook forward priority 0 ; policy drop ; }'
nft add rule inet hub_transit forward ct state established,related accept
nft add rule inet hub_transit forward iifname wg0 oifname wg0 tcp dport 443 ip saddr 10.66.0.10 ip daddr 10.77.1.20 accept

Zwei Details sind erwähnenswert, weil sie stille Fehler verursachen. Ein Accept in einer Basiskette überschreibt kein Drop in einer anderen, also verschmelzen Sie dies mit der bestehenden Policy, statt es daneben zu laden. Und die Quelladresse identifiziert das Gerät, nicht die Person; halten Sie die Anwendungsauthentifizierung getrennt von der Netzzulassung.

Wo ein Alias zu einer echten Adresse wird

Standort A erhält eine Anfrage für 10.77.1.20, schreibt das Ziel auf die echte Anwendung um und schreibt die Quelle auf seine eigene LAN-Adresse um, damit die Antwort ohne eine Route zum Tunnel zurückkehren kann. Beide Übersetzungen an einer Stelle zu erledigen hält den Rest des Netzes unwissend über den Alias. Die folgenden Regeln sind der ganze Mechanismus:

nft add table ip site_a_nat
nft add chain ip site_a_nat pre '{ type nat hook prerouting priority -100 ; policy accept ; }'
nft add chain ip site_a_nat post '{ type nat hook postrouting priority 100 ; policy accept ; }'
nft add rule ip site_a_nat pre iifname wg0 tcp dport 443 ip saddr 10.66.0.10 ip daddr 10.77.1.20 dnat to 10.10.7.20:443
nft add rule ip site_a_nat post iifname wg0 oifname lan0 tcp dport 443 ip saddr 10.66.0.10 ip daddr 10.10.7.20 snat to 10.10.7.2

Die Forward-Policy von Standort A muss dann den übersetzten Fluss vom Tunnel-Interface zum LAN-Interface zulassen, plus die Rückrichtung. Der Forward-Hook sieht das Ziel nach der Zielübersetzung und vor der Quellumschreibung, deshalb nennt die Regel die Adresse der echten Anwendung. Lesen Sie diese beiden Hooks in dieser Reihenfolge, wann immer eine Regel auf nichts zu passen scheint. Eine Forward-Regel, die gegen den Alias geschrieben ist, kann nie passen, weil der Alias an diesem Hook nicht mehr existiert.

Standort B wiederholt dies mit seinem eigenen Alias und seinem eigenen Schlüssel. Er darf den privaten Schlüssel von Standort A nicht wiederverwenden, denn zwei Peers, die eine Identität teilen, sind ein Konfigurationsfehler, der schwer zu sehen und leicht durch Kopieren einer Datei zu erzeugen ist. Halten Sie beide Gateway-Dokumente identisch außer bei den Werten, die sich unterscheiden müssen, damit der Unterschied bei der Durchsicht auffällt. Eine kopierte Datei ist der übliche Ursprung dieses Fehlers.

Die Quellumschreibung hat einen Preis. Die Anwendung sieht das Gateway als ihren Client, sodass ihre Protokolle nicht mehr zeigen, welcher Nutzer sich verbunden hat. Behalten Sie den Audit-Trail des Gateways, und schwächen Sie nicht den Anwendungs-Login ab, um eine Netzidentität auszugleichen, die die Übersetzung entfernt hat.

Wie Sie beweisen, dass beide veröffentlichten Namen antworten

Geben Sie jedem Alias einen DNS-Namen und konfigurieren Sie die Anwendung und das Zertifikat für diesen Namen, denn die Übersetzung schreibt Weiterleitungen oder eingebettete absolute URLs nicht um. Verwenden Sie einen Namen pro Standort, damit eine Zertifikatsabweichung nie für einen Routingfehler gehalten wird.

Testen Sie vom echten Client, bestätigen Sie, welcher Standort geantwortet hat, und testen Sie auch einen nicht autorisierten Port. Verwenden Sie neue Verbindungen nach jeder NAT-Änderung, da etablierter Zustand die alte Zuordnung behält:

wg show wg0 allowed-ips
sudo nft list ruleset
curl -sS -o /dev/null -w "%{http_code}\n" https://site-a.example.net/

Ein leerer oder unerwarteter Alias im ersten Befehl bedeutet, dass die Peer-Auswahl falsch ist, bevor irgendeine Firewall-Regel zählt. Wenn der Alias richtig ist und der Name trotzdem fehlschlägt, ist das Problem zu DNS und Zertifikaten gewandert. Sobald beide Namen antworten und der dritte Port geschlossen bleibt, tut das Design, was es behauptet: zwei eng veröffentlichte Dienste, keine zwei verschmolzenen LANs.