AdGuard Home & unbound | erweiterte Konfiguration

[plang.pl]

Einige kennen ja bereits meinen Thread zum Thema Einrichtung von AdGuard + unbound als DNS-Server.
Da ich dort an die Grenzen des Forums stoße (bezüglich in-Text-Bilder und Anzahl der Zeichen), trenne ich den Inhalt (nach Rücksprache mit einem Mod) nun in 2 Threads auf.

Hier soll es darum gehen, was man nach erfolgreicher Einrichtung weiter an den Containern und auch außenrum verbessern kann. Alle hier gelisteten Schritt sind optional. Grundsätzlich kann man AdGuard und unbound nach Durchführung der "Grund-Anleitung" schon gut betreiben. Wer aber noch etwas mehr rausholen will, ist hier richtig.

HINWEIS: Keine Gewährleistung auf Vollständigkeit und 100%ige Korrektheit! Wem ein Fehler auffällt, der kann das gerne (mit freundlichem Umgangston) hier melden!

Schritt 1: Verbesserungen am AdGuard-Container vornehmen
Schritt 1.1: Errors im Log von AdGuard beheben (Achtung: gewisse Kenntnisse auf dem Terminal / mit nano oder vi erforderlich):
Es kommt in manchen Konstellationen vor, dass im Container des AdGaurd immer mal wieder folgendes geloggt wird:

Hierzu sieht die Lösung wie folgt aus (danke an @Rodys):
Linux ist sehr sparsam mit dem UDP Buffer. Um das zu ändern, muss man in der /etc/sysctl.confund in der /etc.defaults/sysctl.conf folgendes ergänzen. So hat der Buffer 3MB und die Fehlermeldung sollte weg sein oder zumindest deutlich seltener auftreten. Funktional bringt diese Meldung aber keine Einschränkungen mit sich.

net.core.rmem_default=3000000
net.core.wmem_default=3000000
net.core.rmem_max=3000000
net.core.wmem_max=3000000

Die genannten Dateien müssen via ssh bearbeitet werden. Mit vi Dateiname können die Dateien bearbeitet werden. Wie man mit vi umgeht, ist z.B. hier beschrieben.
Für Anfänger ist eventuell die Bearbeitung mit nano einfacher. Das ist allerdings standardmäßig auf der DS nicht installiert. Man kann es aber nachinstallieren, wenn man das 3rd Party Paket "SynoCLI File Tools" aus dem Paket-Zentrum installiert. Dieses ist aber nur sichtbar, wenn man die SynoCommunity als Paketquelle hinzugefügt hat. Die Adresse lautet: https://packages.synocommunity.com/.

Schritt 1.2: Cloudflare-Domain aus den Logs exkludieren
Der Healthcheck des unbound-Containers fragt alle 30sec die Domain von Cloudflare an:

Man könnte sich das Image selbst bauen und den Healthcheck auskommentieren. Davon halte ich aber nix, da man das bei Updates neu machen muss und man den Healthcheck verliert. Ich habe bei mir einfach die Domain aus den Logs exkludiert:




Schritt 1.3: Hostnameauflösung in der Web-Ansicht des AdGuard-Containers
So wie ich es konfiguriert habe, fragt der AdGuard auch bei privaten IP-Adressen den unbound. Das hat den Nachteil, dass Hostnames nicht in der Weboberfläche des AdGuard aufgelöst werden. Konkret heißt das, dass bei den anfragenden Clients nicht die Namen, sondern die IP-Adressen gelistet werden. Man kann nun hergehen und die Fritte als privaten inversen DNS-Resolver angeben. Dann sieht man die Hostnamen. Das wiederum hat aber den Nachteil, dass eingetragene Records des unbound nicht aufgelöst werden können (Auswirkung siehe hier). Hier kann jeder selbst entscheiden, wie er es haben will. Wem die Auflösung der Hostnames in der Web-Ansicht des AdGuard wichtig ist, kann folgende Einstellung tätigen:

Zu finden unter Einstellungen -> DNS-Einstellungen. Natürlich müsst ihr wieder die IP des Routers anpassen, falls das bei euch eine andere ist.

Schritt 1.4: Weitere Blocklisten
Unter Filter -> DNS-Sperrliste seht ihr die Blocklisten, die ihr abonniert habt. Dort könnt ihr noch viele weitere ergänzen. Dazu einfach mal nach „Sperrlisten AdGuard“ oder „Sperrlisten pihole“ oder „AdBlock Listen“ oder dergleichen googeln.

