Praxisbewährtes Homelab-Architekturkonzept mit Proxmox, Docker, Reverse Proxy & Home Assistant

Anleitungen / Projekte
1

Ich möchte hier ein in der Praxis gewachsenes Homelab-Architekturkonzept vorstellen, das auf Stabilität, Klarheit und Wiederherstellbarkeit ausgelegt ist. Ich habe es in mühsamer Kleinarbeit mit ChatGPT erstellt und in der Praxis erprobt. Von Vorteil war, dass ich ein ausgebildeter ITler bin und ChatGPT konkrete Vorgaben machen und Irrwege verhindern konnte. Dieses Konzept hat Emterprise-Niveau erreicht. Es hat mir z.B. aktuell geholfen, als ich meinen Router auf Werkseinstellungen zurücksetzen musste. :zany_face:

Worum geht es?

Es handelt sich um eine klar strukturierte Home-Infrastruktur, die folgende Kernkomponenten kombiniert:

  • Proxmox VE als Virtualisierungs-Plattform

  • Docker für Applikations-Services

  • NGINX Proxy Manager als zentraler HTTPS-Entry-Point

  • AdGuard Home als internes DNS

  • NetBox als Single Source of Truth

  • Uptime Kuma für Monitoring

  • Home Assistant als integraler Bestandteil des Systems

  • QNAP NAS für Storage & Backups

Zentrale Idee

Alle internen Dienste sind über eine eigene interne Domain (home.arpa) erreichbar.
TLS wird ausschließlich zentral terminiert (Reverse Proxy), Backends laufen konsequent über HTTP.

Die Trennung ist strikt:

  • intern: *.home.arpa

  • extern: ausgewählte Services über eine öffentliche Domain

Proxxmox selbst nimmt dabei eine Sonderrolle ein und wird bewusst nicht über den Reverse Proxy geführt.

Warum ist das interessant?

  • klare Trennung von Control-Plane und Services

  • reproduzierbare Restore-Strategien

  • sauberes DNS-Design ohne Loops

  • skalierbar (mehr Nodes, mehr Services)

  • Home Assistant ist kein Sonderfall, sondern vollständig integriert

  • ideal für alle, die ihr Homelab dokumentierbar und wartbar halten wollen

Besonderes Learning

Ein wichtiges Praxis-Ergebnis war die Erkenntnis, dass Proxmox-Restores nur in produktive VMs möglich sind – Test-Restores erfordern daher Kopien produktiver Maschinen. Diese Erfahrung hat die Architektur maßgeblich beeinflusst.

Bei der angehängten Datei handelt es sich um eine Markdown-Datei, abgespeichert als txt, weil sonst nicht uploadber. :wink:

Wenn Interesse besteht, kann ich gerne weitere Details teilen (DNS-Design, NetBox-Modellierung, Restore-Abläufe).

LAN-Konfiguration.txt (5,7 KB)

2

Ich habe jetzt die gesamte Doku auf github veröffentlicht. Homelab Documentation

3

Moin,

ganz nette Zusammenstellen, auch sinnvolle Punkte, ist mir ehrlich gesagt aber an einigen Punkten etwas “too much” für mein Homelab, weil einige Punkte für mich nicht relevant sind ( externe Zugriff auf interne Dienste z.b. nutze ich nicht, ergo hab ich keinen NGINX-Proxy ).

Was mir aber fehlt, ist die Netzwerk-Konfiguration. da wäre bei mir ein entscheidener Punkt, weil ich z.b. hinter eine Firewall diverse VLAN’s nutze für die unterschiedlichen Dienste, bzw. System - z.b. sind alle Server im Server-VLAN, alle smarthome-Systeme im Smarthome-VLAN usw.

Da braucht es dann entsprechende Firewallregelwerke zu, die die Kommunikation regeln.

Meine Dokumentation dieser ganzen Regelwerke besteht schlichtweg daraus, das ich die Konfiguration der Firewall runterlade und extern sichere ( Notebook, Backup-Platten, etc. ). Damit ist auch die IP-Konfig alle System direkt gesichert.

4

Moin,

vielen Dank für dein Feedback – das kann ich gut nachvollziehen. „Too much“ ist im Homelab-Kontext ja oft eher ein Zeichen dafür, dass jemand sehr bewusst priorisiert.

Ein Punkt, den ich für mein konkretes Setup bewusst anders gelöst habe, ist das Thema VLANs. VLAN-Segmentierung ist technisch sauber und in vielen Homelabs absolut sinnvoll – bei mir wäre sie aber mehr Komplexität als Nutzen, aus folgenden Gründen:

