Homelab-Umbau Teil 4: Ein Ort für Dienste

Warum überhaupt Link zu Überschrift

Nach Teil 3 routet die OPNsense, der R4 ist Switch und Access Point. Was fehlt, ist ein Ort, an dem Dienste laufen können. FreeRADIUS, eine eigene CA, eine Telefonanlage — das muss alles irgendwo hin.

Auf die Firewall gehört sowas nicht. Eine Firewall soll Pakete weiterleiten und Regeln durchsetzen, sonst nichts. Je mehr da nebenher läuft, desto grösser die Angriffsfläche und desto unangenehmer jedes Update.

Was ich nicht gemacht habe Link zu Überschrift

Die naheliegende Option stand schon im Rack: Docker auf der Synology. Das NAS hat 18 GB RAM und läuft ohnehin durch.

Zwei Gründe dagegen, und der zweite wiegt schwerer.

Der offensichtliche: Die CPU reicht hinten und vorne nicht. NAS-CPUs sind auf Dateidienste und Stromverbrauch ausgelegt, nicht darauf, ein Dutzend Dienste parallel zu fahren. RAM allein hilft da nicht.

Der wichtigere: Ein NAS soll ein NAS sein. Da liegen meine Backups und meine Daten. Wenn auf derselben Kiste eine Telefonanlage mit Internet-Kontakt läuft, habe ich zwei sehr unterschiedliche Vertrauensniveaus auf einer Maschine zusammengelegt. Das ist derselbe Denkfehler wie ein flaches Netz, nur eine Ebene höher.

Rollentrennung ist billiger als das Aufräumen danach.

Die Kiste Link zu Überschrift

Ein gebrauchter Dell OptiPlex 3000 Micro: i5, 32 GB RAM, 500 GB NVMe plus 1 TB SSD. 300 Euro.

Ich hab dafür eine Weile auf Kleinanzeigen und eBay gesucht, und das hat sich gelohnt. Gebrauchte Business-Mini-PCs sind für Homelabs schwer zu schlagen: Sie kommen aus Leasing-Rückläufern in grossen Stückzahlen, sind auf Dauerbetrieb ausgelegt, leise, sparsam und klein. 32 GB RAM neu zu kaufen kostet derzeit fast so viel wie die ganze Maschine gebraucht.

Was man dafür in Kauf nimmt: kein ECC, keine Fernwartung, begrenzte Erweiterbarkeit. Für einen Homelab-Host ist das in Ordnung — anders als bei der Firewall, wo mir die fehlende Fernwartung später noch auf die Füsse gefallen ist.

Warum Proxmox Link zu Überschrift

Bare Metal mit Docker wäre die schlankere Variante gewesen. Dagegen sprach: Ich wollte echte Isolation als Option, nicht nur Container-Isolation. Warum, dazu gleich mehr.

Proxmox gibt mir beides auf einer Oberfläche — VMs mit KVM und Container mit LXC — dazu Snapshots, Backups und eine Weboberfläche, über die ich auch dann noch auf eine Maschine komme, wenn deren Netzwerk kaputt ist. Letzteres habe ich in dieser Serie schon schmerzhaft vermisst.

Es ist ein Single Node, kein Cluster. Ein Proxmox-Cluster braucht für Quorum sinnvollerweise drei Knoten. Mit zwei hat man mehr Komplexität und weniger Verfügbarkeit als mit einem — das lohnt sich hier nicht.

Installation Link zu Überschrift

Unspektakulär: ISO auf einen Stick, durchklicken, fertig. Ich habe die Vorgaben des Installers übernommen — ext4 für das System, darauf ein LVM-thin-Pool für die virtuellen Platten. Die zweite SSD hängt zusätzlich als eigener Speicher für Images und grössere Daten drin.

Die Alternative wäre ZFS gewesen. Das bringt Prüfsummen gegen stillen Datenverfall, Kompression und Replikation zu einem zweiten Knoten mit. Nur: Ich habe einen Knoten und keine Redundanz — ZFS könnte einen Fehler erkennen, aber ohne Spiegel nicht reparieren. Und meine beiden Platten taugen nicht zum Spiegeln, dafür sind sie zu unterschiedlich. Dazu kostet ZFS spürbar RAM, der sonst den VMs zur Verfügung steht.

Ehrlich gesagt habe ich das beim Installieren nicht so durchdacht, sondern schlicht die Vorgaben genommen. Im Nachhinein halte ich die Entscheidung trotzdem für richtig. Wer Prüfsummen und Replikation braucht, sollte ZFS nehmen — aber dann bitte auch mit Spiegel, sonst bringt es wenig.

