23.03.2023

4589

Wireguard: Verständnisfragen AllowedIPs

Hallo,

ich betreibe einen zentralen VPN-Server, zu dem sich verschiedene Clients über verschiedene Wireguard-"Instanzen" verbinden, d.h. es gibt mehrere Wireguard-Server auf verschiedenen Ports auf dem selben Server.

Nun ist u.A. ein Server an diesen VPN angebunden, der einen Dienst bereitstellt.
Ich möchte von einem mobilen Client (der über eine andere Wireguard-Instanz zum selben VPN-Server verbunden ist) auf diesen Dienst zugreifen.
Leider ist mir nicht ganz klar, wie das per "AllowedIPs" umgesetzt werden muss.

Ich skizziere mal meinen Aufbau:

wgA, Port 1000, Netz: 10.0.0.0/24, hier hängt der Server: 10.0.0.2
wgB, Port 2000, Netz: 10.1.0.0/24, hier hängt der mobile Client: 10.1.0.2

Wie müssen meine configs aussehen, damit der Client auf den Server zugreifen kann?
Dass ich im Betriebssystem noch ein Firewall-Freischaltungen benötige usw. ist klar, den Teil bekomme ich selbst hin.

Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben

Content-ID: 6479650249

Url: https://administrator.de/forum/wireguard-verstaendnisfragen-allowedips-6479650249.html

Ausgedruckt am: 22.12.2024 um 11:12 Uhr

11 Kommentare

Neuester Kommentar

es gibt mehrere Wireguard-Server auf verschiedenen Ports auf dem selben Server.

Wozu diesen Unsinn? Gibt es dafür einen triftigen Grund?

Leider ist mir nicht ganz klar, wie das per "AllowedIPs" umgesetzt werden muss.

Lesen und verstehen:
Merkzettel: VPN Installation mit Wireguard
Die "Allowed IPs" bestimmen immer welche remoten IPs in den Tunnel geroutet werden. Wireguard nennt das Verfahren Cryptokey Routing.

Ich skizziere mal meinen Aufbau:

Sind das externe oder interne WG IPs?? Etwas mehr Details würden allen hier helfen für eine zielführende Hilfe!
Ein Beispiel für eine kombinierte WG Site-to-Site Vernetzung mit Client VPN findest du z.B. HIER.

Es ist einfacher, jedem Kunden einen eigenen, neuen Tunnel zu Verfügung zu stellen, darum gibt es mehrere.

Es sind interne WG-IPs, die externen sind hier ja unerheblich.

Ich möchte also (durch die beiden WG-Tunnel hinweg) nach Möglichkeit z.B. folgendes machen:

10.1.0.2:23462 -> 10.0.0.1:80

Moin...

Zitat von @strator6750:

Es ist einfacher, jedem Kunden einen eigenen, neuen Tunnel zu Verfügung zu stellen, darum gibt es mehrere.

nun, abgesehen das du "Kunden" hast, aber dein Handwerk nicht verstehst- jeder endpoint bekommt doch (sollte) eine feste IP /32!
wiso ist das nicht einfach?

Es sind interne WG-IPs, die externen sind hier ja unerheblich.

wenn du es sagst

Ich möchte also (durch die beiden WG-Tunnel hinweg) nach Möglichkeit z.B. folgendes machen:

10.1.0.2:23462 -> 10.0.0.1:80

das kannst du ja machen, erstelle doch dazu eine FW Regel... und gut ist
@aqui hat super anleitungen erstellt, das lernst du in wenigen stunden!
Frank

Es ist einfacher, jedem Kunden einen eigenen, neuen Tunnel zu Verfügung zu stellen, darum gibt es mehrere.

Das ist ja auch richtig. Aber jeder Kunde bekommt einen eigenen Peer Eintrag !! Niemals startet man für jeden einzelnen Kunden einen kompletten Wireguard Prozess, das wäre ja völliger Quatsch.
Vermutlich hast du dich also nur gedrückt aus falsch, kann das sein?

nach Möglichkeit z.B. folgendes machen:

Port bezogen funktioniert kein Cryptorouting! Das geht imme rnur mit Adressen oder Netzen.
Dafür hast du im Server iptables oder besser die moderneren nftables an Bord!!
Kollege @Vision2015 hat es schon gesagt: Routing hat bekanntlich mit Firewalling NICHTS zu tun!

