Ich hab bei mir einen NUC mit ioBroker laufen und Alexa im Haus.
Die steuern Hue Lampen und Sonos Speaker.
Zumindest bis zum Zeitpunkt der Installation von Pi-Hole auf meiner NAS.
Bei Alexa habe ich die Sonos speaker jeweils als bevorzugten Ausgabe Lautsprecher im entsprechenden Raum eingestellt.
Somit wurde Musik automatisch über diese ausgegeben und man konnte einfach sagen: Alexa lauter, und der Sonos wurde lauter. Das geht jetzt nicht mehr.
Ebenso startet ein Radiosender nicht mehr auf dem bevorzugten Lautsprecher sondern im Echo.
Beim ioBroker ist es so dass er die Sonos gelegentlich lauter oder leider macht.
Das kann er nun nicht mehr.
Ebenso werden die Hue Lampen nicht mehr geschaltet wenn der ioBroker das anstößt.
Im Netz habe ich schon etwas recherchiert dass Sonos keine manuellem DNS Server mag.
Das lässt sich offenbar nicht ändern.
Allein das ist für mich ein K.O. Kriterium.
Die Geschichte mit ioB und hue sowieso.
Das bringt mich dazu den Pi-Hole nun doch wieder zu deaktivieren.
Zumindest solange bis Ich weiß ob und wie sich das lösen lässt.
hast du dir schon mal angeschaut, welche Queries von deinen Sonos-Geräten im Pihole aufgeführt werden und welche davon geblockt werden? Ich könnte mir vorstellen, wenn du die Blockierten sukzessive einzeln auf die Whiteliste setzt, dann findest du vielleicht raus, welche Domains deine Geräte unbedingt auflösen können müssen, ohne ihnen gleich alles zu erlauben.
Die Vorschlaghammer-Methode wäre ein Upgrade auf Pihole v5.0 (aktuell noch Beta, aber sicher nicht mehr lange). Dort kannst du für jeden Clients individuell die Filterung einstellen (also auch komplett ausnehmen), ohne den Pihole für das gesamte Netz deaktivieren zu müssen.
Die Sonos-Geräte wurden irgendwann auf zwangsweise Cloudnutzung umgestellt, selbst dann, wenn man die Cloudfunktionen überhaupt nicht nutzen wollte. Seitdem funken sie munter Telemetrie-Daten nach Hause.
Für mich war das ein Grund, diese Geräte aus dem Haus zu verbannen, aber das muss jeder selbst entscheiden. (klicken für mehr)
Wer schon zuvor Cloud-Dienste genutzt hat wie z.B. die Anbindung an eine Sprachsteuerung, wird das wohl eher hinnehmen (wobei es auch für die Cloudanbindung der Sprachsteuerung keinen zwingenden Grund gibt, leider aber auch kaum brauchbare und gleichzeitig einfach zu bedienende Alternativen).
Man sollte sich dann nur bewusst machen, dass damit die Funktonsfähigkeit von Geräten im eigenen Haus direkt von einem stabilen Internetzugang und der Verfügbarkeit der Server der entsprechenden Diensteanbieter abhängt. Stellt so ein Anbieter seinen Dienst ein, führt das auch zu Problemen mit den Geräten.
Daneben sind manche Diensteanbieter auch schon auf die Idee kommen, den Zugang zu den Cloudfunktionen über ein kostenpflichtiges Abo-Modell zu monetarisieren.
In Verbindung mit einem Cloudzwang grenzt das für mich an Erpressung.
Genug philosophiert:
Um die von Deinen IoT-Geräten angefragten Domänen zu erkennen. könnte ein Blick auf folgenden Beitrag helfen:
Ich habe das vergangene Query Log geprüft.
Die einzigen geblockten Domains der Sonos Geräte ist "msmetrics.ws.sonos.com"
Ob sie jetzt Telemetrie Daten nachhause schicken oder nicht, ist mir relativ egal.
Da bin ich nicht so.
Aber meine o.g. Probleme sind es mir eben auch nicht wert, "werbefreie" Netzwerkgeräte zu besitzen.
Dann schalte ich den PiHole lieber wieder ab.
Das mag jeder anders sehen.
Ich für meinen Teil halte es für absolut ausgeschlossen, sich komplett vor ungewollter Preisgabe von personenbezogenen Daten zu schützen.
Auch wenn der PiHole hier im Heimnetz einiges leistet, hilft er nicht mehr sobald man das Haus verlässt.
Ich will auch keine Grundsatzdiskussion starten.
WIe gesagt, jeder sieht es viellecht etwas anders.
Ich danke die für deine große HIlfe bei der EInrichtung und dem Verstehen des PiHole.
Wie gesagt, mit v5.0 kannst du auch nur für deine Sonos Geräte Pihole "umgehen" - und der Rest deines Netzwerks kommt trotzdem in den Genuss von weniger Werbung
Das soll auch jeder.
Wir machen keine Vorschriften, wir teilen hier nur unsere Erfahrungen.
Es wäre sinnvoll, dies auch live zu tun:
Möglichst nur die auffälligen Geräte laufen lassen und dann die eingehende Anfragen unter Tools | Tail pihole.log beobachten, und dann daraus mögliche Whiteliste-Einträge ableiten.
Wenn das nichts bringt oder mit vielen Domänen zu unübersichtlich wird, kannst Du analog zu yubiusers v5-Vorschlag auch für Pihole v4 über manuelle Anpassungen für dnsmasq einen client-spezifischen DNS-Bypass legen.
Da Du Docker einsetzt:
Die Beta ist schon weitgehend stabil (aber immer noch Beta).
Wenn Du Dir das mal anschauen möchtest:
In Docker-Compose folgende Zeile
Ich habe es hinbekommen.
Und zwar musste ich zunächste per SSH "docker pull pihole/pihole:beta-v5.0" ausführen.
Dann tauchte im DOcker auf der Syno unter "Abbilder" das geladene PiHole5 Image auf.
Habe das INterface wieder auf bond0 geändert und meine ServerIP (10.0.0.123) eingetragen.
Leider kann der Container irgendwas nicht zuordnen.
Es ist genau das gleiche Problem wie hier bereits beschrieben,
nur dass ich die Umgebungsvariable "SERVERIP" bereits bei der Installation gefüllt habe.
Und bei mir gehts um eine anderen Port:
(network.c.464) can't bind to port: 10.0.123 80 Address already in use
Dort half zunächst ein Neustart ohne volumes. Das ist einen Test wert.
Eventuell gibt es mit einigen Deiner Einstellungen Konflikte. Die sollte man dann allerdings beheben, denn die volumes braucht man, sonst überlebt Deine Konfguraton einen Neustart nicht.
Ich habe aktuell aber keine Dockerinstallation mehr laufen, so dass ich das aktuell nicht nachbauen kann.
Hast Du jetzt oder vorher einen anderen Port in Pi-hole verwendet?
Port 80 ist der Standardport, insofern würde es mich wundern, wenn der Port bei Dir zu Konflikten führt. Ich vermute eher, dass die IP-Adresse 10.0.0.123 Probleme bereitet, eventuell weil diese bereits im Einsatz war und daher von Docker intern noch benutzt wird.
In Deinem Fall ginge es wohl um einen Abgleich der Infos aus dieser Datei mit den entsprechenden Docker-Environment-Variablen.
/etc/lighttpd/lighttpd.conf gilt für einen Zugriff innerhalb des Pi-hole-Containers. Du öffnest eine interaktive Bash-Shell im Docker-Container über docker exec:
docker exec -it <container-id-or-name> bash
Damit kannst Du Kommandos wie auf einem normalen Rechner absetzen. Am Ende verlässt Du sie mit:
exit
Eventuell gibt es über Deine Web-Oberfläche einen einfacheren Weg, eine Shell zu öffnen.
Manipulationen an diesen Dateien würde ich weder über den von Dir genannten Subvolume-Pfad noch über eine Shell vornehmen (höchstens zu Testzwecken).
Nur Dateien unter den über volumes konfigurierten Pfaden überleben einen Docker-Neustart.
Habe den Container einfach per Web Oberfläche in Docker installiert.
Wenn man dort "gleiches Netzwerk nutzen wie Host" wählt, kann man keine Ports mappen.
