Proxmox SDN — Software Defined Networking in der Praxis

Proxmox SDN (Software Defined Networking) ist eine der am meisten unterschätzten Funktionen der Plattform. Statt Netzwerksegmentierung über Switch-VLANs zu steuern — mit allem was das an Koordinationsaufwand bedeutet — definiert man Netzwerke zentral in Proxmox und verteilt sie automatisch auf alle Cluster-Nodes.

SDN-Konzepte verstehen

Proxmox SDN kennt drei Kernkonzepte:

Zones definieren die Netzwerktechnologie. Je nach Zone kommunizieren VMs anders miteinander und werden unterschiedlich isoliert.

VNets sind virtuelle Netzwerke innerhalb einer Zone. Eine Zone kann mehrere VNets enthalten. VNets erscheinen auf jedem Node als Linux-Bridge.

Subnets (optional, ab Proxmox 8) ermöglichen IPAM und DHCP direkt in Proxmox — wir fokussieren uns hier auf die Netzwerktechnologie, nicht das IPAM.

Zone-Typen: Wann was?

Zone-Typ	Einsatzgebiet	Voraussetzung
Simple	Einfache interne Netze ohne Isolation zwischen Nodes	Kein besonderer Uplink
VLAN	Bestehende VLAN-Infrastruktur integrieren	Managed Switch mit VLAN-Trunk
VXLAN	Multi-Node-Isolation ohne Switch-Konfiguration	Layer-3-Konnektivität zwischen Nodes
EVPN	BGP-basiertes Routing, Multitenancy	BGP-fähige Infrastruktur

Für die meisten Produktionsumgebungen ohne dedizierte Netzwerkabteilung: VXLAN. Kein Switch muss angefasst werden, die Isolation funktioniert auf Layer 3.

VXLAN-Zone einrichten

VXLAN tunnelt Layer-2-Traffic über UDP (Port 4789) durch das bestehende Layer-3-Netz. Jede Zone bekommt eine eindeutige VNI (VXLAN Network Identifier).

Voraussetzung: SDN-Pakete installieren

apt install libpve-network-perl ifupdown2

Danach im Proxmox-Webinterface: Datacenter → SDN erscheint als Menüpunkt.

Zone erstellen (CLI)

# VXLAN-Zone erstellen
pvesh create /cluster/sdn/zones \
  --zone vxlan-prod \
  --type vxlan \
  --peers 10.0.0.10,10.0.0.11,10.0.0.12
  # peers = IP-Adressen aller Cluster-Nodes im Management-Netz

VNet erstellen

# VNet für Produktions-VMs (VXLAN Network Identifier: 1000)
pvesh create /cluster/sdn/vnets \
  --vnet prod-vms \
  --zone vxlan-prod \
  --tag 1000

# VNet für DMZ
pvesh create /cluster/sdn/vnets \
  --vnet dmz \
  --zone vxlan-prod \
  --tag 1001

Konfiguration verteilen

# Änderungen auf alle Nodes anwenden
pvesh set /cluster/sdn

Danach erscheinen prod-vms und dmz als wählbare Bridges in der VM-Netzwerkkonfiguration — auf jedem Cluster-Node.

VLAN-Zone für bestehende Infrastruktur

Wer bereits eine VLAN-Infrastruktur hat und nur die Verwaltung zentralisieren will:

# VLAN-Zone auf bestehender Bridge
pvesh create /cluster/sdn/zones \
  --zone vlan-existing \
  --type vlan \
  --bridge vmbr1
  # vmbr1 = VLAN-aware Bridge aus Artikel 1

# VNet für VLAN 20
pvesh create /cluster/sdn/vnets \
  --vnet kunden-a \
  --zone vlan-existing \
  --tag 20

VM einer SDN-VNet zuweisen

# VM 101 ins prod-vms-Netz
qm set 101 -net0 virtio,bridge=prod-vms

# VM 102 in die DMZ
qm set 102 -net0 virtio,bridge=dmz

Isolation verifizieren

# Auf Node 1: VM im prod-vms-Netz anpingen
# Auf Node 2: VM im dmz-Netz — sollte NICHT erreichbar sein ohne Routing

# VXLAN-Traffic sichtbar machen
tcpdump -i any udp port 4789 -n

Stolpersteine

MTU-Probleme: VXLAN fügt 50 Byte Overhead hinzu. Wenn die physische MTU 1500 ist, muss die VM-MTU auf 1450 gesetzt werden — sonst stille Paketverluste bei großen Transfers.

# MTU auf VM-Bridge setzen
ip link set dev prod-vms mtu 1450
# Persistent in /etc/network/interfaces via post-up

Firewall blockiert UDP 4789: Wenn zwischen Nodes eine Firewall sitzt, muss UDP 4789 (VXLAN) erlaubt sein. Sonst keine Kommunikation zwischen VMs auf verschiedenen Nodes.

SDN-Konfiguration nach Node-Reboot: pvesh set /cluster/sdn muss nach Änderungen aufgerufen werden. Die Konfiguration wird automatisch beim Booten angewendet — aber nur wenn sie committed wurde.

Im nächsten Teil konfigurieren wir die Proxmox-Firewall auf allen drei Ebenen und nutzen dabei die Netzwerksegmentierung aus Teil 1 und 2.