11
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.
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.
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-ID: 6479650249
Url: https://administrator.de/contentid/6479650249
Printed on: September 1, 2024 at 02:09 o'clock
11 Comments
Latest comment
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
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...
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
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!Es ist einfacher, jedem Kunden einen eigenen, neuen Tunnel zu Verfügung zu stellen, darum gibt es mehrere.
wiso ist das nicht einfach?
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
@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.
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.
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.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?
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 DROPCheers briggs
1
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
}
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.
Wenns das denn nun war bitte deinen Thread hier dann auch als erledigt markieren!
