Wireguard Verbindung von VPS auf Ionos zu lokalen Pi-hole

Moin,

wie auch immer Deine Konfiguration ist, die Pakete im VPN müssen jedenfalls bis zum Pihole. Kannst Du ja testen, indem Du mit einem Client im VPN den pihole über nslookup abfragst. Da, mutmaßlich, Deine VPN-Clients aus einem Transfernetz kommen, müssen natürlich alle "Blockaden" unterwegs beseitigt sein.
Also

• grundsätzliche Erreichbarkeit des Pihole im Rahmen der Wireguard-Konfiguration
• Freigabe bei etwaig dazwischen liegenden Firewalls
• Konfiguration des Pihole, dass er Anfragen aus dem Transfernetz/VPN entgegennimmt (ggf. so, wie oben dargestellt, einfach alles erlauben, immer besser natürlich begrenzt auf das weitere Netz/die weiteren Netze neben dem normalen LAN oder den VLANs

Gruß

DivideByZero

Wenn das denn nun die Lösung war bitte deinen Thread dann auch als erledigt markieren!
Wie kann ich einen Beitrag als gelöst markieren?

Du hast es leider wieder nicht geschafft deine WG Server Konfg und auch die eines Beispielclients hier zu posten und zwingst wieder zum Kristallkugeln. 😡
Ob VPN Clients den lokalen DNS Server im 10er Netz erreichen können hängt massgeblich von deren Wireguard Konfig ab.
Der DNS Eintrag, wenn man denn will, definiert eine DNS IP Adresse mit der alle Clients dann bei aktivem Tunnel arbeiten. Ist der Tunnel deaktiviert fallen sie auf den im Betriebssystem konfigurierten DNS zurück.

Also checke bitte deine Server und Client Konfig ob diese mit der Beispiel Konfig des Tutorials übereinstimmt. Insbesondere was das DNS Setting anbetrifft!!
Merkzettel: VPN Installation mit Wireguard
Bitte ggf. posten damit wir checken können welche Fehler du ggf. beim grundlegenden Setup gemacht hast!
Funktionieren tut das was du willst schon wenn man es denn richtig macht. Da sist ja ein klassisches VPN Setup mit einem lokalen DNS Server.

Schonmal sehr gut. Zeigt das die WG Konfig dort vermutlich erstmal OK ist. (Geraten?!)

Jetzts wirds aber wirr bei dir....
Du schreibst

• 1.) "Ich kann von N2 und N3 auf die WG-Endgeräte in N1 zugreifen"
• 2.) dann aber..."Was nicht geht, ist der zugriff auf die DNS Server in N1."

Das ist völlig widersprüchlich. Wenn du von N2 und N3 auf alle Endgeräte in N1 zugreifen kannst dann doch auch auf die DNS Server die in N1 sitzen!
Owohl der Begriff "N1" auch wieder mehrdeutig ist umfasst er 3 (!) IP Netze:

• VLAN10 10.0.0/24,
• VLAN20 192.168.20.0/24,
• VLAN100 192.168.100.0/24

Welches Dieser Netze ist denn nun "N1" oder sind damit alle 3 Netze gemeint??
Und... WER routet zwischen diesen IP Netzen??
Dazu kommt das du zu mindestens in 2 der N1 Netze je einen WG Client hat der eine Tunnel aufbaut was so oder so zwar machbar ist aber in dem Falle völlig unsinnig ist wenn ein Router zwischen diesen VLANs routet. Das würde nur dann Sinn machen wenn diese 3 VLAN untereinander völlig isoliert sind.
Kann aber auch nicht der Fall sein denn der DNS Server für diese Netze befindet sich ja zentral im 10er Netz also MUSS dort geroutet werden wenn Clients aus anderen Netzen diesen DNS nutzen.
Also alles ziemlicher Murks und wirr designed ohne einen Plan.

Es ist auch ziemlicher Blödsinn wenn der VLAN Router ein Mikrotik ist der perfekt Wireguard kann, den nicht als WG Client für das zentrale VPN Dialin auf den VPS Server zu verwenden statt dieser unsäglichen Frickelei mit einzelnen (überflüssigen) Clients in den VLAN Segmenten?!
Der Mikrotik bedient dann mit einem WG Peer zentral deine N1 Netze und den Zugriff kannst du sehr granular über dess Firewall steuern.
So ein Konzept ist deutlich sauberer und sinnvoller als das was du da mit den Clients frickelst. Gibt es einen zwingenden Grund dafür?

