DNS-Redirect auf pi-hole

Zitat von Curiosity

Jetzt muss ich nur noch rausfinden, wie die Iptables Regeln automatisch bei einem Reboot der UDM-SE oder Firmware update beim start ausgeführt werden.

Über einen geeigneten funktionierenden Tip würde ich mich freuen.

Such mal im Forum nach CronJobs, meine letztens was wegen DDNS gelesen zu haben, die sind auch nach einem Reboot und eventull upgrade weiter aktiv.

Thema

Cronjob auf UDM-Pro

Hallo zusammen,
ich wollte einen Cronjob auf meiner UDM Pro anlegen, der regelmäßig diesen Befehl absetzt:
(Quelltext, 1 Zeile)


Ich habe mich also als root per SSH aufgeschaltet und mit "unifi-os shell" bin ich in die shell Ebene.

Dann habe ich einen neuen Cronjob angelegt, der aber bis hierhin noch leer ist:
(Quelltext, 1 Zeile)


Leider gibt es auf der UDM Pro kein "vi" oder "nano", um Inhalt da rein zu bekommen.

Weiß jemand eine Lösung, und wird das auf der UDM Pro funktionieren?

Viele Grüße, Max

maxwellpity

15. Juni 2021

sebcodes

Danke für den Link, ich meine, den habe ich schon mal gelesen gehabt. Allerdings beim Überfliegen ist mir schon aufgefallen, das der eher für die UDM/Pro ist. Die genannten Tools funktionieren bei der UDM Pro SE wohl nicht mehr, vor allem wenn da jetzt schon die 3.x drauf ist.

Aber ich lese mich da heute Nachmittag nochmal rein. Ist auf der Arbeit gerade etwas schlecht.

Hallo @all,

so hab heute Nachmittag nochmal nach einer Lösung gesucht und für mich eine Zufriedene Lösung gefunden, die sogar einen Reboot übersteht.

Da ja auf der UDM-SE ein Debian Bullseye Unterbau besteht konnte man das Problem relativ einfach lösen ohne zusätzliche Software zu installieren.

und zwar über die aktuell Entfernte Datei in Debian Bullseye /etc/rc.local

Also per SSH auf die UDM-SE einloggen und die Datei /etc/rc.local mit folgendem Standard-Inhalt anlegen:

#!/bin/sh -e
#
# rc.local
#
# This script is executed at the end of each multiuser runlevel.systemctl start rc-local# Make sure that the script will "exit 0" on success or any other
# value on error.
#
# In order to enable or disable this script just change the execution
# bits.
#
# By default this script does nothing.
exit 0

Die Datei mit folgenden Kommando ausführbar machen: chmod +x /etc/rc.local

Danach den systemd Manager mit systemctl daemon-reload konfigurieren.

Jetzt wird der rc-local Daemon mit systemctl start rc-local gestartet.

Läuft alles? Ein kurzer Check des Status vom rc-local mit systemctl status rc-local. Jetzt sollte die Ausgabe so aussehen:

● rc-local.service - /etc/rc.local Compatibility
     Loaded: loaded (/lib/systemd/system/rc-local.service; enabled-runtime; vendor preset: enabled)
    Drop-In: /lib/systemd/system/rc-local.service.d
             └─debian.conf
     Active: active (exited) since Wed 2023-08-09 17:08:32 CEST; 43min ago
       Docs: man:systemd-rc-local-generator(8)
      Tasks: 0 (limit: 4724)
     Memory: 0B
        CPU: 0
     CGroup: /system.slice/rc-local.service

Danach hatte ich dann meine eigentliche rc.local mit meinen Iptables Inhalt gefüllt. Das sah dann so aus:

#!/bin/sh -e
#
# rc.local
#
# This script is executed at the end of each multiuser runlevel.
# Make sure that the script will "exit 0" on success or any other
# value on error.
#
# In order to enable or disable this script just change the execution
# bits.
#
# By default this script does nothing.


#Redirect DNS Traffic over Pihole

iptables -t nat -A PREROUTING -p tcp --dport 53 -j DNAT --to 10.x.x.x
iptables -t nat -A PREROUTING -p udp --dport 53 -j DNAT --to 10.x.x.x
iptables -t nat -A PREROUTING -p tcp --dport 853 -j DNAT --to 10.x.x.x
iptables -t nat -A PREROUTING -p udp --dport 853 -j DNAT --to 10.x.x.x 

exit 0

10.x.x.x ist natürlich die IP des Pihole.

Danach habe ich den rc.local Daemon mit systemctl restart rc-local neugestartet und et voilà: fertig war meine Reboot-resistente Änderung für die Umleitung des DNS-Traffics über meine Pi-Holes (hab das nach der Arbeit natürlich gleich mit einem reboot der UDM-SE getestet, läuft ). Jetzt kann sich kein fest einprogrammierter DNS-Server-Eintrag von irgendwelchen Geräten an meinen Pi-Holes vorbeimogeln. Außer natürlich verschlüsselter Traffic über DNS over HTTPS (DoH). Für das Schlupfloch habe zusätzlich eine Liste auf dem Pi-Hole eingepflegt, die einige DoH-Server filtert.

