☰

Wireguard-Mesh zwischen öffentlichem und lokalem Netzwerk

tag-icon • tag-icon networking vpn wireguard
Wireguard-Mesh zwischen öffentlichem und lokalem Netzwerk

Mein Mesh-Setup ist derzeit wie folgt: Bildbeschreibung hier eingeben

Mit einer Wireguard-Konfiguration ähnlich dieser auf jedem Knoten:

[Interface]
Address = 10.1.0.1/32
PrivateKey =
ListenPort = 5888

[Peer] # example public node [1-3]
PublicKey =
AllowedIPs = 10.1.0.2/32
Endpoint = X.X.X.X:5888
PersistentKeepalive = 25

[Peer] # example node behind cgnat [4-6]
PublicKey = 
AllowedIPs = 10.1.0.51/32
PersistentKeepalive = 25

Dadurch kann ich alle grünen Linien im obigen Diagramm anpingen. Aber ich kann keine der roten Linien zwischen den Knoten im CGNAT anpingen. Wie kann ich das tun?

VERSUCH 1 (ohne Node3)

Beispiel CGNAT ( Node4)

[Interface] # NODE 4
Address = 10.3.0.3/32
PrivateKey = 

[Peer] # NODE 1, 5 & 6
PublicKey = 
AllowedIPs = 10.3.0.1/32,10.3.0.51/32,10.3.0.52/32
Endpoint = X.X.X.X:5888
PersistentKeepalive = 25

[Peer] # NODE 2
PublicKey = 
AllowedIPs = 10.3.0.2/32
Endpoint = X.X.X.Y:5888
PersistentKeepalive = 25

Beispiel Öffentlicher Endpunkt ( Node1)

[Interface] # NODE 1
Address = 10.3.0.1/32
PrivateKey = 
ListenPort = 5888

[Peer] # NODE 5
PublicKey = 
AllowedIPs = 10.3.0.51/32
PersistentKeepalive = 25

[Peer] # NODE 6
PublicKey = 
AllowedIPs = 10.3.0.52/32
PersistentKeepalive = 25

[Peer] # NODE 2
PublicKey = 
AllowedIPs = 10.3.0.2/32
Endpoint = X.X.X.Y:5888
PersistentKeepalive = 25

[Peer] # NODE 4
PublicKey = 
AllowedIPs = 10.3.0.3/32
PersistentKeepalive = 25

Ich bin auch gelaufen auf Node1:

$ sysctl -w net.ipv4.ip_forward=1
$ sysctl -w net.ipv4.conf.maxnet.forwarding=1

wo maxnetist mein wg-name.

Antwort1

Wenn die Knoten 4,5,6 jeweils hinter ihrem eigenenCGNAT, dann können sie wie üblich keine ordnungsgemäße Kommunikation zwischen ihnen herstellen. Sie müssen sich auf die Knoten 1,2,3 verlassen, um den Verkehr weiterzuleiten. Diese CGNAT-Knoten benötigen also zusätzlicheErlaubteIPsfür einige öffentliche Peers in ihren Einstellungen, um anderen CGNAT-Knoten den Zugriff durch die öffentlichen Knoten zu erlauben, und die öffentlichen Knoten müssen als Router festgelegt werden.

Beispiel für Knoten 4, wobei angenommen wird, dass er die IP-Adresse 10.1.0.51/32 hat und Knoten 2 als Routing-Knoten verwendet wird:

[Interface]
Address = 10.1.0.51/32
PrivateKey =

[Peer] # example public node 1
PublicKey =
AllowedIPs = 10.1.0.1/32
Endpoint = X.X.X.X:5888
PersistentKeepalive = 25

[Peer] # example public node 2
PublicKey =
AllowedIPs = 10.1.0.2/32,10.1.0.52/32,10.1.0.53/32
Endpoint = Y.Y.Y.Y:5888
PersistentKeepalive = 25

[Peer] # example public node 3
PublicKey =
AllowedIPs = 10.1.0.3/32
Endpoint = Z.Z.Z.Z:5888
PersistentKeepalive = 25

Die IP-Adressen anderer CGNAT-Knoten werden voraussichtlich über Knoten 2 weitergeleitet und sollten zu den IP-Adressen dieses Peers hinzugefügt werden.ErlaubteIPs. Dadurch sollten sie auch automatisch zur Routing-Tabelle hinzugefügt werden.

Knoten 2 muss nun auch ein Router sein, zumindest auf seiner WireGuard-Schnittstelle, die sowohl Eingang als auch Ausgang sein wird. Unter Linux würde dies beispielsweise mit (unter der Annahme einer Schnittstelle) erfolgenwg0):

sysctl -w net.ipv4.conf.wg0.forwarding=1

Die Firewall-Regeln müssen auch weitergeleiteten Datenverkehr zulassen aufwg0.

Bitte beachten Sie, dass es nicht notwendig ist, die anderen CGNAT-Peers auf den CGNAT-Knoten zu definieren, und wenn sie definiert sind,darf nichthaben die IP-Adressen anderer CGNAT-Knoten inErlaubteIPs:

  • Sie sind nicht direkt erreichbar und
  • wenn die gleiche Adresse in nachfolgendenErlaubteIPses wird aus jeder vorherigen Definition gelöscht und nur der zuletzt definierte Peer hat es. MitKryptoschlüssel-RoutingIP-Adresse(n) <=> Peer.

Knoten 5 und 6 müssen eine kompatible Konfiguration haben (Knoten 2 muss ebenfalls als Router verwendet werden). Sie können sich stattdessen auch Folgendes vorstellen:

  • geteilte Rollen, wobei 4 und 5 von Knoten 2, 4 und 6 von Knoten 3 und 5 und 6 von Knoten 1 geroutet werden,
  • oder mehrere IP-Adressen innerhalb verschiedener IP-Blöcke, so dass jeder Block über einen anderen Routing-Knoten geroutet werden kann,
  • oder die Verwendung von Onion-Routing mit WireGuard-Verkehr innerhalb des WireGuard-Verkehrs, sodass die Routing-Knoten den Verkehr, der nicht für sie bestimmt ist, nicht dekodieren können,
  • oder die Verwendung mehrerer unabhängiger WireGuard-Schnittstellen (die untereinander nicht der Kryptoschlüssel-Interaktion unterliegen, sondern nur der Routing-Tabelle),
  • oder eine Kombination der vorherigen Optionen,

[...]

In allen Fällen ist für jede Topologieänderung, selbst wenn diese auf einen Fehler und nicht auf eine beabsichtigte Änderung zurückzuführen ist, eine Möglichkeit zum Synchronisieren der Konfigurationsänderungen in allen betroffenen Peers erforderlich. Derzeit gibt es hierfür kein spezielles Tool.

Abschließend noch ein Blog, in demBGP(das wäre das fehlende Tool) wird zusammen mit WireGuard verwendet, mit mehreren Adressen und auch einer Schnittstelle pro Peer-Knoten, wobei nur dieser Peer definiert ist, um das Cryptokey-Routing zu umgehen. Daraus kann man wahrscheinlich etwas lernen, aber das Thema ist für mich viel zu fortgeschritten.

Routenbasiertes VPN unter Linux mit WireGuard

verwandte Informationen