Proxmox Cluster Netzwerk auf Hetzner: Private Networks + vSwitch richtig nutzen

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 dir die Bausteine, um Proxmox auf Hetzner sauber zu segmentieren – privat, stabil und skalierbar.

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 du sie vermeidest
• Unser Vorgehen bei WZ-IT
• Weiterführende Guides

---

Welche Netze braucht ein Proxmox Setup wirklich?

Proxmox funktioniert auch "alles in einem Netz". Aber gut (und HA-fähig) wird es erst, wenn du Traffic sauber trennst.

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 Wiki).

Merksatz: Corosync ist "Cluster-Herzschlag". Wenn der Herzschlag stottert, verliert der Cluster Quorum – und dann wird's ungemütlich.

1.3 Storage-Netz (optional – aber bei Ceph fast Pflicht)

Wenn du Ceph (oder generell storage-intensiven Traffic) nutzt, brauchst du ein eigenes Netz.

Der wichtigste Satz aus der Proxmox-Doku:

"Storage communication should never be on the same network as corosync!" (Proxmox Wiki)

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 du später manuell an Netzwerk-Tools arbeitest oder spezielle Distros nutzt.

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 du private Netzwerkkommunikation brauchst – 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 brauchst du 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. Mehr Details zur Umsetzung findest du auf unserer Proxmox auf Hetzner Service-Seite.

---

Referenz-Architekturen

Drei Patterns, die in Projekten funktionieren – abhängig von Budget und Verfügbarkeitsziel. Alle drei setzen wir regelmäßig für Kunden um (→ Service-Seite).

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). Wir helfen bei der Planung und Umsetzung.

---

Pattern B: 3-Node Cluster (der "Standard" für ernsthafte HA)

Für wen: Echtes Failover, Wartung ohne Downtime, Resilienz.

Netze:

• Management-Netz (sicher)
• Corosync/Cluster-Netz (separat!)
• Storage-Netz (wenn Ceph / storage-intensiv) – niemals mit Corosync teilen!

Optional: Redundanz fürs Cluster-Netz (zweiter Ring) – empfohlen über zwei physisch getrennte Netze (RRP).

---

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.

---

Schritt-für-Schritt Vorgehen

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!)

Ein simpler Plan spart später Tage:

• 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)

1. vSwitch erstellen
2. Dedicated Server an vSwitch hängen
3. Cloud Network Subnet mit vSwitch connection anlegen
4. Dedicated OS-seitig konfigurieren

Schritt 5: Proxmox Interfaces sauber zuordnen

• Management: Bridge/Interface für Admin-Zugriff
• Corosync: eigenes Interface/Link
• Storage: eigenes Interface/Link

Bei "einfach default" Clustering landet Corosync oft im gleichen Netz wie GUI und VM-Traffic – genau das vermeiden. Unsicher bei der Zuordnung? Wir beraten dich.

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

---

Häufige Fehler und wie du sie vermeidest

Fehler 1: Corosync und Storage im gleichen Netz

Storage-Kommunikation niemals im Corosync-Netz.

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 end-to-end konsistent. Wenn Jumbo: überall. Wenn nicht: überall 1500.

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:

1. Anforderungsanalyse: Single Node vs. Cluster, HA-Ziele, Storage-Anforderungen
2. Netzwerk-Design: IP-Plan, Subnetz-Struktur, vSwitch-Topologie
3. Setup: Cloud Networks, vSwitch, Proxmox Installation mit sauberer Interface-Zuordnung
4. Härtung: Management absichern, Firewall, Bastion/VPN
5. Validierung: Corosync-Stabilität, Failover-Tests, Monitoring
6. Dokumentation: Netzwerkplan, Runbooks, Eskalationspfade

Wir übernehmen das komplette Setup oder auditieren bestehende Infrastrukturen.

Zur Service-Seite: Proxmox auf Hetzner →

---

Weiterführende Guides

• Verschlüsselte Proxmox-Backups mit Hetzner Storage Box
• Proxmox Übersicht
• Proxmox Wartung & Support
• VMware zu Proxmox Migration