Der Ausfall war nie das, was ich debuggt habe

Gegen 01:45 ist das Homelab ausgefallen — nicht nur ein Dienst, sondern alle. Das hier ist das Postmortem, inklusive dem Teil, in dem mein erster Fix nicht funktioniert hat und warum das so war.

Was ich der Reihe nach vermutet habe

Traefik. Alles läuft darüber, also sieht ein Totalausfall so aus, als wäre der Router kaputt. Traefik war aber gesund.

CrowdSec. Ein IPS, das kürzlich aggressivere Regeln bekommen hatte. Ein Massen-Ban würde exakt so aussehen. Es war aber nichts Relevantes gebannt.

Authentik. Forward-auth sitzt vor den meisten internen Services, also sorgt ein SSO-Ausfall auch für komplette Unerreichbarkeit. Auch Authentik war gesund.

Drei plausible Ursachen, jede davon könnte das beobachtete Symptom erzeugen, aber alle drei waren unschuldig. Das ist das klassische Zeichen dafür, dass du auf der falschen Ebene suchst.

Der gescheiterte Workaround

Namensauflösung war offensichtlich beteiligt, also habe ich versucht, DNS auf einen bekannten, funktionierenden Resolver zu pinnen, statt auf die floating virtual IP. Das hat nichts gebracht.

Der Grund ist notierenswert: Ich habe das Redirect ohne Root-Rechte ausgeführt, dadurch blieb das systemd-Stub-Symlink intakt und meine Änderung war stillschweigend ein No-Op. Kein Fehler, keine Warnung. Das System hat einfach weiter den alten Pfad benutzt. Ich habe eine ganze Weile damit verbracht, einen Fix zu verifizieren, der nie angewendet wurde.

Zweiter Versuch, diesmal als Root: Die Namensauflösung wurde auf die echte Adresse des primären DNS-Hosts gepinnt und der keepalived-VIP komplett umgangen. Damit lief wieder alles.

Die eigentliche Ursache

Ein Netzwerkport ist auf Switch-Ebene ausgefallen. Nicht DNS, nicht Traefik, nicht CrowdSec, nicht Authentik. Das DNS-Symptom war am auffälligsten, weil Namensauflösung schnell fehlschlägt und alles andere erst danach.

Später am Tag habe ich bestätigt, dass VIP und primärer DNS-Host die gleiche MAC teilen, was beweist, dass keepalived die Adresse weiterhin korrekt besessen hat — die HA-Schicht hat also ihren Job gemacht. Sie kann aber keinen toten physikalischen Link umgehen, dafür ist sie nicht da.

Der schmerzhafte Nachklapp

Einer der offenen Punkte, die ich mir notiert habe, war: Hat das Monitoring überhaupt darauf alarmiert, und falls nicht, Check ergänzen.

Ich habe ein Dashboard, einen Uptime-Monitor, einen Metrics-Stack, einen Log-Aggregator und einen Push-Notification-Service. Von einem Totalausfall habe ich erfahren, weil ich selbst etwas benutzen wollte. Coverage von Services ist keine Coverage der darunterliegenden Schicht.

Was ich daraus mitnehme

• Das, was du zuerst vermutest, ist meistens downstream von dem, was wirklich kaputt ist. Drei gesunde Verdächtige in Folge sind ein Signal: Aufhören zu untersuchen, stattdessen eine Ebene tiefer gehen.
• Verifiziere, dass dein Fix angewendet wurde, bevor du prüfst, ob er funktioniert hat. Ein stiller No-Op kostet mehr als ein lauter Fehler.
• Das Postmortem enthält den gescheiterten Versuch. Das rauszuschneiden hätte das Dokument aufgeräumter, aber weniger nützlich gemacht.