Wie man einen Mikrotik als Wireguard Client schnell und einfach an den VPS Server anbindet erklärt dir, wie immer, ein Foren Thread:
Mikrotik als Wireguard VPN Client auf Server verbinden

Wie ist das genau zu verstehen? Arbeiten die dann als NUR Clients oder routen sie auch das Netz??
Wenn sie als NUR Clients arbeiten dann musst du natürlich für den Fall eine lokalen DNS sicherstellen das diese den auch routingtechnisch erreichen können. Da das aber bei dir ja lokal ist hat siese Frage dann nichts mit dem Wireguard Setup zu tun, das ist klar. Das ist dann eine eher routingtechnische Frage zw. den VLANs.

So oder so wäre das aber ein recht unsinniges Konstrukt. Es wäre doch deutlich sinnvoller den Mikrotik den VPN Peer auf auf den Server aufzumachen und die Clients dann ohne lokale VPN Frickelei auf dem Server arbeiten zu lassen. Gäbe es einen Grund der dagegen spräche? 🤔

Dann hast du Wireguard nicht verstanden oder das Tutorial nicht gelesen...
Der Mikrotik kann doch ebenso wie alle anderen Wireguard Komponenten auch entweder Server (Resonder) oder auch Client (Initiator) sein.
Das ist ausschliesslich davon abhängig wie DU als Admin das konfigurierst.
Du hast das oben gepostete Beispiel eines Mikrotik als Wireguard Client gar nicht gelesen, oder?
Ansonsten wäre deine Frage dazu hier doch obsolet gewesen. 😡

Welche Optionen denn??
Folge doch schlicht und einfach der o.a. Anleitung als Client, dort ist das doch alles explizit und Schritt für Schritt auch für Laien verständlich erklärt.
Hier nochmals deine ToDos: (Annahme interne WG Client IP für den MT ist: 172.22.22.22, musst du durch deine Adressierung ersetzen)

• Interne WG IP und Schlüsselpaar für den Mikrotik Client erzeugen
• Mikrotik Client Peer auf dem Server anlegen mit:

Danach mit wg-quick down wg0 und einem folgenden wg-quick up wg0 den Wireguard Server einmal neu durchstraten das der den neuen Peer aktiviert. Alternativ den WG Daemon mit systemctl restart wg-quick@wg0.service neu starten.
Das wäre der Server Part...

Weiter gehts mit dem Mikrotik Client:

Im WG Menü + klicken und ein WG Tunnelinterface einrichten

Den Namen kannst du frei wählen!

WG Client IP auf dem Tunnel Interface setzen

VPS Server Peer einrichten

(Annahme: WG interne Server IP: 172.22.22.1)
Hier trägst du die VPS Server IP und den WG UDP Endpoint Port deines Servers ein sowie das .8.0er Netz von N2 und die Client IP von N4 sofern die aus den N1 Netzen erreichbar sein sollen. ⚠️ Achte auf die internen WG Adressen die in den AllowedIPs immer als /32 mit Hostmaske angegeben werden müssen! (Siehe dazu auch Wireguard Tutorial)

Statische Route konfigurieren

Der Mikrotik lernt als Router keine Wireguard Routen dynamisch wie man es von klassischen WG Clients kennt. Das ist auch sinnvoll und üblich bei dedizierten Routern oder Firewalls denn würde man dem Tür und Tor öffnen könnten so Routen injiziert werden die man nicht möchte. (Security). Für N2 gilt dann

Wie man die Ping Checks vom Mikrotik auf den Server macht findest du im oben geposteten Lösungsthread. Wenn man denn mal liest...
Ist doch alles kein Hexenwerk und diese 4 einfachen Schritte von oben in 10 Minuten im WinBox GUI mit ein paar Klicks konfiguriert. Stattdessen machst du eine umständliche und unnütze von hinten durch die Brust ins Auge Frickelei die alles unnötig verkompliziert. Keep it simple stupid...!
Viel mehr "Silbertablett" geht jetzt nicht...

