Architektur & Infrastruktur Netzwerkarchitektur Gesamtübersicht Die Infrastruktur „Hainbach 45“ basiert auf einer segmentierten Smart-Home- und Homelab-Architektur mit zentral verwalteter Netzwerk-, Container- und Diensteplattform. Ziele der Architektur: Trennung kritischer Infrastruktur kontrollierte VLAN-Kommunikation zentrale DNS- und Reverse-Proxy-Architektur reproduzierbare Containerplattform mehrstufiges Backup- und Recovery-Konzept zentrale Monitoring- und Alerting-Plattform Reduktion von Single Points of Failure Vorbereitung auf professionelle Betriebs- und Sicherheitsstandards Die Umgebung orientiert sich konzeptionell an etablierten Unternehmensprinzipien sowie ausgewählten Grundideen der NIS-2-Richtlinie. Zentrale Komponenten Netzwerk TP-Link Omada Infrastruktur VLAN-basierte Segmentierung getrennte WLANs für Produktiv-, IoT-, Gast- und Managementnetz zentrale ACL-Steuerung über Gateway-Firewallregeln Infrastrukturdienste AdGuard Home NGINX Proxy Manager Portainer ntfy Uptime Kuma Produktivdienste Nextcloud Vaultwarden Grafana InfluxDB BookStack Smart-Home-Plattform ioBroker Homematic IP / CCU3 Shelly PV- und Energiemanagementsysteme Serverrollen App-Server Zentrale Plattform für: Produktivdienste Containerplattform Monitoring Kollaboration Dokumentation Edge-Server Zentrale Infrastrukturplattform für: DNS Reverse Proxy Infrastrukturzugriffe IoT-Server Dedizierte Smart-Home- und Automatisierungsplattform. Architekturprinzipien Die Umgebung basiert auf folgenden Grundprinzipien: Infrastrukturtrennung zentrale Verwaltung reproduzierbare Container hostbasierte Kernservices Split-DNS Reverse-Proxy-First-Prinzip systemd-first-Prinzip Backup aller persistenten Daten kontrollierte Updates Physische Topologie Die physische Netzwerkstruktur von „Hainbach 45“ basiert auf einem zentralisierten Core-Design mit sternförmiger Verteilung aller relevanten Netzwerksegmente. Architekturprinzip Die Infrastruktur wurde bewusst zentralisiert aufgebaut, um: VLAN-Management zu vereinfachen Access-Point-Verwaltung zu zentralisieren PoE-Versorgung zu bündeln strukturierte Segmentierung umzusetzen Fehleranalysen zu vereinfachen Infrastrukturkomponenten kontrolliert abzusichern Zentrale Netzwerkkomponenten Gerät Modell Funktion Router TP-Link ER605 v2.0 Gateway / Routing / VLAN Main Switch TP-Link SG2210MP v4.20 zentraler PoE-Core-Switch Switch H45 TP-Link SG3428 v2.30 Haupt-LAN Switch IoT TP-Link SG3428 v2.30 IoT-Netz Switch ib-GES TP-Link SG3210 v3.20 zusätzliche Infrastruktur Controller TP-Link OC200 zentrale Netzwerkverwaltung Netzwerkdesign Die Infrastruktur basiert auf folgenden Kernprinzipien: zentraler Routingpunkt VLAN-basierte Segmentierung Trennung von Infrastruktur-, Benutzer- und IoT-Netzen zentrale ACL-Steuerung dedizierte Infrastrukturserver Reverse-Proxy-First-Prinzip Split-DNS-Architektur Physische Struktur Die Netzwerkverteilung erfolgt sternförmig vom zentralen Core-Switch aus. Wichtige Bereiche: Produktivnetzwerk IoT-Netzwerk Managementnetz WLAN-Infrastruktur Serverplattform NAS-/Backup-Infrastruktur Management Die zentrale Verwaltung erfolgt über: Omada Controller (OC200) zentrale Switch-Verwaltung zentrale Access-Point-Verwaltung zentrale WLAN-Konfiguration zentrale VLAN- und ACL-Konfiguration Infrastrukturserver App-Server Zentrale Plattform für: Containerplattform Produktivdienste Monitoring Dokumentation Kollaborationsdienste Edge-Server Dedizierter Infrastrukturserver für: AdGuard Home NGINX Proxy Manager DNS-Infrastruktur Reverse Proxy IoT-Server Dedizierte Smart-Home-Plattform für: ioBroker zukünftige MQTT-Dienste Smart-Home-Integrationen Architekturprinzipien DHCP Strategie Server & Hosts Übersicht Server- & Hostsysteme Die Infrastruktur von Hainbach 45 basiert auf mehreren dedizierten Server- und Hostsystemen mit klar getrennten Aufgabenbereichen. Die Trennung der Systeme dient: der Reduktion von Single Points of Failure der besseren Wartbarkeit der kontrollierten Segmentierung der sauberen Trennung von Infrastruktur- und Produktivdiensten der besseren Skalierbarkeit Architekturprinzipien Die Serverlandschaft basiert auf folgenden Grundprinzipien: dedizierte Rollen pro System Containerisierung über Docker zentrale Verwaltung über Portainer Reverse-Proxy-First-Prinzip zentrale DNS-Infrastruktur hostbasierte Kernservices bei kritischen Funktionen systemd-basierte Betriebsservices kontrollierte Backupstrategie Übersicht der Systeme System Rolle Hauptaufgaben App-Server zentrale Produktivplattform Containerdienste, Monitoring, Dokumentation Edge-Server Infrastrukturplattform DNS, Reverse Proxy, Infrastrukturzugriffe IoT-Server Smart-Home-Plattform ioBroker, Automatisierung NAS-Systeme Storage & Backup Datenspeicherung, Replikation, Sicherung App-Server Der App-Server bildet die zentrale Produktivplattform der Umgebung. Hauptaufgaben Docker-Hosting Portainer Nextcloud Vaultwarden Grafana InfluxDB BookStack zentrale Infrastrukturservices Architektur Der Server basiert auf: Docker Portainer zentralem Reverse Proxy persistenten Volumes zentraler Backupstrategie Besonderheiten Der App-Server stellt einen zentralen Infrastrukturknoten dar. Daher werden: Backups priorisiert Updates kontrolliert durchgeführt Dienste zentral überwacht Edge-Server Der Edge-Server dient als dedizierte Infrastrukturplattform. Hauptaufgaben AdGuard Home NGINX Proxy Manager DNS-Infrastruktur Reverse Proxy Infrastrukturzugriffe externe Zugriffspfade Architekturprinzip Der Edge-Server wurde bewusst von der Produktivplattform getrennt. Dadurch bleiben: DNS Reverse Proxy Infrastrukturzugriffe auch bei Problemen des App-Servers möglichst verfügbar. Besonderheiten Der Server stellt einen kritischen Infrastrukturbaustein dar, da zentrale Netzwerkdienste von ihm abhängen. IoT-Server Der IoT-Server bildet die dedizierte Smart-Home-Plattform. Hauptaufgaben ioBroker Homematic-Integration Smart-Home-Automatisierung zukünftige MQTT-Dienste OT-nahe Integrationen Architekturprinzip Die Smart-Home-Plattform wurde bewusst von Produktiv- und Infrastrukturdiensten getrennt. Vorteile: bessere Stabilität reduzierte Seiteneffekte einfachere Wartung klarere Segmentierung NAS-Infrastruktur Die NAS-Systeme dienen: zentraler Datenspeicherung Backup Replikation Langzeitarchivierung Verwendete Systeme QNAP Synology Architekturprinzipien Die Backupstrategie basiert auf mehreren Ebenen: Primärbackup Replikation externe Sicherung Offline-/Langzeitkonzepte Containerplattform Die zentrale Containerverwaltung erfolgt über: Docker Portainer Containerisierung wird verwendet für: bessere Wartbarkeit Reproduzierbarkeit vereinfachte Updates klare Service-Trennung Infrastrukturprinzipien Die Infrastruktur orientiert sich an folgenden Grundprinzipien: zentrale Verwaltung kontrollierte Segmentierung reproduzierbare Systeme dokumentierte Architektur Backup aller persistenten Daten minimierte Angriffsflächen klare Rollenverteilung App-Server Edge-Server IoT-Server Rollen & Verantwortlichkeiten VLANs & WLAN VLAN Übersicht Die Infrastruktur „Hainbach 45“ basiert auf einer konsequent segmentierten VLAN-Architektur. Ziel der Segmentierung ist: Trennung kritischer Systeme Reduktion lateraler Bewegungen kontrollierte Netzwerkkommunikation Isolation unsicherer IoT-Geräte vereinfachte Firewallsteuerung bessere Fehleranalyse strukturierter Infrastrukturaufbau Architekturprinzip Die Netzwerksegmentierung orientiert sich an folgenden Grundprinzipien: Infrastrukturtrennung Least-Privilege-Kommunikation zentrale ACL-Steuerung kontrollierter Zugriff auf Managementsysteme Trennung von Benutzer-, Infrastruktur- und IoT-Netzen VLAN-Übersicht VLAN Bezeichnung Netzwerk Zweck 1 Management 10.45.1.0/24 Switches, APs, Infrastrukturmanagement 10 H45 LAN 10.45.10.0/24 Produktivnetzwerk 81 IoT LAN 10.45.81.0/24 Smart-Home- und IoT-Geräte 99 Gastnetz getrennt isoliertes Gastnetzwerk VLAN 1 – Management Das Managementnetz dient ausschließlich der Verwaltung der Netzwerkinfrastruktur. Enthaltene Systeme: Omada Controller Switches Access Points Managementschnittstellen Der Zugriff erfolgt ausschließlich kontrolliert über definierte Firewallregeln. VLAN 10 – H45 LAN Das Hauptnetzwerk beinhaltet: Serverplattform NAS-Systeme Arbeitsgeräte Infrastrukturserver zentrale Dienste Dieses Netzwerk bildet das zentrale Produktivsegment der Umgebung. VLAN 81 – IoT LAN Das IoT-Netzwerk enthält: Smart-Home-Geräte IoT-Komponenten nicht vertrauenswürdige Endgeräte Automatisierungskomponenten Die Kommunikation erfolgt kontrolliert über ACL-Regeln. Direkte Zugriffe auf Managementsysteme werden grundsätzlich unterbunden. Gastnetz Das Gastnetz ist vollständig vom Produktivnetz getrennt. Eigenschaften: ausschließlich Internetzugriff keine interne Kommunikation keine Erreichbarkeit von Infrastrukturkomponenten Kommunikationsprinzip Die Kommunikation zwischen VLANs erfolgt ausschließlich kontrolliert über: Gateway-Firewallregeln ACLs definierte Freigaben Reverse-Proxy-Zugriffe Grundsätzlich gilt: deny-by-default explizite Freigaben minimale Berechtigungen Sicherheitsprinzipien Die VLAN-Architektur dient insbesondere: der Reduktion von Angriffsflächen der Segmentierung unsicherer Geräte der Trennung kritischer Dienste der besseren Überwachung der vereinfachten Fehleranalyse Die Umgebung orientiert sich konzeptionell an professionellen Netzwerksegmentierungsprinzipien. WLAN Struktur Die WLAN-Infrastruktur von Hainbach 45 basiert auf einer zentral verwalteten Omada-Architektur mit VLAN-basierter Segmentierung. Ziele: Trennung unterschiedlicher Sicherheitszonen zentrale Verwaltung kontrollierte Netzwerksegmentierung optimierte WLAN-Abdeckung Unterstützung moderner WLAN-Standards sichere Einbindung von IoT-Geräten Verwendete SSIDs SSID VLAN Zweck Frequenz H45 VLAN 10 Haupt-WLAN / Produktivnetz 2.4 / 5 / 6 GHz H45-IoT VLAN 81 Smart-Home- und IoT-Geräte 2.4 GHz H45-Gast VLAN 50 Gastzugriff 2.4 GHz H45-Mgmt VLAN 1 Infrastrukturverwaltung 5 GHz Architekturprinzipien Die WLAN-Architektur basiert auf folgenden Grundprinzipien: getrennte SSIDs pro Sicherheitszone VLAN-basierte Netztrennung zentrales WLAN-Management isoliertes Gastnetz getrennte IoT-Kommunikation dediziertes Management-WLAN kontrollierte Ost-West-Kommunikation Haupt-WLAN „H45“ Das Haupt-WLAN dient dem Zugriff auf: Server NAS-Systeme Arbeitsplatzgeräte Administratorgeräte Infrastrukturservices Eigenschaften: VLAN 10 primäres Produktivnetz Zugriff auf interne Dienste moderne WLAN-Standards Multi-Band-Betrieb IoT-WLAN „H45-IoT“ Das IoT-WLAN dient ausschließlich Smart-Home- und IoT-Geräten. Enthaltene Geräte: Shelly PV-Systeme Sensorik Verbrauchersteuerungen Smart-Home-Komponenten Eigenschaften: VLAN 81 ausschließlich 2.4 GHz getrennt vom Hauptnetz eingeschränkte Kommunikationspfade Die Segmentierung reduziert potenzielle Sicherheitsrisiken unsicherer IoT-Geräte. Gast-WLAN „H45-Gast“ Das Gastnetz dient Besuchern ausschließlich für Internetzugriffe. Eigenschaften: vollständige Isolation vom internen Netzwerk kein Zugriff auf Infrastruktur oder Server separates VLAN getrennte SSID Management-WLAN „H45-Mgmt“ Das Management-WLAN dient ausschließlich administrativen Zugriffen. Zwecke: Infrastrukturverwaltung Omada-Management Wartung Fehlersuche Eigenschaften: VLAN 1 ausschließlich für Administratorgeräte eingeschränkte Nutzung erhöhte Sicherheitsanforderungen Access-Point-Infrastruktur Die WLAN-Abdeckung erfolgt zentral über mehrere TP-Link Omada Access Points. Standorte: Access Point Standort AP-EG Garage Garage AP-EG Küche Erdgeschoss AP-KG Flur Keller AP-KG Werkstatt Werkstatt AP-OG Flur Obergeschoss Die Verwaltung erfolgt zentral über den Omada Controller. Sicherheitsprinzipien Die WLAN-Infrastruktur orientiert sich an folgenden Sicherheitsprinzipien: VLAN-Segmentierung getrennte Sicherheitszonen zentrale ACL-Steuerung minimierte Kommunikationspfade dedizierte Verwaltungszugänge Isolation unsicherer Geräte Besonderheiten Das Haupt-WLAN nutzt moderne WLAN-Standards inklusive Multi-Link Operation (MLO). Zusätzlich wurde bewusst eine getrennte IoT-Infrastruktur umgesetzt, um: Broadcast-Domänen zu reduzieren Risiken durch IoT-Geräte zu minimieren Fehlersuche zu vereinfachen Stabilität des Produktivnetzes zu erhöhen IoT Segmentierung Gastnetz Firewall DNS Übersicht Die DNS-Infrastruktur bildet eine zentrale Grundlage der gesamten H45-Umgebung. Nahezu alle Dienste hängen direkt oder indirekt von funktionierender Namensauflösung ab. Die Architektur basiert auf: AdGuard Home DNS-Rewrites Split-DNS zentralem Reverse Proxy internen Hostnamen vereinheitlichten HTTPS-Zugriffen Zielsetzung Ziele der DNS-Architektur: zentrale Namensauflösung interne Hostnamen statt IP-Adressen konsistente interne/externe URLs Vorbereitung auf Reverse-Proxy-Architektur vereinfachte Zertifikatsverwaltung minimierte Direktzugriffe auf Systeme bessere Wartbarkeit einfachere Migration von Diensten Architekturprinzipien Die DNS-Infrastruktur basiert auf folgenden Grundprinzipien: zentrale DNS-Verwaltung Reverse-Proxy-first-Prinzip Split-DNS kontrollierte interne Hostnamen minimierte Direktzugriffe konsistente Dienstnamen zentrale Zugriffskontrolle Zentrale Komponenten Komponente Funktion AdGuard Home DNS-Server / lokale DNS-Auflösung DNS-Rewrites interne Zielumleitungen Split-DNS interne/externe URL-Vereinheitlichung NGINX Proxy Manager zentrale HTTPS-Terminierung Grundprinzip Benutzer greifen grundsätzlich nicht direkt auf: Containerports interne Zielsysteme lokale IP-Adressen zu. Stattdessen erfolgt der Zugriff über: DNS-Namen HTTPS Reverse Proxy Typische Hostnamen Hostname Funktion portainer.home Containerverwaltung grafana.home Monitoring proxy.home Reverse Proxy adguard.home DNS-Verwaltung iobroker.home Smart-Home qnap.home NAS synology.home Synology Split-DNS Die Umgebung verwendet Split-DNS. Dadurch funktionieren identische URLs: intern extern über VPN ohne unterschiedliche Hostnamen verwenden zu müssen. Sicherheitsprinzipien Die DNS-Infrastruktur dient insbesondere: der zentralen Zugriffskontrolle der Reduktion direkter Systemzugriffe der Vereinheitlichung von HTTPS-Zugriffen der einfacheren Verwaltung der Vorbereitung auf professionelle Infrastrukturstandards Kritikalität Die DNS-Infrastruktur stellt einen kritischen Infrastrukturbaustein dar. Ein Ausfall führt typischerweise zu: Problemen bei interner Namensauflösung eingeschränkten Servicezugriffen Problemen beim Reverse Proxy Störungen interner Plattformdienste Zugehörige Seiten AdGuard Home Split-DNS DNS-Rewrites Namenskonventionen AdGuard Home AdGuard Home dient als zentraler DNS-Server der H45-Infrastruktur. Der Dienst übernimmt: DNS-Auflösung lokale Hostnamen DNS-Rewrites Split-DNS Werbe- und Trackingfilterung zentrale DNS-Verwaltung Architekturrolle AdGuard Home bildet einen kritischen Infrastrukturbaustein. Nahezu alle internen Dienste hängen direkt oder indirekt von funktionierender DNS-Auflösung ab. Der Dienst läuft auf dem: System Funktion Edge-Server DNS-Infrastruktur Hauptaufgaben Lokale DNS-Auflösung Interne Dienste werden über Hostnamen statt IP-Adressen erreicht. Beispiele: Hostname Ziel portainer.home Portainer grafana.home Grafana iobroker.home ioBroker proxy.home NGINX Proxy Manager adguard.home AdGuard Home DNS-Rewrites AdGuard verwendet DNS-Rewrites zur internen Auflösung von Diensten. Dadurch können: interne Dienste Reverse-Proxy-Ziele öffentliche Domains intern umgeleitet werden Split-DNS Die Infrastruktur verwendet Split-DNS. Dadurch funktionieren identische URLs: intern extern via VPN Intern werden die Domains direkt auf interne Systeme aufgelöst. Upstream-DNS AdGuard Home verwendet externe DNS-Resolver für nicht lokale Anfragen. Beispiele: Quad9 Cloudflare Google DNS Die Auswahl kann je nach Datenschutz- und Verfügbarkeitsanforderungen angepasst werden. DHCP-Integration Die Clients erhalten den DNS-Server automatisch über DHCP. Die Verteilung erfolgt zentral über: Omada Controller VLAN-spezifische DHCP-Konfiguration Sicherheitsprinzipien Die DNS-Infrastruktur folgt folgenden Grundprinzipien: zentrale Namensauflösung minimierte Direktzugriffe kontrollierte interne Hostnamen Trennung interner/externer Infrastruktur vereinfachte Zertifikatsverwaltung Besonderheiten Die Umgebung verwendet bewusst: interne Hostnamen Reverse-Proxy-first-Prinzip zentrale DNS-Rewrites Split-DNS Dadurch bleiben: URLs konsistent Dienste leichter migrierbar Zertifikate einfacher verwaltbar Kritikalität AdGuard Home stellt einen kritischen Infrastrukturservice dar. Ein Ausfall führt typischerweise zu: Problemen bei interner Namensauflösung eingeschränkter Erreichbarkeit interner Dienste Problemen bei Reverse-Proxy-Zugriffen Ausfällen interner Service-URLs Split-DNS Die Infrastruktur von Hainbach 45 verwendet Split-DNS zur Vereinheitlichung interner und externer Dienstzugriffe. Dadurch funktionieren dieselben URLs: intern im LAN extern über das Internet über VPN Zielsetzung Ziele der Split-DNS-Architektur: identische interne/externe URLs Vermeidung von Hairpin NAT vereinfachte Zertifikatsverwaltung konsistente Benutzererfahrung zentrale Reverse-Proxy-Architektur einfachere Migration von Diensten Grundprinzip Die DNS-Antwort hängt vom Standort des Clients ab. Intern Interne Clients erhalten: wiki.schwarzi.at → 10.45.10.8 DNS-Rewrites Zweck AdGuard Home dient als zentraler interner DNS-Resolver innerhalb der Infrastruktur Hainbach 45. Mittels DNS-Rewrites werden interne Hostnamen zentral auf den Reverse Proxy ( 10.45.10.8 ) geleitet. Dadurch entstehen folgende Vorteile: einheitliche interne URLs einfache Serviceerreichbarkeit zentrale HTTPS-Terminierung Vorbereitung für Split-DNS keine direkten Containerports notwendig bessere Wartbarkeit Grundprinzip Die interne DNS-Auflösung erfolgt bewusst nicht direkt auf Zielserver oder Container. Stattdessen erfolgt die Kommunikation über: Client → AdGuard DNS → Reverse Proxy (NGINX Proxy Manager) → Zielservice Dadurch bleiben: Containerports verborgen HTTPS zentral verwaltbar Zertifikate konsistent Dienste einfacher migrierbar Aktuelle DNS-Rewrites Infrastruktur & Verwaltung Hostname Ziel portainer.home 10.45.10.8 grafana.home 10.45.10.8 adguard.home 10.45.10.8 proxy.home 10.45.10.8 influx.home 10.45.10.8 uptime.home 10.45.10.8 wiki.home 10.45.10.8 Smart Home & OT Hostname Ziel iobroker.home 10.45.10.8 ccu3.home 10.45.10.8 hmi.home 10.45.10.8 Storage & Plattformdienste Hostname Ziel nextcloud.home 10.45.10.8 synology.home 10.45.10.8 qnap.home 10.45.10.8 Netzwerk & Remotezugriff Hostname Ziel wireguard.home 10.45.10.8 Architekturentscheidung Es werden bewusst keine direkten Containerports produktiv verwendet. Stattdessen erfolgt der Zugriff standardisiert über: DNS-Rewrite → Reverse Proxy → Zielcontainer Dies verbessert: Sicherheit Wartbarkeit Migrationsfähigkeit Zertifikatsverwaltung Benutzerfreundlichkeit Besonderheiten Alle Hostnamen zeigen bewusst auf denselben zentralen Infrastrukturknoten: 10.45.10.8 Dort erfolgt die eigentliche Dienstweiterleitung über: NGINX Proxy Manager virtuelle Hosts HTTPS-Terminierung interne Routingregeln Namenskonventionen Zweck Die Infrastruktur von Hainbach 45 verwendet standardisierte Namenskonventionen zur besseren Übersichtlichkeit, Wartbarkeit und Skalierbarkeit. Ziele: konsistente Hostnamen einfachere Administration bessere Lesbarkeit vereinfachtes Troubleshooting klare Infrastrukturtrennung nachvollziehbare Servicezuordnung Grundprinzipien Die Namensgebung erfolgt nach folgenden Regeln: kurze und eindeutige Namen sprechende Hostnamen konsistente Schreibweise Kleinbuchstaben keine Sonderzeichen keine Leerzeichen thematische Gruppierung Interne Domains Die interne Infrastruktur verwendet aktuell primär: .home Beispiele: portainer.home grafana.home iobroker.home wiki.home Öffentliche Domains Extern erreichbare Dienste verwenden: schwarzi.at Beispiele: wiki.schwarzi.at vault.schwarzi.at nxt.schwarzi.at Infrastruktur-Hostnamen Infrastruktur & Verwaltung Hostname Funktion proxy.home Reverse Proxy adguard.home DNS-Server portainer.home Containerverwaltung grafana.home Monitoring influx.home Zeitreihendatenbank uptime.home Monitoring Smart Home & OT Hostname Funktion iobroker.home Smart-Home-Plattform ccu3.home Homematic-Zentrale hmi.home Bedienoberflächen Storage & Plattformdienste Hostname Funktion nextcloud.home Fileservice synology.home Synology NAS qnap.home QNAP NAS wiki.home Infrastruktur-Wiki Netzwerk & Remotezugriff Hostname Funktion wireguard.home VPN-Zugriff Servernamen Die physischen bzw. virtuellen Systeme verwenden sprechende Rollennamen. Servername Funktion App-Server zentrale Produktivplattform Edge-Server Infrastrukturplattform IoT-Server Smart-Home-Plattform Architekturprinzip Die Namensgebung orientiert sich bewusst an: Rollen Funktionen Dienstarten Infrastruktursegmenten Dadurch bleiben: Systeme leichter identifizierbar Dienste einfacher migrierbar Dokumentationen konsistent DNS-Strukturen übersichtlich Besonderheiten Die Infrastruktur verwendet bewusst: interne Kurzdomains Reverse-Proxy-first-Prinzip DNS-Rewrites Split-DNS Dadurch funktionieren interne und externe Zugriffe möglichst konsistent. Zukünftige Erweiterungen Neue Dienste sollen: in bestehende Namensschemata passen konsistent benannt werden möglichst sprechende Namen verwenden direkt über Reverse Proxy erreichbar sein Reverse Proxy Übersicht Die Reverse-Proxy-Infrastruktur bildet die zentrale Zugriffsschicht der H45-Umgebung. Nahezu alle webbasierten Dienste werden nicht direkt, sondern über den zentralen Reverse Proxy veröffentlicht. Die Architektur basiert auf: NGINX Proxy Manager zentraler HTTPS-Terminierung DNS-Rewrites Split-DNS internen und externen Domains zentralem Routing Zielsetzung Ziele der Reverse-Proxy-Architektur: zentrale HTTPS-Verwaltung keine direkten Containerports konsistente URLs vereinfachte Zertifikatsverwaltung bessere Wartbarkeit vereinfachte Migration von Diensten zentrale Zugriffskontrolle Architekturprinzip Zugriffe erfolgen grundsätzlich nicht direkt auf: Containerports interne Serviceports Zielsysteme Stattdessen: Client → DNS → Reverse Proxy → Zielservice Der Reverse Proxy übernimmt anschließend: HTTPS-Terminierung Hostname-Routing Weiterleitung Zertifikatsverwaltung Zentrale Komponente Komponente Funktion NGINX Proxy Manager zentraler Reverse Proxy Infrastrukturrolle Der Reverse Proxy dient als zentrale Einstiegsschicht für: interne Dienste externe Dienste VPN-Zugriffe HTTPS Split-DNS Vorteile Zentrale HTTPS-Verwaltung Zertifikate werden zentral verwaltet. Dadurch entfällt HTTPS-Konfiguration auf einzelnen Diensten. Konsistente URLs Interne und externe Zugriffe verwenden möglichst identische Hostnamen. Beispiele: wiki.schwarzi.at vault.schwarzi.at nxt.schwarzi.at Keine direkten Containerports Containerports werden möglichst nicht produktiv veröffentlicht. Der Zugriff erfolgt standardisiert über: DNS → Reverse Proxy → Zielcontainer Abhängigkeiten Die Reverse-Proxy-Infrastruktur hängt direkt ab von: DNS AdGuard Home Split-DNS funktionierenden Zielcontainern interner Netzwerkkonnektivität Sicherheitsprinzipien Die Architektur folgt folgenden Grundprinzipien: zentrale Zugriffskontrolle minimierte Direktzugriffe zentrale HTTPS-Terminierung konsistente Hostnamen kontrollierte Veröffentlichung von Diensten Zugehörige Seiten NGINX Proxy Manager Proxy Hosts HTTPS / Zertifikate Externe Domains Interne Domains Nginx Proxy Manager Zweck NGINX Proxy Manager (NPM) dient als zentraler Reverse Proxy der H45-Infrastruktur. Der Dienst übernimmt: HTTPS-Terminierung Hostname-basiertes Routing Reverse Proxy interne/externe Dienstveröffentlichung Zertifikatsverwaltung Zugriffskontrolle Infrastrukturrolle Der Reverse Proxy bildet die zentrale Zugriffsschicht für nahezu alle webbasierten Dienste. Zugriffe erfolgen grundsätzlich nicht direkt auf: Containerports interne Zielsysteme lokale Serviceports Stattdessen: Client → DNS → NGINX Proxy Manager → Zielservice Architekturprinzipien Die Reverse-Proxy-Architektur folgt folgenden Grundprinzipien: zentrale HTTPS-Verwaltung keine direkten Containerports zentrale Zugriffskontrolle konsistente Hostnamen vereinfachte Migration von Diensten Split-DNS-Kompatibilität Infrastrukturstandort System Funktion Edge-Server Reverse Proxy / HTTPS-Gateway Proxy-Host-Struktur Die Umgebung unterscheidet grundsätzlich zwischen: Internen Diensten Nur intern erreichbar: portainer.home grafana.home proxy.home adguard.home uptime.home wireguard.home Öffentlichen Diensten Extern erreichbar über HTTPS: wiki.schwarzi.at vault.schwarzi.at nxt.schwarzi.at ntfy.schwarzi.at qnap.schwarzi.at syn.schwarzi.at Interne Proxy Hosts Infrastruktur & Verwaltung Domain Ziel adguard.home http://10.45.10.8:3001 grafana.home http://10.45.10.10:3000 influx.home http://10.45.10.10:8086 portainer.home https://10.45.10.10:9443 proxy.home http://10.45.10.8:81 uptime.home http://10.45.10.10:3003 wiki.home http://10.45.10.10:3006 Smart Home & OT Domain Ziel iobroker.home http://10.45.10.15:8081 hmi.home http://10.45.10.15:8082 ccu3.home http://10.45.81.15:80 Netzwerk & Remotezugriff Domain Ziel wireguard.home http://10.45.10.8:51821 Öffentliche Proxy Hosts Domain Ziel wiki.schwarzi.at http://10.45.10.10:3006 vault.schwarzi.at http://10.45.10.10:8090 nxt.schwarzi.at http://10.45.10.10:8080 ntfy.schwarzi.at http://10.45.10.10:2586 qnap.schwarzi.at https://10.45.10.52:443 syn.schwarzi.at https://10.45.10.51:5845 geo.schwarzi.at http://10.45.10.15:7999 SSL-Strategie Die Infrastruktur verwendet: interne HTTP-Hosts öffentliche HTTPS-Hosts zentrale Zertifikatsverwaltung Öffentliche Dienste verwenden Let's Encrypt-Zertifikate direkt über NGINX Proxy Manager. Zugriffslisten Die Umgebung verwendet Zugriffskontrolllisten zur Trennung von: internen Diensten öffentlichen Diensten geschützten Diensten Aktuell vorhanden: Zugriffsliste Zweck Intern ausschließlich interne Zugriffe Public + Credentials öffentliche Dienste mit Authentifizierung Sicherheitsprinzipien Die Reverse-Proxy-Architektur dient insbesondere: der zentralen Zugriffskontrolle der Reduktion direkter Systemzugriffe der zentralen HTTPS-Terminierung der konsistenten Dienstveröffentlichung der Vorbereitung auf professionelle Infrastrukturstandards Besonderheiten Die Umgebung verwendet bewusst: Split-DNS Reverse-Proxy-first-Prinzip DNS-Rewrites zentrale HTTPS-Terminierung konsistente interne/externe Domains Dadurch bleiben: URLs konsistent Dienste leichter migrierbar Zertifikate zentral verwaltbar Zugriffe besser kontrollierbar Dokumentation Proxy Hosts Hier Screenshots der Proxy-Host-Konfiguration einfügen Zugriffslisten Hier Screenshot der Zugriffsliste einfügen HTTPS / Zertifikate Zweck Die Infrastruktur von Hainbach 45 verwendet HTTPS zur verschlüsselten Kommunikation zwischen Clients und Diensten. Die HTTPS-Verwaltung erfolgt zentral über: NGINX Proxy Manager Dadurch müssen Zertifikate nicht auf einzelnen Diensten verwaltet werden. Architekturprinzip HTTPS wird bewusst zentral terminiert. Die Kommunikation erfolgt grundsätzlich: Client → HTTPS → Reverse Proxy → Zielservice Die eigentlichen Zielservices laufen intern überwiegend weiterhin über HTTP. Vorteile der zentralen HTTPS-Terminierung Vereinfachte Zertifikatsverwaltung Zertifikate werden ausschließlich zentral verwaltet. Dadurch entfällt: Zertifikatsmanagement auf Einzelcontainern manuelle Zertifikatsverteilung komplexe Einzelkonfiguration Konsistente URLs Alle Dienste verwenden standardisierte Domains. Beispiele: wiki.schwarzi.at vault.schwarzi.at nxt.schwarzi.at Vereinfachte Migrationen Da Zertifikate zentral verwaltet werden: können Dienste leichter verschoben werden bleiben URLs unverändert müssen Clients nicht angepasst werden Öffentliche HTTPS-Dienste Folgende Dienste verwenden aktuell öffentliche HTTPS-Zertifikate: Domain Dienst wiki.schwarzi.at Wiki / Dokumentation vault.schwarzi.at Vaultwarden nxt.schwarzi.at Nextcloud ntfy.schwarzi.at Benachrichtigungssystem qnap.schwarzi.at QNAP NAS syn.schwarzi.at Synology NAS geo.schwarzi.at Geo-/Map-Dienst Zertifikatsquelle Die öffentlichen Zertifikate werden automatisch über: Let's Encrypt bezogen und verwaltet. Die Verwaltung erfolgt direkt im: NGINX Proxy Manager Interne Dienste Interne Dienste verwenden aktuell überwiegend: HTTP interne DNS-Rewrites interne VLAN-Kommunikation Beispiele: Dienst Zugriff portainer.home HTTP intern grafana.home HTTP intern proxy.home HTTP intern adguard.home HTTP intern Split-DNS Die Infrastruktur verwendet Split-DNS. Dadurch funktionieren identische Domains: intern extern über VPN ohne unterschiedliche URLs verwenden zu müssen. Sicherheitsprinzipien Die HTTPS-Architektur dient insbesondere: verschlüsselter Kommunikation zentraler Zugriffskontrolle konsistenter Zertifikatsverwaltung Reduktion direkter Servicezugriffe vereinfachter Wartung Architekturentscheidung Die Umgebung verwendet bewusst: Reverse-Proxy-first-Prinzip zentrale HTTPS-Terminierung Split-DNS DNS-Rewrites minimierte Direktzugriffe Dadurch bleibt die Infrastruktur: konsistent wartbar skalierbar migrationsfähig Besonderheiten Die Zielsysteme selbst benötigen meist keine öffentlichen Zertifikate mehr. Die eigentliche HTTPS-Kommunikation endet bereits am Reverse Proxy. Dadurch wird die interne Infrastruktur erheblich vereinfacht. Dokumentation Öffentliche Proxy Hosts Hier Screenshot der öffentlichen HTTPS-Proxy-Hosts einfügen Let's Encrypt / SSL-Konfiguration Optional Screenshot der SSL-Konfiguration einfügen Docker Übersicht Die Infrastruktur von Hainbach 45 basiert zentral auf Docker-Containern. Nahezu alle Plattformdienste laufen containerisiert. Die Containerisierung dient insbesondere: standardisierten Deployments einfacheren Migrationen besserer Wartbarkeit isolierten Diensten vereinfachten Updates reproduzierbaren Konfigurationen Architekturprinzip Die Umgebung verwendet bewusst: Docker Docker Compose Portainer zentrale Reverse-Proxy-Struktur persistente Volumes serviceorientierte Trennung Zentrale Verwaltungsplattform Die Verwaltung erfolgt primär über: Portainer Portainer dient zur: Stack-Verwaltung Containerverwaltung Log-Analyse Neustarts Updateverwaltung Compose-Deployment Infrastrukturprinzipien Die Containerarchitektur folgt folgenden Grundprinzipien: ein Dienst pro Container Trennung von Daten und Anwendung persistente Volumes zentrale Proxy-Integration DNS-/Reverse-Proxy-first-Prinzip möglichst keine direkten Containerports Hauptplattformen System Funktion App-Server zentrale Produktivplattform Edge-Server Infrastrukturplattform IoT-Server Smart-Home-Plattform Wichtige Containerdienste Infrastruktur Dienst Funktion NGINX Proxy Manager Reverse Proxy AdGuard Home DNS Portainer Containerverwaltung Uptime Kuma Monitoring ntfy Benachrichtigungen Plattformdienste Dienst Funktion Nextcloud Fileservice Vaultwarden Passwortverwaltung BookStack Dokumentation Monitoring Dienst Funktion Grafana Dashboards InfluxDB Zeitreihendatenbank Smart Home & OT Dienst Funktion ioBroker Smart-Home-Plattform WireGuard VPN Datenhaltung Containerdaten werden persistent gespeichert. Typische Speicherorte: /srv/docker/ Beispiele: /srv/docker/nginx-proxy-manager /srv/docker/adguard /srv/docker/bookstack Reverse-Proxy-Integration Nahezu alle Containerdienste werden veröffentlicht über: DNS → Reverse Proxy → Zielcontainer Direkte Containerports werden möglichst vermieden. Sicherheitsprinzipien Die Containerarchitektur dient insbesondere: Diensttrennung einfacheren Backups kontrollierten Veröffentlichungen vereinfachten Migrationen reproduzierbaren Deployments Backup-Strategie Containerdaten werden zentral gesichert mittels: Restic Die Sicherung erfolgt auf: QNAP NAS Replikation auf Synology zusätzliche externe Sicherung vorgesehen Besonderheiten Die Umgebung verwendet bewusst: Docker Compose Stack-basierte Deployments zentrale Proxy-Architektur zentrale DNS-Struktur serviceorientierte Trennung Dadurch bleibt die Infrastruktur: modular wartbar migrationsfähig skalierbar Zugehörige Seiten Portainer Docker-Stacks Persistente Volumes Container-Backup Update-Strategie Netzwerkstruktur Portainer Portainer Zweck Portainer dient als zentrale Verwaltungsoberfläche für die Docker-Infrastruktur von Hainbach 45. Die Plattform ermöglicht die grafische Verwaltung von: Containern Docker-Stacks Volumes Netzwerken Logs Images Updates Infrastrukturrolle Portainer bildet die zentrale Administrationsplattform für nahezu alle containerisierten Dienste. Die Plattform wird verwendet für: Stack-Deployments Neustarts Fehleranalyse Containerverwaltung Updateverwaltung Log-Analyse Architekturprinzip Die Umgebung verwendet bewusst: Docker Compose Stack-basierte Deployments zentrale Containerverwaltung persistente Datenhaltung Reverse-Proxy-Integration Infrastrukturstandort System Funktion App-Server zentrale Containerplattform Zugriff Der Zugriff erfolgt intern über: portainer.home Die Veröffentlichung erfolgt über: DNS → Reverse Proxy → Portainer Zielsystem Dienst Ziel Portainer https://10.45.10.10:9443 Hauptfunktionen Stack-Verwaltung Container werden überwiegend als Docker-Stacks betrieben. Dadurch bleiben: Konfigurationen reproduzierbar Deployments standardisiert Dienste leichter migrierbar Containerverwaltung Portainer ermöglicht: Starten Stoppen Neustarten Entfernen Überwachen von Containern. Log-Analyse Logs können zentral eingesehen werden. Dies erleichtert: Fehleranalyse Troubleshooting Serviceüberwachung Netzwerkverwaltung Docker-Netzwerke können zentral verwaltet werden. Dies betrifft insbesondere: interne Servicekommunikation Proxy-Netzwerke Containerisolation Wichtige Stacks Infrastruktur Stack Funktion nginx-proxy-manager Reverse Proxy adguard DNS uptime-kuma Monitoring ntfy Benachrichtigungen wireguard VPN Plattformdienste Stack Funktion nextcloud Fileservice vaultwarden Passwortverwaltung bookstack Dokumentation Monitoring Stack Funktion grafana Dashboards influxdb Zeitreihendatenbank Sicherheitsprinzipien Die Plattform dient insbesondere: zentraler Verwaltung kontrollierten Deployments reproduzierbaren Konfigurationen vereinfachten Wartungsarbeiten besserer Übersichtlichkeit Backup-Strategie Die Docker-Daten werden persistent gespeichert und mittels Restic gesichert. Typische Speicherorte: /srv/docker/ Besonderheiten Die Umgebung verwendet bewusst: Stack-basierte Deployments zentrale Containerverwaltung Reverse-Proxy-first-Prinzip DNS-Rewrites persistente Volumes Dadurch bleibt die Infrastruktur: modular wartbar migrationsfähig skalierbar Dokumentation Portainer Dashboard Optional Screenshot des Portainer-Dashboards einfügen Stack-Übersicht Optional Screenshot der Stack-Liste einfügen Docker-Stacks Docker-Stacks Zweck Die Infrastruktur von Hainbach 45 verwendet überwiegend Docker-Stacks auf Basis von Docker Compose. Stacks dienen zur: standardisierten Bereitstellung Gruppierung zusammengehöriger Dienste reproduzierbaren Konfiguration vereinfachten Migration zentralen Verwaltung Architekturprinzip Jeder Dienst bzw. Dienstverbund wird als eigener Stack betrieben. Beispiele: Reverse Proxy DNS Monitoring Nextcloud Vaultwarden BookStack Dadurch bleiben: Dienste isoliert Deployments übersichtlich Konfigurationen nachvollziehbar Wartungsarbeiten einfacher Verwaltung Die Stack-Verwaltung erfolgt zentral über: Portainer Deployments erfolgen typischerweise über: Docker Compose Stack-Dateien Portainer Webinterface Hauptstacks Infrastruktur Stack Funktion nginx-proxy-manager Reverse Proxy adguard DNS uptime-kuma Monitoring ntfy Benachrichtigungen wireguard VPN Plattformdienste Stack Funktion nextcloud Fileservice vaultwarden Passwortverwaltung bookstack Dokumentation Monitoring Stack Funktion grafana Dashboards influxdb Zeitreihendatenbank Smart Home & OT Stack Funktion iobroker Smart-Home-Plattform Aufbau eines Stacks Ein typischer Stack besteht aus: Compose-Datei Containerdefinitionen Volumes Netzwerken Umgebungsvariablen Reverse-Proxy-Anbindung Persistente Datenhaltung Containerdaten werden persistent gespeichert. Typische Speicherorte: /srv/docker/ Beispiele: /srv/docker/nginx-proxy-manager /srv/docker/adguard /srv/docker/bookstack Netzwerkprinzip Container werden bewusst nicht direkt veröffentlicht. Der Zugriff erfolgt standardisiert über: DNS → Reverse Proxy → Zielcontainer Direkte Containerports werden möglichst vermieden. Vorteile der Stack-Struktur Reproduzierbarkeit Stacks können jederzeit erneut bereitgestellt werden. Migration Dienste lassen sich einfacher auf andere Systeme verschieben. Wartbarkeit Konfigurationen bleiben zentral dokumentiert. Backupfähigkeit Volumes und Stack-Dateien können gezielt gesichert werden. Sicherheitsprinzipien Die Stack-Architektur dient insbesondere: Diensttrennung kontrollierten Veröffentlichungen minimierten Direktzugriffen vereinfachten Backups reproduzierbaren Deployments Besonderheiten Die Umgebung verwendet bewusst: Compose-basierte Deployments serviceorientierte Trennung Reverse-Proxy-first-Prinzip zentrale DNS-Struktur persistente Volumes Dadurch bleibt die Infrastruktur: modular wartbar skalierbar migrationsfähig Dokumentation Stack-Übersicht Optional Screenshot der Stack-Liste in Portainer einfügen Beispiel-Compose-Datei Optional Beispiel eines Compose-Stacks einfügen Persistente Daten Persistente Daten Zweck Die Infrastruktur von Hainbach 45 verwendet persistente Datenhaltung zur dauerhaften Speicherung containerbezogener Daten. Dadurch bleiben Daten erhalten bei: Container-Neustarts Updates Stack-Neuinstallationen Migrationen Hostwechseln Architekturprinzip Container selbst werden als austauschbar betrachtet. Persistente Daten werden bewusst außerhalb der Container gespeichert. Dadurch bleiben: Konfigurationen Datenbanken Medien Benutzerdateien Zertifikate unabhängig vom Container erhalten. Speicherstruktur Die zentrale Datenhaltung erfolgt überwiegend unter: /srv/docker/ Wichtige Verzeichnisse Infrastrukturdienste Dienst Pfad AdGuard Home /srv/docker/adguard NGINX Proxy Manager /srv/docker/nginx-proxy-manager BookStack /srv/docker/bookstack Uptime Kuma /srv/docker/uptime-kuma Plattformdienste Dienst Pfad Nextcloud /srv/docker/nextcloud Vaultwarden /srv/docker/vaultwarden ntfy /srv/docker/ntfy Monitoring Dienst Pfad Grafana /srv/docker/grafana InfluxDB /srv/docker/influxdb Smart Home & OT Dienst Pfad ioBroker /srv/docker/iobroker Vorteile persistenter Datenhaltung Einfachere Migration Container können neu erstellt werden, ohne Daten zu verlieren. Vereinfachte Backups Nur persistente Verzeichnisse müssen gesichert werden. Reproduzierbare Infrastruktur Containerdefinition und Datenhaltung bleiben getrennt. Vereinfachte Wiederherstellung Ein Restore erfolgt typischerweise durch: 1. Daten zurückspielen 2. Stack erneut deployen 3. Container starten Backup-Strategie Die persistenten Daten werden mittels: Restic gesichert. Backupziele: QNAP NAS Synology-Replikation geplante Offsite-Sicherung Architekturentscheidung Die Infrastruktur verwendet bewusst: bind mounts persistente Verzeichnisse servicegetrennte Speicherstrukturen keine wichtigen Daten innerhalb von Containern Sicherheitsprinzipien Die Datenstruktur dient insbesondere: kontrollierten Backups vereinfachten Restores besserer Übersichtlichkeit reduzierten Datenverlusten klaren Servicegrenzen Besonderheiten Die Datenhaltung orientiert sich bewusst an: serviceorientierter Trennung reproduzierbaren Deployments einfacher Backupfähigkeit klarer Verzeichnisstruktur Dadurch bleibt die Infrastruktur: wartbar nachvollziehbar migrationsfähig recoveryfähig Dokumentation Verzeichnisstruktur Optional Screenshot der /srv/docker -Struktur einfügen Backupintegration Optional Screenshot der Restic-Backupstruktur einfügen Update-Strategie Update-Strategie Zweck Die Infrastruktur von Hainbach 45 verwendet eine kontrollierte und überwachte Update-Strategie. Ziel ist: stabile Betriebsführung kontrollierte Wartungsfenster Vermeidung ungeprüfter Änderungen Reduktion von Ausfallrisiken frühzeitige Erkennung neuer Container-Versionen Grundprinzip Updates werden bewusst: kontrolliert manuell nachvollziehbar durchgeführt. Automatische Containerupdates werden nicht verwendet. Architekturprinzipien Die Update-Strategie basiert auf folgenden Grundprinzipien: keine unkontrollierten Auto-Updates zentrale Überwachung neuer Versionen geplante Wartungsfenster vorherige Backups reproduzierbare Stack-Deployments kontrollierte Neustarts Container-Updates Container werden überwiegend aktualisiert über: Portainer → Stack bearbeiten → Image aktualisieren → Redeploy Alternativ: docker compose pull docker compose up -d Monitoring neuer Versionen Die Infrastruktur verwendet: Diun zur Überwachung neuer Container-Versionen. Diun Zweck Diun überwacht verfügbare Updates für: Docker-Container Images neue Versionen Benachrichtigungen erfolgen über: ntfy Entscheidung gegen Watchtower Watchtower wurde bewusst verworfen. Grund: Docker-29-Kompatibilitätsprobleme automatische Änderungen unerwünscht fehlende Kontrolle über Wartungszeitpunkte Fehlerbild: client version 1.25 is too old Betriebssystem-Updates Linux-Updates erfolgen bewusst getrennt von Containerupdates. Aktualisiert werden insbesondere: Debian Raspberry Pi OS Sicherheitsupdates Kernelupdates Update-Monitoring Die Infrastruktur verwendet zusätzlich: apt-Update-Checks systemd Timer ntfy-Benachrichtigungen Dadurch werden verfügbare Updates automatisch gemeldet. Backup vor Updates Vor größeren Änderungen werden bevorzugt erstellt: Restic-Backups Snapshots Konfigurationssicherungen Insbesondere vor: Datenbankupdates Nextcloud-Upgrades Infrastrukturänderungen Reverse-Proxy-Anpassungen Wartungsstrategie Updates erfolgen bevorzugt: außerhalb kritischer Nutzungszeiten kontrolliert schrittweise dokumentiert Sicherheitsprinzipien Die Update-Strategie dient insbesondere: höherer Stabilität kontrollierten Änderungen reduzierten Ausfallrisiken nachvollziehbaren Wartungen einfacheren Rollbacks Architekturentscheidung Die Infrastruktur verwendet bewusst: kontrollierte Updates keine Auto-Updater Monitoring statt Automatisierung zentrale Benachrichtigungen reproduzierbare Stack-Strukturen Dadurch bleibt die Umgebung: stabil nachvollziehbar wartbar recoveryfähig Dokumentation Diun Optional Screenshot der Diun-Konfiguration einfügen ntfy-Updates Optional Screenshot der Update-Benachrichtigungen einfügen Portainer-Stacks Optional Screenshot der Stack-Verwaltung einfügen Server Plattformdienste Übersicht Zweck Die Infrastruktur von Hainbach 45 verwendet mehrere zentrale Plattformdienste zur Bereitstellung von: Infrastrukturservices Monitoring Dokumentation Remotezugriff Visualisierung Benachrichtigungen Die Dienste bilden die technische Grundlage der gesamten Smart-Home- und Homelab-Umgebung. Architekturprinzip Die Plattformdienste basieren bewusst auf: Docker-Containern zentraler Verwaltung Reverse-Proxy-Integration DNS-basierter Erreichbarkeit persistenter Datenhaltung serviceorientierter Trennung Hauptdienste Dienst Funktion ntfy Benachrichtigungen Uptime Kuma Monitoring Grafana Dashboards InfluxDB Zeitreihendatenbank BookStack Dokumentation WireGuard VPN-Zugriff Architekturübersicht Die Plattformdienste kommunizieren typischerweise über: DNS → Reverse Proxy → Plattformdienst Dadurch bleiben: Zugriffe standardisiert Containerports verborgen HTTPS zentral verwaltbar Dienste einfacher migrierbar Infrastrukturprinzipien Die Umgebung verwendet bewusst: serviceorientierte Trennung zentrale DNS-Struktur Reverse-Proxy-first-Prinzip containerisierte Dienste persistente Volumes reproduzierbare Deployments Zugriffskonzept Die meisten Plattformdienste sind intern erreichbar über: *.home Beispiele: grafana.home portainer.home wiki.home adguard.home Öffentliche Dienste werden zusätzlich veröffentlicht über: *.schwarzi.at Sicherheitsprinzipien Die Plattformarchitektur dient insbesondere: kontrollierten Zugriffen zentraler Verwaltung vereinfachten Wartungen reduzierten Direktzugriffen besserer Infrastrukturübersicht Containerisierung Nahezu alle Plattformdienste laufen containerisiert. Die Verwaltung erfolgt zentral über: Portainer Persistente Datenhaltung Konfigurationen und Daten werden dauerhaft gespeichert unter: /srv/docker/ Dadurch bleiben Dienste unabhängig von einzelnen Containern erhalten. Monitoringintegration Die Plattformdienste sind in die Monitoringstruktur integriert über: Uptime Kuma ntfy Grafana InfluxDB Zugehörige Seiten ntfy Uptime Kuma Diun Grafana InfluxDB BookStack WireGuard ntfy Zweck ntfy dient als zentrale Benachrichtigungsplattform der H45-Infrastruktur. Der Dienst ermöglicht Push-Benachrichtigungen für: Backups Systemfehler Updatehinweise Monitoringereignisse Serviceausfälle Benachrichtigungen werden direkt an mobile Geräte übertragen. Architekturprinzip Die Infrastruktur verwendet bewusst: leichtgewichtige Push-Benachrichtigungen zentrale Topics systemd-basierte Integration minimale externe Abhängigkeiten Infrastrukturstandort System Funktion App-Server zentrale Benachrichtigungsplattform Zugriff Intern http://10.45.10.10:2586 Extern https://ntfy.schwarzi.at Verwendete Topics Topic Zweck H45-Backup erfolgreiche Backups H45-Alerts Fehler / Warnungen H45-Updates OS- und Containerupdates H45-Uptime Uptime-Kuma-Benachrichtigungen H45-Notify allgemeine Tests Hauptfunktionen Backup-Benachrichtigungen Restic-Backups senden Meldungen bei: erfolgreichem Backup fehlgeschlagenem Backup Die Integration erfolgt über: systemd ExecStartPost OnFailure Monitoring-Benachrichtigungen Uptime Kuma verwendet ntfy für: Serviceausfälle Wiederherstellungen Statusänderungen Update-Benachrichtigungen Updates werden überwacht über: Diun apt-Checks systemd Timer Benachrichtigungen erfolgen zentral über ntfy. Android-Integration Verwendete App: ntfy Konfiguration: Einstellung Wert Server http://10.45.10.10:2586 Topics H45-* Akkuoptimierung deaktiviert Hintergrundaktivität erlaubt Architekturübersicht Benachrichtigungsfluss: Dienst → ntfy → Smartphone Sicherheitsprinzipien Die Benachrichtigungsplattform dient insbesondere: schneller Fehlererkennung zentraler Alarmierung reduzierten Reaktionszeiten vereinfachter Betriebsüberwachung Architekturentscheidung Die Umgebung verwendet bewusst: ntfy statt komplexer SaaS-Lösungen lokale Infrastruktur zentrale Topics systemd-first-Prinzip einfache HTTP-Integration Dadurch bleibt die Plattform: leichtgewichtig wartbar datenschutzfreundlich stabil Besonderheiten Die Integration erfolgt bewusst minimalinvasiv. Bestehende Backup- und Monitoring-Skripte werden nicht unnötig verändert. Benachrichtigungen werden stattdessen ergänzt über: systemd Drop-Ins zusätzliche Scripts OnFailure-Mechanismen Dokumentation ntfy Topics Optional Screenshot der ntfy-Topics einfügen Android-App Optional Screenshot der ntfy-App einfügen Uptime-Kuma-Integration Optional Screenshot der ntfy-Notification-Konfiguration einfügen Uptime Kuma Zweck Uptime Kuma dient als zentrale Plattform zur Verfügbarkeitsüberwachung der H45-Infrastruktur. Der Dienst überwacht: Infrastrukturkomponenten Webdienste DNS Smart-Home-Dienste NAS-Systeme Internetverbindungen Bei Ausfällen erfolgen automatische Benachrichtigungen über ntfy. Architekturprinzip Die Monitoring-Infrastruktur verwendet bewusst: zentrale Verfügbarkeitsüberwachung einfache HTTP-/Ping-Checks zentrale Benachrichtigungen containerisierte Dienste minimale Komplexität Infrastrukturstandort System Funktion App-Server Verfügbarkeitsmonitoring Zugriff Intern uptime.home Direktzugriff http://10.45.10.10:3003 Hauptfunktionen Infrastrukturmonitoring Überwachung von: DNS Reverse Proxy Containerplattform NAS-Systemen Internetverbindungen Webdienstmonitoring Überwachung von: Nextcloud Vaultwarden Portainer Grafana ioBroker ntfy Netzwerkmonitoring Zusätzlich werden überwacht: Router NAS-Systeme Netzwerkverbindungen Internetzugriff Verwendete Monitore Monitor Typ Internet Ping AdGuard HTTP NGINX Proxy Manager HTTP Portainer HTTPS Nextcloud HTTPS Vaultwarden HTTPS ioBroker HTTP ntfy HTTP QNAP Ping Synology Ping Portainer-Besonderheit Empfohlene URL: https://10.45.10.10:9443/api/status Zusätzlich aktiviert: TLS/SSL-Fehler ignorieren Standard-Monitoring-Einstellungen Parameter Wert Prüfintervall 60 Sekunden Wiederholungen 2 Retry-Intervall 30 Sekunden Timeout 15 Sekunden Benachrichtigungen Benachrichtigungen erfolgen zentral über: ntfy Verwendetes Topic: H45-Uptime Architekturübersicht Monitoringfluss: Dienste → Uptime Kuma → ntfy → Smartphone Docker-Integration Uptime Kuma läuft containerisiert. Docker-Compose services: uptime-kuma: image: louislam/uptime-kuma:1 container_name: uptime-kuma restart: unless-stopped ports: - 3003:3001 volumes: - /opt/uptime-kuma:/app/data environment: - TZ=Europe/Vienna Sicherheitsprinzipien Die Monitoringplattform dient insbesondere: schneller Fehlererkennung zentraler Infrastrukturüberwachung reduzierten Reaktionszeiten frühzeitiger Problemerkennung Architekturentscheidung Die Umgebung verwendet bewusst: einfache HTTP-/Ping-Monitore zentrale Benachrichtigungen containerisierte Überwachung ntfy-Integration Reverse-Proxy-first-Prinzip Dadurch bleibt die Plattform: leichtgewichtig stabil nachvollziehbar wartbar Besonderheiten Die Plattform überwacht bewusst: interne Infrastruktur öffentliche Dienste DNS Reverse Proxy Smart-Home-Dienste NAS-Systeme Dadurch entsteht ein zentraler Überblick über den Infrastrukturstatus. Dokumentation Dashboard Optional Screenshot des Uptime-Kuma-Dashboards einfügen Monitore Optional Screenshot der Monitorliste einfügen ntfy-Integration Optional Screenshot der Notification-Konfiguration einfügen Diun Zweck Diun dient zur Überwachung verfügbarer Updates für Docker-Container innerhalb der H45-Infrastruktur. Der Dienst erkennt neue Container-Versionen und informiert zentral über: neue Images verfügbare Updates geänderte Container-Tags Benachrichtigungen erfolgen über ntfy. Architekturprinzip Die Infrastruktur verwendet bewusst: kontrollierte Updates keine automatischen Containerupdates zentrale Updateüberwachung Benachrichtigungen statt Auto-Updater Zielsetzung Ziele der Plattform: frühzeitige Erkennung neuer Container-Versionen kontrollierte Wartungsfenster reduzierte Ausfallrisiken nachvollziehbare Updates stabile Infrastruktur Infrastrukturstandort System Funktion App-Server Container-Update-Monitoring Hauptfunktionen Image-Überwachung Diun überwacht: Docker Hub Container-Registries neue Image-Versionen geänderte Tags Benachrichtigungen Benachrichtigungen erfolgen zentral über: ntfy Verwendetes Topic: H45-Updates Architekturübersicht Updatefluss: Container Registry → Diun → ntfy → Smartphone Verwendete Strategie Die Umgebung verwendet bewusst: Monitoring statt Auto-Updates manuelle Freigabe neuer Versionen kontrollierte Deployments geplante Wartungsfenster Entscheidung gegen Watchtower Watchtower wurde bewusst verworfen. Gründe: Docker-29-Kompatibilitätsprobleme automatische Änderungen unerwünscht reduzierte Kontrolle höheres Risiko ungeprüfter Updates Bekannter Fehler: client version 1.25 is too old Vorteile von Diun Kontrollierte Updates Updates erfolgen ausschließlich bewusst und manuell. Frühzeitige Information Neue Versionen werden frühzeitig erkannt. Reduzierte Risiken Keine ungeprüften automatischen Änderungen an Produktivsystemen. Bessere Wartbarkeit Updates können geplant und dokumentiert durchgeführt werden. Sicherheitsprinzipien Die Updateüberwachung dient insbesondere: höherer Stabilität kontrollierten Änderungen reduzierten Ausfallrisiken nachvollziehbaren Wartungen Architekturentscheidung Die Umgebung verwendet bewusst: Benachrichtigungen statt Auto-Updater ntfy-Integration manuelle Freigaben kontrollierte Wartungsfenster reproduzierbare Stack-Deployments Dadurch bleibt die Infrastruktur: stabil wartbar nachvollziehbar recoveryfähig Besonderheiten Die Plattform überwacht ausschließlich Container-Updates. Betriebssystemupdates werden separat überwacht über: apt systemd Timer ntfy Dokumentation Diun Dashboard / Logs Optional Screenshot der Diun-Logs einfügen ntfy-Benachrichtigungen Optional Screenshot der Update-Benachrichtigungen einfügen Portainer Stack Optional Screenshot des Diun-Stacks einfügen Grafana Zweck Grafana dient als zentrale Visualisierungsplattform der H45-Infrastruktur. Die Plattform ermöglicht: Dashboards Zeitreihenvisualisierung Infrastrukturmonitoring Smart-Home-Visualisierung Langzeitanalysen Die Datenbasis stammt primär aus InfluxDB. Architekturprinzip Die Monitoring-Infrastruktur verwendet bewusst: zentrale Dashboards getrennte Datenspeicherung Zeitreihendatenbanken serviceübergreifende Visualisierung containerisierte Plattformdienste Infrastrukturstandort System Funktion App-Server Monitoring & Dashboards Zugriff Intern grafana.home Direktzugriff http://10.45.10.10:3000 Hauptfunktionen Infrastrukturmonitoring Visualisierung von: Serverstatus Netzwerkdaten Containerzuständen Verfügbarkeiten Performancewerten Smart-Home-Monitoring Visualisierung von: Shelly-Daten Energieverbrauch PV-Daten Sensorwerten Smart-Home-Zuständen Langzeitanalyse Grafana ermöglicht: historische Analysen Trendbeobachtungen Zeitreihenvergleiche Langzeitmonitoring Datenquellen Datenquelle Zweck InfluxDB Zeitreihendaten ioBroker Smart-Home-Daten Uptime Kuma Statusinformationen Architekturübersicht Monitoringfluss: Geräte / Dienste → ioBroker / Monitoring → InfluxDB → Grafana → Dashboard Verwendete Dashboards Infrastruktur Serverstatus Docker Netzwerk Verfügbarkeit Smart Home Shelly Energieverbrauch PV Sensorik Smart-Home-Zustände Sicherheitsprinzipien Die Plattform dient insbesondere: zentraler Übersicht vereinfachter Analyse Infrastrukturtransparenz Langzeitüberwachung schneller Fehlererkennung Docker-Integration Grafana läuft containerisiert. Persistente Daten werden gespeichert unter: /srv/docker/grafana Reverse-Proxy-Integration Der Zugriff erfolgt über: DNS → Reverse Proxy → Grafana Direkte Containerports werden möglichst vermieden. Besonderheiten Die Umgebung verwendet bewusst: zentrale Dashboards Zeitreihendatenbanken serviceübergreifende Visualisierung Reverse-Proxy-first-Prinzip persistente Datenhaltung Dadurch bleibt die Plattform: wartbar nachvollziehbar erweiterbar langfristig nutzbar Dokumentation Dashboards Optional Screenshot der Dashboards einfügen Datenquellen Optional Screenshot der InfluxDB-Datenquelle einfügen Smart-Home-Visualisierung Optional Screenshot der Energie-/Shelly-Dashboards einfügen InfluxDB Zweck InfluxDB dient als zentrale Zeitreihendatenbank der H45-Infrastruktur. Die Plattform speichert: Monitoringdaten Smart-Home-Daten Sensordaten Energieverbrauchswerte Zeitreiheninformationen Die Daten werden primär durch Grafana visualisiert. Architekturprinzip Die Infrastruktur verwendet bewusst: zentrale Zeitreihenspeicherung getrennte Datenspeicherung langfristige Datenhaltung serviceübergreifende Analyse containerisierte Plattformdienste Infrastrukturstandort System Funktion App-Server Zeitreihendatenbank Zugriff Intern influx.home Direktzugriff http://10.45.10.10:8086 Hauptfunktionen Zeitreihenspeicherung Speicherung von: Sensordaten Statuswerten Energieverbrauch Leistungsdaten Infrastrukturmetriken Smart-Home-Daten InfluxDB dient insbesondere als Datenspeicher für: ioBroker Shelly PV-Daten Temperaturwerte Energieverbrauchswerte Langzeitarchivierung Die Plattform ermöglicht: historische Analysen Trendanalysen Langzeitvergleiche Zeitreihenvisualisierung Architekturübersicht Datenfluss: Geräte / Sensoren → ioBroker → InfluxDB → Grafana → Dashboard Datenquellen Quelle Zweck ioBroker Smart-Home-Daten Shelly Energie-/Leistungsdaten Monitoringdienste Infrastrukturmetriken Verwendete Datenarten Smart Home Temperaturen Statuswerte Schaltzustände Energieverbrauch Leistungswerte Infrastruktur Systemstatus Netzwerkdaten Verfügbarkeiten Monitoringwerte Docker-Integration InfluxDB läuft containerisiert. Persistente Daten werden gespeichert unter: /srv/docker/influxdb Reverse-Proxy-Integration Der Zugriff erfolgt intern über: DNS → Reverse Proxy → InfluxDB Direkte Containerports werden möglichst vermieden. Sicherheitsprinzipien Die Plattform dient insbesondere: zentraler Datenspeicherung langfristiger Analyse Infrastrukturtransparenz kontrollierter Datenhaltung serviceübergreifender Visualisierung Backup-Strategie Die persistenten Daten werden mittels: Restic gesichert. Die Sicherung erfolgt gemeinsam mit den übrigen Docker-Daten. Besonderheiten Die Umgebung verwendet bewusst: zentrale Zeitreihenspeicherung serviceübergreifende Datenerfassung persistente Datenhaltung Reverse-Proxy-first-Prinzip containerisierte Plattformdienste Dadurch bleibt die Plattform: wartbar nachvollziehbar skalierbar langfristig nutzbar Kritikalität InfluxDB gilt als wichtiger Infrastrukturbaustein für: Monitoring Langzeitanalysen Smart-Home-Auswertungen Grafana-Dashboards Ein Ausfall führt primär zu: fehlenden historischen Daten eingeschränkten Dashboards fehlender Langzeitvisualisierung Dokumentation Datenbanken / Buckets Optional Screenshot der Buckets einfügen Grafana-Integration Optional Screenshot der Datenquelle einfügen Smart-Home-Daten Optional Screenshot der Zeitreihen einfügen BookStack Zweck BookStack dient als zentrale Dokumentationsplattform der H45-Infrastruktur. Die Plattform ersetzt das bisherige Word-basierte IT-Handbuch schrittweise durch ein strukturiertes, webbasiertes Betriebswiki. BookStack wird verwendet für: Architektur- und Infrastrukturdokumentation Betriebs- und Wartungsdokumentation Smart-Home- und OT-Dokumentation Notfall- und Recovery-Dokumentation Lessons Learned technische Betriebsnotizen Architekturprinzip BookStack basiert auf einer klaren Dokumentationshierarchie: Regal → Buch → Kapitel → Seite Diese Struktur passt zur H45-Dokumentation deutlich besser als eine klassische Wiki-Ordnerstruktur. Infrastrukturstandort System Funktion App-Server Dokumentationsplattform Zugriff Intern wiki.home Extern wiki.schwarzi.at Zielsystem Dienst Ziel BookStack http://10.45.10.10:3006 Reverse-Proxy-Integration BookStack wird über NGINX Proxy Manager veröffentlicht. Zugriffsfluss: Client → DNS → Reverse Proxy → BookStack APP_URL BookStack benötigt eine eindeutige kanonische URL. Empfohlene produktive Einstellung: APP_URL=https://wiki.schwarzi.at Eine parallele gleichwertige Nutzung mehrerer Basis-URLs ist nicht vorgesehen. Struktur der H45-Dokumentation Regal Hainbach 45 Bücher Buch Zweck Architektur & Infrastruktur Aufbau der technischen Umgebung Betrieb & Wartung Betriebsprozesse, Backup, Monitoring, Updates Smart Home & OT ioBroker, CCU3, Shelly, PV, IoT Notfall & Recovery Wiederherstellung, Notfallzugriff, SPOFs Wissensbasis / Lessons Learned Erkenntnisse, Entscheidungen, Migrationshistorie Vorteile gegenüber Word BookStack bietet: bessere Navigation einfachere Aktualisierung einzelner Seiten Suchfunktion klare Kapitelstruktur PDF-Export Bilder und Diagramme Versionierung bessere Wartbarkeit Backup-Relevanz BookStack ist ein kritischer Dokumentationsdienst. Zu sichern sind insbesondere: BookStack-Konfiguration Datenbank hochgeladene Bilder Anhänge Seiteninhalte Persistente Daten befinden sich unter: /srv/docker/bookstack Sicherheitsprinzipien Die Plattform enthält potenziell sensible Infrastrukturinformationen. Daher gelten folgende Prinzipien: keine Klartext-Passwörter Zugangsdaten bleiben in Vaultwarden Notfallinformationen nur kontrolliert dokumentieren öffentliche Erreichbarkeit nur bewusst freigeben regelmäßiges Backup Besonderheiten BookStack wird als zentrale „Source of Truth“ für die H45-Dokumentation verwendet. Das bisherige IT-Handbuch wird perspektivisch nur noch als: PDF-Export Archivkopie Offline-Notfalldokument verwendet. Dokumentation Startseite / Regalstruktur Optional Screenshot der BookStack-Regalstruktur einfügen Bücherübersicht Optional Screenshot der Bücherübersicht einfügen Exportfunktion Optional Screenshot der PDF-Exportfunktion einfügen