Schritt 1.4.1: Meine Blocklisten / Regeln nutzen
Ich stelle hier auch die Blocklisten bereit, die ich derzeit verwende. Um es einfacher / schneller für euch zu machen, stelle ich den Part der Config-Datei des AdGuard bereit, der die Blocklisten enthält. Anstatt entsprechend oft manuell die Listen hinzufügen zu müssen, einfach die Config editieren. Die Datei im angehängten ZIP öffnen (filters.txt | zu finden in der BASIC-Anleitung). Darin befinden sich meine Blocklisten und meine benutzerdefinierte Liste, die zusätzliche gefährliche Dienste blockt oder auch ungefährliche Dienste, die ansonsten geblockt werden würden, freigibt.
Installation: In den Ordner /docker/adguard/conf auf der DS wechseln. Dort die Datei AdGuardHome.yaml mit einem Editor öffnen (idealerweise mit dem Text-Editor des DSM). Dort alles von der Zeile filters: bis die Zeile vor dhcp: rauslöschen und mit dem Inhalt meiner filters.txt ersetzen. Anschließend einmal den AdGuard Home Container neu starten.
Achtung!
In meinen benutzerdefinierten Umschreibungen wird die Domain fritz.box blockiert (aber nicht die Subdomains, weil die FritzBox intern dieses DNS-Suffix verwendet). Diese ist danach nicht mehr aufrufbar. Das habe ich gemacht, weil es schon mindestens einmal vorkam, dass diese Domain von "Gaunern" erworben worden ist und für dubiose Dinge genutzt wurde. Möchte man also weiterhin über diese Adresse das Webinterface der FritzBox aufrufen wollen, muss man diese Zeile unter den "benutzerdefinierten Filterregeln" löschen: ||fritz.box. Natürlich kann man auch gleich beim Importieren meiner Listen die ganze Zeile aus der Config-Datei löschen. Wenn die Auflösung dann immer noch nicht hinhaut, bitte Schritt 1.5 beachten.

Schritt 1.5: Auflösung der Domain fritz.box wieder hinbiegen
Möchte man nach der Umstellung der Clients auf den AdGuard als DNS-Server weiterhin via fritz.box auf die Web-Oberfläche der FritzBox zugreifen, muss man eine Anpassung an der DNS-Auflösung vornehmen. Hinweis: Diese Änderung ist nur dann erforderlich, wenn der Schritt 5.2 durchgeführt worden ist. (Bitte bei der Ausführung von Schritt 1.4.1 aufpassen: Wenn die Auflösung wieder funktionieren soll, muss die Domain wieder aus der Blocklist gelöscht werden; habe ich aber dort bereits beschrieben).
Vorgehensweise:
Am AdGuard in der Weboberfläche in den Bereich "Filter" -> "DNS-Umschreibungen" wechseln:


In dem auftauchenden Bereich unten links auf "DNS-Umschreibung hinzufügen" klicken und dort eine Umschreibung für die Domain auf die IP des Routers setzen (in meinem Fall 10.1.1.1; per default 192.168.178.1):


Abgesehen davon kann man natürlich auch über die IP-Adresse (per default die 192.168.178.1) auf die Oberfläche zugreifen. Ich habe es bei mir anders gelöst: Ich habe einen Reverse Proxy gebaut (router.meinedomain.de), mit dem ich über https auf die FritzBox komme.

Schritt 2: Infrastruktur-Verbesserungen
Schritt 2.1: Vorbeimogeln am AdGuard verhindern
Es gibt teilweise Geräte, die versuchen, sich entweder am AdGuard vorbeizumogeln (hatte schon Smart-TVs, die die "Kastrierung" der Werbung irgendwie bemerkten und auf 3rd Party DNS-Server ausgewichen sind). Um das zu verhindern, kann man in der FritzBox mit Zugangsprofilen arbeiten und damit für alle Geräte, außer der DS ausgehenden Verkehr auf Port 53 (DNS) sperren. An der Stelle möchte ich das Rad nicht neu erfinden und verlinke einfach auf ein YouTube-Video vom sempervideo: Link
Ich selbst habe aber mehr Ports bezüglich DNS gesperrt: 53 UDP (Standard); 853 TCP (DNS-over-TLS); 5353 UDP (Multicast DNS; sollte ohnehin niemals nach extern gehen).
Nun haben Geräte keine Wahl mehr: Entweder den AdGuard nutzen, oder keine Antwort mehr auf DNS-Anfragen erhalten. Technisch gesehen gibt es einen witeren Weg, das immer noch zu umgehen. Und zwar, indem ein Client nicht beim AdGuard, sondern beim unbound anfragt. In der Praxis wird das zwar eher nicht passieren. Dennoch kann man das auch noch unterbinden, wenn man möchte. Und zwar muss man in der unbound.conf Folgendes abändern: Man löscht die Zeilen, die mit access-control: beginnen, raus oder kommentiert sie mit einem # am Beginn der Zeile aus. Anschließend fügt man diese Zeile (nicht auskommentiert!) ein: access-control: 127.0.0.1/32 allow. Das bewirkt, dass nur noch Anfragen der DS selbst (also die des AdGuard-Containers) zugelassen werden.
Achtung!
Einige Geräte (allen voran diverse Smartphones) benutzen in der Standard-Einstellung "zum Schutz der Privatsphäre" "private DNS-Server" (vergesst es! Das ist nur Marketing-Bla-Bla!). Wenn diese Option an einem Gerät aktiv ist, ist kein Internetzugriff mehr möglich, da die FritzBox die DNS-Anfragen blockt! Also diese Option an den Clients ausschalten.

