Verzögerte und fehlschlagende Seitenaufrufe seit Update auf v5.8.1

Help Deutschsprachige Hilfe
1

Hallo Forum,

ich nutze pi-hole v5.8.1 auf einem RPi4 und gehe über einen Asus RT-AC68U mit Asuswrt-Merlin Firmware in's Kabelnetz von Vodafone, soweit sind alle up-to-date. Auf dem Pi läuft außer netdata kein anderer Service. Seit nicht ganz 2 Wochen sind viele, nicht alle, Seitenaufrufe stark verzögert bzw. laden erst nach unterschiedlich langen Wartezeiten; manche laden gar nicht oder erst nach vielen page reloads. Kurz nach dem Erscheinen von v5.8.1 habe pi-hole aktualisiert (5.8.0 übersprungen). Wenn ich mit auf einem beliebigen Rechner über VPN in's Netz gehe, sind die Seitenaufrufe "wie früher", d. h. nicht verzögert – verstehe ich das richtig, dass eine VPN Verbindung pi-hole komplett umgeht? Was ich nicht nachvollziehen/verstehen kann ist, dass wenn ich pi-hole "disable", es selten die beschriebenen Probleme löst.

Auch ich hatte nach dem Update viele Meldungen zur dnsmasq packet truncation, und eine /etc/dnsmasq.d/99-edns.conf mit dem Wert edns-packet-max=1280 angelegt. Was nichts am eigentlichen Problem mit den Seitenladezeiten geändert hat.

Auffällig ist, dass die Transferraten davon unbeeindruckt zu sein scheinen. Downloads sind, wenn sie angelaufen sind, wie gewohnt schnell. Anderes Beispiel, eine Zoom-Konferenz: Die Initialisierung per Website dauert teilweise sehr lange bzw. muss mehrmals wiederholt werden, aber nachdem die Verbindung hergestellt wurde, läuft das über viele Stunden stabil. Im Log kann ich nichts auffälliges entdecken.

Im Forum bin ich über den Standard-Post auf den default Blocking mode gestoßen, der in meiner /etc/pihole/pihole-FTL.conf nicht gesetzt war. Mit dem Eintrag BLOCKINGMODE=NULL und Neustart des DNS Resolver ändert es sich leider nicht.

Das debug.log lässt sich wiederholt nicht vom pi-hole Webinterface aus hochladen:
[i] Debug script running in automated mode
* Using curl for transmission.
* curl failed, contact Pi-hole support for assistance.
* Error message: curl: (6) Could not resolve host: tricorder.pi-hole.net

[✗] There was an error uploading your debug log.

  • Please try again or contact the Pi-hole team for assistance.
  • A local copy of the debug log can be found at: /var/log/pihole_debug.log

Wenn ich tricorder.pi-hole.net im Browser aufrufe und den Zugriff gewähren will, bekomme ich:
403 ForbiddenForbidden: Forbidden
If you should have access, contact your administrator with your request id 3d4f28b4-88fc-4ca0-ae77-a59ff4e6f295 and session details (URL entfernt).

Wie könnte ich euch das Log noch zukommen lassen?

2

Ausgeführt auf Deinem Pi-hole-RPi4, was geben folgende Kommandos zurück?
(Bitte teile die vollständige Ausgabe mit uns)

cat /etc/resolv.conf

dig tricorder.pi-hole.net

echo ">stats >quit" | nc localhost 4711
3 
cat /etc/resolv.conf
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
#     DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
nameserver 127.0.0.1

dig tricorder.pi-hole.net

; <<>> DiG 9.11.5-P4-5.1+deb10u6-Raspbian <<>> tricorder.pi-hole.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 27847
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 4, ADDITIONAL: 9

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: 98676760c8e7d9c64a77f69261e871685cf278c3a05f14f9 (good)
;; QUESTION SECTION:
;tricorder.pi-hole.net.		IN	A

;; ANSWER SECTION:
tricorder.pi-hole.net.	60	IN	CNAME	docker-2-ny1.pi-hole.net.
docker-2-ny1.pi-hole.net. 3600	IN	A	164.90.255.4

