Das meiste habe ich zu Hause gelernt.

Der Aufbau

Wie die Ebenen zusammenspielen — vom Gerät unterwegs bis zu den Daten.

Was ich privat gebaut habe

Wie ich arbeite

Sechs Grundsätze, die sich in diesem Aufbau wiederfinden.

• Erst beschreiben, dann bauen. Adressplan, Dienste und Zugriffsregeln liegen versioniert in einer Versionsverwaltung (Git). Die Beschreibung ist die Quelle der Wahrheit, nicht mein Gedächtnis — auch in sechs Monaten noch.
• Keine Sicherung ohne Probe. Eine Sicherung, deren Wiederherstellung nie getestet wurde, ist eine Hoffnung. Ich spiele zurück, bevor ich sie als Sicherung bezeichne.
• Zugang nur über Identität. Jeder Dienst steht hinter einer Anmeldung mit zweitem Faktor; mehrere Fehlversuche lösen eine Sperre und eine Meldung an mich aus. Kein Dienst ist „nur schnell“ ohne Schutz erreichbar.
• Änderungen nachvollziehbar. Jede Änderung an der Konfiguration ist eine Version mit Grund. Wenn etwas kaputtgeht, will ich wissen, was ich wann geändert habe — nicht raten.
• Melden statt suchen. Schwellwerte, Ausfälle und fehlgeschlagene Anmeldungen lösen Meldungen aus. Ich erfahre es, bevor jemand anruft.
• Weniger Angriffsfläche. Was ich nicht brauche, ist ausgeschaltet statt nur ungenutzt; Rechte so knapp wie möglich; Zugangsdaten in einem Tresor statt in einer Datei auf dem Schreibtisch.

Technik im Einsatz

Werkzeuge, die ich hier täglich betreibe — nicht aus dem Katalog, sondern im Betrieb.

• Proxmox VE
• LXC-Container
• Docker & Compose
• ZFS
• TrueNAS
• Nginx Proxy Manager
• AdGuard Home
• Authelia mit TOTP
• WireGuard
• Cloudflare Tunnel
• NetAlertX
• Home Assistant
• Shelly
• Python
• Bash
• Git
• Cron

Der Fernzugang ins interne Netz läuft über WireGuard — damit arbeite ich unterwegs auf denselben Systemen wie zu Hause, ohne dafür eine Oberfläche ins offene Netz zu stellen.

Aus der Praxis — vier Fehler, vier Lehren

Die interessanten Geschichten sind nicht die, wo alles lief, sondern die anderen.

• Ein Steuergerät belegte die Adresse eines Servers. Der Dienst war für ein paar Minuten nicht erreichbar. Ursache: Der Bereich für automatische Vergabe enthielt die Adressen der Server — ein Gerät ohne feste Adresse bekam genau die Adresse, die schon vergeben war. Behoben: automatische Vergabe hinter alle festen Plätze verschoben und danach jedes Gerät einzeln geprüft. Dabei kam der zweite Fall heraus: Die zentrale Datenablage holte ihre Adresse selbst, was beim nächsten Wechsel alle Verbindungen gebrochen hätte. Lehre: Ein Adressplan ist nur so gut wie die Prüfung danach.
• Ein Gerät antwortete, war aber nicht erreichbar. Die Verwaltungsoberfläche meldete das Gerät als sauber — die Steuerung erreichte es trotzdem nicht. Ursache: Das Gerät hing auf einer alten Adresse, der Zwischenspeicher der Steuerung trug noch den alten Wert. Behoben: Adresse direkt am Gerät verifiziert (Gegenprobe über die Hardware-Adresse), Zwischenspeicher korrigiert, Steuerung neu gestartet — genau in dieser Reihenfolge, sonst holt der Neustart den alten Stand zurück. Lehre: Wenn Oberfläche und Wirklichkeit auseinandergehen, gilt die Wirklichkeit.
• Der Host blieb unter Last stehen. Bei Schreiblast auf die Platten wurde der Virtualisierungshost träge bis unbedienbar. Ursache: der Übertragungsweg, über den die virtuellen Maschinen auf die Platten zugreifen. Behoben: anderen Übertragungsweg gewählt, zusätzlich eine Überwachung auf stehende Systeme ergänzt. Seither keine Ausfälle dieser Art. Lehre: Symptome dämpfen hilft nicht — ohne Ursache kommt der Fehler wieder.
• Härtetest statt Annahme. Nach dem Umbau des Fernzugangs habe ich jede veröffentlichte Adresse ohne Anmeldung abgerufen: Alle antworteten mit „Zugriff verweigert“, keine einzige Oberfläche war sichtbar. Ebenso geprüft: Nach mehreren Fehlversuchen greift die Sperre und löst eine Meldung an mich aus. Lehre: „Müsste geschützt sein“ ist kein Nachweis — ich probiere es aus, und zwar bevor es jemand anderes tut.

Und beruflich