1. Gericht
Das kann man machen, muss man aber nicht. Skripte die immer was "automatisieren" bergen auch immer eine latente Gefahr etwas zu "verschlimmbessern".
Die Wireguard Konfig ist recht banal und in der Regel bei einem Client Peer nur ein simpler 2-Zeiler in der wg0.conf Datei den man in nichtmal einer Minute im Editor ergänzt hat. Ob man für solche Banalitäten ein Skript benötigt muss jeder für sich selber entscheiden.
Wie man es auch einfach händisch macht erklärt das hiesige Wireguard Tutorial in allen Einzelheiten. Es hilft auch das Skript zu "kontrollieren" ob es sauber arbeitet oder irgendwelchen Unsinn in die wg0.conf bringt wie Firewall Kommandos, oder Redirect statt Split Tunneling usw. usw.

2. Gericht
Wie und wo du die Keys zu den Peer erzeugst spielt keinerlei Rolle. Das kann man auf dem Server machen auf dem Mikrotik oder auf jedem x-beliebigen Client oder oder. Wichtig ist nur das man ein gültiges Key Pärchen für den jeweiligen Peer hat. Key Paare sind NICHT abhängig von irgendeiner Hardware auf der sie erzeugt wurden.
Ob man den UDP Port der Tunnelverbindung auf dem Default belässt ist ebenfalls persönliche Geschmackssache. Es kann sicher nicht schaden wenn man seinen VPN Traffic etwas individualisiert denn mit dem Default Port ist dieser Traffic immer sofort identifizierbar. Auch blocken einige Provider in einfachen Consumer Accounts oftmals die VPN Default Ports.
Wichtig ist darauf zu achten das der gewählt Port in der empfohlenen Range der IANA Ephemeral Ports (49152 bis 65535) liegt.

4. Gericht
Bei einem Client musst du ja bei der Peer Definition immer nur den Public Key angeben. Folglich wird dort auch nur der Public Key verwendet und das Private Feld bleibt leer. Anders machst du es in deiner wg0.conf Datei ja auch nicht!
Die wg0.conf beschreibt ja mehr oder minder den offiziellen Wireguard Weg der Konfiguration den auch Endgeräte mit GUI wie der Mikrotik von der Logik her NICHT anders machen.
Wenn man also diese Logik weiterdenkt dann steht da also immer nur der Pub Key wie es sich auch gehört in einer Peer Definition.

Diese Frage lässt leider wieder vermuten das du das Wireguard Tutorial NICHT sorgfältig gelesen hast, denn sonst wäre sie obsolet.
Die Logik der Keys ist immer gleich und extra für dich wiederholen wir sie nochmal aus dem Tutorial aus Sicht des Servers (VPN Responder):

Server (VPN Responder):
[Interface]
Address = <Interne_WG_Server_IP>
PrivateKey = <Privater-Key-Server>
ListenPort = <UDP_Tunnelport>
[Peer]
PublicKey = <Öffentlicher-Key-Client>
AllowedIPs = <Interne_WG_Client_IP/32, remote_IP_Netze>

Client (VPN Initiator):
[Interface]
Address = <Interne_WG_Client_IP>
PrivateKey = <Privater-Key-Client>
(DNS = 192.168.x.y) --> Optional, nur wenn interner DNS erforderlich ist.
[Peer]
PublicKey = <Öffentlicher-Key-Server>
Endpoint = <Server_IP_FQDN>: <UDP_Tunnelport>
AllowedIPs = <Interne_WG_Server_IP/32>
PersistentkeepAlive = 25

Jeder Peer braucht also immer ein Key Pärchen aus einem öffentlichen und privaten Key. Und ja, du hast natürlich Recht, wenn man das nicht sauber dokumentiert welches Pärchen zu welchem Peer gehört dann kann das eine Quelle für Fehler sein.
Auch ein guter Punkt gerade keine überflüssigen Skripte zur Erstellung zu verwenden weil man schlecht kontrollieren kann was die so "anrichten". Ebenso kannst du deine jeweiligen wg0.conf Dateien auch mit Kommentarzeilen versehen die dir als Admin deutlich die Übersicht erleichtern.
Hier bist also DU selber als Admin gefordert das du das sauber dokumentierst und auch in 3 Wochen noch weisst was du gemacht hast.

Jetzt musst du nur noch kochen und genießen. Bon Appetit!