Projektübersicht

Ein Topton Mini-PC wurde als dedizierter Proxmox VE Hypervisor eingerichtet. Zwei NVMe-SSDs laufen im ZFS-Mirror, vier Netzwerkbrücken trennen WAN, LAN, NAS-Segment und ein isoliertes Lab-Netzwerk voneinander. Der Host bildet die Basis fur alle weiteren VMs und LXC-Container im Heimnetz. Proxmox VE nutzt KVM als Hypervisor-Technologie fur die Virtualisierung von VMs.

1. Situation (Ausgangslage)

Im Heimnetz war ein einfacher Consumer-Router im Einsatz: keine echte Firewall, keine Netzwerksegmentierung, kein DNS-Filtering, kein VPN auf Router-Ebene. Alle Geräte befanden sich im selben Subnetz, ohne Trennung zwischen vertrauenswürdigen und nicht vertrauenswürdigen Endgeräten. Fur ein Heimlabor mit Lern- und Dokumentationszweck war das unzureichend.

2. Task (Zielsetzung)

• Hypervisor-Plattform: Proxmox VE auf einem dedizierten Mini-PC installieren und produktionsreif konfigurieren.
• Ausfallsicherheit: Zwei NVMe-SSDs im ZFS-Mirror betreiben, damit ein Laufwerksausfall keine Datenverluste verursacht.
• Netzwerksegmentierung: Separate Bridges fur WAN, LAN, NAS-Segment und ein isoliertes Lab-Netzwerk einrichten.
• Basis fur OPNsense: Den Host so vorbereiten, dass OPNsense als VM den Heimrouter ersetzen kann.

3. Action (Umsetzung)

A. Installation mit ZFS-Mirror

Proxmox VE 9.2 wurde uber den grafischen Installer auf dem Mini-PC eingerichtet. Als Dateisystem wurde ZFS (RAID1) uber beide NVMe-SSDs gewahlt. ZFS bietet gegenuber ext4 entscheidende Vorteile fur einen Hypervisor: Spiegelung uber beide Laufwerke, automatische Checksum-Verifizierung aller Datenblocke (Schutz vor Bitrot), Copy-on-Write-Snapshots fur VMs sowie LZ4-Kompression. Jede SSD erhielt eine eigene EFI-Partition, damit das System auch bei Ausfall eines Laufwerks bootfahig bleibt.

B. Repository- und Systemkonfiguration

Nach der Installation wurden die Enterprise-Repositories deaktiviert (erfordern eine kostenpflichtige Subscription) und die No-Subscription-Repositories im DEB822-Format eingerichtet. Das System wurde vollstandig aktualisiert. NTP wurde auf den internen Gateway-NTP-Dienst konfiguriert (nach der spateren OPNsense-Installation ubernimmt diese Rolle die Firewall-VM), Zeitzone auf Europe/Berlin gesetzt.

C. Netzwerkbrucken

Alle funf physischen Interfaces des Mini-PC wurden als manual konfiguriert, ohne eigene IP. Die IP-Konfiguration liegt ausschliesslich auf den Bridges - ein haufiger Fehler bei der Ersteinrichtung. Vier Bridges wurden angelegt:

• vmbr0 (WAN): Verbindet den physischen Ethernet-Port direkt mit der OPNsense-VM. Keine IP auf dem Host - der Host benotigt keinen WAN-Zugang.
• vmbr1 (LAN/Management): Tragt die Management-IP des Hypervisors. Uber diese Bridge sind alle VMs und LXC-Container erreichbar, ebenso die Web-UI.
• vmbr2 (NAS-Segment): Gebunden an einen USB-3.0-Gigabit-Adapter. Physisch getrenntes Netzwerksegment fur die Synology NAS - nur Systeme mit expliziter Firewall-Regel in OPNsense durfen darauf zugreifen.
• vmbr3 (Lab/Hacking-Lab): Rein virtuelles Segment ohne physischen Port (bridge-ports none). VMs im Lab kommunizieren nur untereinander, kein Traffic kann das Segment ohne OPNsense-Regel verlassen.

Spanning Tree Protocol wurde auf allen Bridges deaktiviert (kein Bedarf in dieser Topologie) und der Forwarding Delay auf 0 Sekunden gesetzt.

D. Storage-Konfiguration und ZFS-Verifikation

Proxmox legt standardmassig zwei Storage-Bereiche an: local fur ISO-Images und Container-Templates auf Dateisystem-Ebene, sowie local-zfs fur VM-Disks und LXC-Rootfs als ZFS Volumes mit Thin Provisioning (sparse 1). Ein manueller ZFS-Scrub wurde ausgefuhrt und verifiziert, dass beide Laufwerke fehlerfrei sind.

4. Result (Ergebnis & Verifikation)

Der Hypervisor lauft stabil mit Proxmox VE 9.2 auf Debian Trixie (Kernel 6.17). Der ZFS-Mirror-Pool zeigt state: ONLINE mit null Read/Write/Checksum-Fehlern, der letzte Scrub reparierte 0 Bytes. Die Pool-Auslastung liegt bei etwa 5 % bei rund 944 GB nutzbarer Kapazitat. Alle vier Netzwerkbrucken sind aktiv und korrekt zugeordnet, verifiziert mit ip a und brctl show. Die Proxmox Web-UI ist uber das LAN erreichbar. Der Host ist bereit fur die nachste Phase: OPNsense als VM zur Ubernahme der Router- und Firewall-Funktion.

Lessons Learned

• NICs als manual konfigurieren: Die IP gehort auf die Bridge, nicht auf die physische NIC. Wer das verwechselt, verliert den Zugang zum Management-Interface - der Fehler ist einfach zu machen und schwer zu debuggen ohne physischen Zugang.
• UEFI-Redundanz ist nicht kostenlos: ZFS-Mirror schutzt die Daten, aber nicht den Bootloader. Beide SSDs brauchen eine eigene EFI-Partition - bei einem Laufwerkstausch muss diese auf das neue Laufwerk ubertragen werden.
• Enterprise-Repos sofort deaktivieren: Ohne Subscription schlagt apt update mit einem Fehler fehl. Das ist kein Bug, sondern das Lizenzmodell. Die No-Subscription-Repositories enthalten dieselben Pakete.
• USB-Ethernet fur NAS-Segmentierung ist ein bewusster Kompromiss: Hohere CPU-Last und Latenz gegenuber nativen PCIe-NICs sind fur Backup-Workloads akzeptabel, aber bei Echtzeit-Anforderungen ware ein dedizierter PCIe-Port vorzuziehen.
• Thin Provisioning beobachten: sparse 1 auf ZFS bedeutet, dass VM-Disks nicht sofort den konfigurierten Speicher belegen. Der Pool kann schneller volllaufen als erwartet, wenn man nur auf die zugewiesenen Grosssen schaut.