Proxmox auf Hetzner professionell betreiben? WZ-IT übernimmt Setup, Netzwerk-Design, Betrieb und Support für Ihre Proxmox-Infrastruktur. Zur Service-Seite →
Wenn ein Proxmox-Cluster "zickt", liegt es erstaunlich oft nicht an Proxmox selbst - sondern am Netzwerk: Corosync läuft über Public IPs, Storage- oder VM-Traffic stört die Cluster-Kommunikation, MTU-Mismatches sorgen für Paketverlust, oder Hybrid-Setups (Cloud + Dedicated) werden über Bastellösungen zusammengeklickt.
Die gute Nachricht: Hetzner Cloud Networks (Private Networks) und der vSwitch geben Ihnen die Bausteine, um Proxmox auf Hetzner sauber zu segmentieren - privat, stabil und skalierbar.
Vor der Providerkonfiguration: Proxmox-Cluster-Netzwerk providerneutral planen für Corosync, Storage, Redundanz und Abnahme.
Inhaltsverzeichnis
- Welche Netze braucht ein Proxmox Setup wirklich?
- Hetzner Cloud Networks (Private Networks) in Klartext
- vSwitch: Dedicated Server privat verbinden
- Referenz-Architekturen
- Schritt-für-Schritt Vorgehen
- Häufige Fehler und wie Sie sie vermeiden
- Unser Vorgehen bei WZ-IT
- Weiterführende Guides
Welche Netze braucht ein Proxmox Setup wirklich?
Trennen Sie Management-, Corosync- und Storage-Traffic, damit Storage-Last die Cluster-Kommunikation nicht beeinträchtigt.
1.1 Management-Netz (GUI/SSH/API)
Das ist der Zugang für Admins und Automatisierung:
- Proxmox Web UI
- SSH
- API / Automation
- Monitoring (z. B. Metriken)
Best Practice: Management nicht öffentlich ins Internet hängen. Stattdessen: VPN/Bastion + Firewall-Regeln.
1.2 Cluster-/Corosync-Netz (separat!)
Corosync ist latenz-sensitiv. Best Practice ist ein separates Netzwerk für Corosync, weil anderer Traffic Corosync stören kann (Proxmox VE Admin Guide).
Merksatz: Corosync ist "Cluster-Herzschlag". Wenn der Herzschlag stottert, verliert der Cluster Quorum - und dann wird's ungemütlich.
Zwischen allen Nodes sind zuverlässige Latenzen unter 5 Millisekunden nötig. Eine dedizierte 1-Gbit-Schnittstelle genügt meist (Proxmox VE Admin Guide).
1.3 Storage-Netz (optional, aber bei Ceph fast Pflicht)
Wenn Sie Ceph (oder generell storage-intensiven Traffic) nutzen, benötigen Sie ein eigenes Netz.
Der wichtigste Satz aus der Proxmox-Doku:
Das Cluster-Netz darf nicht durch Storage oder Live-Migration stark ausgelastet werden. (Proxmox VE Admin Guide)
Storage-Recovery/Backfill kann massiv Traffic erzeugen - und genau das kann Corosync aus dem Tritt bringen.
Hetzner Cloud Networks (Private Networks) in Klartext
Hetzner Cloud Networks sind eine private Umgebung, damit Server direkt miteinander kommunizieren können. Jeder Server bekommt eine private IP, die nicht im Internet ist - die Verbindungen laufen über dedizierte Interfaces als private Layer-3 Links (Hetzner Docs).
Was das praktisch bedeutet:
- Cloud-Server sprechen über private IPs miteinander (ohne Internet)
- "Management" und "Backend" Traffic kann in private Netze gelegt werden
- Public Internet bleibt über die Public IP erreichbar (wenn gewünscht)
2.1 Automatische Konfiguration (hc-utils / DHCP)
Auf Hetzner Cloud Images ist standardmäßig hc-utils installiert. Private Network Interfaces werden automatisch per DHCP konfiguriert (systemd service [email protected], DHCP-Client dhcpcd) (Hetzner Docs).
Wichtig zu wissen, wenn Sie später manuell an Netzwerk-Tools arbeiten oder spezielle Distributionen nutzen.
2.2 MTU-Falle (nicht ignorieren)
Die MTU auf privaten und öffentlichen Interfaces kann unterschiedlich sein (Hetzner Docs).
Für Proxmox heißt das: MTU konsistent halten, besonders auf Corosync- und Storage-Netzen. Halb aktivierte Jumbo Frames sind ein Klassiker für "manchmal geht's, manchmal nicht".
vSwitch: Dedicated Server privat verbinden
vSwitch ist der Hebel, wenn Proxmox auf Dedicated Root Servern läuft und Sie private Netzwerkkommunikation benötigen - zwischen Dedicated Servern untereinander und/oder mit Hetzner Cloud Servern.
Für Dedicated Root Server wird ein vSwitch erstellt und die Dedicated Server daran gehängt. Das allein reicht schon, um Dedicated Server untereinander privat zu verbinden (Layer-2). Optional kann der vSwitch zusätzlich mit einem Hetzner Cloud Network gekoppelt werden - dafür wird im Cloud Network ein Subnet mit vSwitch connection erstellt (Hetzner Docs).
Wann benötigen Sie vSwitch?
Typische Use Cases:
- Proxmox Cluster auf Dedicated - private Corosync/Storage-Kommunikation zwischen den Nodes
- Hybrid-Setup - Dedicated Proxmox Nodes + Cloud Bastion/Monitoring/Automation
- Private Kommunikation zwischen Cloud und Dedicated (Admin-Zugriff, Backup, Monitoring)
- Backend-Traffic privat, statt über Public IPs
Kurz: vSwitch ist die Grundlage für private Netze auf Dedicated - standalone oder als Bridge zur Cloud.
Referenz-Architekturen
Hosting-Anbieter vergleichen, bevor Hardware und Netze festgelegt werden.
Drei Patterns, die in Projekten funktionieren - abhängig von Budget und Verfügbarkeitsziel. Planung und Aufbau des Netzwerks durch WZ-IT: Proxmox auf Hetzner.
Pattern A: Single Node auf Dedicated (minimal, aber sauber)
Für wen: Kleine bis mittlere Setups, Kostenfokus, "erstmal loslegen".
Netze:
- Management (absichern!)
- Optional: Backup/Storage Backend (privat)
Warum das okay ist: Proxmox kann Single Node. Die Stabilität kommt über Betrieb: Backups, Restore-Tests, Monitoring, Update-Prozess.
Wichtig: Single Node ≠ HA. Es braucht einen Plan, wie bei Hardwareausfall wieder hochgefahren wird (RTO).
Pattern B: 3-Node Cluster (der "Standard" für ernsthafte HA)
HA-Cluster aufbauen, zwei Nodes mit QDevice und Storage-Wahl.
Für wen: Echtes Failover, Wartung ohne Downtime, Resilienz.
Netze:
- Management-Netz (sicher)
- Corosync/Cluster-Netz (separat!)
- Storage-Netz (wenn Ceph / storage-intensiv), nicht mit Corosync geteilt
Optional: Ein zweiter Corosync-Link über Kronosnet (--link1) sollte auf einem physisch getrennten Netz liegen. Bis zu acht Links werden unterstützt (Admin Guide).
Pattern C: Hybrid (Cloud Bastion/Tools + Dedicated Proxmox Cluster via vSwitch)
Für wen: Teams, die Cloud-Komfort (Bastion, Monitoring, CI, VPN) wollen, aber Workloads auf Bare Metal betreiben.
Netze:
- Cloud Network(s) für Bastion/Monitoring
- vSwitch koppelt Cloud Network ↔ Dedicated
- Dedicated Nodes nutzen private Links, Public IPs nur wo nötig
Vorteil: Proxmox GUI/SSH komplett über private IPs erreichbar (über Bastion/VPN), statt öffentlich exponiert.
Hetzner vSwitch und Cloud Network für Proxmox einrichten: Schritt für Schritt
Schritt 1: Zielbild und Anforderungen festlegen
Vor dem ersten Klick beantworten:
- Single Node oder Cluster?
- HA-Ziel (RPO/RTO, Failover erwartet?)
- Storage: lokal (ZFS) oder verteilt (Ceph)?
- Wie viele Netze möglich (NICs/Ports)?
- Wer greift wie zu (VPN/Bastion/Office IPs)?
Schritt 2: IP-Plan und Namensschema (wirklich vorher!)
Legen Sie vor der Einrichtung Folgendes fest:
- Subnetze pro Zweck (Mgmt/Corosync/Storage)
- IP-Range pro Subnetz (nicht zu klein)
- Hostnames und Node-IDs
- Welche Services am Public Internet (wenn überhaupt)
Schritt 3: Hetzner Cloud Networks erstellen
- Mindestens ein Cloud Network anlegen (Management/Backend)
- Bei größeren Setups: mehrere Subnets/Networks (Mgmt getrennt vom Backend)
- MTU-Themen beachten bei Mixed-Interfaces
Schritt 4: vSwitch einrichten (Dedicated ↔ Cloud)
- vSwitch erstellen
- Dedicated Server an vSwitch hängen
- Cloud Network Subnet mit vSwitch connection anlegen
- Dedicated OS-seitig konfigurieren
OS-seitig wird der vSwitch als VLAN-Interface mit MTU 1400 konfiguriert (Hetzner Docs):
auto enp7s0.4000
iface enp7s0.4000 inet static
address 10.10.20.11/24
vlan-raw-device enp7s0
mtu 1400
Schritt 5: Proxmox Interfaces sauber zuordnen
- Management: Bridge/Interface für Admin-Zugriff
- Corosync: eigenes Interface/Link
- Storage: eigenes Interface/Link
Corosync binden Sie bei der Cluster-Erstellung explizit an den eigenen Link; ein zweiter Link liefert Redundanz (Proxmox Doku):
# Node 1:
pvecm create CLUSTERNAME --link0 10.10.20.11 --link1 10.10.30.11
# Node 2 (Join):
pvecm add 10.10.20.11 --link0 10.10.20.12 --link1 10.10.30.12
Bei "einfach default" Clustering landet Corosync oft im gleichen Netz wie GUI und VM-Traffic - genau das vermeiden.
Schritt 6: Validierung
Nach dem Aufbau (vor Produktiv):
- Läuft Corosync stabil (keine Paketverluste/Spikes)?
- Ist Storage-Traffic wirklich getrennt?
- Funktioniert Live-Migration ohne Corosync zu stören?
- Failover-Tests: HA/Restart-Verhalten
Quorum und Cluster-Mitgliedschaft prüfen Sie mit:
pvecm status
Häufige Fehler bei Proxmox auf Hetzner: Corosync, MTU, öffentliche IPs
Fehler 1: Corosync und Storage im gleichen Netz
Corosync und Storage sollen kein gemeinsames Netz nutzen; Ausnahme ist höchstens ein niedrig priorisierter Fallback-Link in einer redundanten Konfiguration (Proxmox Admin Guide).
Fix: Storage-Netz separieren. Corosync bekommt "ruhige" Leitung.
Fehler 2: Cluster über Public IP
Public IP ist:
- unnötig exponiert
- häufiger störanfällig
- oft schlechter kontrollierbar (Firewalling/NAT/Routing)
Fix: Private Networks + vSwitch nutzen.
Fehler 3: MTU/Jumbo Frames halb aktiviert
Private und öffentliche Interfaces können unterschiedliche MTUs haben.
Fix: MTU auf dem gesamten Pfad konsistent halten. Für das vSwitch-VLAN-Interface gibt Hetzner MTU 1400 vor; Jumbo Frames nur, wenn jeder Hop sie unterstützt. Die übrigen Pfade nach Hetzner-Vorgaben prüfen.
Fehler 4: Hybrid ohne vSwitch
WireGuard zwischen Cloud und Dedicated, NAT hier, Routing da - funktioniert bis es "komisch wird".
Fix: vSwitch nutzen für saubere Cloud ↔ Dedicated Kopplung.
Fehler 5: Management UI öffentlich erreichbar
Unnötiges Risiko.
Fix: Bastion/VPN + restriktive Firewall, Management nur aus privaten Netzen.
Unser Vorgehen bei WZ-IT
Bei Proxmox auf Hetzner gehen wir so vor:
- Anforderungsanalyse: Single Node vs. Cluster, HA-Ziele, Storage-Anforderungen
- Netzwerk-Design: IP-Plan, Subnetz-Struktur, vSwitch-Topologie
- Setup: Cloud Networks, vSwitch, Proxmox Installation mit sauberer Interface-Zuordnung
- Härtung: Management absichern, Firewall, Bastion/VPN
- Validierung: Corosync-Stabilität, Failover-Tests, Monitoring
- Dokumentation: Netzwerkplan, Runbooks, Eskalationspfade
Wir übernehmen das komplette Setup oder auditieren bestehende Infrastrukturen.
Zur Service-Seite: Proxmox auf Hetzner →
Weiterführende Guides
Zur öffentlichen Anbindung und zu privaten Gästen: Proxmox auf Hetzner mit einer IP und Firewall-VM.
Quellen
Stand: Oktober 2026.
