bilal/homelab-doku
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

cleanup

Browse source
This commit is contained in:
Bilal Teke 2026-06-04 08:28:37 +02:00
parent 000f4ec8be
commit c139352d95
25 changed files with 504 additions and 1114 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

25
Unraid/README.md
View file

@ -1,17 +1,19 @@
# Unraid-Dokumentation # Unraid-Dokumentation
Diese Dokumentation beschreibt Aufbau, Dienste und Betrieb des Unraid-Servers. Diese Dokumentation beschreibt den Aufbau und Betrieb des zentralen privaten Homeservers. Sie richtet sich auch an Personen, die Unraid nicht regelmäßig administrieren.
## Einstieg ## Empfohlener Einstieg
- [Übersicht](overview.md) 1. Die [Übersicht](overview.md) erklärt die Rolle des Servers im Homelab.
- [Dienste und Anwendungen](services.md) 2. [Dienste und Anwendungen](services.md) zeigt, welche Funktionen der Server bereitstellt.
- [Bekannte Themen und Verbesserungspotenzial](known-issues.md) 3. [Storage](storage.md) und [Shares](shares.md) erklären, wo die Daten liegen.
4. [Docker](docker.md) beschreibt den technischen Betrieb der Anwendungen.
5. [Bekannte Themen](known-issues.md) sammelt offene Arbeiten an einer zentralen Stelle.
## Infrastruktur ## Infrastruktur
- [Hardware](hardware.md) - [Hardware](hardware.md)
- [Speicher, Array und Pools](storage.md) - [Storage, Array und Cache](storage.md)
- [Shares und Datenablage](shares.md) - [Shares und Datenablage](shares.md)
- [Netzwerk](networking.md) - [Netzwerk](networking.md)
- [Docker](docker.md) - [Docker](docker.md)
@ -24,3 +26,14 @@ Diese Dokumentation beschreibt Aufbau, Dienste und Betrieb des Unraid-Servers.
- [Backup](backup.md) - [Backup](backup.md)
- [Wartung und Betrieb](maintenance.md) - [Wartung und Betrieb](maintenance.md)
## Begriffe
| Begriff | Bedeutung |
|---|---|
| Array | Gruppe der hauptsächlich für dauerhafte Daten genutzten Festplatten |
| Parity | Zusätzliche Informationen, mit denen der Ausfall eines Array-Laufwerks rekonstruiert werden kann |
| Cache Pool | Schneller SSD-Speicher für häufig verwendete oder zunächst zwischengespeicherte Daten |
| Share | Logische Datenfreigabe, die Speicherorte über einen gemeinsamen Namen zugänglich macht |
| Container | Isolierte Laufzeitumgebung für einen Dienst oder eine Anwendung |
| Reverse Proxy | Zentraler Einstiegspunkt, der Anfragen an den passenden internen Dienst weiterleitet |

22
Unraid/backup.md
View file

@ -1,22 +1,18 @@
# Backup Dokumentation # Backup Dokumentation
## Backup-Strategie ## Aktueller Stand
Noch zu dokumentieren. Der Unraid-Server ist als zentrales Backup-Ziel vorgesehen. Aktuell sind unter anderem ein Share für Home-Assistant-Backups (`ha_backup`) und ein Share für Wiederherstellungsdaten (`restore`) bekannt.
## Gesicherte Daten Diese Shares allein bilden noch keine vollständig dokumentierte Backup-Strategie. Insbesondere ist noch nicht festgelegt, welche Daten regelmäßig gesichert werden und wie eine Wiederherstellung durchgeführt wird.
Noch zu dokumentieren. ## Abgrenzung zur Parität
## Backup-Ziele Die aktive Array-Parität schützt vor dem Ausfall eines einzelnen Array-Laufwerks. Sie ersetzt kein Backup, da sie nicht gegen versehentliches Löschen, beschädigte Daten oder den vollständigen Verlust des Servers schützt.
Noch zu dokumentieren. ## Weiterführende Dokumentation
## Wiederherstellung - Vorhandene Datenbereiche: [Shares und Datenablage](shares.md)
- Physischer Speicher und Parität: [Storage](storage.md)
Noch zu dokumentieren. - Noch offene Arbeiten: [Bekannte Themen und Verbesserungspotenzial](known-issues.md)
## Restore-Tests
Noch zu dokumentieren.

135
Unraid/docker.md
View file

@ -1,124 +1,59 @@
# Docker Dokumentation # Docker Dokumentation
## Allgemein Docker betreibt die Anwendungen des Unraid-Servers in voneinander getrennten Containern. Die fachliche Aufgabe jedes Dienstes steht unter [Dienste und Anwendungen](services.md).
Der Unraid-Server nutzt Docker als zentrale Plattform für: ## Containerstatus
- Infrastruktur-Dienste | Dienst | Status |
- Medienserver |---|---|
- Dokumentenmanagement | AdGuard Home | aktiv |
- Smart Home Komponenten | Immich | aktiv |
- interne Anwendungen | MariaDB | aktiv |
| Netdata | aktiv |
--- | NPM | aktiv |
| Paperless-ngx | aktiv |
| PhotoPrism | aktiv |
| Plex | aktiv |
| Redis | aktiv |
| Scrypted | aktiv |
| Seafile | gestoppt |
| Wiki.js | aktiv |
## Netzwerkmodi ## Netzwerkmodi
Verwendete Modi: Die Container verwenden aktuell unterschiedliche Netzwerkmodi:
- bridge | Modus | Einordnung |
- host
- br0
- compose-basierte Netzwerke
---
## Produktive Container
| Dienst | Aufgabe | Status |
|---|---|---|
| AdGuard Home | DNS | aktiv |
| Immich | Fotoverwaltung | aktiv |
| MariaDB | Datenbank | aktiv |
| Netdata | Monitoring | aktiv |
| NPM | Reverse Proxy | aktiv |
| Paperless-ngx | Dokumentenmanagement | aktiv |
| PhotoPrism | Fotoverwaltung | aktiv |
| Plex | Medienserver | aktiv |
| Redis | Cache/Datenbank | aktiv |
| Scrypted | Kamera-Integration | aktiv |
| Seafile | Dateisynchronisation | gestoppt |
| Wiki.js | Dokumentation | aktiv |
---
## Medienstack
| Dienst | Aufgabe |
|---|---| |---|---|
| Sonarr | Serienverwaltung | | bridge | Container nutzt ein von Docker verwaltetes Netzwerk |
| Radarr | Filmverwaltung | | host | Container verwendet direkt das Netzwerk des Unraid-Servers |
| Lidarr | Musikverwaltung | | br0 | Container erhält Zugang zum physischen Netzwerk über eine Bridge |
| Seerr | Request Management | | Compose-Netzwerk | Netzwerk wird gemeinsam mit einem Compose Stack definiert |
| SABnzbd | Downloads |
--- Viele Dienste laufen im Bridge-Netzwerk und besitzen direkte Portfreigaben im lokalen Netzwerk. Eine einheitliche Zielarchitektur ist noch nicht festgelegt.
## Compose Nutzung ## Compose
### Vorhandene Compose Stacks Compose beschreibt zusammengehörige Container und ihre Konfiguration in einer reproduzierbaren Datei.
| Stack | Status | | Stack | Status |
|---|---| |---|---|
| Immich | aktiv | | Immich | aktiv |
Der Server nutzt bereits: Der Server nutzt bereits den Compose Manager. Weitere Container sollen langfristig in reproduzierbare Compose Stacks überführt werden.
- Compose Manager ## Gestoppte oder möglicherweise ungenutzte Container
- Compose-basierte Containerverwaltung
Dies ermöglicht: | Container | Aktueller oder vermuteter Status |
- reproduzierbare Stacks
- bessere Versionskontrolle
- Infrastructure as Code
---
## Netzwerkarchitektur
### Auffälligkeiten
Viele Dienste laufen aktuell:
- im bridge Netzwerk
- mit direkten Portfreigaben
Langfristig geplant:
- interne Netzwerke
- zentrale Reverse-Proxy-Struktur
- weniger direkte LAN-Portfreigaben
---
## Gestoppte Container
| Container | Vermuteter Status |
|---|---| |---|---|
| Seafile | Wartung/Migration | | Seafile | Wartung oder Migration |
| Recyclarr | ungenutzt | | Recyclarr | vermutlich ungenutzt |
| Whisparr | ungenutzt | | Whisparr | vermutlich ungenutzt |
| Adminer | temporär | | Adminer | temporär |
| Firefly Importer | Altlast/Test | | Firefly Importer | Altlast oder Test |
--- Der tatsächliche Zweck dieser Container sollte vor einer Änderung oder Entfernung geprüft werden.
## Beobachtungen ## Offene Arbeiten
### Positiv Die offenen Docker-Themen werden zentral unter [Bekannte Themen und Verbesserungspotenzial](known-issues.md) gepflegt.
- bereits relativ moderne Struktur
- Compose bereits im Einsatz
- klare Dienstetrennung
- wenige offensichtliche Docker-Probleme
---
## Verbesserungspotenzial
- interne Netzwerke vereinheitlichen
- Portfreigaben reduzieren
- Altlasten entfernen
- Compose Migration ausbauen
- zentrale Labels/Standards definieren