Schritt 2.2: Automatisierte Updates der root.hints & der root.zone
In dem Projekt.zip (aus der Grund-Anleitung) befindet sich eine Datei mit dem Namen unbound-update.sh. Das ist ein Shell-Script und aktualisiert die Zonendatei der Root-Server und die Infos mit den Root-Servern. Anschließend wird der unbound Container neu gestartet, um die Änderungen anzuwenden. Wenn man dieses Script nicht hinterlegt / automatisiert plant, sollte man die 2 Dateien von Zeit zu Zeit manuell aktualisieren. Die URLs stehen im Script (einfach mit Texteditor öffnen) oder auch oben bei Schritt 1.
Ich stelle hier noch 2 Optionen vor, wie man dieses Script automatoisieren kann. Die letzere Variante ist ein wenig schwieriger, als die erste. Aber wie so oft im Leben, ist sie eben auch die bessere. Grund: Falls ich hier das Projekt update, kann ich auch das Script bei euch mit updaten. Und: Wenn ihr unbound mal nicht mehr nutzen solltet, wird das Script auch nicht mehr ausgeführt, selbst wenn ihr vergesst, die Aufgabe im DSM zu löschen. Wenn ihr es bis hierher geschafft habt, schafft ihr es easy auch, die bessere Variante umzusetzen. Aber ich lasse euch die Wahl. Die Schritte, die in der folgenden Anleitung in grüner Schrift sind, könnt ihr weglassen. Dann habt ihr die einfache Variante umgesetzt. Den rot geschriebenen Schritt nur bei der einfachen Variante beachten.
Schritt 2.2.1: wieder mit ssh auf die DS verbinden und die folgenden Befehle ausführen:
-cd /volume1/docker/unbound
-chmod +x unbound-update.sh
Schritt 2.2.2: im Aufgabenplaner der Systemsteuerung eine geplante Aufgabe anlegen, die einmal monatlich dieses Script startet:

->im erscheinenden Fenster einen aussagekräftigen Namen für die Aufgabe vergeben und WICHTIG: Benutzer auf "root" ändern!:

->anschließend auf den Reiter "Zeitplan" wechseln und dort einen sinnvollen Zeitplan hinterlegen:

In meinem Beispiel hier wird das Script jeden ersten Freitag im Monat um 0 Uhr ausgeführt.
->danach wechseln auf den letzten Reiter "Aufgabeneinstellungen" und dort bei "benutzerdefiniertes Script" Folgendes eintragen:
Für Variante 1:
bash /volume1/docker/unbound/unbound-update.sh
Für Variante 2:

curl --output /volume1/docker/unbound/data/root.hints https://www.internic.net/domain/named.root
curl --output /volume1/docker/unbound/data/auth-zone/root.zone https://www.internic.net/domain/root.zone
synowebapi --exec api=SYNO.Docker.Container version=1 method=restart name=unbound

Schritt 2.2.3: Anschließend dieses Fenster mit "OK" schließen, die Warnung bestätigen. Wenn gefragt wird, das Passwort eingeben und fertig.

Hinweis: Wer das Kontrukt nicht auf einer DS betreibt, muss im Script die Zeile synowebapi --exec api=SYNO.Docker.Container version=1 method=restart name=unbound durch docker restart unbound ersetzen.



Wenn es hierzu fragen gibt, könnt ihr euch gerne in diesem Thread melden!

Spoiler: Agenda

-tiefer in die Konfiguration des AdGuard Containers gehen -> per Client-Konfiguration erklären
-Erlauben Regeln aus den benutzerdefinierten Umschreibungen zu den Positivlisten verschieben
-Update der Konfigurationsdatei des unbound
->Konfiguration Remote-Management des unbound via CLI

