Wireguard - kein Zugriff auf Adguard DNS

[svbeagle]

Moin zusammen,

Bin kein Netzwerk- oder Container-Experte und ich verstehe die Ursache folgenden Problems nicht - vielleicht könnt Ihr mir ein paar Tipps und Hinweise geben.

********* Mein Setup ************
Heimnetzwerk-IP-Range 192.169.1.x
Fritzbox 192.168.1.1
Synology DS920: 192.168.1.8

Auf Synology läuft Docker - IP-Range 172.17.0.x
Synology Webserver aktiv


Wireguard läuft auf meiner DS920+ als eingenes SPK-Paket (installiert nach folgender Anleitung: https://www.blackvoid.club/wireguard-spk-for-your-synology-nas/
Im Docker läuft wg-easy zur Wireguard-Konfiguration über die Standard-Bridge mit folgender Konfiguration

- WG_DEFAULT_ADDRESS=192.168.13.x

Zugriff von aussen funktioniert problemlos

Im Docker läuft auch mein adGuard DNS. Installiert in einer eigenen IP-Range 192.168.99.x. Für den Zugriff darauf ist eine "adguard_bridge" eingerichtet.
Zugriff auf adguard (und andere Container) wiederum über MACVLAN 192.168.1.40/29, wobei Adguard auf 192.168.1.40 erreicht wird

Auf meinem Heinmetzwerk erreiche ich damit Adguard DNS und Adguard Admin-Konsole über 192.168.1.40 problemlos, alle Filter in Adguard greifen auf allen Geräten im lokalen LAN / WLAN.

Synology DNS-Server (für lokale Hostnames) aktiv, mit Forwarding auf 192.168.1.40


************* Das Problem ************
Ich möchte gerne, dass die Clients, die über Wireguard ins Netzwerk kommen, auch den Adguard-DNS verwenden.
Dafür habe ich in Wg-easy den Default-DNS-Server konfiguriert

- WG_DEFAULT_DNS=192.168.1.40

Die Verbindung der Clients funktioniert weiterhin, allerdings können diese nun keine einzige externe Webseite erreichen.
Der Zugriff auf interne IP-Adressen funktioniert über VPN wobei;:
Beim Zugriff auf 192.168.1.40 landet man nicht auf der Adguard-Login-Page, sondern auf der Standard-Webserver-Page von der Synology.


********* Was ist zu tun? ***********
Irgendwie agiert die IP-Adresse 192.168.1.40 beim VPN-Zugriff nicht mehr als DNS-Sever. Warum? Was fehlt mir hier?
Eine zusätzilche Bridge wird wohl nicht notwendig sein, denn der Zugriff auf 192.168.1.x ist ja über VPN möglich.

Vielleicht könnt ihr mir hier weiterhelfen.
Danke!

 

[Stationary]

Was für eine Fritzbox ist das, warum nutzt Du nicht Wireguard auf dem Router? Da ist es besser aufgehoben als auf der DS.

 

[svbeagle]

Ja, ich kenne die Diskussionen, VPN nicht am NAS zu betreiben.
Die Fritzbox gibts nicht her - ist eine 6591 Cable von Vondafone mit FritzOS 7.29 drauf. Das dauert vermutlich noch bis das kommt....

 

[Benie]

Muss ja nicht zwingend Wireguard sein, Ein stinknormales VPN läßt sich mit jeder FritzBox ab OS 7.00 einrichten. Mit my Fritz kein Problem.
Das einzige was Du hierzu brauchst ist eine öffentliche IP. Die dürftest Du bei Vodafone mit dem Argument, benötigt für das HomeyOffice, und natürlich dabei sehr nett sein problemlos bekommen.

 

[svbeagle]

Natürlich kann ich ein anderes VPN einrichten (OpenVPN funktioniert über den Synology VPN-Server).
Aber ich möchte eigentlich gerne das Problem prinzipiell verstehen und nicht Umgehungslösungen diskutieren.

 

[Benie]

Kann ich verstehen und kann ich nachvollziehen, ich bin da auch so, reinbeisen bis man es hat.

 

[plang.pl]

Dein Problem ist das MACVLAN. Die DS selbst kann nicht mit Containern im MACVLAN reden. Außer du baust einen Workaround (https://www.synology-forum.de/threa...guard-problem-openvswitch.117355/post-1016794). Besser aber, du nutzt AdGuard einfach ohne MACVLAN.
Du kannst auf der DS mal testweise das Paket "SynoCLI Network Tools" aus der SynoCommunity installieren. Dann kannst du dich mit ssh verbinden und wirst sehen, dass du die IP des AdGuard von der DS aus nicht pingen kannst.

 

[svbeagle]

Danke für den verlinkten Workaround.
Verständnisfrage dazu:
Die 10.1.1.9/32 ist die IP-Adresse Deiner DS?
Die 10.1.1.4/30 sind die IP-Adressen Deiner MACVLAN?

Habe ich das richtig verstanden?

 

[plang.pl]

Nein. Die 10.1.1.9 ist einfach eine freie Adresse in meinem LAN. Diese nutzt die DS, um mit dem AdGuard zu sprechen.
10.1.1.4 war die Adresse meines AdGuards.
Du musst folgende Befehle absetzen:

ip link add MACVLAN link eth0 type macvlan mode bridge
ip addr add IP1/32 dev MACVLAN
ip link set MACVLAN up
ip route add IP2/32 dev MACVLAN

Wobei Folgendes zu beachten ist:
-"MACVLAN" ist hier nur der Name, den kannst du beliebig setzen
-wenn Openvswitch an ist / der VMM installiert ist, musst du "eth0" durch "ovs_eth0" ersetzen
-wenn du nicht LAN1 benutzt, dann musst du "eth0" auch anpassen
-"IP1" ersetzen durch eine IP-Adresse deines Heimnetzes, welche nicht belegt und außerhalb des DHCP-Range ist
-"IP2" ersetzen durch die IP-Adresse deines AdGuards
-hinter den IPs sind Subnetzmasken. "/32" bedeutet, dass es sich um eine einzelne Adresse handelt
->ich wollte damals meinen AdGuard und meinen unbound im MACVLAN erreichen, deshalb hatte ich "/30" gesetzt
-nach dem Reboot ist das wieder wech -> brauchst ein Script in der Aufgabenplanung
So könnte ein Script in der Aufgabenplanung (als root!) aussehen. Es wartet erst, bis der Docker Dienst läuft. Ansonsten könnte es Probleme geben

#!/bin/bash
while ! /usr/local/bin/docker info >/dev/null 2>&1;
do
    sleep 5s
done
sleep 5s
ip link add MACVLAN link eth0 type macvlan mode bridge
ip addr add IP1/32 dev MACVLAN
ip link set MACVLAN up
ip route add IP2/32 dev MACVLAN

 

[svbeagle]

Hallo,
vielen Dank für die Klarstellung. Ich hatte ein ähnliches Script schon in Arbeit und habe es jetzt nach Deinen Hinweisen angepasst.
Die neue IP2 ist von der DS aus auch pingbar, aber es werden weiterhin keine DNS-Anfragen über diese IP beantwortet (nslookup-Requests mit dieser IP als DNS-Server liefern keinen Response)

Habe testweise anstelle von Adguard nun PiHole im Docker (auf 192.168.1.45) deployed - aber auch hier das gleiche Verhalten: Keine DNS-Responses über die IP 192.168.1.47 (Die IP ist definitiv frei und nur dann pingbar, wenn die ip-route auch angelegt wurde.)

while ! /usr/local/bin/docker info >/dev/null 2>&1;
do
    echo sleep
    sleep 5s
done
sleep 5s

ip link add DS9_2_Pihole link ovs_eth0 type macvlan mode bridge
ip addr add 192.168.1.47/32 dev DS9_2_Pihole
ip link set DS9_2_Pihole up
ip route add 192.168.1.45/32 dev DS9_2_Pihole

Noch eine Idee?

 

[svbeagle]

Bin selbst noch ein bisschen weitergekommen - anscheinend hat es mit dem Ausführungszeitpunkt des Scripts zu tun.
Es wird beim Systemstart korrekt ausgeführt - und wartet auch auf Docker.
Allerdings ist der Host 192.168.1.45 dann immer noch nicht pingbar und der DNS-Server kann via Wireguard nicht benutzt werden.

Wenn ich das Script allerdings nach einer Weile nochmals manuell ausführe, wird - wie erwartet - protokolliert, dass der link schon existiert (2x "RTNETLINK answers: File exists"), aber danach ist 192.168.1.45 pingbar und wird auch via Wireguard benutzt.

Kann es sein, dass das Script zu früh - zwar nach dem Start von Docker, aber vor dem Start des Pihole-Containers - ausgeführt wird und deshalb nicht richtig greift?
Habe testweise ein "sleep 180s" nach dem Start von Docker hinzugefügt - das hilft auch nichts.

Kann ich anders prüfen, ob der pi-hole-container schon läuft?

 

[plang.pl]

keine DNS-Anfragen über diese IP beantwortet

Du musst die Anfragen auch an die IP des pihole stellen und nicht an die IP der Bridge - diese führt zur DS.

Kann ich anders prüfen, ob der pi-hole-container schon läuft?

Kann sein, kann ich dir gerade nicht sagen, weil ich unterwegs bin. 180s nach dem Start sollte der Container aber ja eigentlich up sein. Und außerdem steht und fällt die Route ja nicht mit dem pihole Container, sondern mit dem Docker-Daemon.

 

[plang.pl]

Hast du das Problem mittlerweile gefixt?
Würde mich interessieren, was die Ursache / Lösung war / ist...