This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

Architektur-Entscheidungen und ihre Begründung

Die Runbooks (00–09) zeigen wie jede Instanz aufgebaut wird. Diese Datei erklärt warum — die Kompromisse und Alternativen, die vor jeder Entscheidung abgewogen wurden. Anonymisierte Zusammenfassung des internen Projekt-Kontexts (der im Original nicht Teil dieser Freigabe ist, siehe ACHTUNG-DISCLAIMER.md).

Ausgangslage: kein öffentliches IPv4 zuhause

Der Internet-Anschluss läuft über Dual-Stack-Lite (DS-Lite) — nur natives IPv6 + eine geteilte, nicht erreichbare IPv4-Adresse (CGNAT) ausgehend. Das bestimmt die halbe Architektur: ein rein lokales Setup wäre von außen gar nicht erreichbar. Zwei Konsequenzen:

• Tailscale (Mesh-VPN) für den Normalfall — jedes eigene Gerät mit installiertem Client kommt direkt ins Heimnetz, unabhängig von der eigenen öffentlichen IP
• Ein VPS mit echter öffentlicher IPv4/IPv6 als Fallback für den Fall, dass kein Tailscale-Client verfügbar ist (fremder Rechner, Internetcafé) — bewusst nur als schmale Bridge, keine große Konfiguration dort

Warum Tailscale statt WireGuard standalone

Tailscale nutzt WireGuard als Transportprotokoll, übernimmt aber Schlüsselverwaltung, NAT-Traversal und Gerätediscovery (MagicDNS) automatisch. Ein eigenständiges WireGuard-Setup hätte denselben Zweck erfüllt, aber jeden dieser Punkte manuell verlangt — für ein Ein-Personen/Familien-Setup ohne Compliance-Anforderungen ist der Zusatzaufwand nicht gerechtfertigt. Bewusst kein Exit-Node (der gesamte Internet-Traffic mobiler Geräte würde sonst über die eigene, langsamere Heimleitung laufen) — nur Subnet-Routing ins Heimnetz.

Warum AdGuard Home als aller erster Schritt

DNS-basiertes Werbe-/Tracker-Blocking ersetzt Browser-Adblocker zuverlässiger, seit Browser-Erweiterungs-APIs (Manifest V3) deren Möglichkeiten eingeschränkt haben — und wirkt netzwerkweit für jedes Gerät, auch IoT/Smart-TV ohne Adblocker-Unterstützung. Es kommt bewusst vor allen anderen Diensten, weil jede spätere Instanz ohnehin über diesen DNS-Server auflösen soll (Rewrites für interne Kurznamen).

Filterlisten-Philosophie: kuratiert statt maximal. Ein Abgleich mit einem deutlich umfangreicheren Fremd-Setup (~60 aktive Listen) zeigte massive Redundanz (mehrere überlappende Malware-/Werbelisten) ohne messbaren Zusatznutzen — mehr Listen bedeuten mehr RAM-Bedarf und mehr False-Positive-Risiko, nicht automatisch mehr Sicherheit. Bewusst nicht übernommen: Content-Filter (NSFW/Anti-Piracy/Dating — reine Lifestyle-Entscheidung, nicht Ad-Blocking-Zweck) und VPN/Proxy-Bypass-/DynDNS-Blocklisten (Kollisionsrisiko mit einem im Haushalt genutzten Firmen-VPN-Tunnel eines Familienmitglieds).

Warum ZFS-Mirror statt TrueNAS-VM für den NAS-Speicher

Mit nur zwei verfügbaren Laufwerksschächten scheidet ein Storage-Passthrough-Setup mit mehr Redundanzstufen praktisch aus. Optionen waren: (a) einfacher Samba-LXC ohne Redundanz, (b) TrueNAS Scale als VM mit Storage-Passthrough, (c) ZFS-Mirror auf Host-Ebene + schlanker Samba-LXC per Bind-Mount. Entschieden für (c) — liefert dieselbe Redundanz (RAID 1) wie eine dedizierte NAS-Lösung, ohne den Ressourcen-Overhead einer vollständigen TrueNAS-VM für nur zwei Platten zu rechtfertigen.

NAS-Protokolle grundsätzlich nie öffentlich exponieren — nur über den Tailscale-Subnet-Router erreichbar. SMB/NFS sind nicht für Angriffsverkehr aus dem offenen Internet gebaut; das öffentliche Zugriffsszenario läuft stattdessen über das Gateway (nächster Abschnitt).

Warum ein zusätzliches Gateway statt NAS direkt öffentlich

Für den seltenen Fall eines fremden Geräts ohne Tailscale-Client übernimmt ein HTML5-Gateway auf dem VPS die Vermittlung (RDP/SFTP/VNC-Verbindungen im Browser, mit eigenem Login + Pflicht-2FA). Das hält den öffentlichen Angriffsfläche auf einen gehärteten Übergang beschränkt, statt mehrere Dienste (NAS, Management-Desktop, …) einzeln absichern zu müssen. Public-Key-only-SSH + fail2ban zusätzlich auf dem VPS selbst, da dort der einzige öffentlich erreichbare Admin-Zugang liegt.

Warum ein separater "Management-Desktop"-Container

Ursprünglich nicht geplant — entstand aus einem konkreten Bedarf: ein zweites Haushaltsmitglied brauchte grafischen Zugriff (v.a. auf die Datei-Oberfläche), ohne die bestehende Fernzugriffs-Sitzung auf den Haupt-PC zu kapern (Windows erlaubt dort nur eine aktive Sitzung gleichzeitig). Lösung: ein minimaler LXC mit Desktop-Umgebung + Browser, rein für Web-Oberflächen gedacht ("Mini-Linux, das nur einen Browser können muss") — kein Vollzugriffs-Arbeitsplatz, kein Terminal für Gäste (siehe Gast-Zugang unten, warum das wichtig wurde).