12
Unraid/hardware.md
View file

@ -1,14 +1,8 @@
# Hardware # Hardware
## System ## Aktueller Dokumentationsstand
Noch zu dokumentieren. Die Hardwarekomponenten des Unraid-Servers sind noch nicht erfasst. Bekannt ist lediglich, dass das Array ungefähr 16 TB und der SSD Cache Pool ungefähr 250 GB bereitstellt.
## Komponenten Details zum Aufbau der Speicherbereiche stehen unter [Storage](storage.md). Offene Dokumentationsarbeiten werden zentral unter [Bekannte Themen und Verbesserungspotenzial](known-issues.md) gepflegt.
Noch zu dokumentieren.
## Erweiterungen
Noch zu dokumentieren.

36
Unraid/known-issues.md
View file

@ -1,22 +1,36 @@
# Bekannte Themen und Verbesserungspotenzial # Bekannte Themen und Verbesserungspotenzial
## Infrastruktur Diese Datei bündelt offene Arbeiten, damit sie nicht zusätzlich in den einzelnen Fachkapiteln gepflegt werden müssen.
Noch zu dokumentieren. ## Hohe Priorität
## Speicher - Backup-Relevanz und Restore-Priorität für jeden Share festlegen
- Wiederherstellungsprozess für zentrale Daten und Anwendungen dokumentieren
- Zugriffsberechtigungen der öffentlichen SMB-Shares prüfen
Noch zu dokumentieren. ## Mittlere Priorität
## Dienste - Cache-Richtung und Verschiebezeitplan je Share dokumentieren
- gestoppte und möglicherweise ungenutzte Container prüfen
- direkte Container-Portfreigaben prüfen und reduzieren
- interne Docker-Netzwerke vereinheitlichen
- weitere Container in reproduzierbare Compose Stacks überführen
Noch zu dokumentieren. ## Dokumentation
## Betrieb - Hardware und Datenträgerzuordnung erfassen
- Dateisysteme dokumentieren
Noch zu dokumentieren. - Speicherort und Zugriffsberechtigungen je Share erfassen
- Abhängigkeiten zwischen Anwendungen, Datenbanken und Caches erfassen
- Paritätsprüfungen und deren Ergebnisse dokumentieren
- Netzwerkschnittstellen, Bridges und VLANs dokumentieren
- Routingregeln und genaue WireGuard-Anbindung dokumentieren
- interne Domains und erreichbare Ports dokumentieren
- überwachte Metriken, Schwellwerte und Alerting dokumentieren
- Verantwortlichkeiten bei Monitoring-Warnungen festlegen
## Langfristige Themen ## Langfristige Themen
Noch zu dokumentieren. - zentrale Standards für Container und Compose definieren
- Tiering- und Archivierungsstrategie festlegen
- automatisierte Wiederherstellung vorbereiten

20
Unraid/maintenance.md
View file

@ -1,18 +1,16 @@
# Wartung und Betrieb # Wartung und Betrieb
## Regelmäßige Aufgaben ## Aktueller Dokumentationsstand
Noch zu dokumentieren. Für den regelmäßigen Betrieb sind noch keine verbindlichen Abläufe dokumentiert. Bekannt ist, dass das Array eine aktive und gültige Parität besitzt und mehrere Anwendungen als Docker-Container betrieben werden.
## Updates ## Relevante Betriebsbereiche
Noch zu dokumentieren. - Zustand von Array und Cache prüfen
- Paritätsprüfungen überwachen
- Containerstatus kontrollieren
- Updates für Unraid und Anwendungen planen
- Backups und Wiederherstellungen testen
## Paritätsprüfungen Die konkreten Zeitpläne, Prüfschritte und Verantwortlichkeiten müssen noch festgelegt werden. Offene Arbeiten stehen unter [Bekannte Themen und Verbesserungspotenzial](known-issues.md).
Noch zu dokumentieren.
## Fehlerbehebung
Noch zu dokumentieren.

18
Unraid/monitoring.md
View file

@ -1,18 +1,10 @@
# Monitoring Dokumentation # Monitoring Dokumentation
## Systemmonitoring ## Aktueller Stand
Noch zu dokumentieren. Netdata läuft als aktiver Docker-Container und dient der Überwachung des Unraid-Servers.
## Speicherüberwachung ## Weiterführende Dokumentation
Noch zu dokumentieren.
## Dienstüberwachung
Noch zu dokumentieren.
## Alerting
Noch zu dokumentieren.
- Technischer Status des Netdata-Containers: [Docker](docker.md)
- Offene Monitoring-Arbeiten: [Bekannte Themen und Verbesserungspotenzial](known-issues.md)

27
Unraid/networking.md
View file

@ -1,18 +1,29 @@
# Unraid Netzwerk # Unraid Netzwerk
## Netzwerkschnittstellen ## Bekannte Netzwerkinformationen
Noch zu dokumentieren. | Eigenschaft | Wert |
|---|---|
| Hostname | mbyt3-server |
| IP-Adresse | 192.168.0.5 |
| Rolle | Private Infrastruktur im Heimnetz |
## VLANs und Bridges ## Verbindung zur VPS
Noch zu dokumentieren. Die öffentliche VPS und der private Unraid-Server sind über das Heimnetz und einen WireGuard-VPN-Tunnel gekoppelt. Dadurch kann die VPS interne Dienste erreichen, ohne Unraid selbst als öffentliche Edge zu verwenden.
## DNS und Routing ## Reverse Proxy und DNS
Noch zu dokumentieren. - NPM dient als Reverse Proxy für interne Dienste.
- AdGuard Home stellt DNS-Dienste bereit.
## VPN-Anbindung Die genauen Domains, Weiterleitungen und DNS-Regeln sind noch nicht dokumentiert.
Noch zu dokumentieren. ## Docker-Netzwerke
Die von Containern verwendeten Netzwerkmodi und ihre Einordnung stehen unter [Docker](docker.md).
## Weiterführende Dokumentation
- Container-Netzwerkmodi: [Docker](docker.md)
- Offene Netzwerk-Dokumentation: [Bekannte Themen und Verbesserungspotenzial](known-issues.md)

78
Unraid/overview.md
View file

@ -10,85 +10,35 @@
| Rolle | Zentraler Homeserver | | Rolle | Zentraler Homeserver |
| Lizenz | Unraid Basic | | Lizenz | Unraid Basic |
--- ## Aufgabe des Servers
## Aufgaben des Servers Der Unraid-Server ist der private Kern des Homelabs. Er speichert die zentralen Daten und betreibt interne Anwendungen für Medien, Dokumente, Smart Home und private Cloud-Dienste.
Der Unraid-Server dient als zentrale private Infrastruktur des Homelabs. Die Anwendungen laufen überwiegend als Docker-Container. Eine vollständige fachliche Übersicht steht unter [Dienste und Anwendungen](services.md); der technische Containerbetrieb ist unter [Docker](docker.md) beschrieben.
Hauptaufgaben:
- Dateispeicher
- Docker Hosting
- Medienserver
- Dokumentenmanagement
- Smart Home Infrastruktur
- Kamera-Integration
- Backup-Ziel
- interne Dienste
- private Cloud-Dienste
---
## Architekturrolle ## Architekturrolle
Die Infrastruktur ist logisch getrennt: Die öffentlich erreichbare VPS und der private Unraid-Server erfüllen unterschiedliche Aufgaben:
```text ```text
Internet Internet
↓ ↓
VPS (Public Edge) VPS (öffentlicher Einstiegspunkt)
↓ WireGuard VPN ↓ WireGuard VPN
Unraid (Private Infrastruktur) Unraid (private Infrastruktur und Daten)
``` ```
Der Unraid-Server hostet überwiegend: - Die VPS stellt die öffentliche Edge-Infrastruktur bereit.
- WireGuard verbindet VPS und Heimnetz über einen verschlüsselten VPN-Tunnel.
- interne Dienste - Unraid betreibt interne Dienste und hält private Daten zentral vor.
- private Daten
- Storage
- Medien
- Smart Home Komponenten
---
## Hauptdienste
| Bereich | Dienste |
|---|---|
| Medien | Plex, Immich |
| Dokumente | Paperless-ngx |
| Cloud | Seafile |
| Smart Home | Scrypted |
| Datenbanken | MariaDB, Redis |
| Verwaltung | Wiki.js |
| Netzwerk | AdGuard Home, NPM |
| Monitoring | Netdata |
---
## Infrastrukturprinzipien ## Infrastrukturprinzipien
### Aktuelle Architektur - öffentliche und private Infrastruktur sind getrennt
- die Kopplung mit der VPS erfolgt über VPN
- VPS als öffentliche Edge - Anwendungen werden überwiegend als Docker-Container betrieben
- Unraid als privater Kern - Daten werden zentral über Array, Cache und Shares organisiert
- Reverse Proxy Trennung
- VPN-basierte Kopplung
- Docker-basierte Dienste
- zentrale Datenhaltung
---
## Zielbild ## Zielbild
Der Unraid-Server soll langfristig: Der Unraid-Server soll langfristig wartungsarm, dokumentiert, leicht wiederherstellbar, energieeffizient und sicher betrieben werden.
- wartungsarm
- dokumentiert
- leicht wiederherstellbar
- energieeffizient
- zentralisiert
- sicher
betrieben werden.

