seit einiger Zeit ist mir aufgefallen, dass eine App spoardisch sehr langsam lädt. Immer wenn eine Abfrage im Web etwas länger dauert, wird ein Lade-Icon gezeigt. Ich hab dann mal 4G statt WLAN genutzt und alles war wieder flott.
Ein Blick in die Queries zeigt keine geblockten Zugriffe, das Deaktivieren von pihole brachte ebenfalls keine Verbesserung. Ich habe nun testweise am Router den DNS wieder auf den Router selber geändert und die Probleme sind gelöst.
Pihole läuft hier auf einem rpi4 mit 4GB RAM, ich habe Lighttpd allerdings durch nginx ersetzt. Für die DNS Funktion ist der Webserver aber wohl nicht wirklich entscheidend, oder? Auf anderen Clients konnte ich keinerlei solche Probleme feststellen.
Hat jemand eine Idee, wo das Problem liegen könnte?
Dein Debug Log zeigt Probleme mit Deiner IPv6-Adresse. (klicken für Details)
[✓] IPv6 address(es) bound to the eth0 interface:
2003:d6::dea6:32<entfernt> does not match the IP found in /etc/pihole/setupVars.conf
fd00::dea6:32<entfernt> does not match the IP found in /etc/pihole/setupVars.conf
fe80::dea6:32<entfernt> does not match the IP found in /etc/pihole/setupVars.conf
*** [ DIAGNOSING ]: Name resolution (IPv4) using a random blocked domain and a known ad-serving domain
[✗] Failed to resolve via localhost (127.0.0.1)
[✗] Failed to resolve via Pi-hole (192.168.178.52)
[✓] doubleclick.com is 172.217.23.14 via a remote, public DNS server (8.8.8.8)
*** [ DIAGNOSING ]: Name resolution (IPv6) using a random blocked domain and a known ad-serving domain
[✗] Failed to resolve via localhost (::1)
[✗] Failed to resolve via Pi-hole (2003:d6::dea6:32<entfernt>)
[✓] doubleclick.com is 2a00:1450:4016:807::200e via a remote, public DNS server (2001:4860:4860::8888)
Insbesondere Smartphones bevorzugen häufig IPv6 gegenüber IPv4.
Ich vermute daher, dass Deine problematischen Clients zunächst erfolglos eine DNS-Anfrage über IPv6 versuchen, bevor sie nach Time-Out auf eine DNS-Frage über IPv4 wechseln.
Du verwendest bislang eine globale IPv6-Adresse (aus dem Adressbereich 2000::/3) für Deinen Pi-hole. Diese kann sich z.B. durch Änderung des IPv6-Präfixes oder durch die Verwendung von Privacy Extensions ändern - ersteres ist bei Dir passiert.
Du solltest überlegen, stattdessen auf eine ULA-Adresse aus dem Adressbereich fd00::/8 zu wechseln, siehe hierzu auch Use IPv6 ULA addresses for Pi-hole.
Diese ist bei Dir bereits vorhanden (fd00::dea6:irgendwas) , lässt sich auf dem RPi z.B. über ip address show anzeigen und müsste nur für Pi-hole konfiguriert werden.
vielen Dank für deine kompetente Antwort. Da ich leider das Verzeichnis, an dem das Webinterface liegt geändert hatte, weigerte sich pihole eine Neukonfiguration durchzuführen. Ich habe daraufhin pihole komplett deinstalliert, nun ist auch das Webinterface wieder dort, wo es im Standardfall hin installiert wird.
Für mein beschränktes Verständnis sieht es mit der IPv6 Adresse so besser aus.
Allerdings kann ich die Apps auf dem iPad nun so gut wie gar nicht mehr nutzen, das ganze hat sich nochmals verschlechtert. Surfen funktioniert allerdings problemlos.
Den rpi habe ich neu gestartet, ebenso das iPad. Könnte das trotz Neustart noch ein Caching Problem sein?
Edit: Ich habe nichts weiter geändert, lediglich etwas gewartet und nun funktionieren die Apps problemlos, ganz ohne Verzögerung. Keine Ahnung, was da noch so hing.
Eine Frage noch zur blocking site: ich gehe davon aus, dass die Datei pihole/index.php die blocking site ist, richtig? Wenn ich nun beim reconfigure keine blocking site einstelle, dann wird an den Client vermutlich einfach ein 404 geschickt. Wenn ich eine blocking site möchte, wird 404 einfach auf pihole.index.php umgeleitet. Soweit so klar..
Im Debug schlägt der Zugriff auf die blocking site fehl, da die Basic Auth auf .php greift. Würde ich nun eine blocking site anzeigen wollen, dann würde der Client dann aber vermutlich weiterhin 401 bekommen anstelle der Standardsite für 404, oder? Oder benötige ich plötzlich für pihole/index.php keine credentials mehr, weil es die Standardsite für 404 ist?
Dein Debug Log sieht jetzt sauber aus, IPv6-Netzwerkanbindung ist gegeben:
*** [ DIAGNOSING ]: Name resolution (IPv6) using a random blocked domain and a known ad-serving domain
[✓] selaspa.cl is :: via localhost (::1)
[✓] selaspa.cl is :: via Pi-hole (fd00::dea6:32<entfernt>)
[✓] doubleclick.com is 2a00:1450:4016:807::200e via a remote, public DNS server (2001:4860:4860::8888)
Nicht auszuschliessen, ich bin aber mit iPads nicht vertraut.
Ich vermute eher, dass Dir nach der Neuinstallation die bisherigen Einträge auf der Whitelist fehlen.
Wenn Du die nicht gesichert haben solltest, kann ich Dir zumindest den Auszug aus Deinem ersten Debug Log per PM zur Verfügung stellen.
Ich habe gerade meinen Post oben editiert, während du geschrieben hast. Die Probleme sind plötzlich verschwunden, alles funktioniert so schnell wie es sollte. Vielen Dank für deine Hilfe!
Wenn du Lust hast, kannst du noch auf meine Frage oben eingehen, ansonsten wünsche ich dir ein schönes Restwochenende
Vorweg: Die Block-Seite funktioniert prinzipiell nur für HTTP - HTTPS bleibt also aussen vor (die zunehmende Verbreitung von HTTPS ist wiederum auch ein Grund, warum Pi-hole inzwischen den NULL-Blockingmode als Standard verwendet).
Genaugenommen die blocking page, aber: ja.
Inhaltlich kann ich zu Deinen Fragen leider nichts weiter sagen, da Du nginx statt des von Pi-hole unterstützten lighttpd verwendest.
Du hättest wahrscheinlich eher Erfolg, wenn Du die Fragen dazu in einem nginx-Forum stellst - oder Du suchst hier bei uns nochmal nach entsprechenden Tips.
Wenn Du nach gründlicher Suche bei uns partout nichts finden solltest, kannst Du natürlich diesbezüglich ein neues Topic aufmachen, am besten steht da dann gleich nginx im Titel, damit Du auch die richtigen User anlockst
Mein Problem mit den sehr langsam funktionierenden Apps ist deutlich besser, trott aber sporadisch immer mal wieder auf. Entweder die Apps laden schnell und alles funktioniert problemlos, oder aber jeder Zugriff ins Internet dauert mehrere Sekunden.
Ich konnte kein Muster erkennen, es werden auch keine Zugriffe von Pihole blockiert, selbst das Deaktivieren hilft dann nicht. Erst wenn Pihole nicht mehr als DNS fungiert sind die Probleme gelöst.
Ich nutze als upstream DNS immer Google und habe solche Probleme wirklich ausschliesslich wenn pihole benutzt wird.
Wenn ich eine App starte, dann kann es sein, dass diese absolut problemlos funktioniert. Beende ich diese und starte sie neu, dann ist es sehr gut möglich, dass danach jeder Zugriff hängt. Das Verhalten ändert sich nicht, während die App offen ist. Heisst: gibt es Probleme dann bleiben diese, bis ich die App schliesse. Läuft es problemlos, dann ebenfalls so lange bis die App geschlossen wird.
Ich habe gestern an meiner Fritz mal IPv6 deaktiviert, danach funktionierte alles problemlos. Anschliessend wieder aktiviert und es war wieder hit or miss. Das Problem liegt also irgendwie an IPv6...