Kein externer Zugriff, keine exponierten Dienste

Alle Dienste sind ausschließlich intern erreichbar. Es gibt:

  • keine Portweiterleitungen

  • keinen Reverse Proxy nach außen

  • keinen Zugriff von unterwegs

Damit entfällt ein zentrales Bedrohungsszenario, für das VLANs häufig eingesetzt werden.

Überschaubare Geräte- und Dienstelandschaft

Mein Homelab besteht aus wenigen Servern und klar definierten Diensten. Es gibt keine große oder dynamisch wachsende IoT-Landschaft. Die Angriffsfläche ist damit so klein, dass Dienst-Härtung und saubere Konfiguration mehr Sicherheitsgewinn bringen als zusätzliche Netzsegmentierung.

VLANs bringen nur mit konsequenten Regeln echten Mehrwert

VLANs erhöhen die Sicherheit nur dann, wenn:

  • Firewall-Regeln sauber und restriktiv gepflegt werden

  • Ausnahmen bewusst gesetzt und verstanden sind

  • regelmäßig überprüft wird, warum etwas kommunizieren darf

In kleinen Umgebungen endet das sonst schnell bei „Allow any → any“, damit alles funktioniert. Dann bleibt vom Sicherheitsgewinn wenig übrig, die Komplexität aber vollständig erhalten.

Betriebs- und Restore-Komplexität

Mein Fokus liegt klar auf:

  • einfacher Fehlersuche

  • schneller Wiederherstellung

  • möglichst wenigen Abhängigkeiten

VLANs und umfangreiche Firewall-Regelwerke erhöhen im Fehlerfall die Anzahl der möglichen Ursachen deutlich – insbesondere bei Netzwerkproblemen.

Risikoabwägung statt Best Practice um jeden Preis

Für mein Szenario ist das größte Risiko nicht laterale Bewegung im Netz, sondern:

  • Fehlkonfigurationen

  • vergessene Sonderregeln

  • unvollständige Dokumentation

Hier fahre ich mit klaren Host-Firewalls, restriktiv konfigurierten Diensten und sauberen Backups pragmatischer und robuster.

Kurz gesagt: VLANs sind kein Selbstzweck. In meinem Homelab würde ich mir damit vor allem zusätzliche Komplexität einkaufen, ohne einen proportionalen Sicherheits- oder Stabilitätsgewinn zu erzielen.

In Setups mit vielen IoT-Geräten, wechselnden Clients, externem Zugriff oder mehreren Nutzern würde ich das sofort anders bewerten. Genau das ist aber auch das Schöne am Homelab: Es darf konsequent auf den eigenen Bedarf optimiert sein – nicht auf ein Lehrbuchbeispiel.

5

Nö, ich würde es eher Faulheit nennen :grinning_face:

Ich bin im IT-Bereich, schlag mich jeden Tag mit Dokumentation, ISO-Zertifizierungen, Audits usw. rum - das will ich das zuhause so einfach wie möglich habe, da mit es nicht in einen zweiten Job ausartet.

Richtig.

Das Zauberwort heist Planung und zwar vorher - Kommunikationsmatrix erstellen auf Papier oder Excel und Co.

  • Welche VLAN darf / muss / darf nicht mit welchem anderen kommunizieren oder welche VLAN -darf / darf mnicht ins Internet.
  • gibt es in den VLAN noch Gerät die zusätzlich noch weitere Rechte brauchen ?
  • Das Grundkonzept einer guten Firewall ist “Verboten ist alles, was nicht erlaubt wird” und darauf basiert das komplette Regelwerk.

Ich hab ne Firewall bei mir laufen, die u.a. mit Aliases arbeitet, zum einen auf IP-adressen basierend aber auch auf Port-basierend.

Das erst was ich mache, ist für Geräte gleichen Type z.b. Drucker und ihren IP-Adressen, einen Alias bauen, das selbe dann auch für Dienste, z.b. MQTT und dieses Alias verwende ich dann ausschliesslich auch in der Firewall-Regel.

Das hat den großen Vorteil, wenn sich IP-Adressen ändern, oder z.b. ein weiterer Drucker dazu kommt, ändere ich nur den Alias und brauche kein einzige Firewall-Regel anzufassen.

Dazu kommt, ich gebe allen Geräte ausschliesslich IP-Adressen per DHCP-Reservation, ich hab kein Gerät bei mir, was ein feste IP eingetragen hat. Somit sind die IP-adressen an einer Stelle zentrale verwaltet und ich kann mir für Dokuzwecke einfach ein CSV-Export machen.