v1.1

Spoiler: Changelog

24-04-17 | v1.1.1
-Hinweis, dass Anleitung Fehler enthalten kann
-unbound-Update Fehler behoben
24-04-16 | v1.1
-Installation meiner Filter besser beschrieben
24-03-20 | v1
-erste Veröffentlichung

 

[Gagac]

Beim Schritt 2.2 hab ich mich für die schwerere Variante entschieden.
Bedeutet das dass ich Schritt 2.2.1 per SSH umsetzen soll und in der Aufgabeneinstellung das lange Skript mit "curl" einfügen soll?

PS: Copy&Paste sollte doch ausreichen oder?

 

[plang.pl]

Du kannst entweder das Script direkt in den Aufgabenplaner legen oder halt ein Script im Dateisystem anlegen und das mit dem Aufgabenplaner aufrufen.

 

[Gagac]

Vielen Dank. Meine eigentliche Frage ist aber, ob ich für die schwere Variante

bash /volume1/docker/unbound/unbound-update.sh

oder

Bash:

curl --output /volume1/docker/unbound/data/root.hints https://www.internic.net/domain/named.root
curl --output /volume1/docker/unbound/data/auth-zone/root.hints https://www.internic.net/domain/root.zone
synowebapi --exec api=SYNO.Docker.Container version=1 method=restart name=unbound

eingeben soll.

Ich denke Letzteres, oder?

 

[plang.pl]

Das liegt bei dir. Funktionieren tut beides.

 

[mj084]

curl --output /volume1/docker/unbound/data/root.hints https://www.internic.net/domain/named.root
curl --output /volume1/docker/unbound/data/auth-zone/root.hints https://www.internic.net/domain/root.zone
synowebapi --exec api=SYNO.Docker.Container version=1 method=restart name=unbound

Hier muss beim zweiten Eintrag sicher auth-zone/root.zone rein anstelle von root.hints oder?

 

[plang.pl]

Nein

 

[mj084]

Ok, was denn dann?

Dann erstellt er aus der heruntergeladenen root.zone aber eine root.hints - in deiner Beschreibung im ersten Post gibst du aber selbst root.zone an?!

Selbst in deinem Script steht:

curl --output /volume1/docker/unbound/data/auth-zone/root.zone https://www.internic.net/domain/root.zone

Testest du auch bevor du hier was veröffentlichst?

 

[plang.pl]

Sorry, ich habe hier halt kein 10-Mann Büro, sondern mache das hier nur als Hobby nebenbei. Da ist mir an einer Stelle ein Fehler unterlaufen. Wie die Datei heißen muss, steht in der unbound.conf. Hier in dem Thread habe ich in die config die root.hints geschrieben. Daher muss das auch so heißen. Werde ich anpassen. Danke

 

[mj084]

Sorry, was soll so eine d### Ausrede?
Ich prüfe es auch nur als Hobby nebenbei - und hör doch einfach mal auf immer auf irgendetwas zu verweisen!

Dein Script hatte einen Fehler und selbst auf Nachfrage bist du felsenfest überzeugt, dass es so richtig ist, obwohl selbst in deinem Updatescript root.zone steht, so muss es auch heissen...

 

[plang.pl]

Nein!!! Es muss root.hints heißen! So wie ich es auch erklärt habe. Und das, was du zuerst gefragt hast, habe ich mit "Nein" beantwortet und das war auch richtig so. Erst mit deiner zweiten Aussage hier ist mir ein Fehler im Script aufgefallen, von dem du bei der ersten Aussage aber ja noch nichts erwähnt hattest. Ich prüfe hier nicht bei jeder Aussage die komplette Anleitung. Darauf habe ich keine Lust und auch keine Zeit dafür.
Ich bin auch nicht hier, um zu diskutieren. Ich muss das nicht machen. Ich bin für jeden Hinweis auf einen Fehler dankbar. Doch dieses unnötige blöd von der Seite anreden muss ich nicht haben.
Jeder sollte auch selbst mitdenken und gegenprüfen. Wer darauf keinen Bock hat, muss sich das professionell einrichten lassen.

 

[mj084]

Warum hast du dann in deinem anderen Thread eine root.zone mit hochgeladen?
Warum heisst der Pfad: https://www.internic.net/domain/root.zone ?

 

[plang.pl]

Weil ich die Website nicht besitze und deshalb dort den Pfad nicht anpassen kann. Wenn du es anders haben willst, passe den Inhalt der unbound.conf an und dann kannst du es auch root.zone nennen, wenn dich das glücklicher macht.
Nein, ich habe keine root.zone hochgeladen. Die Datei heißt im Archiv korrekterweise root.hints

 

