# 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: ```text 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: ```text 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: ```text 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: ```text 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: ```text NGINX Proxy Manager ``` Dadurch müssen Zertifikate nicht auf einzelnen Diensten verwaltet werden. --- # Architekturprinzip HTTPS wird bewusst zentral terminiert. Die Kommunikation erfolgt grundsätzlich: ```text 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: ```text 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: ```text Let's Encrypt ``` bezogen und verwaltet. Die Verwaltung erfolgt direkt im: ```text 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