„WLAN geht nicht“ — den Ausfall aus der Pi-hole-Datenbank rekonstruiert

Sonntagabend, 18:10: „WLAN geht nicht." Nach einem Neustart aller Geräte lief alles wieder, und damit hätte die Geschichte enden können. Aber ich wollte wissen, seit wann es nicht ging — und warum.

Die Ausgangslage war ernüchternd. Der Pi mit Pi-hole antwortete, der Router antwortete, der Server nicht. Der Pi hatte kein persistentes Journal — nach dem Reboot war der vorherige Boot einfach weg. Die Docker-Logs der DNS-Container: Cron-Zeilen. Der Monitoring-Benutzer der Firewall bekam für alle Log-Endpunkte einen 403. Und das Control Center, das den Ausfall hätte zeigen sollen, sitzt hinter genau dem Router, der ausgefallen war.

Eine Quelle blieb: die Pi-hole-Langzeitdatenbank. 3,4 Millionen Zeilen in der Tabelle queries, jede mit Zeitstempel, Client, Antworttyp. Daraus ließ sich die Nacht rekonstruieren:

Samstag 19:05 die letzten weitergeleiteten Anfragen mit echter Antwort. 19:10 bis 19:15 die ersten Forwards ohne Antwort, ab 19:12 SERVFAIL. Von da an die ganze Nacht und den ganzen Sonntag praktisch 100 % SERVFAIL bei allen Forwards — um fünf Uhr morgens 84 von 86. Die Clients erreichten den Pi noch (gleiches Layer 2), bekamen aber keine Auflösung. Sonntag 06:13 bis 06:28 verschwanden binnen fünfzehn Minuten alle WLAN-Geräte aus der Datenbank — und der Access Point gleich mit. Ab 06:28 nur noch der Server mit seinen Monitoring-Probes und der Pi selbst. 10:39 die letzte Anfrage des Servers. 13:27 der Pi-hole-Updatechecker: Could not resolve host. 18:09 Reboot des Pi durch mich; die erste DHCP-Transaktion läuft 45 Sekunden in den Timeout — der Router bootete in dem Moment selbst noch. 18:13: neun Clients, Forwards mit Antwort. Alles normal.

Was das ausschließt und was es zeigt. Pi-hole und Unbound waren nicht das Problem — sie antworteten durchgehend, nur der Weg nach draußen fehlte. Ein reines WAN-Problem erklärt nicht, warum die WLAN-Geräte den Pi im selben Subnetz nicht mehr erreichten; dafür braucht es fehlendes DHCP oder einen toten Access Point. Der AP hängt selbst am DHCP und verschwand mit. Zwei unabhängige Fehler sind möglich, aber unwahrscheinlicher als einer: Der Router bediente ab 19:10 weder Routing noch DHCP. Die Ursache selbst stand erst zwei Tage später fest — davon handelt der nächste Eintrag.

Was ich mitnehme: Ein Ausfall, den niemand bemerkt, dauert so lange, bis jemand den Laptop aufklappt. Monitoring im überwachten Netz ist bei Router-Ausfall wertlos. Ein Pi ohne persistentes Journal ist bei der Diagnose ein Gerät ohne Gedächtnis. Und die DNS-Datenbank ist eine unterschätzte Zeitmaschine: Sie sieht jedes Gerät, das etwas wollte — und wann es aufhörte, etwas zu wollen.