Beim mir funktioniert die Iptables-Umleitung ohne die Masquerade-Regel, da mein Pi-Hole in einem separaten Subnetz liegt, wie der Rest der Netzwerke. Die Clients bekommen davon nichts mit, das passiert transparent, die meinen die Antwort von ihren einprogrammierten DNS Server zu erhalten. Wie in folgenden Beispiel hab ich mal einfach die Abfrage von einem Client gestartet und einen abzufragenden DNS-Server angegeben:

loxberry@loxberry:~ $ dig qnap.de  @8.8.8.8

; <<>> DiG 9.16.42-Debian <<>> qnap.de @8.8.8.8
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 24268
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: ec5b5eab000a80079a615cec64d3be5745ae27d7b50cdb25 (good)
;; QUESTION SECTION:
;qnap.de.                       IN      A

;; ANSWER SECTION:
qnap.de.                2400    IN      A       18.233.144.27
qnap.de.                2400    IN      A       3.222.6.149
qnap.de.                2400    IN      A       34.195.88.28

;; Query time: 36 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Wed Aug 09 18:27:03 CEST 2023
;; MSG SIZE  rcvd: 112

Angeblich wurde der 8.8.8.8 abgefragt, aber die Antwort kam von meinem Pi-Hole:

Nicht wundern über den Pi-Hole-Port 533. Das ist mein BIND-DNS Upstream-Server für den Pi-Hole. Der ist für die lokale Namensauflösung meines lokalen Netzwerks und die eigentlich Auflösungen der IP-Adressen des Internets verantwortlich. Dieser leitet dann alle Anfragen, die er nicht selbst beantworten kann entweder über den DNSCrypt-Proxy oder Stubby weiter, damit diese dann die korrekte IP liefern. Der Pihole ist also praktisch die Vorfilterung meiner IP-Abfragen.

Hallo zusammen,

erst einmal herzlichen Dank für Eure investierte Arbeit und die super Anleitung.

Leider bin ich zwar UniFi-Nutzer, allerdings habe ich einen UDR, also keine UDM.

Und da immer mehr Geräte im Heimnetz hart codierte DNS-Server nutzen und damit die im Netzwerk installierten DNS-Server verwenden, die per DHCP verteilt werden, würde ich die Lösung gerne bei mir umsetzen.

Gibt es Erfahrungen, ob das Vorgehen auch in einem Unifi Dream Router funktioniert oder ob ggf. Anpassungen erforderlich sind?

Danke und viele Grüße,

Matthias

Zitat von matmike

Hallo zusammen,

erst einmal herzlichen Dank für Eure investierte Arbeit und die super Anleitung.

Leider bin ich zwar UniFi-Nutzer, allerdings habe ich einen UDR, also keine UDM.

Und da immer mehr Geräte im Heimnetz hart codierte DNS-Server nutzen und damit die im Netzwerk installierten DNS-Server verwenden, die per DHCP verteilt werden, würde ich die Lösung gerne bei mir umsetzen.

Gibt es Erfahrungen, ob das Vorgehen auch in einem Unifi Dream Router funktioniert oder ob ggf. Anpassungen erforderlich sind?

Danke und viele Grüße,

Matthias

Alles anzeigen

Die UDR basiert auf dem selben Betriebssystem wie die UDM SE. Somit sollte das gehen.

Prima, vielen Dank! Das hatte ich gehofft und mache mich vsl. am Wochenende mal an die Versuche, das umzusetzen.

Viele Grüße,

Matthias

ich hab in einem meiner Netze auch ne UDR laufen, da kannst du problemlos auch nen Pi dranhänge, wie jkasten schon gesagt hat, analog zur UDM

Aso, da ist meine Frage glaube ich falsch angekommen.

Der Pi hängt dran (mit AdGuardHome, das finde ich besser als piHole), ein paar Subnetzen und so weiter.

Konkret ging es dann um die Frage, ob die NAT-Regeln aus dem Post von curiosity so funktionieren. Da hat mir jkasten ja weitergeholfen und ich versuche am Wochenende, die momentan implementierten Block-Regeln in der Firewall für alle Geräte außer meinem Pi durch die NAT-Regeln zu ersetzen, damit auch wirklich der Verkehr umgebogen wird.

Früher hatte ich das über json-Files auf dem USG, das ist aber ja leider mit den neuen Geräten nicht mehr direkt möglich.

Viele Grüße,

Matthias

So, kleines Update der ganzen Aktion:

Hat im Prinzip genau so geklappt wie beschrieben.

Ich habe zur Sicherheit noch per ifconfig geprüft, welches Interface ich denn überhaupt beeinflussen will, da habe ich mehrere Netze laufen. Das Standard-Netz ist aber auch beim UDR br0.