;; AUTHORITY SECTION:
pi-hole.net.		95826	IN	NS	ns4.pi-hole.net.
pi-hole.net.		95826	IN	NS	ns1.pi-hole.net.
pi-hole.net.		95826	IN	NS	ns3.pi-hole.net.
pi-hole.net.		95826	IN	NS	ns2.pi-hole.net.

;; ADDITIONAL SECTION:
ns1.pi-hole.net.	1199	IN	A	205.251.193.151
ns2.pi-hole.net.	95826	IN	A	205.251.195.241
ns3.pi-hole.net.	95826	IN	A	205.251.199.220
ns4.pi-hole.net.	95826	IN	A	205.251.196.125
ns1.pi-hole.net.	95826	IN	AAAA	2600:9000:5301:9700::1
ns2.pi-hole.net.	95826	IN	AAAA	2600:9000:5303:f100::1
ns3.pi-hole.net.	95826	IN	AAAA	2600:9000:5307:dc00::1
ns4.pi-hole.net.	95826	IN	AAAA	2600:9000:5304:7d00::1

;; Query time: 447 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Wed Jan 19 21:15:36 CET 2022
;; MSG SIZE  rcvd: 369

echo ">stats >quit" | nc localhost 4711
domains_being_blocked 2679875
dns_queries_today 13645
ads_blocked_today 392
ads_percentage_today 2.872847
unique_domains 3537
queries_forwarded 9731
queries_cached 3469
clients_ever_seen 19
unique_clients 14
dns_queries_all_types 13645
reply_NODATA 1785
reply_NXDOMAIN 214
reply_CNAME 5210
reply_IP 5068
privacy_level 0
status enabled

Danke für deine Hilfe!

Edit: Eben hat es mal mit dem Debug Log geklappt → https://tricorder.pi-hole.net/GYWJGMkL/

4

Lässt sich daraus bereits feststellen, wo der "Knoten liegt", @Bucking_Horn?

5

Die Ausgaben sind soweit unauffällig.

Da Dein Pi-hole-Hostrechner ebenfalls Pi-hole (über 127.0.0.1 (loopback)) für DNS nutzt, könnte "Could not resolve host: tricorder.pi-hole.net" auf einen temporären Ausfall von Pi-holes Upstream-DNS-Servern hingedeutet haben und damit möglicherweise auch andere zeitweise auftretenden Verzögerungen erklären.

Läuft es denn mittlerweile wieder?
Falls es immer noch zu Verzögerungen kommt, stell uns bitte ein neues Debug Token zur Verfügung.

6

Ich habe den Eindruck, dass die deutlich verzögerten bis fehlschlagenden Seitenaufrufe tagsüber und bis ca. 20/21 Uhr ihre Phase haben. Spät abends nur selten. pihole abzuschalten hilft ab und zu, aber nicht immer. Das ist der Punkt, der mich wundert: pihole zu deaktivieren hilft nur manchmal, deswegen fällt es mir schwer nachzuvollziehen, wo's klemmt.

Wenn es wieder zu lauten :face_with_symbols_over_mouth: kommt, stelle ich ein neues Debug Token zur Verfügung. Vielleicht liegt's an Vodafone :disguised_face: …?

Danke für deine Hilfe! :smiley:

7

Danke für deine Hilfe, @Bucking_Horn :clap:

8

Irrtum:
Direkt mit dem Kabelmodem verbunden, sind die Seitenaufrufe immer unverzüglich und der Seitenaufbau deutlich schneller. Da es nicht wirklich Hilft, Pi-hole zu pausieren, werde ich ein altes Backup zurückspielen und hier berichten, ob sich das änders verhält.

Gestern waren z. B. trello.com und Microsoft Teams über Stunden hinweg kaum nutzbar, ich kann aber kein Muster erkennen, welche Seiten mal gut, welche mal schlecht bis gar nicht erreichbar sind. Meine laienhafte Vermutung ist, dass die DNS Auflösung klemmt. Ich schaue mir mit gping in der Shell an, welche Zeiten da kommen, da kam bei M$ und Trello nur noch could not resolve host.

9

Es gab Ende Januar bei Vodafone Störungsmeldungen, und auch 1&1 hatte Anfang Februar DNS-Probleme.

Könnte Dein Anschluss davon betroffen gewesen sein?

10