19
Unraid/security.md
View file

@ -1,18 +1,19 @@
# Sicherheitsdokumentation # Sicherheitsdokumentation
## Zugriffsmodell ## Grundprinzip
Noch zu dokumentieren. Der Unraid-Server ist als private Infrastruktur im Heimnetz vorgesehen. Die öffentliche Edge-Infrastruktur läuft getrennt auf der VPS; die Kopplung erfolgt über einen WireGuard-VPN-Tunnel.
## Benutzer und Berechtigungen ## Zugriffsbereiche
Noch zu dokumentieren. - Interne Dienste werden unter anderem über NPM als Reverse Proxy bereitgestellt.
- AdGuard Home stellt interne DNS-Dienste bereit.
- Einige SMB-Shares sind öffentlich im lokalen Netzwerk freigegeben.
- Benutzerbezogene Shares sind als privat gekennzeichnet.
## Netzwerkzugriff Die konkreten SMB-Freigaben stehen unter [Shares und Datenablage](shares.md). Netzwerkdetails stehen unter [Unraid Netzwerk](networking.md).
Noch zu dokumentieren. ## Offene Arbeiten
## Sicherheitsmaßnahmen Offene Prüfungen und Dokumentationsarbeiten werden zentral unter [Bekannte Themen und Verbesserungspotenzial](known-issues.md) gepflegt.
Noch zu dokumentieren.

42
Unraid/services.md
View file

@ -1,14 +1,46 @@
# Dienste und Anwendungen # Dienste und Anwendungen
## Dienstübersicht Diese Übersicht beschreibt den fachlichen Zweck der Anwendungen. Technische Details zu Containerstatus, Netzwerken und Compose stehen unter [Docker](docker.md).
Noch zu dokumentieren. ## Infrastruktur und Verwaltung
| Dienst | Aufgabe |
|---|---|
| AdGuard Home | DNS-Dienst für das interne Netzwerk |
| MariaDB | Datenbank für andere Anwendungen |
| Netdata | Überwachung des Servers |
| NPM | Reverse Proxy für interne Dienste |
| Redis | Schneller Cache und Datenspeicher für andere Anwendungen |
| Wiki.js | Interne Dokumentation |
## Private Daten und Anwendungen
| Dienst | Aufgabe |
|---|---|
| Immich | Fotoverwaltung |
| Paperless-ngx | Dokumentenmanagement und Dokumentenarchiv |
| PhotoPrism | Fotoverwaltung |
| Plex | Medienserver |
| Scrypted | Kamera-Integration |
| Seafile | Dateisynchronisation |
## Medienverwaltung
| Dienst | Aufgabe |
|---|---|
| Sonarr | Serienverwaltung |
| Radarr | Filmverwaltung |
| Lidarr | Musikverwaltung |
| Seerr | Verwaltung von Medienanfragen |
| SABnzbd | Download-Verwaltung |
## Abhängigkeiten ## Abhängigkeiten
Noch zu dokumentieren. Einige Anwendungen benötigen Datenbanken oder Caches. Die genaue Zuordnung ist noch nicht dokumentiert.
## Kritikalität ## Weiterführende Dokumentation
Noch zu dokumentieren. - Datenablage und Zugriffsrechte: [Shares und Datenablage](shares.md)
- Containerstatus und technische Verwaltung: [Docker](docker.md)
- Überwachung: [Monitoring](monitoring.md)

57
Unraid/shares.md
View file

@ -1,18 +1,59 @@
# Shares und Datenablage # Shares und Datenablage
## Share-Übersicht Shares sind benannte Datenfreigaben. Sie verbergen den konkreten Speicherort auf Array oder Cache und stellen Daten für Anwendungen oder Benutzer bereit.
Noch zu dokumentieren. ## Anwendungs- und Systemdaten
## Zugriffsrechte | Share | Zweck |
|---|---|
| appdata | Persistente Containerdaten |
| system | Docker- und Systemdaten |
| domains | Daten virtueller Maschinen |
| downloads | Medien-Downloads |
| nextcloud | Nextcloud-Daten |
| paperless | Dokumentenarchiv |
| photos | Bilddaten |
| plex-media | Medienbibliothek |
| plex-transcode | Temporäre Daten für Plex-Transcoding |
| seafile | Seafile-Daten |
| wiki | Daten von Wiki.js |
| restore | Daten für Wiederherstellungen |
| ha_backup | Home-Assistant-Backups |
Noch zu dokumentieren. ## Cache-Nutzung
## Cache-Verhalten Bei den folgenden Shares werden Daten zwischen Cache und Array bewegt:
Noch zu dokumentieren. | Share | Cache-Verhalten |
|---|---|
| appdata | Cache ↔ Array |
| system | Cache ↔ Array |
| plex-transcode | Cache ↔ Array |
| seafile | Cache ↔ Array |
## Datenklassifizierung Die genaue Richtung und der Zeitplan der Verschiebungen sind noch nicht dokumentiert.
Noch zu dokumentieren. ## Netzwerkfreigaben
### Öffentlich zugängliche SMB-Shares
Diese Shares sind im lokalen Netzwerk ohne benutzerbezogene Einschränkung freigegeben:
| Share | Freigabe |
|---|---|
| Pictures | Public |
| plex-media | Public |
| timemachine | Public |
### Benutzerbezogene Shares
| Share | Zugriff |
|---|---|
| bilal | Private |
| julia | Private |
## Weiterführende Dokumentation
- Physischer Speicher und Parität: [Storage](storage.md)
- Backup-Stand: [Backup](backup.md)
- Offene Arbeiten an Shares: [Bekannte Themen und Verbesserungspotenzial](known-issues.md)

111
Unraid/storage.md
View file

@ -1,18 +1,14 @@
# Storage Dokumentation # Storage Dokumentation
## Allgemeiner Aufbau Storage beschreibt die physischen und logischen Speicherbereiche des Servers. Die einzelnen Datenfreigaben und ihre Zugriffsrechte sind separat unter [Shares und Datenablage](shares.md) dokumentiert.
Der Unraid-Server nutzt: ## Aufbau
- klassisches Unraid Array Der Unraid-Server verwendet ein klassisches Unraid Array für die dauerhafte Datenhaltung und einen SSD Cache Pool für schnell benötigte oder zunächst zwischengespeicherte Daten.
- SSD Cache
- zentrale User Shares
---
## Array ## Array
### Aktueller Status Das Array bündelt die Datenträger für die zentrale Datenhaltung. Die aktive Parität ermöglicht die Rekonstruktion beim Ausfall eines Array-Laufwerks, ersetzt jedoch kein Backup.
| Eigenschaft | Wert | | Eigenschaft | Wert |
|---|---| |---|---|
@ -21,105 +17,16 @@ Der Unraid-Server nutzt:
| Parity | aktiv | | Parity | aktiv |
| Zustand | valid | | Zustand | valid |
--- ## SSD Cache Pool
## Cache Der Cache Pool stellt schnelleren SSD-Speicher bereit. Er wird unter anderem für Containerdaten, Systemdaten, temporäre Daten und schnelle Schreibvorgänge verwendet.
### SSD Cache Pool
| Eigenschaft | Wert | | Eigenschaft | Wert |
|---|---| |---|---|
| Größe | ~250 GB | | Größe | ~250 GB |
| Nutzung | ~48 GB | | Nutzung | ~48 GB |
Der Cache dient für: ## Weiterführende Dokumentation
- Appdata - Datenfreigaben und Cache-Zuordnung: [Shares und Datenablage](shares.md)
- Docker Daten - Offene Storage-Arbeiten: [Bekannte Themen und Verbesserungspotenzial](known-issues.md)
- temporäre Daten
- schnelle Schreibvorgänge
---
## Shares
### Produktive Shares
| Share | Zweck |
|---|---|
| appdata | Containerdaten |
| system | Docker/Systemdaten |
| domains | VM Daten |
| downloads | Medien-Downloads |
| nextcloud | Nextcloud Daten |
| paperless | Dokumentenarchiv |
| photos | Bilddaten |
| plex-media | Medienbibliothek |
| plex-transcode | Plex Transcoding |
| seafile | Seafile Daten |
| wiki | Wiki.js Daten |
| restore | Wiederherstellung |
| ha_backup | Home Assistant Backups |
---
## Cache Nutzung
### Shares mit Cache Nutzung
| Share | Cache |
|---|---|
| appdata | Cache ↔ Array |
| system | Cache ↔ Array |
| plex-transcode | Cache ↔ Array |
| seafile | Cache ↔ Array |
---
## Öffentliche SMB Shares
| Share | Freigabe |
|---|---|
| Pictures | Public |
| plex-media | Public |
| timemachine | Public |
---
## Benutzerbezogene Shares
| Share | Zugriff |
|---|---|
| bilal | Private |
| julia | Private |
---
## Beobachtungen
### Positiv
- klare Share-Struktur
- saubere Trennung der Daten
- sinnvoller SSD Cache Einsatz
- zentrale Datenhaltung
---
## Verbesserungspotenzial
### Noch offen
- Share-Dokumentation ergänzen
- Backup-Relevanz je Share definieren
- Restore-Prioritäten festlegen
- Archivierungsstrategie dokumentieren
---
## Langfristige Ziele
- vollständige Backup-Strategie
- nachvollziehbare Datenstruktur
- automatisierte Wiederherstellung
- saubere Tiering-Strategie

16
Unraid/virtual-machines.md
View file

@ -1,18 +1,8 @@
# Virtuelle Maschinen # Virtuelle Maschinen
## VM-Übersicht ## Aktueller Dokumentationsstand
Noch zu dokumentieren. Der Share `domains` ist für Daten virtueller Maschinen vorgesehen. Aktuell sind jedoch keine betriebenen virtuellen Maschinen, deren Ressourcen oder Sicherungsverfahren dokumentiert.
## Ressourcen Die Einordnung des Shares steht unter [Shares und Datenablage](shares.md).
Noch zu dokumentieren.
## Passthrough
Noch zu dokumentieren.
## Speicher und Backups
Noch zu dokumentieren.

24
VPS/README.md
View file

@ -1,12 +1,14 @@
# VPS-Dokumentation # VPS-Dokumentation
Die VPS dient als öffentliche Edge-Infrastruktur des Homelabs. Die Dokumentation ist nach Verantwortungsbereichen gegliedert. Diese Dokumentation beschreibt die öffentlich erreichbare Edge-Infrastruktur des Homelabs. Sie richtet sich auch an Personen, die den Server nicht regelmäßig administrieren.
## Einstieg ## Empfohlener Einstieg
- [Übersicht](overview.md) 1. Die [Übersicht](overview.md) erklärt die Rolle der VPS im Homelab.
- [Dienste](services.md) 2. [Dienste](services.md) zeigt, welche Funktionen die VPS bereitstellt.
- [Bekannte Themen und Verbesserungspotenzial](known-issues.md) 3. [Netzwerk](networking.md), [WireGuard](wireguard.md) und [Sicherheit](security.md) erklären Erreichbarkeit und Schutz.
4. [Docker](docker.md) beschreibt den technischen Betrieb der Anwendungen.
5. [Bekannte Themen](known-issues.md) sammelt offene Arbeiten an einer zentralen Stelle.
## Infrastruktur ## Infrastruktur
@ -21,3 +23,15 @@ Die VPS dient als öffentliche Edge-Infrastruktur des Homelabs. Die Dokumentatio
- [Backup](backup.md) - [Backup](backup.md)
- [Wartung und Betrieb](maintenance.md) - [Wartung und Betrieb](maintenance.md)
## Begriffe
| Begriff | Bedeutung |
|---|---|
| VPS | Virtueller Server bei einem externen Anbieter |
| Public Edge | Öffentlich erreichbarer Einstiegspunkt vor den privaten Diensten |
| Reverse Proxy | Zentraler Einstiegspunkt, der Anfragen an den passenden Dienst weiterleitet |
| TLS-Terminierung | Entschlüsselung und Verarbeitung von HTTPS-Verbindungen am Reverse Proxy |
| SSO | Einmalige Anmeldung für den Zugriff auf mehrere Dienste |
| VPN | Verschlüsselte Verbindung zwischen getrennten Netzwerken oder Geräten |
| Container | Isolierte Laufzeitumgebung für einen Dienst oder eine Anwendung |
| Binding | Adresse und Port, auf denen ein Dienst Verbindungen annimmt |

96
VPS/backup.md
View file

@ -1,18 +1,17 @@
# Backup Dokumentation # Backup Dokumentation
## Backup Strategie ## Backup-Strategie
Die VPS wird per restic auf eine Hetzner Storage Box gesichert. Die VPS wird mit restic über SFTP auf eine Hetzner Storage Box gesichert.
Transport: | Eigenschaft | Wert |
|---|---|
- SFTP | Backup-Werkzeug | restic |
| Transport | SFTP |
Backup Tool: | Ziel | Hetzner Storage Box |
| Repository | `backups/vps` |
- restic | Zeitplan | täglich um 02:30 UTC |
| systemd Timer | `restic-backup.timer` |
---
## Gesicherte Verzeichnisse ## Gesicherte Verzeichnisse
@ -23,61 +22,20 @@ Backup Tool:
/etc/letsencrypt /etc/letsencrypt
``` ```
--- `/opt` enthält überwiegend die persistenten Daten und Konfigurationen der Docker-Dienste. Die weiteren Verzeichnisse enthalten WireGuard-, SSH- und Zertifikatskonfigurationen.
## Backup Ziel ## Aufbewahrung
### Hetzner Storage Box
Repository Struktur:
```text
backups/vps
```
---
## Retention Policy
| Typ | Anzahl | | Typ | Anzahl |
|---|---| |---|---|
| Daily | 7 | | Täglich | 7 |
| Weekly | 4 | | Wöchentlich | 4 |
| Monthly | 6 | | Monatlich | 6 |
Zusätzlich: Nicht mehr benötigte Backup-Daten werden regelmäßig mit `prune` bereinigt.
- regelmäßiges prune
---
## Backup Zeitplan
### systemd timer
Nächster Lauf:
- täglich um 02:30 UTC
Timer:
- restic-backup.timer
---
## Ziele der Backupstrategie
- vollständige Wiederherstellbarkeit der VPS
- schnelle Recovery
- Schutz vor Fehlkonfigurationen
- Schutz vor Datenverlust
---
## Wiederherstellungsziele ## Wiederherstellungsziele
Die folgenden Bereiche müssen wiederherstellbar sein:
| Bereich | Wichtigkeit | | Bereich | Wichtigkeit |
|---|---| |---|---|
| Docker Stacks | kritisch | | Docker Stacks | kritisch |
@ -85,22 +43,12 @@ Die folgenden Bereiche müssen wiederherstellbar sein:
| authentik | kritisch | | authentik | kritisch |
| WireGuard | kritisch | | WireGuard | kritisch |
| Zertifikate | kritisch | | Zertifikate | kritisch |
| SSH Zugriff | kritisch | | SSH-Zugriff | kritisch |
--- Ziel ist, die VPS vollständig reproduzierbar und innerhalb kurzer Zeit wiederherstellbar zu machen.
## Verbesserungspotenzial ## Weiterführende Dokumentation
### Noch offen - Automatisierte Wartung: [Wartung und Betrieb](maintenance.md)
- Backup-Überwachung: [Monitoring](monitoring.md)
- Restore-Test dokumentieren - Offene Backup- und Recovery-Arbeiten: [Bekannte Themen und Verbesserungspotenzial](known-issues.md)
- Backup Monitoring ergänzen
- Backup Erfolg automatisch prüfen
- Alerting bei Fehlern
- Dokumentierte Recovery-Anleitung
---
## Langfristiges Ziel
Die VPS soll vollständig reproduzierbar und innerhalb kurzer Zeit wiederherstellbar sein.

146
VPS/docker.md
View file

@ -1,91 +1,42 @@
# Docker Übersicht # Docker Dokumentation
## Docker Netzwerke Docker betreibt den Großteil der Anwendungen der VPS in voneinander getrennten Containern. Die fachliche Aufgabe jedes Dienstes steht unter [Dienste und Anwendungen](services.md).
## Docker-Netzwerke
| Netzwerk | Zweck | | Netzwerk | Zweck |
|---|---| |---|---|
| proxy | Hauptnetzwerk für Reverse Proxy und Dienste | | `proxy` | Gemeinsames Netzwerk für Reverse Proxy und erreichbare Dienste |
| authentik_authentik | internes authentik Netzwerk | | `authentik_authentik` | Internes Netzwerk für authentik-Komponenten |
| nextcloud_internal | internes Nextcloud Netzwerk | | `nextcloud_internal` | Internes Netzwerk für Nextcloud-Komponenten |
| teamspeak_default | isoliertes TeamSpeak Netzwerk | | `teamspeak_default` | Isoliertes Netzwerk für TeamSpeak |
--- Das Hauptnetzwerk `proxy` verwendet das Subnetz `172.20.0.0/16`. Es ermöglicht Nginx Proxy Manager den Zugriff auf die Dienste, die über den Reverse Proxy bereitgestellt werden.
## Hauptnetzwerk „proxy“ ## Container und Netzwerke
### Netzwerk | Container | Technische Rolle | Netzwerk |
- Name: proxy
- Subnetz: 172.20.0.0/16
Das proxy-Netzwerk dient als zentrale Kommunikationsschicht zwischen:
- Nginx Proxy Manager
- öffentlichen Diensten
- internen Reverse-Proxy-Zielen
---
## Container
| Container | Aufgabe | Netzwerk |
|---|---|---| |---|---|---|
| npm | Reverse Proxy | proxy | | npm | Reverse Proxy | `proxy` |
| authentik-server | SSO Frontend | proxy | | authentik-server | SSO-Frontend | `proxy` |
| authentik-worker | Hintergrundprozesse | authentik_authentik | | authentik-worker | Hintergrundprozesse | `authentik_authentik` |
| authentik-postgresql | Datenbank | authentik_authentik | | authentik-postgresql | Datenbank | `authentik_authentik` |
| authentik-redis | Cache | authentik_authentik | | authentik-redis | Cache | `authentik_authentik` |
| nextcloud | Cloud-Plattform | proxy | | nextcloud | Cloud-Anwendung | `proxy` |
| nextcloud-db | MariaDB | nextcloud_internal | | nextcloud-db | Datenbank | `nextcloud_internal` |
| nextcloud-redis | Redis Cache | nextcloud_internal | | nextcloud-redis | Cache | `nextcloud_internal` |
| vaultwarden | Passwortmanager | proxy | | vaultwarden | Passwortmanager | `proxy` |
| forgejo | Git Hosting | proxy | | forgejo | Git-Hosting | `proxy` |
| collabora | Office Integration | proxy | | collabora | Office-Integration | `proxy` |
| uptime-kuma | Verfügbarkeitsmonitoring | proxy | | uptime-kuma | Verfügbarkeitsmonitoring | `proxy` |
| netdata | Monitoring | proxy | | netdata | Systemmonitoring | `proxy` |
| adguardhome | DNS | proxy | | adguardhome | DNS | `proxy` |
| teamspeak | Voice Server | teamspeak_default | | teamspeak | Voice-Server | `teamspeak_default` |
| site | Statische Webseite | proxy | | site | Statische Webseite | `proxy` |
--- ## Persistente Daten
## Öffentlich erreichbare Ports Die Dienstverzeichnisse liegen überwiegend unter `/opt`. Jeder Dienst besitzt ein eigenes Verzeichnis, beispielsweise:
| Port | Dienst |
|---|---|
| 80 | NPM HTTP |
| 443 | NPM HTTPS |
| 9000 | authentik |
| 3000 | Forgejo |
| 2222 | Forgejo SSH |
| 9987/UDP | TeamSpeak |
| 10011 | TeamSpeak ServerQuery |
| 30033 | TeamSpeak Dateitransfer |
| 51820/UDP | WireGuard |
---
## Localhost-only Bindings
| Port | Dienst |
|---|---|
| 81 | NPM Admin |
| 3001 | Uptime Kuma |
| 3002 | AdGuard UI |
---
## Docker Speicherstruktur
### Basisverzeichnis
```text
/opt/
```
Jeder Dienst besitzt aktuell ein eigenes Verzeichnis.
Beispiele:
```text ```text
/opt/authentik /opt/authentik
@ -93,39 +44,10 @@ Beispiele:
/opt/npm /opt/npm
``` ```
--- Die VPS verwendet überwiegend Bind Mounts und lokale persistente Verzeichnisse statt benannter Docker-Volumes. Dadurch sind Datenablage, Backup und Migration leichter nachvollziehbar.
## Persistenzstrategie ## Weiterführende Dokumentation
Die VPS nutzt überwiegend: - Öffentliche Ports und lokale Bindings: [Sicherheit](security.md)
- Gesicherte Verzeichnisse: [Backup](backup.md)
- Bind Mounts - Offene Docker-Arbeiten: [Bekannte Themen und Verbesserungspotenzial](known-issues.md)
- lokale persistente Verzeichnisse
anstatt vieler benannter Docker-Volumes.
Vorteile:
- einfachere Backups
- einfachere Migration
- einfachere Wiederherstellung
- bessere Übersichtlichkeit
---
## Aktuelle Beobachtungen
### Positiv
- saubere Trennung der Dienste
- wenige Netzwerke
- kaum Docker-Müll
- minimale Anzahl ungenutzter Volumes
- strukturierter Aufbau
### Verbesserungspotenzial
- unnötige öffentliche Portfreigaben reduzieren
- Compose-Strukturen vereinheitlichen
- Labels und Restart Policies standardisieren
- Netzwerk-Namenskonventionen vereinheitlichen

73
VPS/known-issues.md
View file

@ -1,47 +1,46 @@
# Bekannte Themen / Verbesserungspotenzial # Bekannte Themen und Verbesserungspotenzial
## Security Diese Datei bündelt offene Arbeiten, damit sie nicht zusätzlich in den einzelnen Fachkapiteln gepflegt werden müssen.
- authentik aktuell direkt öffentlich erreichbar ## Hohe Priorität
- Forgejo öffentlich exposed
- öffentliche Ports teilweise historisch gewachsen
--- - direkten öffentlichen Zugriff auf authentik entfernen
- öffentliche Erreichbarkeit von Forgejo prüfen
- historisch gewachsene öffentliche Ports prüfen und reduzieren
- Restore-Prozess dokumentieren und regelmäßig testen
- Backup-Erfolg automatisch prüfen und Fehler melden
## Mittlere Priorität
- zentrale Loggingstrategie festlegen
- Compose-Dateien und Verzeichnisstrukturen vereinheitlichen
- Labels und Restart Policies standardisieren
- Docker-Netzwerk-Namenskonventionen vereinheitlichen
- automatisches Docker- und Journal-Cleanup planen
- Rolle von AdGuard Home auf der VPS bewerten
## Monitoring und Alerting
- zentrales Alerting einrichten
- Sicherheitsbenachrichtigungen automatisieren
- Backup-Fehler überwachen
- Zertifikatswarnungen einrichten
- WireGuard-Tunnel und VPN-Verfügbarkeit überwachen
- Docker Health Alerts einrichten
- Health Reports automatisieren
- Matrix als Benachrichtigungskanal prüfen
## Dokumentation ## Dokumentation
- WireGuard Peers noch nicht vollständig benannt - WireGuard-Peers vollständig Geräten und Zwecken zuordnen
- Domains/Subdomains noch nicht dokumentiert - Domains und Subdomains dokumentieren
- Compose Standards noch nicht vereinheitlicht - Recovery-Anleitung erstellen
- Zielwerte für Wiederherstellungszeit und maximalen Datenverlust festlegen
---
## Monitoring
- kein zentrales Alerting
- Backup Monitoring fehlt
- VPN Monitoring ausbaufähig
---
## Docker
- Compose-Dateien unterschiedlich aufgebaut
- Netzwerk-Namenskonventionen uneinheitlich
- Logging noch nicht standardisiert
---
## Backups
- Restore-Prozess noch nicht dokumentiert
- kein regelmäßiger Restore-Test
---
## Langfristige Themen ## Langfristige Themen
- Matrix Server - Matrix-Server
- zentrale Benachrichtigungen - vollständige Infrastructure-as-Code-Struktur
- vollständige Infrastructure-as-Code Struktur
- automatische Inventarisierung - automatische Inventarisierung
- reproduzierbare Konfiguration
- optionales, sicher geschütztes QR-Code-Archiv für WireGuard-Clients

63
VPS/maintenance.md
View file

@ -1,66 +1,45 @@
# Wartung und Betrieb # Wartung und Betrieb
## Regelmäßige Aufgaben ## Vorgesehene manuelle Aufgaben
Diese Checkliste beschreibt die vorgesehenen Prüfungen. Nicht alle Aufgaben sind bereits als regelmäßig durchgeführter Prozess bestätigt.
### Täglich ### Täglich
- Monitoring prüfen - Monitoring prüfen
- Uptime Kuma Alerts prüfen - Uptime-Kuma-Alerts prüfen
- CrowdSec Events prüfen - CrowdSec-Ereignisse prüfen
---
### Wöchentlich ### Wöchentlich
- Docker Container Status prüfen - Status der Docker-Container prüfen
- verfügbare Updates prüfen - verfügbare Updates prüfen
- Backup Logs prüfen - Backup-Logs prüfen
- freien Speicherplatz prüfen - freien Speicherplatz prüfen
---
### Monatlich ### Monatlich
- Restore-Prozess testen - Restore-Prozess testen
- ungenutzte Docker Images entfernen - ungenutzte Docker-Images entfernen
- Logs prüfen - Logs prüfen
- Sicherheitsreview durchführen - Sicherheitsreview durchführen
---
## Automatische Wartung ## Automatische Wartung
### Bereits vorhanden | Timer oder Funktion | Aufgabe | Status |
|---|---|---|
| `apt-daily.timer` | Paketupdates | aktiv |
| `apt-daily-upgrade.timer` | Sicherheitsupdates | aktiv |
| `restic-backup.timer` | Backups | aktiv |
| `logrotate.timer` | Logrotation | aktiv |
| `crowdsec-hub-update.timer` | CrowdSec-Updates | aktiv |
| Funktion | Status | ## Ziel
|---|---|
| apt Updates | aktiv |
| Security Updates | aktiv |
| restic Backup | aktiv |
| logrotate | aktiv |
| CrowdSec Updates | aktiv |
--- Der Betrieb soll möglichst wartungsarm, stabil, nachvollziehbar und automatisiert sein.
## Geplante Automatisierung ## Weiterführende Dokumentation
| Funktion | Status | - Überwachung: [Monitoring](monitoring.md)
|---|---| - Backup-Konfiguration: [Backup](backup.md)
| Docker Cleanup | geplant | - Geplante Automatisierungen und offene Arbeiten: [Bekannte Themen und Verbesserungspotenzial](known-issues.md)
| Journal Cleanup | geplant |
| Backup Validation | geplant |
| Health Reports | geplant |
| Matrix Alerts | geplant |
---
## Wartungsziele
Die VPS soll möglichst:
- wartungsarm
- stabil
- nachvollziehbar
- automatisiert
betrieben werden.

124
VPS/monitoring.md
View file

@ -1,128 +1,30 @@
# Monitoring Dokumentation # Monitoring Dokumentation
## Monitoring Stack Monitoring soll Probleme frühzeitig erkennen und sichtbar machen. Die VPS verwendet dafür mehrere Systeme mit unterschiedlichen Aufgaben.
Die VPS nutzt aktuell mehrere Monitoring-Lösungen mit unterschiedlichen Aufgabenbereichen.
---
## Verwendete Systeme ## Verwendete Systeme
| Dienst | Aufgabe | | System | Aufgabe |
|---|---| |---|---|
| Netdata | Live-Systemmonitoring | | Netdata | Live-Überwachung des Servers und der Container |
| Uptime Kuma | Verfügbarkeitsmonitoring | | Uptime Kuma | Prüfung der externen Erreichbarkeit |
| CrowdSec | Sicherheitsmonitoring | | CrowdSec | Erkennung sicherheitsrelevanter Ereignisse |
| Ubuntu Timer | Wartung / Updates | | systemd Timer | Automatisierte Ausführung geplanter Aufgaben |
---
## Netdata ## Netdata
### Aufgabe Netdata überwacht CPU, RAM, Prozesse, Netzwerk, Docker, Festplatten und weitere Systemmetriken. Netdata läuft im Container `netdata`.
Netdata überwacht:
- CPU
- RAM
- Prozesse
- Netzwerk
- Docker
- Festplatten
- Systemmetriken
Container:
- netdata
---
## Uptime Kuma ## Uptime Kuma
### Aufgabe Uptime Kuma prüft externe Erreichbarkeit, HTTPS, Zertifikate, Dienste und Domains. Details zur lokalen Erreichbarkeit stehen unter [Sicherheit](security.md).
Uptime Kuma überwacht:
- externe Erreichbarkeit
- HTTPS Checks
- Zertifikate
- Dienste
- Domains
Container:
- uptime-kuma
Localhost Binding:
```text
127.0.0.1:3001
```
---
## CrowdSec ## CrowdSec
### Aufgabe CrowdSec überwacht unter anderem Loginversuche, Angriffe und bekannte schädliche IP-Adressen. Es ist mit nftables, Docker und dem Reverse Proxy integriert.
CrowdSec überwacht: ## Weiterführende Dokumentation
- Loginversuche - Sicherheitsarchitektur: [Sicherheit](security.md)
- Angriffe - Aktive Wartungstimer: [Wartung und Betrieb](maintenance.md)
- bekannte Bad IPs - Offene Monitoring- und Alerting-Arbeiten: [Bekannte Themen und Verbesserungspotenzial](known-issues.md)
Integration:
- nftables
- Docker
- Reverse Proxy
---
## Systemd Timer
### Aktive Wartungstimer
| Timer | Aufgabe |
|---|---|
| apt-daily.timer | Paketupdates |
| apt-daily-upgrade.timer | Sicherheitsupdates |
| restic-backup.timer | Backups |
| logrotate.timer | Logrotation |
| crowdsec-hub-update.timer | CrowdSec Updates |
---
## Aktuelle Beobachtungen
### Positiv
- mehrere Monitoring-Ebenen vorhanden
- Backups automatisiert
- CrowdSec integriert
- geringe Systemlast
- ausreichende Leistungsreserven
---
## Verbesserungspotenzial
### Noch offen
- zentrales Alerting
- Matrix Integration
- Backup Fehler Monitoring
- Zertifikatswarnungen
- VPN Health Checks
- Docker Health Alerts
---
## Langfristiges Ziel
Das Monitoring soll:
- frühzeitig Probleme erkennen
- automatisch benachrichtigen
- Fehlkonfigurationen sichtbar machen
- möglichst wartungsarm funktionieren

111
VPS/networking.md
View file

@ -2,101 +2,36 @@
## Öffentliches Netzwerk ## Öffentliches Netzwerk
| Interface | Adresse | | Interface | Adresse | Zweck |
|---|---| |---|---|---|
| eth0 | 46.225.176.170 | | `eth0` | `46.225.176.170` | Öffentliche Erreichbarkeit der VPS |
--- ## Netzwerkrollen
## VPN Die VPS verbindet drei Bereiche:
### WireGuard
Die VPS dient als zentraler WireGuard-Hub zwischen:
- VPS
- Heimnetz
- zusätzlichen Clients
Interface:
- wg0
Listening Port:
- 51820/UDP
---
## Heimnetz Routing
Folgende Route wird aktuell über WireGuard bereitgestellt:
```text ```text
192.168.0.0/24 Internet
↓ eth0
VPS
├── öffentliche Dienste
├── lokale Dienste
└── Docker-Netzwerke
↓ wg0
Heimnetz 192.168.0.0/24
``` ```
Dadurch kann die VPS interne Dienste im Heimnetz sicher über VPN erreichen. - `eth0` verbindet die VPS mit dem Internet.
- `wg0` verbindet die VPS über WireGuard mit dem Heimnetz und weiteren Clients.
- Docker-Netzwerke trennen und verbinden die einzelnen Container.
--- ## Heimnetz-Routing
## Firewall / Paketfilterung Die Route `192.168.0.0/24` wird über den Heimnetz-Peer von WireGuard bereitgestellt. Dadurch kann die VPS interne Dienste im Heimnetz erreichen, ohne diese direkt im Internet freizugeben.
### Aktueller Zustand ## Weiterführende Dokumentation
UFW ist nicht aktiv. - WireGuard-Netz und Peers: [WireGuard](wireguard.md)
- Docker-Netzwerke: [Docker](docker.md)
Stattdessen nutzt die VPS: - Firewall und erreichbare Ports: [Sicherheit](security.md)
- Offene Netzwerk-Arbeiten: [Bekannte Themen und Verbesserungspotenzial](known-issues.md)
- nftables
- Docker-verwaltete Firewallregeln
- CrowdSec Integration
---
## Sicherheitslayer
| Layer | Aufgabe |
|---|---|
| Docker nftables Regeln | Container-Isolation |
| CrowdSec | Dynamische Blockierung |
| WireGuard | Sicherer privater Zugriff |
| NPM | TLS Terminierung |
---
## Docker Netzwerkarchitektur
### proxy Netzwerk
Subnetz:
```text
172.20.0.0/16
```
Wichtige Dienste:
- NPM
- authentik
- Nextcloud
- Vaultwarden
- Forgejo
- Monitoring-Dienste
---
## Aktuelle Sicherheitsbeobachtungen
### Positiv
- interne Docker-Segmentierung vorhanden
- RAW nftables Isolationsregeln aktiv
- Localhost Bindings bereits genutzt
- CrowdSec in INPUT Chain integriert
### Mögliche Verbesserungen
- direkten öffentlichen Zugriff auf authentik entfernen
- öffentliche Erreichbarkeit von Forgejo prüfen
- Rolle von AdGuard auf der VPS bewerten

75
VPS/overview.md
View file

@ -13,69 +13,30 @@
| Hauptbenutzer | mbyte | | Hauptbenutzer | mbyte |
| Container Runtime | Docker | | Container Runtime | Docker |
---
## Aufgabe der VPS ## Aufgabe der VPS
Die VPS dient als öffentliche Edge-Infrastruktur des Homelabs. Die VPS ist der öffentlich erreichbare Einstiegspunkt des Homelabs. Sie nimmt Verbindungen aus dem Internet an, schützt und authentifiziert Zugriffe und leitet Anfragen an öffentliche oder über VPN erreichbare interne Dienste weiter.
Hauptaufgaben: Die fachlichen Aufgaben der Anwendungen stehen unter [Dienste](services.md). Der technische Containerbetrieb ist unter [Docker](docker.md) beschrieben.
- Öffentlicher Reverse Proxy ## Architekturrolle
- Authentifizierung / SSO
- VPN-Gateway
- Sicherheitslayer
- Öffentlicher Einstiegspunkt für interne Dienste
- Externes Monitoring
---
## Hauptdienste
| Dienst | Aufgabe |
|---|---|
| Nginx Proxy Manager | Reverse Proxy und TLS |
| authentik | SSO / Identity Provider |
| CrowdSec | Intrusion Prevention |
| WireGuard | VPN-Tunnel ins Heimnetz |
| Nextcloud | Cloud / Kollaboration |
| Vaultwarden | Passwortmanager |
| Forgejo | Git Hosting |
| Uptime Kuma | Verfügbarkeitsmonitoring |
| Netdata | Systemmonitoring |
| AdGuard Home | DNS-Dienst |
| Collabora | Office-Integration |
| TeamSpeak | Voice-Server |
---
## Infrastruktur-Architektur
```text ```text
Internet Internet
↓ ↓
VPS VPS (öffentlicher Einstiegspunkt, Authentifizierung und Schutz)
├── Nginx Proxy Manager ↓ WireGuard VPN
├── authentik Heimnetz und Unraid (private Infrastruktur und Daten)
├── CrowdSec
├── WireGuard
├── Öffentliche Dienste
└── Monitoring
↓ VPN
Heimnetz
├── Unraid
├── internes NPM
├── Home Assistant
├── Seafile
├── Immich
└── interne Dienste
``` ```
--- - Nginx Proxy Manager nimmt Webanfragen entgegen und stellt HTTPS bereit.
- authentik stellt die zentrale Anmeldung bereit.
- CrowdSec und nftables schützen den öffentlich erreichbaren Server.
- WireGuard verbindet die VPS verschlüsselt mit dem Heimnetz.
## Ressourcenverbrauch ## Ressourcenverbrauch
### Aktueller Status (2026-05-26) Stand: 2026-05-26
| Ressource | Nutzung | | Ressource | Nutzung |
|---|---| |---|---|
@ -86,18 +47,6 @@ Heimnetz
Die VPS besitzt aktuell deutliche Leistungsreserven. Die VPS besitzt aktuell deutliche Leistungsreserven.
---
## Zielbild ## Zielbild
Die VPS soll langfristig: Die VPS soll langfristig stabil, wartungsarm, sicher, vollständig überwacht und innerhalb kurzer Zeit wiederherstellbar sein.
- stabil
- selbstwartend
- dokumentiert
- leicht wiederherstellbar
- sicher
- wartungsarm
- vollständig überwacht
sein.

110
VPS/security.md
View file

@ -1,109 +1,49 @@
# Sicherheitsdokumentation # Sicherheitsdokumentation
## Sicherheitsarchitektur ## Sicherheitsprinzip
Die VPS nutzt mehrere Sicherheitslayer. Die VPS ist öffentlich erreichbar und verwendet mehrere Schutzebenen. Nginx Proxy Manager nimmt Webverbindungen an, authentik schützt geeignete Dienste durch zentrale Anmeldung, nftables filtert Netzwerkverkehr und CrowdSec blockiert erkannte Angreifer dynamisch.
---
## Sicherheitskomponenten ## Sicherheitskomponenten
| Komponente | Aufgabe | | Komponente | Aufgabe |
|---|---| |---|---|
| CrowdSec | Dynamische Angriffsblockierung | | nftables | Paketfilterung auf dem Host |
| nftables | Paketfilterung | | Docker-Netzwerkisolierung | Trennung der Container-Netzwerke |
| Docker Netzwerkisolierung | Segmentierung | | CrowdSec | Erkennung und dynamische Blockierung von Angriffen |
| WireGuard | Sicherer Fernzugriff | | WireGuard | Verschlüsselter privater Zugriff |
| Nginx Proxy Manager | TLS Terminierung | | Nginx Proxy Manager | Reverse Proxy und TLS-Terminierung |
| authentik | Zentrale Authentifizierung | | authentik | Zentrale Authentifizierung |
--- ## Firewall und Isolation
## Firewall UFW ist deaktiviert. Die VPS verwendet stattdessen nftables, Docker-verwaltete Firewallregeln und die CrowdSec-Integration.
### Aktueller Zustand Die Docker-Netzwerke sind durch RAW-Regeln, Netzwerkisolation und interface-basierte Filterung segmentiert. CrowdSec ist in die INPUT Chain integriert.
UFW ist deaktiviert.
Die VPS nutzt stattdessen:
- nftables
- Docker-verwaltete Regeln
- CrowdSec Integration
---
## Docker Isolation
Die Docker-Netzwerke sind durch nftables-Regeln segmentiert.
Vorhanden:
- RAW Regeln
- Netzwerkisolation
- Interface-basierte Filterung
---
## Öffentlich erreichbare Dienste ## Öffentlich erreichbare Dienste
| Dienst | Port | | Dienst | Port |
|---|---| |---|---|
| NPM | 80 / 443 | | Nginx Proxy Manager | `80/tcp`, `443/tcp` |
| Forgejo | 3000 | | Forgejo | `3000/tcp` |
| Forgejo SSH | 2222 | | Forgejo SSH | `2222/tcp` |
| authentik | 9000 | | authentik | `9000/tcp` |
| TeamSpeak | 9987 / 10011 / 30033 | | TeamSpeak | `9987/udp`, `10011/tcp`, `30033/tcp` |
| WireGuard | 51820 | | WireGuard | `51820/udp` |
--- ## Nur lokal erreichbare Dienste
## Lokale Bindings Bindings auf `127.0.0.1` nehmen nur Verbindungen vom Server selbst an und sind nicht direkt aus dem Internet erreichbar.
Folgende Dienste sind nur lokal erreichbar:
| Dienst | Binding | | Dienst | Binding |
|---|---| |---|---|
| NPM Admin | 127.0.0.1:81 | | NPM Admin | `127.0.0.1:81` |
| Uptime Kuma | 127.0.0.1:3001 | | Uptime Kuma | `127.0.0.1:3001` |
| AdGuard UI | 127.0.0.1:3002 | | AdGuard UI | `127.0.0.1:3002` |
--- ## Weiterführende Dokumentation
## Sicherheitsbeobachtungen - Netzwerkrollen und Routing: [Netzwerk](networking.md)
- WireGuard-Konfiguration: [WireGuard](wireguard.md)
### Positiv - Offene Sicherheitsarbeiten: [Bekannte Themen und Verbesserungspotenzial](known-issues.md)
- CrowdSec aktiv
- Docker Netzwerksegmentierung
- Localhost Bindings vorhanden
- VPN sauber getrennt
- geringe Angriffsfläche des Hosts
---
## Verbesserungspotenzial
### Hohe Priorität
- authentik nicht direkt öffentlich exposen
- Forgejo Exposure prüfen
- öffentliche Ports reduzieren
---
### Mittlere Priorität
- Compose Standards vereinheitlichen
- zentrale Loggingstrategie
- automatische Sicherheitsbenachrichtigungen
---
## Langfristige Ziele
- minimale Angriffsfläche
- vollständig dokumentierte Infrastruktur
- automatisierte Sicherheitsüberwachung
- reproduzierbare Konfiguration
- wartungsarme Architektur

71
VPS/services.md
View file

@ -1,53 +1,38 @@
# Dienste Übersicht # Dienste und Anwendungen
## Reverse Proxy Diese Übersicht beschreibt den fachlichen Zweck der Dienste. Technische Details zu Containern und Netzwerken stehen unter [Docker](docker.md).
| Dienst | Beschreibung | ## Zugriff und Sicherheit
| Dienst | Aufgabe |
|---|---| |---|---|
| Nginx Proxy Manager | Öffentlicher Reverse Proxy | | Nginx Proxy Manager | Öffentlicher Reverse Proxy und TLS-Terminierung |
| authentik | Zentrale Authentifizierung | | authentik | Zentrale Authentifizierung und SSO |
| CrowdSec | Erkennung und dynamische Blockierung von Angriffen |
| WireGuard | Verschlüsselte Verbindung zwischen VPS, Heimnetz und Clients |
--- ## Cloud, Produktivität und Verwaltung
## Cloud / Produktivität | Dienst | Aufgabe |
| Dienst | Beschreibung |
|---|---| |---|---|
| Nextcloud | Cloud Plattform | | Nextcloud | Cloud-Plattform und Zusammenarbeit |
| Collabora | Office Integration | | Collabora | Office-Integration für Nextcloud |
| Vaultwarden | Passwortmanager | | Vaultwarden | Passwortmanager |
| Forgejo | Git-Hosting |
| AdGuard Home | DNS-Dienst |
| Site | Statische Webseite |
--- ## Monitoring und Kommunikation
## Infrastruktur | Dienst | Aufgabe |
| Dienst | Beschreibung |
|---|---| |---|---|
| WireGuard | VPN | | Netdata | Live-Systemmonitoring |
| CrowdSec | Angriffsschutz | | Uptime Kuma | Überwachung der Erreichbarkeit |
| AdGuard Home | DNS | | TeamSpeak | Voice-Server |
| Forgejo | Git Hosting |
--- ## SSO-Status
## Monitoring Die Tabelle enthält auch Dienste, die über die VPS erreichbar sind, aber nicht zwingend direkt auf ihr laufen.
| Dienst | Beschreibung |
|---|---|
| Netdata | Live Monitoring |
| Uptime Kuma | Uptime Monitoring |
---
## Kommunikation
| Dienst | Beschreibung |
|---|---|
| TeamSpeak | Voice Server |
---
## SSO Status
| Dienst | SSO | | Dienst | SSO |
|---|---| |---|---|
@ -57,8 +42,6 @@
| Forgejo | geplant | | Forgejo | geplant |
| Matrix | geplant | | Matrix | geplant |
---
## Bekannte Abhängigkeiten ## Bekannte Abhängigkeiten
| Dienst | Abhängigkeit | | Dienst | Abhängigkeit |
@ -68,4 +51,10 @@
| authentik | PostgreSQL | | authentik | PostgreSQL |
| authentik | Redis | | authentik | Redis |
| Collabora | Nextcloud | | Collabora | Nextcloud |
| NPM | proxy Netzwerk | | Nginx Proxy Manager | Docker-Netzwerk `proxy` |
## Weiterführende Dokumentation
- Container und Docker-Netzwerke: [Docker](docker.md)
- Öffentliche Erreichbarkeit: [Sicherheit](security.md)
- Überwachung: [Monitoring](monitoring.md)

107
VPS/wireguard.md
View file

@ -1,96 +1,35 @@
# WireGuard Dokumentation # WireGuard Dokumentation
## Allgemein WireGuard stellt verschlüsselte Netzwerkverbindungen zwischen der VPS, dem Heimnetz, mobilen Clients und weiteren Geräten bereit. Die VPS arbeitet dabei als zentraler Hub.
Die VPS dient als zentraler WireGuard-Hub zwischen: ## Konfiguration
- VPS | Eigenschaft | Wert |
- Heimnetz |---|---|
- mobilen Clients | Interface | `wg0` |
- zusätzlichen Geräten | Listening Port | `51820/UDP` |
| VPN-Subnetz | `10.100.0.0/24` |
| Geroutetes Heimnetz | `192.168.0.0/24` |
Interface: Der Heimnetz-Peer stellt der VPS die Route zum privaten Heimnetz bereit. Die einzelnen Clients erhalten jeweils eine eigene `/32`-Adresse, damit ihre Zuordnung eindeutig bleibt.
- wg0
Listening Port:
- 51820/UDP
---
## VPN Netzwerk
### WireGuard Subnetz
```text
10.100.0.0/24
```
---
## Heimnetz Routing
Folgende Route wird über den Heimnetz-Peer bereitgestellt:
```text
192.168.0.0/24
```
Dadurch kann die VPS interne Dienste zuhause sicher erreichen.
---
## Aktuelle Peers ## Aktuelle Peers
| Peer | Allowed IPs | Beschreibung | | VPN-IP | Allowed IPs | Beschreibung |
|---|---|---| |---|---|---|
| 10.100.0.4 | 10.100.0.4/32 | Client | | `10.100.0.2` | `10.100.0.2/32` | Client |
| 10.100.0.6 | 10.100.0.6/32 | Client | | `10.100.0.3` | `10.100.0.3/32` | Client |
| 10.100.0.55 | 10.100.0.55/32 | Client | | `10.100.0.4` | `10.100.0.4/32` | Client |
| 10.100.0.2 | 10.100.0.2/32 | Client | | `10.100.0.5` | `10.100.0.5/32` | Client |
| 10.100.0.3 | 10.100.0.3/32 | Client | | `10.100.0.6` | `10.100.0.6/32` | Client |
| 10.100.0.5 | 10.100.0.5/32 | Client | | `10.100.0.7` | `10.100.0.7/32` | Client |
| 10.100.0.10 | 10.100.0.10/32 + 192.168.0.0/24 | Heimnetz Gateway | | `10.100.0.10` | `10.100.0.10/32`, `192.168.0.0/24` | Heimnetz-Gateway |
| 10.100.0.7 | 10.100.0.7/32 | Client | | `10.100.0.55` | `10.100.0.55/32` | Client |
--- Keepalive ist für die Verbindung konfiguriert. Aktuell sind keine offensichtlichen Routing-Konflikte dokumentiert.
## Beobachtungen ## Weiterführende Dokumentation
### Positiv - Netzwerkrolle und Routing: [Netzwerk](networking.md)
- Backup der WireGuard-Konfiguration: [Backup](backup.md)
- Saubere /32 Zuordnung pro Client - Offene Peer- und Monitoring-Arbeiten: [Bekannte Themen und Verbesserungspotenzial](known-issues.md)
- Heimnetz sauber über separaten Peer geroutet
- Keine offensichtlichen Routing-Konflikte
- Keepalive sauber konfiguriert
---
## Verbesserungspotenzial
### Dokumentation ergänzen
Aktuell fehlen:
- Gerätenamen
- Zuordnung der Peers
- Zweck einzelner Clients
Empfehlung:
| VPN IP | Gerät | Zweck |
|---|---|---|
| 10.100.0.x | MacBook | Mobiler Zugriff |
| 10.100.0.x | Unraid | Heimnetz Gateway |
| ... | ... | ... |
---
## Langfristige Ziele
- Vollständige Peer-Dokumentation
- Backup der WireGuard-Konfiguration
- Monitoring des VPN-Tunnels
- Alerting bei Tunnel-Ausfall
- Optional QR-Code Archivierung