Vielleicht noch ein Hinweis für alle, die durch die neue Lösung ihre alten Blocking-Regeln ablösen: Diese musste ich rausnehmen, da sie ansonsten mit den per NAT umgebogenen Botschaften kollidieren.

Vielen Dank nochmal für Eure Hilfe und Eure Anleitungen,

Matthias

So, heute hat sich ein kleines Problem ergeben: Beim Start scheint es eine Kollision zu geben, die zu folgender Ausgabe führt:

root@Dream-Router:/etc# systemctl status rc-local
● rc-local.service - /etc/rc.local Compatibility
     Loaded: loaded (/lib/systemd/system/rc-local.service; enabled-runtime; ven>
    Drop-In: /lib/systemd/system/rc-local.service.d
             └─debian.conf
     Active: failed (Result: exit-code) since Mon 2024-04-22 19:12:23 CEST; 11m>
       Docs: man:systemd-rc-local-generator(8)
        CPU: 17ms

Apr 22 19:12:22 Dream-Router systemd[1]: Starting /etc/rc.local Compatibility...
Apr 22 19:12:23 Dream-Router rc.local[5340]: Another app is currently holding t>
Apr 22 19:12:23 Dream-Router systemd[1]: rc-local.service: Control process exit>
Apr 22 19:12:23 Dream-Router systemd[1]: rc-local.service: Failed with result '>
Apr 22 19:12:23 Dream-Router systemd[1]: Failed to start /etc/rc.local Compatib>
lines 1-13/13 (END)
● rc-local.service - /etc/rc.local Compatibility
     Loaded: loaded (/lib/systemd/system/rc-local.service; enabled-runtime; vendor preset: enabled)
    Drop-In: /lib/systemd/system/rc-local.service.d
             └─debian.conf
     Active: failed (Result: exit-code) since Mon 2024-04-22 19:12:23 CEST; 11min ago
       Docs: man:systemd-rc-local-generator(8)
        CPU: 17ms

Apr 22 19:12:22 Dream-Router systemd[1]: Starting /etc/rc.local Compatibility...
Apr 22 19:12:23 Dream-Router rc.local[5340]: Another app is currently holding the xtables lock. Perhaps you want to us>
Apr 22 19:12:23 Dream-Router systemd[1]: rc-local.service: Control process exited, code=exited, status=4/NOPERMISSION
Apr 22 19:12:23 Dream-Router systemd[1]: rc-local.service: Failed with result 'exit-code'.
Apr 22 19:12:23 Dream-Router systemd[1]: Failed to start /etc/rc.local Compatibility.

(leider abgeschnitten, sollte aber erkennbar sein).

Wenn ich das Skript ausführe nach dem Start, also auf der Konsole, gibt es kein Problem. Ich vermute, dass hier die Ausführung gleichzeitig mit den Änderungen kommt, die das System für die über die UI angelegten Regeln durchführt.

Kann damit Jemand etwas anfangen bzw. kennt eine Lösung?

Zitat von matmike

Another app is currently holding the xtables lock. Perhaps you want to us>

Du Versuchst Regel hinzuzufügen während irgendwas anders grade regeln hinzufügt.

Bau in das Script ein "sleep 10“ (oder höher) damit das Unifi System seinen kram in ruhe einträgt bevorzugst.

du dein kram einträgst.

ODER:

weil so genau kann man das nicht sagen es könnte sein

/run/xtables.lock existiert noch und ist geöffnet von einem anderen process

(lsof /run/xtables.lock würde sagen wer). Da ggf drauf warten das da keiner zugreift

bzw. file löschen...

Aber das warten oben sollte ausreichen.

Ich hatte bei mir auch das Problem mit dem @reboot.
Hab zwar nicht rausgefunden an was es lag, aber es ging nicht.

Mache das dann einfach minütlich im Nachhinein und prüfe aber vorab, ob es die Regel schon gibts, sonst hat man sie ja doppelt und dreifach...
Nur so als Möglichkeit für dich - schau einfach mal rein wenns dich interessiert -->

Beitrag

RE: 2 pi-holes als DNS mit UXG-Lite

Ich fasse nochmal zusammen was ich gemacht habe:

1.) Beide PiHole IP's als DNS Server in den beiden VLANs HEIM & VPN hinterlegt, damit sie per DHCP verteilt werden.
GAST lasse ich bei mir offen und ohne AdBlocker.
Die WAN seitigen DNS Server sind auf Standard, habe aber zusätzlich unter Settings - Security den DNS Shield mit Manuell & Cloudflare aktiviert! Gehe auch in den PiHoles über Cloudflare mit DoT

2.) Group mit meinen beiden PiHole IPs angelegt (von Vorteil wenn die IP's angrenzend sind, da…

DKeppi

11. April 2024

Bin auch für Verbesserungsvorschläge offen

P.S.: Merke grad', dass bei mir der Port 853 noch fehlt... gleich eingefügt!