Sehr wahrscheinlich ja, die Probleme fingen aber zwei Wochen früher an. Wenn ich Pi-hole mit LAN-Kabel direkt am Modem übergehe, läuft das perfekt. Wenn ich Pi-hole nur pausiere, ändert das selten was am geschilderten Problem. Heute Nacht spiele ich das alte Backup ein, und berichte.

11

Ich kann derzeit keine Hinweise dafür erkennen, dass das etwas ändern würde.
Ich kann mich allerdings auch nicht mehr allzu gut an Dein Debug Log erinnern (das mittlerweile abgelaufen ist).

Kannst Du uns bitte ein neues Debug Token zur Verfügung stellen?

12

Aktuell ist wieder vieles nicht erreichbar, auch das pihole_debug.log lässt sich nicht hochladen:

********************************************
********************************************
[✓] ** FINISHED DEBUGGING! **

   * The debug log can be uploaded to tricorder.pi-hole.net for sharing with developers only.
[i] Debug script running in automated mode
    * Using curl for transmission.
    * curl failed, contact Pi-hole support for assistance.
    * Error message: curl: (6) Could not resolve host: tricorder.pi-hole.net

[✗]  There was an error uploading your debug log.
   * Please try again or contact the Pi-hole team for assistance.
   * A local copy of the debug log can be found at: /var/log/pihole_debug.log

Ich bin jetzt per SSH rein und habe es hier angehängt (Suffix .txt nur zum Upload angehängt), danke für deine Hilfe.
(Moderator edit: explicit debug log removed)

13

Dein Debug Log sieht soweit unauffällig aus.

Nur zu IPv6 habe ich eine Anmerkung:
Dein Netzwerk verfügt zwar nicht über öffentlichen IPv6-Zugriff, Clients können aber sehr wohl mit einer link-lokalen IPv6-Adresse arbeiten (aus dem Bereich fe80::/10).
Dein Router könnte in einem solchen Fall seine eigene IPv6-Adresse als DNS-Server verteilen, was IPv6-Clients erlauben würde, Pi-hole zu umgehen.
Du solltest die Konfiguration Deines Routers diesbezüglich überprüfen.

Bei der Gelegenheit solltest Du auch prüfen, ob Du eventuell im Router noch eine ältere, nun ggf. ungültige IPv6-Adresse von Pi-hole hinterlegt hast. Clients oder Client-Software, die IPv6 bevorzugen, würden dann zunächst erfolglos die Auflösung über diese veraltete IPv6 versuchen, bevor sie auf IPv4 zurückfallen, was Deine Beobachtung erklären könnte.

Ich sehe außerdem, dass Du die DNS-Server von digitalcourage.de und censurfridns.dk nutzt. Zumindest der erstere ist nach meinen eigenen Erfahrungen bisweilen temporär überlastet, was ebenfalls sporadische Verzögerungen erklären könnte.

Du könntest das bei Deiner nächsten Beobachtung von Verzögerungen überprüfen, indem Du die Domäne der langsamer aufgebauten Webseite direkt über eine der IPs dieser DNS-Server auflöst, z.B.

nslookup www.slowdomain.com 46.182.19.48

www.slowdomain.com ist natürlich durch die entsprechende Domäne zu ersetzen.

Außerdem können die entsprechenden Auszüge aus Pi-holes Logs hier hilfreich sein:

grep www.slowdomain.com /var/log/pihole.log
15

Aktuell ist IPv6 nicht im Asus RT-AC68U (Asuswrt-Merlin 386.4) aktiviert, (pardon für die Frage) sollte es das sein? Bei der Aktivierung stünde mir zur Verfügung:

Native
Static IPv6
Passthrough
FLET's IPv6 service
Tunnel 6to4
Tunnel 6in4
Tunnel 6rd

EDIT Meine Tests anhand der offiziellen Empfehlung von Asus zu Pi-hole und IPv6, oder einem Zufallsfund hier im Forum, blockieren entweder alle Seitenaufrufe, oder ergeben gar keine IPv6 Konnektivität (das ist der aktuelle Stand).

Der Tipp mit den DNS-Servern hat's gebracht! Seit der Umstellung auf andere Server läuft's wieder viel besser. Vielen Dank dafür, @Bucking_Horn !

16

This topic was automatically closed 21 days after the last reply. New replies are no longer allowed.