Wenn die 10.1.0.2 deine interne Tunnel Client IP ist und die dann hat dieser Client einfach nur
AllowedIPs = 10.1.0.1/32
In seinem Setup. Das lässt dann lediglich die IP Kommunikation nur mit dem Server (10.1.0.1) zu.
Eine interne Kommunikation über unterschiedliche WG Prozesse ist generell nicht möglich. Wie oben schon gesagt ist das zudem auch ein völlig falsches WG Setup bzw. Design.

Tatsächlich ist es so, dass jeder Kunde (bisher) einen eigenen Server hat, "innerhalb" dieses Servers jedoch durchaus mehrere Clients.

Also z.B:

Kunde A) Server, Client1, Client2, Client3, ...
Kunde B) Server, Client1, Client2
...

Habe mir das Setup angeschaut und könnte tatsächlich mit recht geringem Aufwand alle Clients in einem Server zusammenfassen, also einem Netz.

Leider wird es - zumindest vorerst - aber so bleiben müssen, dass der angebotene Dienste NICHT auf dem selben Host läuft wie der WG-Server.
Insofern wird dann Bspw. "Client1" ein "Server", der einen Dienst anbietet.
Aber das Problem muss ich dann eben mit Routing auf dem WG-Server lösen.

dass der angebotene Dienste NICHT auf dem selben Host läuft wie der WG-Server.

Das ist ja auch nicht das Problem. Dann gibst du halt diesen Host zusätzlich mit einer /32er Hostmaske ein.
AllowedIPs = 10.1.0.1/32, 10.0.0.1/32
So kann der Client dann einzig nur den WG Server und den Applikationsserver erreichen und nichts anderes.
Dein grundsätzlicher WG Designfehler ist das du auf dem WG Server mehrere WG Prozesse laufen hast. Das ist falsch, denn das lösst man nur über Peers wenn man es nutzerspezifisch machen will.
Das Filtern nach TCP oder UDP Ports der jeweiligen Anwendung kann WG so nicht leisten. Dafür gibt es , wie bereits gesagt, iptables oder nftables oder wenn dein WG Server eine Winblows Kiste ist dann deren lokale Firewall.

Ich hatte es gerade nicht explizit dazu geschrieben, aber: Ja, dass man nicht nach Ports/Protokollen usw. filtern kann war mir grundsätzlich klar, ich wollte nur ein Beispiel geben.

Ergänzungsfrage: Du hast mir ja bereits genannt, wie ich einen Client konfigurieren müsste, damit er auf einen anderen Peer zugreifen kann.
Kann ich das auf dem WG-Server zwingend einschränken? Denn theoretisch könnte sich ein Client doch seine WG-config so bearbeiten, dass er sich weitere Peers als Ziele einträgt, um diese erreichen zu können?

Natürlich kann ich das alles mit der jeweiligen Firewall der Clients abfangen, aber am liebsten wäre mir, wenn ich es zusätzlich seitens des WG-Servers einschränken könnte, da ich diesen unter Kontrolle habe, viele der Clients jedoch nicht.

Zitat von @strator6750:
Denn theoretisch könnte sich ein Client doch seine WG-config so bearbeiten, dass er sich weitere Peers als Ziele einträgt, um diese erreichen zu können?

Das würde aber auch nur klappen wenn man den anderen Client manipuliert den man erreichen möchte denn dessen AllowedIPs steht ja weiterhin auf der 32 IP des Wireguard-Servers (10.0.0.1/32) also akzeptiert dieser auch nur Traffic von dem und nicht von jemand anderes.

Kann ich das auf dem WG-Server zwingend einschränken?

Ja, man kann generell in der Firewall des Wireguard Servers in der FORWARD chain Traffic zwischen Wireguard Peers unterbinden indem man das Forwarding des Wireguard Subnetzes in das des Wireguard subnetzes droppt. Hört sich komisch an aber sämtlicher Traffic der Wireguard-Clients geht wegen des Cryptokey routings zwingend durch die Forward-Chain am Server, und damit lässt sich die Kommunikation untereinander unterbinden.
Bsp. mit iptables

iptables -I FORWARD -i wg0 -o wg0 -s  10.0.0.0/24 -d 10.0.0.0/24 -j DROP

Cheers briggs

Oder mit den moderneren nftables: 😉

chain forward {
                 type filter hook output priority 0;
                 ip saddr 10.0.0.0/24 ip daddr 10.0.0.0/24 drop
        } 

Zitat von @aqui:
Oder mit den moderneren nftables: 😉

Modern ja aber wenn es ein komplexeres FW-Setup wird bei hohem Durchsatz zur Zeit noch etwas langsamer als iptables, aber das wird sich sicher irgendwann noch ändern.