Eine Sache muss man nach der Installation von Hand erledigen: Proxmox richtet standardmässig das Enterprise-Repository ein, das ohne Subscription nicht erreichbar ist. Bei jedem Update meckert es. Man trägt stattdessen das No-Subscription-Repository ein — dieselben Pakete, nur ohne den Enterprise-Testzyklus davor.

Und ja: Die Subscription-Erinnerung beim Login meckert trotzdem weiterhin. Damit lebe ich.

VM oder Container Link zu Überschrift

Das ist die Entscheidung, die man bei jedem neuen Dienst wieder trifft, und ich habe dafür inzwischen eine klare Regel.

LXC-Container teilen sich den Kernel mit dem Host. Das macht sie leicht, schnell und sparsam — und es bedeutet, dass eine Kernel-Schwachstelle einen Ausbruch aus dem Container zum Ausbruch auf den Host machen kann. Eine VM hat einen eigenen Kernel. Sie kostet mehr RAM und startet langsamer, aber die Trennung ist echt.

Meine Regel: Wer mit dem Internet spricht, kriegt eine VM. Wer rein intern arbeitet, kriegt einen Container.

Konkret heisst das:

Dienst Typ Warum
Telefonanlage VM Spricht mit externen SIP-Anbietern
FreeRADIUS LXC Nur internes Netz
Interne CA LXC Nur internes Netz

Die Telefonanlage ist der interessante Fall. Ein SIP-Server hält dauerhaft Verbindungen zu Anbietern im Internet und nimmt von dort Daten entgegen. Wenn da etwas schiefgeht, will ich nicht, dass zwischen dem Angreifer und meinem Virtualisierungshost nur eine Kernel-Lücke steht. Bei FreeRADIUS greift das Argument nicht — der redet ausschliesslich mit meinem Access Point.

Der Netzwerk-Teil Link zu Überschrift

Das ist die Stelle, an der Proxmox und der Rest des Umbaus zusammenkommen.

Der Host hängt per Trunk am R4 — also an einem Port, über den mehrere VLANs gleichzeitig laufen. Damit das funktioniert, muss die Bridge auf dem Proxmox-Host VLAN-aware sein. Das ist ein Haken in den Netzwerk-Einstellungen von vmbr0, und ohne ihn kann man einer VM kein VLAN zuweisen.

Ist er gesetzt, funktioniert der Rest angenehm einfach: Der Host selbst bleibt im Standard-VLAN, und jede einzelne virtuelle Netzwerkkarte bekommt ihr eigenes Tag. Bei der VM unter Hardware → Netzwerkgerät → VLAN Tag eintragen, fertig. Die VM landet im gewünschten VLAN, ohne dass im Gastsystem irgendetwas konfiguriert werden muss.

Damit ist die Grundlage für alles Weitere gelegt: Ein Dienst kann jetzt in genau dem Netz stehen, in das er gehört — und nicht dort, wo zufällig der Host steht.

Diagramm: Init7 Glasfaser auf die OPNsense, dahinter der R4 als Switch und Access Point. Im Netz 10.0.1.0/24 stehen die bisherigen Geräte und neu der Proxmox-Host, über einen Trunk-Port angebunden.

Der Host hängt über einen Trunk am R4 — noch im selben Netz wie alles andere.

Ein praktischer Nebeneffekt, der beim Debuggen hilft: Proxmox vergibt seinen virtuellen Netzwerkkarten MAC-Adressen aus einem eigenen Bereich, der mit bc:24:11 beginnt. In den DHCP-Leases der Firewall sieht man damit auf einen Blick, welche Einträge zu virtuellen Gästen gehören und welche zu echter Hardware.

Was noch fehlt Link zu Überschrift

Backups. Es gibt keine.

Das ist die grösste offene Baustelle in diesem Aufbau, und ich schreibe es hin, statt es zu verschweigen. Proxmox bringt einen brauchbaren Backup-Mechanismus mit, und ein NAS mit reichlich Platz steht zwei Meter daneben. Es gibt also keine Ausrede ausser der ehrlichen: Ich habe es noch nicht gemacht.

Snapshots sind übrigens kein Ersatz. Die liegen auf derselben Platte im selben Gerät. Wenn der Host stirbt, sind sie mit weg.

Das hole ich in Teil 6 nach — und zwar bevor mehr Dienste dazukommen.

Nächster Schritt Link zu Überschrift

Die Infrastruktur steht: eine Firewall, die Regeln durchsetzen kann, und ein Host, auf dem Dienste laufen. Zeit für das erste eigene VLAN — und ich fange bewusst mit dem kleinsten, am besten abgegrenzten Fall an: Telefonie.


Teil einer Serie über den Umbau meines Heimnetzes. Stand: August 2026. Fragen, Korrekturen und eigene Erfahrungen gerne in die Kommentare.