[mj084]

Sorry, jetzt ist es nicht mehr lustig!

1. Du gibst in deinem ursprünglichen Script root.zone an, du lädsts die Projekt.zip mit entsprechendem Inhalt hoch und lügst jetzt noch?

Es geht hier nicht um mich glücklicher machen, sondern dass hier jemand uneinsichtig ist und patzig reagiert!

 

[Gagac]

Bitte nicht streiten Leute. Fehler können jedem unterlaufen ^^
Muss ich jetzt etwas ausbessern, oder passt der ursprünglich geschriebene Eintrag?

curl --output /volume1/docker/unbound/data/root.hints https://www.internic.net/domain/named.root
curl --output /volume1/docker/unbound/data/auth-zone/root.hints https://www.internic.net/domain/root.zone
synowebapi --exec api=SYNO.Docker.Container version=1 method=restart name=unbound

 

[Wiesel6]

Vielleicht liegt hier bei @mj084 eine falsche Erwartungshaltung? In einem anderen wurde eine gute Zusammenfassung geschrieben
https://www.synology-forum.de/threads/weiss-jemand-wo-kw-abgeblieben-ist.133187/post-1162247

Hier im Forum kann es von den freiwilligen Helfern keinen Anspruch auf 100% exakte Anleitungen geben.
Und zum Umgangston „wie man in den Wald hineinruft, so schallt es heraus“

 

[mj084]

Nein, ich denke nicht.
Wenn ich einen Maintainer und sehr erfahrenen User laut Profil eine normale Frage stelle, die nach Sinn von Unbound ohne Hyperlocal Modus bei AdGuard - ja da erwarte ich dann schon eine normale Antwort anstatt Ausflüchte - gerade wenn man hier so eine Anleitung die sich einige draufpacken, zum Besten gibt ..

Wenn sich der User dann wegen so etwas angegriffen fühlt, dann tut es mir Leid - ich weiß längst auch nicht alles und versuche nur Dinge nachzuvollziehen, deswegen fragte ich ja nachdem möglichen übersehenen Sinn von Unbound in jenem Modus.

Wenn man dann als User noch normale Fragen stellt und sogar Fehler findet(warum kein anderer?), und man dann ignoriert wird, dann braucht sich in den Foren auch keiner mehr wundern wenn neue User auch keine Lust mehr haben zu helfen...

 

[Benares]

@mj084, wenn ich mir deine bisher 43 Beiträge im Forum so anschaue, hast du bisher noch nie was zum Forum beigetragen, sondern immer nur Forderungen gestellt.
So eine "Habe wille"-Mentalität kotzt mich an.
So ein Forum wie das hier lebt von der konstruktiven Zusammenarbeit aller Mitglieder. Klar passieren da manchmal auch Fehler, keiner kann alles wissen. Aber da rauft man sich zusammen, und versucht das gemeinsam zu klären.

 

[Wiesel6]

Ich verstehe nicht wieso der „Maintainer“ so hervorgehoben wird. Was das ist und wieso das einzelne User haben steht hier.
https://www.synology-forum.de/threads/willkommen-im-neuen-forum.108229/post-1089929

Bevor als nächstes noch Contributor kommt. Das sind User, die das Forum mit einer Geldspende unterstützen. Stichwort Kaffeeautomat auf der rechten Seite.

 

[mj084]

@mj084, wenn ich mir deine bisher 43 Beiträge im Forum so anschaue, hast du bisher noch nie was zum Forum beigetragen, sondern immer nur Forderungen gestellt.
So eine "Habe wille"-Mentalität kotzt mich an.
So ein Forum wie das hier lebt von der konstruktiven Zusammenarbeit aller Mitglieder. Klar passieren da manchmal auch Fehler, keiner kann alles wissen. Aber da rauft man sich zusammen, und versucht das gemeinsam zu klären.

Danke, dass du dir die Mühe gemacht hast, alle meine Beiträge zu lesen

Kannst du mir genau mitteilen wo ich konkret Forderungen stelle und wo die "Habe wille" Menatalität zum Vorschein kommt?

Konstruktive Zusammenarbeit? Wenn man solche Posts wie deine liest - der ist gut

Sorry, ich habe oben geschrieben, dass keiner alles wissen kann - und es war mein Ziel das zu klären, wenn man aber ignoriert wird, dann muss man sich nicht wundern wenn auch keine Lust mehr was gemeinsam zu klären - zumal ich es danach auch noch getan habe.

Aber wenn das die Reaktion hier im Forum auf konkrete Nachfragen ist - oh weh