Wer im Homelab oder in einer kleinen Verwaltung mehrere getrennte Netze braucht – für Test-VMs, Mandanten oder eine kleine DMZ –, stößt mit zusätzlichen Bridges und VLAN-Interfaces auf dem Hypervisor schnell an Grenzen. Proxmox VE bringt dafür Software-Defined Networking mit: Zonen, virtuelle Netze (VNets) und Subnetze werden zentral im Cluster definiert und auf jedem Knoten als normale Linux-Bridge bereitgestellt.

Was SDN in Proxmox VE leistet

Eine Zone ist ein abgegrenzter Netzbereich, ein VNet ein virtuelles Netz innerhalb dieser Zone, ein Subnetz ein IP-Bereich im VNet. Seit Proxmox VE 8.1 sind die SDN-Kernpakete vorinstalliert; bei älteren Installationen muss libpve-network-perl auf jedem Knoten nachinstalliert werden.

Die Konfiguration liegt unter /etc/pve/sdn und wird über das Cluster-Dateisystem verteilt. Änderungen werden zunächst als „pending“ gesammelt und dann gemeinsam angewendet; den ausgerollten Stand halten die Dateien .running-config und .version fest. Das ist der entscheidende Unterschied zu handgeschriebenen Interface-Dateien: Der Rollout erfolgt atomar und ist nachvollziehbar.

Voraussetzungen prüfen

# auf jedem Knoten ausführen
pveversion
dpkg -l ifupdown2 libpve-network-perl | grep ^ii
tail -3 /etc/network/interfaces   # muss "source /etc/network/interfaces.d/*" enthalten

Die Bridge, auf der die VLAN-Zone aufsetzt (typisch vmbr0), muss VLAN-Tags durchreichen – bei Linux-Bridges über die Option „VLAN aware“, und der Switch-Port muss die Tags als Trunk führen. Fehlt das, funktioniert das Netz lokal, aber nicht über Knoten- oder Switchgrenzen hinweg.

Zone und VNet anlegen

Im Web-Interface unter Datacenter → SDN → Zones eine Zone vom Typ VLAN erstellen: ID myvlanzone, Bridge vmbr0, dazu die Knoten auswählen, auf denen das Netz verfügbar sein soll. Danach unter VNets ein VNet mit maximal acht Zeichen ID anlegen (etwa vnet1) und Zone sowie VLAN-Tag 10 zuweisen. Der Tag bestimmt die Isolation: Ein zweites VNet mit Tag 20 ergibt ein getrenntes Segment auf derselben Bridge.

Derselbe Weg per CLI:

pvesh create /cluster/sdn/zones --zone myvlanzone --type vlan --bridge vmbr0 --nodes pve1,pve2
pvesh create /cluster/sdn/vnets --vnet vnet1 --zone myvlanzone --tag 10 --alias "Labor VLAN 10"
pvesh set /cluster/sdn          # pending-Änderungen anwenden
pvesh get /cluster/sdn/vnets    # Kontrolle

Erst mit dem Anwenden entsteht auf den Knoten die Bridge vnet1. Sie erscheint danach in der Hardware-Auswahl von VMs und Containern und lässt sich wie jede andere Bridge verwenden.

Subnetz, IPAM und DHCP

Optional wird im VNet ein Subnetz mit CIDR und Gateway hinterlegt, bei Layer-3-Zonen zusätzlich SNAT. Liegt ein Subnetz mit Gateway vor, kann Proxmox Adressen über das eingebaute IPAM verwalten und per DHCP an Gäste ausgeben. Dafür muss auf jedem Knoten dnsmasq installiert und die Standardinstanz deaktiviert werden:

apt install dnsmasq
systemctl disable --now dnsmasq

DHCP-Bereiche werden pro Subnetz gesetzt, wie die Proxmox-Dokumentation es für die API zeigt:

pvesh set /cluster/sdn/vnets/vnet1/subnets/10.0.3.0/24 -dhcp-range start-address=10.0.3.100,end-address=10.0.3.200

Wichtig: IPAM und DHCP stehen bei Proxmox im Status „Tech Preview“. Für eine produktive Adressverwaltung bleibt ein externer DHCP- oder IPAM-Dienst die konservativere Wahl; ohne DHCP werden die Adressen statisch in den Gästen gesetzt.

Prüfen und typische Fehler

ip -br address show vnet1
ip -d link show vnet1
cat /etc/pve/sdn/vnets.cfg
ping -c2 10.0.3.101     # VM auf dem zweiten Knoten

Häufige Ursachen für Probleme: Änderungen wurden angelegt, aber nicht angewendet; die VNet-ID ist länger als acht Zeichen; das VLAN-Tag fehlt am Uplink; oder bei VXLAN-Zonen ist die MTU zu groß (Standard 1450 Byte, also 50 Byte weniger als das physische Interface).

Sicherheitsgewinn und Grenzen

Eine VLAN-Zone trennt Netze auf Layer 2, ersetzt aber keine Firewall. Proxmox bietet pro VNet eine eigene Firewall und die Option „Port Isolation“, die jedoch nur lokal auf jedem Knoten wirkt. Für knotenübergreifende Isolation empfiehlt die Dokumentation, im VNet-Firewall standardmäßig zu verwerfen und nur benötigten Verkehr zuzulassen. Wer eine rein interne Testumgebung ohne Uplink braucht, nimmt eine Simple Zone mit SNAT.

Quellen

Hinweis: Dieser Beitrag wurde mit Unterstützung künstlicher Intelligenz (KI) erstellt.

Tags

No responses yet

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert