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
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)
- [Dienste und Anwendungen](services.md)
- [Bekannte Themen und Verbesserungspotenzial](known-issues.md)
1. Die [Übersicht](overview.md) erklärt die Rolle des Servers im Homelab.
2. [Dienste und Anwendungen](services.md) zeigt, welche Funktionen der Server bereitstellt.
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
- [Hardware](hardware.md)
- [Speicher, Array und Pools](storage.md)
- [Storage, Array und Cache](storage.md)
- [Shares und Datenablage](shares.md)
- [Netzwerk](networking.md)
- [Docker](docker.md)
@ -24,3 +26,14 @@ Diese Dokumentation beschreibt Aufbau, Dienste und Betrieb des Unraid-Servers.
- [Backup](backup.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-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
Noch zu dokumentieren.
## Restore-Tests
Noch zu dokumentieren.
- Vorhandene Datenbereiche: [Shares und Datenablage](shares.md)
- Physischer Speicher und Parität: [Storage](storage.md)
- Noch offene Arbeiten: [Bekannte Themen und Verbesserungspotenzial](known-issues.md)

135
Unraid/docker.md
View file

@ -1,124 +1,59 @@
# 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
- Medienserver
- Dokumentenmanagement
- Smart Home Komponenten
- interne Anwendungen
---
| Dienst | Status |
|---|---|
| AdGuard Home | aktiv |
| Immich | aktiv |
| MariaDB | aktiv |
| Netdata | aktiv |
| NPM | aktiv |
| Paperless-ngx | aktiv |
| PhotoPrism | aktiv |
| Plex | aktiv |
| Redis | aktiv |
| Scrypted | aktiv |
| Seafile | gestoppt |
| Wiki.js | aktiv |
## Netzwerkmodi
Verwendete Modi:
Die Container verwenden aktuell unterschiedliche Netzwerkmodi:
- bridge
- 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 |
| Modus | Einordnung |
|---|---|
| Sonarr | Serienverwaltung |
| Radarr | Filmverwaltung |
| Lidarr | Musikverwaltung |
| Seerr | Request Management |
| SABnzbd | Downloads |
| bridge | Container nutzt ein von Docker verwaltetes Netzwerk |
| host | Container verwendet direkt das Netzwerk des Unraid-Servers |
| br0 | Container erhält Zugang zum physischen Netzwerk über eine Bridge |
| Compose-Netzwerk | Netzwerk wird gemeinsam mit einem Compose Stack definiert |
---
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 |
|---|---|
| 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
- Compose-basierte Containerverwaltung
## Gestoppte oder möglicherweise ungenutzte Container
Dies ermöglicht:
- 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 |
| Container | Aktueller oder vermuteter Status |
|---|---|
| Seafile | Wartung/Migration |
| Recyclarr | ungenutzt |
| Whisparr | ungenutzt |
| Seafile | Wartung oder Migration |
| Recyclarr | vermutlich ungenutzt |
| Whisparr | vermutlich ungenutzt |
| 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
- 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
Die offenen Docker-Themen werden zentral unter [Bekannte Themen und Verbesserungspotenzial](known-issues.md) gepflegt.

12
Unraid/hardware.md
View file

@ -1,14 +1,8 @@
# 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
Noch zu dokumentieren.
## Erweiterungen
Noch zu dokumentieren.
Details zum Aufbau der Speicherbereiche stehen unter [Storage](storage.md). Offene Dokumentationsarbeiten werden zentral unter [Bekannte Themen und Verbesserungspotenzial](known-issues.md) gepflegt.

36
Unraid/known-issues.md
View file

@ -1,22 +1,36 @@
# 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
Noch zu dokumentieren.
- Hardware und Datenträgerzuordnung erfassen
- Dateisysteme 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
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
## 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
Noch zu dokumentieren.
## Fehlerbehebung
Noch zu dokumentieren.
Die konkreten Zeitpläne, Prüfschritte und Verantwortlichkeiten müssen noch festgelegt werden. Offene Arbeiten stehen unter [Bekannte Themen und Verbesserungspotenzial](known-issues.md).

18
Unraid/monitoring.md
View file

@ -1,18 +1,10 @@
# Monitoring Dokumentation
## Systemmonitoring
## Aktueller Stand
Noch zu dokumentieren.
Netdata läuft als aktiver Docker-Container und dient der Überwachung des Unraid-Servers.
## Speicherüberwachung
Noch zu dokumentieren.
## Dienstüberwachung
Noch zu dokumentieren.
## Alerting
Noch zu dokumentieren.
## Weiterführende Dokumentation
- 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
## 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 |
| 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.
Hauptaufgaben:
- Dateispeicher
- Docker Hosting
- Medienserver
- Dokumentenmanagement
- Smart Home Infrastruktur
- Kamera-Integration
- Backup-Ziel
- interne Dienste
- private Cloud-Dienste
---
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.
## Architekturrolle
Die Infrastruktur ist logisch getrennt:
Die öffentlich erreichbare VPS und der private Unraid-Server erfüllen unterschiedliche Aufgaben:
```text
Internet
↓
VPS (Public Edge)
VPS (öffentlicher Einstiegspunkt)
↓ WireGuard VPN
Unraid (Private Infrastruktur)
Unraid (private Infrastruktur und Daten)
```
Der Unraid-Server hostet überwiegend:
- interne Dienste
- 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 |
---
- Die VPS stellt die öffentliche Edge-Infrastruktur bereit.
- WireGuard verbindet VPS und Heimnetz über einen verschlüsselten VPN-Tunnel.
- Unraid betreibt interne Dienste und hält private Daten zentral vor.
## Infrastrukturprinzipien
### Aktuelle Architektur
- VPS als öffentliche Edge
- Unraid als privater Kern
- Reverse Proxy Trennung
- VPN-basierte Kopplung
- Docker-basierte Dienste
- zentrale Datenhaltung
---
- öffentliche und private Infrastruktur sind getrennt
- die Kopplung mit der VPS erfolgt über VPN
- Anwendungen werden überwiegend als Docker-Container betrieben
- Daten werden zentral über Array, Cache und Shares organisiert
## Zielbild
Der Unraid-Server soll langfristig:
- wartungsarm
- dokumentiert
- leicht wiederherstellbar
- energieeffizient
- zentralisiert
- sicher
betrieben werden.
Der Unraid-Server soll langfristig wartungsarm, dokumentiert, leicht wiederherstellbar, energieeffizient und sicher betrieben werden.

19
Unraid/security.md
View file

@ -1,18 +1,19 @@
# 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
Noch zu dokumentieren.
Offene Prüfungen und Dokumentationsarbeiten werden zentral unter [Bekannte Themen und Verbesserungspotenzial](known-issues.md) gepflegt.

42
Unraid/services.md
View file

@ -1,14 +1,46 @@
# 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
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
## 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
## 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
- SSD Cache
- zentrale User Shares
---
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.
## 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 |
|---|---|
@ -21,105 +17,16 @@ Der Unraid-Server nutzt:
| Parity | aktiv |
| Zustand | valid |
---
## SSD Cache Pool
## Cache
### SSD Cache Pool
Der Cache Pool stellt schnelleren SSD-Speicher bereit. Er wird unter anderem für Containerdaten, Systemdaten, temporäre Daten und schnelle Schreibvorgänge verwendet.
| Eigenschaft | Wert |
|---|---|
| Größe | ~250 GB |
| Nutzung | ~48 GB |
Der Cache dient für:
## Weiterführende Dokumentation
- Appdata
- Docker Daten
- 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
- Datenfreigaben und Cache-Zuordnung: [Shares und Datenablage](shares.md)
- Offene Storage-Arbeiten: [Bekannte Themen und Verbesserungspotenzial](known-issues.md)

16
Unraid/virtual-machines.md
View file

@ -1,18 +1,8 @@
# 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
Noch zu dokumentieren.
## Passthrough
Noch zu dokumentieren.
## Speicher und Backups
Noch zu dokumentieren.
Die Einordnung des Shares steht unter [Shares und Datenablage](shares.md).

24
VPS/README.md
View file

@ -1,12 +1,14 @@
# 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)
- [Dienste](services.md)
- [Bekannte Themen und Verbesserungspotenzial](known-issues.md)
1. Die [Übersicht](overview.md) erklärt die Rolle der VPS im Homelab.
2. [Dienste](services.md) zeigt, welche Funktionen die VPS bereitstellt.
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
@ -21,3 +23,15 @@ Die VPS dient als öffentliche Edge-Infrastruktur des Homelabs. Die Dokumentatio
- [Backup](backup.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 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:
- SFTP
Backup Tool:
- restic
---
| Eigenschaft | Wert |
|---|---|
| Backup-Werkzeug | restic |
| Transport | SFTP |
| Ziel | Hetzner Storage Box |
| Repository | `backups/vps` |
| Zeitplan | täglich um 02:30 UTC |
| systemd Timer | `restic-backup.timer` |
## Gesicherte Verzeichnisse
@ -23,61 +22,20 @@ Backup Tool:
/etc/letsencrypt
```
---
`/opt` enthält überwiegend die persistenten Daten und Konfigurationen der Docker-Dienste. Die weiteren Verzeichnisse enthalten WireGuard-, SSH- und Zertifikatskonfigurationen.
## Backup Ziel
### Hetzner Storage Box
Repository Struktur:
```text
backups/vps
```
---
## Retention Policy
## Aufbewahrung
| Typ | Anzahl |
|---|---|
| Daily | 7 |
| Weekly | 4 |
| Monthly | 6 |
| Täglich | 7 |
| Wöchentlich | 4 |
| Monatlich | 6 |
Zusätzlich:
- 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
---
Nicht mehr benötigte Backup-Daten werden regelmäßig mit `prune` bereinigt.
## Wiederherstellungsziele
Die folgenden Bereiche müssen wiederherstellbar sein:
| Bereich | Wichtigkeit |
|---|---|
| Docker Stacks | kritisch |
@ -85,22 +43,12 @@ Die folgenden Bereiche müssen wiederherstellbar sein:
| authentik | kritisch |
| WireGuard | 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
- Restore-Test dokumentieren
- 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.
- Automatisierte Wartung: [Wartung und Betrieb](maintenance.md)
- Backup-Überwachung: [Monitoring](monitoring.md)
- Offene Backup- und Recovery-Arbeiten: [Bekannte Themen und Verbesserungspotenzial](known-issues.md)

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 |
|---|---|
| proxy | Hauptnetzwerk für Reverse Proxy und Dienste |
| authentik_authentik | internes authentik Netzwerk |
| nextcloud_internal | internes Nextcloud Netzwerk |
| teamspeak_default | isoliertes TeamSpeak Netzwerk |
| `proxy` | Gemeinsames Netzwerk für Reverse Proxy und erreichbare Dienste |
| `authentik_authentik` | Internes Netzwerk für authentik-Komponenten |
| `nextcloud_internal` | Internes Netzwerk für Nextcloud-Komponenten |
| `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
- 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 |
| Container | Technische Rolle | Netzwerk |
|---|---|---|
| npm | Reverse Proxy | proxy |
| authentik-server | SSO Frontend | proxy |
| authentik-worker | Hintergrundprozesse | authentik_authentik |
| authentik-postgresql | Datenbank | authentik_authentik |
| authentik-redis | Cache | authentik_authentik |
| nextcloud | Cloud-Plattform | proxy |
| nextcloud-db | MariaDB | nextcloud_internal |
| nextcloud-redis | Redis Cache | nextcloud_internal |
| vaultwarden | Passwortmanager | proxy |
| forgejo | Git Hosting | proxy |
| collabora | Office Integration | proxy |
| uptime-kuma | Verfügbarkeitsmonitoring | proxy |
| netdata | Monitoring | proxy |
| adguardhome | DNS | proxy |
| teamspeak | Voice Server | teamspeak_default |
| site | Statische Webseite | proxy |
| npm | Reverse Proxy | `proxy` |
| authentik-server | SSO-Frontend | `proxy` |
| authentik-worker | Hintergrundprozesse | `authentik_authentik` |
| authentik-postgresql | Datenbank | `authentik_authentik` |
| authentik-redis | Cache | `authentik_authentik` |
| nextcloud | Cloud-Anwendung | `proxy` |
| nextcloud-db | Datenbank | `nextcloud_internal` |
| nextcloud-redis | Cache | `nextcloud_internal` |
| vaultwarden | Passwortmanager | `proxy` |
| forgejo | Git-Hosting | `proxy` |
| collabora | Office-Integration | `proxy` |
| uptime-kuma | Verfügbarkeitsmonitoring | `proxy` |
| netdata | Systemmonitoring | `proxy` |
| adguardhome | DNS | `proxy` |
| teamspeak | Voice-Server | `teamspeak_default` |
| site | Statische Webseite | `proxy` |
---
## Persistente Daten
## Öffentlich erreichbare Ports
| 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:
Die Dienstverzeichnisse liegen überwiegend unter `/opt`. Jeder Dienst besitzt ein eigenes Verzeichnis, beispielsweise:
```text
/opt/authentik
@ -93,39 +44,10 @@ Beispiele:
/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:
- Bind Mounts
- 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
- Öffentliche Ports und lokale Bindings: [Sicherheit](security.md)
- Gesicherte Verzeichnisse: [Backup](backup.md)
- Offene Docker-Arbeiten: [Bekannte Themen und Verbesserungspotenzial](known-issues.md)

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
- Forgejo öffentlich exposed
- öffentliche Ports teilweise historisch gewachsen
## Hohe Priorität
---
- 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
- WireGuard Peers noch nicht vollständig benannt
- Domains/Subdomains noch nicht dokumentiert
- Compose Standards noch nicht vereinheitlicht
---
## 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
---
- WireGuard-Peers vollständig Geräten und Zwecken zuordnen
- Domains und Subdomains dokumentieren
- Recovery-Anleitung erstellen
- Zielwerte für Wiederherstellungszeit und maximalen Datenverlust festlegen
## Langfristige Themen
- Matrix Server
- zentrale Benachrichtigungen
- vollständige Infrastructure-as-Code Struktur
- Matrix-Server
- vollständige Infrastructure-as-Code-Struktur
- 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
## 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
- Monitoring prüfen
- Uptime Kuma Alerts prüfen
- CrowdSec Events prüfen
---
- Uptime-Kuma-Alerts prüfen
- CrowdSec-Ereignisse prüfen
### Wöchentlich
- Docker Container Status prüfen
- Status der Docker-Container prüfen
- verfügbare Updates prüfen
- Backup Logs prüfen
- Backup-Logs prüfen
- freien Speicherplatz prüfen
---
### Monatlich
- Restore-Prozess testen
- ungenutzte Docker Images entfernen
- ungenutzte Docker-Images entfernen
- Logs prüfen
- Sicherheitsreview durchführen
---
## 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 |
|---|---|
| apt Updates | aktiv |
| Security Updates | aktiv |
| restic Backup | aktiv |
| logrotate | aktiv |
| CrowdSec Updates | aktiv |
## Ziel
---
Der Betrieb soll möglichst wartungsarm, stabil, nachvollziehbar und automatisiert sein.
## Geplante Automatisierung
## Weiterführende Dokumentation
| Funktion | Status |
|---|---|
| Docker Cleanup | geplant |
| Journal Cleanup | geplant |
| Backup Validation | geplant |
| Health Reports | geplant |
| Matrix Alerts | geplant |
---
## Wartungsziele
Die VPS soll möglichst:
- wartungsarm
- stabil
- nachvollziehbar
- automatisiert
betrieben werden.
- Überwachung: [Monitoring](monitoring.md)
- Backup-Konfiguration: [Backup](backup.md)
- Geplante Automatisierungen und offene Arbeiten: [Bekannte Themen und Verbesserungspotenzial](known-issues.md)

124
VPS/monitoring.md
View file

@ -1,128 +1,30 @@
# Monitoring Dokumentation
## Monitoring Stack
Die VPS nutzt aktuell mehrere Monitoring-Lösungen mit unterschiedlichen Aufgabenbereichen.
---
Monitoring soll Probleme frühzeitig erkennen und sichtbar machen. Die VPS verwendet dafür mehrere Systeme mit unterschiedlichen Aufgaben.
## Verwendete Systeme
| Dienst | Aufgabe |
| System | Aufgabe |
|---|---|
| Netdata | Live-Systemmonitoring |
| Uptime Kuma | Verfügbarkeitsmonitoring |
| CrowdSec | Sicherheitsmonitoring |
| Ubuntu Timer | Wartung / Updates |
---
| Netdata | Live-Überwachung des Servers und der Container |
| Uptime Kuma | Prüfung der externen Erreichbarkeit |
| CrowdSec | Erkennung sicherheitsrelevanter Ereignisse |
| systemd Timer | Automatisierte Ausführung geplanter Aufgaben |
## Netdata
### Aufgabe
Netdata überwacht:
- CPU
- RAM
- Prozesse
- Netzwerk
- Docker
- Festplatten
- Systemmetriken
Container:
- netdata
---
Netdata überwacht CPU, RAM, Prozesse, Netzwerk, Docker, Festplatten und weitere Systemmetriken. Netdata läuft im Container `netdata`.
## Uptime Kuma
### Aufgabe
Uptime Kuma überwacht:
- externe Erreichbarkeit
- HTTPS Checks
- Zertifikate
- Dienste
- Domains
Container:
- uptime-kuma
Localhost Binding:
```text
127.0.0.1:3001
```
---
Uptime Kuma prüft externe Erreichbarkeit, HTTPS, Zertifikate, Dienste und Domains. Details zur lokalen Erreichbarkeit stehen unter [Sicherheit](security.md).
## 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
- Angriffe
- bekannte Bad IPs
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
- Sicherheitsarchitektur: [Sicherheit](security.md)
- Aktive Wartungstimer: [Wartung und Betrieb](maintenance.md)
- Offene Monitoring- und Alerting-Arbeiten: [Bekannte Themen und Verbesserungspotenzial](known-issues.md)

111
VPS/networking.md
View file

@ -2,101 +2,36 @@
## Öffentliches Netzwerk
| Interface | Adresse |
|---|---|
| eth0 | 46.225.176.170 |
| Interface | Adresse | Zweck |
|---|---|---|
| `eth0` | `46.225.176.170` | Öffentliche Erreichbarkeit der VPS |
---
## Netzwerkrollen
## VPN
### 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:
Die VPS verbindet drei Bereiche:
```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.
Stattdessen nutzt die VPS:
- 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
- WireGuard-Netz und Peers: [WireGuard](wireguard.md)
- Docker-Netzwerke: [Docker](docker.md)
- Firewall und erreichbare Ports: [Sicherheit](security.md)
- Offene Netzwerk-Arbeiten: [Bekannte Themen und Verbesserungspotenzial](known-issues.md)

75
VPS/overview.md
View file

@ -13,69 +13,30 @@
| Hauptbenutzer | mbyte |
| Container Runtime | Docker |
---
## 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
- 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
## Architekturrolle
```text
Internet
↓
VPS
├── Nginx Proxy Manager
├── authentik
├── CrowdSec
├── WireGuard
├── Öffentliche Dienste
└── Monitoring
↓ VPN
Heimnetz
├── Unraid
├── internes NPM
├── Home Assistant
├── Seafile
├── Immich
└── interne Dienste
VPS (öffentlicher Einstiegspunkt, Authentifizierung und Schutz)
↓ WireGuard VPN
Heimnetz und Unraid (private Infrastruktur und Daten)
```
---
- 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
### Aktueller Status (2026-05-26)
Stand: 2026-05-26
| Ressource | Nutzung |
|---|---|
@ -86,18 +47,6 @@ Heimnetz
Die VPS besitzt aktuell deutliche Leistungsreserven.
---
## Zielbild
Die VPS soll langfristig:
- stabil
- selbstwartend
- dokumentiert
- leicht wiederherstellbar
- sicher
- wartungsarm
- vollständig überwacht
sein.
Die VPS soll langfristig stabil, wartungsarm, sicher, vollständig überwacht und innerhalb kurzer Zeit wiederherstellbar sein.

110
VPS/security.md
View file

@ -1,109 +1,49 @@
# 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
| Komponente | Aufgabe |
|---|---|
| CrowdSec | Dynamische Angriffsblockierung |
| nftables | Paketfilterung |
| Docker Netzwerkisolierung | Segmentierung |
| WireGuard | Sicherer Fernzugriff |
| Nginx Proxy Manager | TLS Terminierung |
| nftables | Paketfilterung auf dem Host |
| Docker-Netzwerkisolierung | Trennung der Container-Netzwerke |
| CrowdSec | Erkennung und dynamische Blockierung von Angriffen |
| WireGuard | Verschlüsselter privater Zugriff |
| Nginx Proxy Manager | Reverse Proxy und TLS-Terminierung |
| authentik | Zentrale Authentifizierung |
---
## Firewall und Isolation
## Firewall
UFW ist deaktiviert. Die VPS verwendet stattdessen nftables, Docker-verwaltete Firewallregeln und die CrowdSec-Integration.
### Aktueller Zustand
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
---
Die Docker-Netzwerke sind durch RAW-Regeln, Netzwerkisolation und interface-basierte Filterung segmentiert. CrowdSec ist in die INPUT Chain integriert.
## Öffentlich erreichbare Dienste
| Dienst | Port |
|---|---|
| NPM | 80 / 443 |
| Forgejo | 3000 |
| Forgejo SSH | 2222 |
| authentik | 9000 |
| TeamSpeak | 9987 / 10011 / 30033 |
| WireGuard | 51820 |
| Nginx Proxy Manager | `80/tcp`, `443/tcp` |
| Forgejo | `3000/tcp` |
| Forgejo SSH | `2222/tcp` |
| authentik | `9000/tcp` |
| TeamSpeak | `9987/udp`, `10011/tcp`, `30033/tcp` |
| WireGuard | `51820/udp` |
---
## Nur lokal erreichbare Dienste
## Lokale Bindings
Folgende Dienste sind nur lokal erreichbar:
Bindings auf `127.0.0.1` nehmen nur Verbindungen vom Server selbst an und sind nicht direkt aus dem Internet erreichbar.
| Dienst | Binding |
|---|---|
| NPM Admin | 127.0.0.1:81 |
| Uptime Kuma | 127.0.0.1:3001 |
| AdGuard UI | 127.0.0.1:3002 |
| NPM Admin | `127.0.0.1:81` |
| Uptime Kuma | `127.0.0.1:3001` |
| AdGuard UI | `127.0.0.1:3002` |
---
## Weiterführende Dokumentation
## Sicherheitsbeobachtungen
### Positiv
- 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
- Netzwerkrollen und Routing: [Netzwerk](networking.md)
- WireGuard-Konfiguration: [WireGuard](wireguard.md)
- Offene Sicherheitsarbeiten: [Bekannte Themen und Verbesserungspotenzial](known-issues.md)

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 |
| authentik | Zentrale Authentifizierung |
| Nginx Proxy Manager | Öffentlicher Reverse Proxy und TLS-Terminierung |
| 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 | Beschreibung |
| Dienst | Aufgabe |
|---|---|
| Nextcloud | Cloud Plattform |
| Collabora | Office Integration |
| Nextcloud | Cloud-Plattform und Zusammenarbeit |
| Collabora | Office-Integration für Nextcloud |
| Vaultwarden | Passwortmanager |
| Forgejo | Git-Hosting |
| AdGuard Home | DNS-Dienst |
| Site | Statische Webseite |
---
## Monitoring und Kommunikation
## Infrastruktur
| Dienst | Beschreibung |
| Dienst | Aufgabe |
|---|---|
| WireGuard | VPN |
| CrowdSec | Angriffsschutz |
| AdGuard Home | DNS |
| Forgejo | Git Hosting |
| Netdata | Live-Systemmonitoring |
| Uptime Kuma | Überwachung der Erreichbarkeit |
| TeamSpeak | Voice-Server |
---
## SSO-Status
## Monitoring
| Dienst | Beschreibung |
|---|---|
| Netdata | Live Monitoring |
| Uptime Kuma | Uptime Monitoring |
---
## Kommunikation
| Dienst | Beschreibung |
|---|---|
| TeamSpeak | Voice Server |
---
## SSO Status
Die Tabelle enthält auch Dienste, die über die VPS erreichbar sind, aber nicht zwingend direkt auf ihr laufen.
| Dienst | SSO |
|---|---|
@ -57,8 +42,6 @@
| Forgejo | geplant |
| Matrix | geplant |
---
## Bekannte Abhängigkeiten
| Dienst | Abhängigkeit |
@ -68,4 +51,10 @@
| authentik | PostgreSQL |
| authentik | Redis |
| 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
## 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
- Heimnetz
- mobilen Clients
- zusätzlichen Geräten
| Eigenschaft | Wert |
|---|---|
| Interface | `wg0` |
| Listening Port | `51820/UDP` |
| VPN-Subnetz | `10.100.0.0/24` |
| Geroutetes Heimnetz | `192.168.0.0/24` |
Interface:
- 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.
---
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.
## Aktuelle Peers
| Peer | Allowed IPs | Beschreibung |
| VPN-IP | Allowed IPs | Beschreibung |
|---|---|---|
| 10.100.0.4 | 10.100.0.4/32 | Client |
| 10.100.0.6 | 10.100.0.6/32 | Client |
| 10.100.0.55 | 10.100.0.55/32 | Client |
| 10.100.0.2 | 10.100.0.2/32 | Client |
| 10.100.0.3 | 10.100.0.3/32 | Client |
| 10.100.0.5 | 10.100.0.5/32 | Client |
| 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.2` | `10.100.0.2/32` | Client |
| `10.100.0.3` | `10.100.0.3/32` | Client |
| `10.100.0.4` | `10.100.0.4/32` | Client |
| `10.100.0.5` | `10.100.0.5/32` | Client |
| `10.100.0.6` | `10.100.0.6/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.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
- Saubere /32 Zuordnung pro Client
- 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
- Netzwerkrolle und Routing: [Netzwerk](networking.md)
- Backup der WireGuard-Konfiguration: [Backup](backup.md)
- Offene Peer- und Monitoring-Arbeiten: [Bekannte Themen und Verbesserungspotenzial](known-issues.md)