Warum der Passwort-Tresor NIE öffentlich

Höchste Sensitivität aller Dienste — bekommt bewusst als einziger Dienst keinen öffentlichen Zugriffsweg, nur Tailnet-intern über automatisches Zertifikats-Handling (statt eines eigenen Reverse-Proxys — weniger bewegliche Teile für den sensibelsten Dienst). Selbst bei einer hypothetischen Kompromittierung des öffentlichen Gateways bliebe der Tresor unerreichbar.

Warum Monitoring: zweistufige Datenhaltung statt einer großen Datenbank

Die einzige verfügbare Storage für den Monitoring-Container ist eine nicht sehr große NVMe (die Festplatten sind fürs allgemeine Stromsparziel tabu, siehe unten) — unbegrenzt wachsende Rohdaten waren keine Option. Fix: kurze Rohdaten-Aufbewahrung (Tage) für Detail-Debugging, parallel dazu automatisch verdichtete Stundenmittelwerte über Jahre für Langzeit-Trends. Ergebnis: dauerhaft kleine Datenmenge, ohne auf Verlaufsvergleiche über Monate verzichten zu müssen.

Kein Agent pro Container — die Virtualisierungsplattform bringt einen eingebauten Metrik-Export für Host + alle Gastsysteme bereits mit, das spart einen zusätzlichen Prozess pro Instanz. Nur das externe VPS (kein Mitglied der Virtualisierungs-Cluster) bekommt einen schlanken externen Agenten.

Selbstgehostete Push-Benachrichtigungen statt E-Mail — der ursprüngliche Plan (Warnmails bei Backup-Fehlschlägen) scheiterte daran, dass der Mailversand vom Host aus nirgendwo ankam (kein Mail-Relay konfiguriert, nur lokal zustellbar). Ein selbstgehosteter Push-Dienst aufs eigene Handy war der pragmatischere Ersatz, ganz ohne Abhängigkeit von einem externen Mail-Anbieter.

Warum Backups per Pull vom Zuhause statt Push vom externen Server

Der externe Server (VPS) erstellt seine eigenen Backups lokal, aber das Heimnetz zieht sie sich anschließend selbst ab (per stark eingeschränktem Schlüssel, nur Lesezugriff auf genau ein Verzeichnis) — nicht umgekehrt. Vorteil: die eigentliche Datenhoheit bleibt beim eigenen Netzwerk, und ein späterer Wechsel des externen Anbieters oder der Domain bleibt unkritisch (einfach vor der Kündigung den letzten Stand ziehen). Bewusst kein Push-Zugriff vom VPS auf das Heimnetz — ein kompromittierter öffentlicher Server hätte sonst Schreibzugriff auf die eigene Backup-Infrastruktur.

Warum Festplatten-Spindown ein echtes Projekt wurde, nicht nur ein Einzeiler

Der Wunsch war simpel: Festplatten sollen möglichst selten aktiv sein statt dauerhaft zu laufen. Die Umsetzung eines aggressiven Spindown-Timeouts warf aber eine echte Frage auf: sind häufige Start/Stop-Zyklen schädlicher für die Plattenlebensdauer als dauerhafter Betrieb? Eine SMART-Auswertung zeigte, dass eine der beiden Platten bereits einen sehr hohen Load-Cycle-Zählerstand hatte (nahe der vom Hersteller spezifizierten Zyklengrenze), während die zweite, baugleiche Platte einen deutlich niedrigeren Wert zeigte — das machte Monitoring dieser Kennzahl zur Voraussetzung für die Entscheidung, nicht zum Nice-to-have. Details zur Fehlersuche (inkl. eines Bugs, bei dem das eigene Monitoring-Skript die Platten unbeabsichtigt bei jedem Check aufweckte) stehen in 08-monitoring.md.

Warum der Gast-Zugang eine eigene, komplett neue Oberfläche bekam

Naheliegend wäre gewesen, den bestehenden Management-Desktop für Besucher freizugeben. Bewusst verworfen: der hat ein Terminal und sitzt im selben flachen Netzwerk wie alle anderen Geräte — für Familie unkritisch, für Fremde (Bewerbungsgespräch-Kontext!) ein echtes Risiko. Stattdessen eine komplett separate, rein lesende Oberfläche (kuratiertes Dashboard, separate Dateifreigabe mit eigens dafür vorbereiteten Inhalten, öffentliche Status-Seite) — lieber ein zweites, bewusst eingeschränktes System bauen als ein bestehendes privilegiertes System nur "ein bisschen" zu öffnen. Details, inkl. der Sicherheitsdiskussion, die zu diesem Design geführt hat: 09-gast-zugang.md.

Bewusst verworfene Ansätze (nicht aus Unwissenheit, sondern nach Abwägung)

• Eigenständige Firewall-Appliance inline — keine passende Hardware für einen dedizierten Router-Ersatz vorhanden, kein Neukauf gerechtfertigt für den erreichten Sicherheitsgewinn
• Cloud-Dokumentenverwaltung mit öffentlichem Reverse-Proxy — zu viel Betriebsaufwand für reinen Eigenbedarf, das bestehende Mesh-VPN deckt den Zugriffsbedarf bereits ab
• DNS-Anfragen über den Router statt direkt zum Ad-Blocking-Server — ein zusätzlicher Hop ohne Mehrwert, der Router wird komplett aus dem DNS-Pfad herausgehalten