Hallo allerseits,
Kann ich bitte einen Hinweis bekommen, was bei mir schief läuft? Statt der Blockpage bekomme ich "Unable to parse results from queryads.php". Hier in Forum habe ich nichts gefunden das mir weiterhilt 
Pi-Hole mit Unbound auf DietPi. Debug-Token: https://tricorder.pi-hole.net/ocim5nube6
Danke schonmal 
Die Blockseite konnte stets ausschließlich für HTTP-Seiten angezeigt werden, für HTTPS-Seiten generell nie.
Da die weitverbreitete Verwendung von HTTPS inzwischen HTTP so gut wie verdrängt hat, verwendet Pi-hole schon seit langem den NULL-Blockmodus als Standard.
Zusätzlich git es in Deinem Fall eine Diskrepanz bei der Webserver-Konfiguration: lighttpd läuft, obwohl Pi-hole nicht für dessen Verwendung konfiguriert ist.
*** [ DIAGNOSING ]: Ports in use
[80] is in use by lighttpd
[80] is in use by lighttpd
127.0.0.1:5335 unbound (IPv4)
[53] is in use by pihole-FTL
[53] is in use by pihole-FTL
[4711] is in use by pihole-FTL
[4711] is in use by pihole-FTL
*** [ DIAGNOSING ]: Setup variables
INSTALL_WEB_SERVER=false
INSTALL_WEB_INTERFACE=true
LIGHTTPD_ENABLED=false
Möglicherweise könnte das auf die Installation über DietPi zurückzuführen sein - das kan ich aber nicht mit Sicherheit sagen.
Hallo und Danke für deine schnelle Antwort.
Die Webserver-Konfiguration ist auf DietPi zurückzuführen. Im Setup kann man da zwischen verschiedenen Webservern wählen. Ich habe PiHole mit "pihole -r" resettet. In den Setup variables steht jetzt LIGHTTPD_ENABLED=true, an den übrigen Ausgaben des Debug-Logs ändert sich dadurch aber nichts. Deshalb meine Fragen:
Danke nochmal für deine Antwort
Wir versuchen immer wieder darauf hinzuweisen, dass wenn Pi-hole über dietpi-software installiert wurde, bei einer Reparatur mit Re-confiiguration über pihole -r Lighttpd nicht ausgewählt werden sollte, da dann verschiedene Lighttpd und PHP Konfigurationen und Instanzen gemischt werden. Vielleicht sollten wir mal einen interaktiven Popup-Dialog draus machen .
Du hast jetzt (z.B. sichtbar über htop) php-fpm Prozesse und php-cgi Prozesse laufen, richtig? Dass sollten wir dann erst einmal in Ordnung bringen, sodass nur ein Setup aktiv ist. In den Fall hast du die Wahl zwischen dem Standard Pi-hole Lighttpd+PHP-CGI Setup und dem DietPi Lighttpd+PHP-FPM Setup. Solange du keine weiter Webseite/Applikation, speziellere Webserver-Einstellungen oder HTTPS altiv hattest, macht es keinen wirklichen Unterschied. Auch HTTPS könnten wir recht einfach in die external.conf portieren.
Die Setup-Variablen haben für den laufenden Betrieb keine Bedeutung. Sie werden bei Reparatur (und womöglich teils beim Update?) verwendet um die Einstellungen der eigentlichen involvierten Programme vorzunehmen.
doubleclick.com sollte eigentlich unabhängig von Unbound aufgelöst werden, aber ich sehe diesen Test regelmäßig fehlschlagen, also möglichweise ein Bug im Debug-Skript selbst. Solange der Server ansonsten keine Verbindungsprobleme hat, würde ich mir darüber keine Sorgen machen.
Der X-Pihole Header wird sowohl beim DietPi Setup als auch natürlich beim Pi-hole Setup gesetzt. Das sollten wir uns noch mal nach der Entscheidung + Bereinigung für eines von beiden ansehen. Möglichweise hat Lighttpd Probleme damit wenn ein Header doppelt gesetzt wurde.
Das ist richtig.
Die Abfrage läuft weder über Pi-hole noch über unbound, sondern via a remote, public DNS server - also über einen öffentlichen DNS-Server.
Wenn die Auflösung über öffentliche DNS-Server scheitert, wird dies in der Mehrheit der Fälle durch eine fehlerhafte Firewallkonfiguration (auf dem Pi-hole-Host oder dem Router) verursacht; fehlende Netzwerkintegration, fehlerhaftes Routing oder nicht verfügbares Gateway, ausgefallene, überlastete oder zensierte DNS-Server sowie Router, die ihrerseits filtern oder DNS-Verkehr auf einen filternden Upstream-DNS-Server umbiegen sind mir ebenfalls begegnet.
Mir ist hingegen kein einziger Fall bekannt, wo das Scheitern der Auflösung über einen öffentlichen DNS-Server auf einen Fehler im Debug-Skript zurückzuführen gewesen ist.
Im vorliegenden Fall würde das isoliert betrachtet zunächst bedeuten, dass Googles IPv6 DNS-Server aus _Renes Netzwerk nicht ereichbar ist.
Sofern das auf IPv6 beschränkt ist, könnte das daran liegen, dass IPv6 nur lokal aktiv ist, z.B. weil IPv6 vom ISP nicht angeboten wird oder der Router kein öffentliches IPV6-Präfix verteilt.
Pi-holes Web-Oberfläche verwendet stellenweise Angaben aus setupVars.conf unmittelbar für die Anzeige.
Darüber hinaus verwendet Pi-hole setupVars.conf bei Rekonfigurations- und Reparaturläufen (pihole -r) sowie bei Upgrades (pihole -up) , und zwar sowohl lesend als auch schreibend.
Manuelle Änderungen an dieser Datei sollten also vermieden werden, da es sonst leicht zu einem Missverhältnis zwischen angezeigter Information und Pi-holes tatsächlicher Konfiguration oder zu einer unbeabsichtigten Umkonfiguration beim nächsten Aufruf des Pihole-Skripts kommen kann.
Zum nachstellen: pi-hole/piholeDebug.sh at 1ab193fa9d5f94798cd4e50d969495d60913ed78 · pi-hole/pi-hole · GitHub
dig +tries=1 +time=2 -6 doubleclick.com @2001:4860:4860::8888 +short AAAA
Ich könnte mir vorstellen, dass die 2 Sekunden in manchen Fällen bei IPv6 zu knapp sind. Ich kenne mehrere Fälle, inclusive unserem VPS, wo IPv6 grundsätzlich funktioniert, aber insbesondere die erste Anfrage und auch Antwort zu einem neuen Host um einige Sekunden verzögert ist. Im Falle unseres VPS konnte niemand das Problem finden, sodass es vermutlich auf schlechtes Routing des ISP zurückzuführen ist. Das ist natürlich untragbar für eine öffentliche Webseite, sodass wir IPv6 deaktivieren mussten . Aber du hast insofern recht, als dass es normalerweise klappen sollte, und bei einer DNS Anfrage von über 2 Sekunden definitiv etwas nicht in Ordnung ist, sei es lokal, im NAT/router oder beim ISP.
Vielen Dank für eure schnellen und ausführlichen Antworten, ich weiß das sehr zu schätzen.
Über htop sehe ich nur php-fpm Prozesse, php-cgi taucht nirgendwo auf. Neben pihole laufen auf dem pi schon noch ein paar andere Prozesse (u.a. iobroker, node-red, tasmoadmin).
Wie finde ich heraus an welcher Stelle eine Fehlkonfiguration vorliegt (bzgl. DNS-Auflösung)? Das Problem ist auf IPv6 beschränkt, sollte aber zur Verfügung stehen (Telekom, IPv6-Unterstützung ist im Router aktiviert). Ich habe keine manuellen Änderungen an der setupVars.conf vorgenommen.
dig +tries=1 +time=2 -6 doubleclick.com @2001:4860:4860::8888 +short AAAA
=> connection timed out; no servers could be reached
Ich hab nochmal ein neues debug-token erstellt. Vielleicht hilfts ja:
https://tricorder.pi-hole.net/p6bb6rfg3k
Erstmal zum IPv6 DNS timeout. Schau mal ob es überhaupt klappt und wie lange es dann dauert. Ich glaube der standard timeout ist immer noch 5 Sekunden, aber vielleicht reicht das ja:
time dig +tries=1 -6 doubleclick.com @2001:4860:4860::8888 +short AAAA
Bzgl. php-fpm, ich have LIGHTTPD_ENABLED missinterpretiert:
INSTALL_WEB_SERVER und dürfte dann bei dir noch auf false stehen. Dann hast du vermutlich in pihole -r "Repair" ausgewählt und nicht "Reconfigure".
.time dig +tries=1 -6 doubleclick.com @2001:4860:4860::8888 +short AAAA
=> connection timed out; no servers could be reached
real 0m5,228s
user 0m0,059s
sys 0m0,023s
pihole -r (Reconfigure) wurde ausgeführt. setupVars.conf:
INSTALL_WEB_SERVER=true
INSTALL_WEB_INTERFACE=true
LIGHTTPD_ENABLED=true
TasmoAdmin/iobroker ohne Probleme erreichbar. pi.hole/admin geht nicht. Da gehts nur über die IP.
Man könnte jetzt längere timeouts versuchen:
dig +tries=1 +time=20 -6 doubleclick.com @2001:4860:4860::8888 +short AAAA
Aber vielleicht klappt IPv6 DNS tatsächlich aus irgendeinem Grund überhaupt nicht. Ist aber auch nicht wichtig, da IPv4 upstream DNS Einträge genauso gut Hosts/Domains zu einer IPv6 Adresse auflösen können, bzw AAAA records handhaben. Als upstream DNS müssen dann halt IPv4 Adressen benutzt werden, aber das ist ja kein Problem.
Okay, dann passt da irgendwas nicht zusammen 
. Kannst du mal die folgenden beiden Dateien posten:
cat /etc/lighttpd/lighttpd.conf
cat /etc/lighttpd/lighttpd.conf.orig
Und:
dpkg -l | grep 'php'
Hmm, hast du das von einem System getestet, welches Pi-hole als DNS benutzt? Der Pi-hole Server selbst tut das nicht, sofern du es nicht manuell eingestellt hast. Wenn Pi-hole benutzt wird, sollte pi.hole correct zur IP aufgelöst werden.
Ich glaube, Du kannst dieses Verhalten ignorieren.
Du verwendest unbound als einzigen Upstream-DNS, und wenn Du unbound nach unserem Guide aufgesetzt hast, erfolgt die Auflösung über IPv4.
Pi-hole wird im Gespann mit unbound daher die korrekte DNS-Auflösung liefern (sowohl für A als auch AAAA, wie von MichaIng schon erwähnt).
Du müsstest dem nur weiter nachgehen, wenn Du außerhalb von DNS noch andere Auffälligkeiten im Zusammenhang mit IPv6 feststellen solltest -außerhalb von DNS hätte das dann auch nichts mit Pi-hole zu tun.
This topic was automatically closed 21 days after the last reply. New replies are no longer allowed.