Proxmox VE-Netzwerke erklärt: Bridges, Bonds und VLANs

Die Antwort zuerst: das eine mentale Modell

Proxmox-VE-Netzwerk ist Linux-Netzwerk, aufgebaut um eine Idee: virtuelle Maschinen und Container stecken ihre virtuellen NICs in Software-Switches namens Linux-Bridges. Die Standard-Bridge, vmbr0, wird bei der Installation angelegt und mit Ihrer physischen NIC verbunden; das ist der einzige Grund, warum Ihre erste VM das Internet erreichen konnte.

Jedes Setup in der Praxis ist eine Variation davon, womit diese Bridges verbunden sind:

• Bridged: Die VM steht direkt am physischen Netzwerk mit eigener öffentlicher IP und MAC. Am einfachsten, aber bei einem Hosting-Provider braucht es dafür vom Provider freigegebene zusätzliche IPs/MACs.
• Routed: Der Host besitzt die öffentlichen Adressen und routet den Traffic zu den VMs. Funktioniert überall, keine MAC-Beschränkungen, etwas mehr Konfiguration.
• NAT / privat: VMs leben auf einer privaten Bridge und teilen sich für ausgehenden Traffic die IP des Hosts. Richtig für VMs, die nicht öffentlich erreichbar sein müssen.

Die Konfiguration liegt in einer gut lesbaren Datei, /etc/network/interfaces, und weil Proxmox ifupdown2 verwendet, greifen Änderungen live mit ifreload -a (oder über "Apply Configuration" in der GUI), ohne Neustart. Dieser Artikel setzt eine funktionierende Installation voraus; sind Sie noch nicht so weit, beginnen Sie mit unserem Proxmox-VE-Einrichtungsleitfaden, der vmbr0 kurz vorstellt; hier folgt jetzt die versprochene Vertiefung. Die Adressen unten sind Dokumentationsbereiche (203.0.113.0/24, 10.0.0.0/24); ersetzen Sie sie durch Ihre eigenen.

Anatomie von vmbr0

Bei einer frischen Installation sieht /etc/network/interfaces im Kern so aus:

auto lo
iface lo inet loopback

iface enp1s0 inet manual

auto vmbr0
iface vmbr0 inet static
    address 203.0.113.10/24
    gateway 203.0.113.1
    bridge-ports enp1s0
    bridge-stp off
    bridge-fd 0

Lesen Sie es von unten nach oben, dann ergibt das Modell Sinn: Die physische NIC (enp1s0) trägt selbst keine IP; sie ist rein ein Bridge-Port. Die Bridge besitzt die IP-Adresse des Hosts und den Uplink. VMs hängen ihre virtuellen NICs (tap-Geräte) an dieselbe Bridge, wodurch diese zu einem unmanaged Switch wird, mit der physischen NIC als Uplink-Port. Alles Weitere in diesem Artikel bedeutet: mehr Bridges hinzufügen, Traffic darauf taggen oder ändern, was sie speist.

Die drei Muster auf einem gehosteten Server

An Ihrem eigenen Switch zu Hause funktioniert Bridged Networking einfach so. Bei einem Dedicated Server bei einem Provider gibt es eine Einschränkung zu beachten: Access-Switches im Rechenzentrum erzwingen üblicherweise MAC-Filterung; Traffic von MAC-Adressen, die der Provider auf Ihrem Port nicht erwartet, wird verworfen. Diese eine Tatsache entscheidet, welches Muster passt:

Bridged: VMs mit eigener öffentlicher IP

Jede VM bekommt eine öffentliche IP, und ihre virtuelle MAC erscheint auf dem Switch des Providers. Das erfordert zusätzliche IPs, die der Provider Ihrem Server zuweist, wobei die MAC der VM dort registriert wird, wo der Provider es verlangt (manche vergeben eine MAC pro IP, manche akzeptieren jede MAC auf Ihrem Port für geroutete Subnetze). Wo das unterstützt wird (wie in unserem Netzwerk, wo zusätzlicher IP-Raum zum Server dazugehört), ist das die sauberste Lösung: Die VM-Konfiguration lautet schlicht "an vmbr0 anbinden, die zugewiesene IP und dasselbe Gateway wie der Host einstellen".

Routed: funktioniert unter jeder MAC-Richtlinie

Auf der Leitung erscheint immer nur die MAC des Hosts; der Host routet für seine VMs. Skizze: öffentliches Subnetz 203.0.113.64/26, geroutet zu Ihrem Server:

auto vmbr1
iface vmbr1 inet static
    address 203.0.113.65/26
    bridge-ports none
    bridge-stp off
    bridge-fd 0

bridge-ports none ist der Kniff, den man sich merken sollte: eine Bridge ohne physischen Port ist ein rein interner Switch. VMs auf vmbr1 nutzen 203.0.113.65 als Gateway; der Host leitet zwischen vmbr1 und dem Uplink weiter (net.ipv4.ip_forward in /etc/sysctl.d/ aktivieren). Der Switch des Providers sieht ausschließlich den Host.

NAT: private VMs mit Zugang nach außen

Dieselbe portlose Bridge mit einem privaten Bereich (10.0.0.1/24 auf der Bridge), dazu eine Masquerade-Regel, damit VMs sich für ausgehenden Traffic die öffentliche IP des Hosts teilen. Richtig für Build-VMs, Datenbanken, die nur andere VMs bedienen, und Lab-Gäste. Eingehender Zugriff, falls nötig, läuft über Port-Forwarding (DNAT) auf dem Host; wird viel weitergeleitet, sollten Sie überlegen, ob die VM nicht einfach eine geroutete öffentliche IP will.

Frei kombinierbar: Ein typischer Host betreibt vmbr0 (öffentlich, bridged) und eine private Bridge für Backend-Traffic zwischen den Gästen.

VLANs: eine Bridge, viele Netzwerke

Das moderne Muster ist die VLAN-aware Bridge, ein einziges Flag auf vmbr0:

auto vmbr0
iface vmbr0 inet static
    address 203.0.113.10/24
    gateway 203.0.113.1
    bridge-ports enp1s0
    bridge-stp off
    bridge-fd 0
    bridge-vlan-aware yes
    bridge-vids 2-4094

Jetzt lässt die Bridge getaggten Traffic durch, und Sie setzen den VLAN Tag pro virtueller NIC in den Hardware-Optionen der VM; die Bridge übernimmt das Taggen/Untaggen, die Gäste bekommen davon nichts mit. Verglichen mit dem älteren Stil einer Bridge pro VLAN (vmbr0v40 und Verwandte) ist das eine Bridge statt einem Dutzend, und keine Host-Konfigurationsänderung, wenn Sie ein neues VLAN einführen: neuen Tag vergeben, fertig. Gäste, die Trunks brauchen (etwa eine Firewall-VM), können ebenfalls direkt getaggten Traffic empfangen.

Wo VLANs auf einen Hosting-Provider treffen: Sie segmentieren Traffic nur dort, wo die Infrastruktur die Tags trägt. Innerhalb Ihres Hosts immer; zwischen Ihren Servern nur, wenn das private Netzwerk des Providers sie erhält (bei uns ist das der Fall; VLANs über das private LAN sind der Weg, wie Kunden segmentierte Multi-Host-Netzwerke aufbauen; es ist auch der Mechanismus hinter Kunden-DMZs).

Bonding: zwei NICs, ein logischer Uplink

Bonds bündeln physische NICs für Redundanz (und manchmal Bandbreite). Der Bond wird zum Port der Bridge:

auto bond0
iface bond0 inet manual
    bond-slaves enp1s0 enp2s0
    bond-miimon 100
    bond-mode 802.3ad
    bond-xmit-hash-policy layer3+4

auto vmbr0
iface vmbr0 inet static
    address 203.0.113.10/24
    gateway 203.0.113.1
    bridge-ports bond0
    ...

Die Moduswahl ist einfacher, als die sieben Optionen vermuten lassen, und die offizielle Dokumentation ist eindeutig: 802.3ad (LACP) verwenden, wenn Ihr Switch das unterstützt; sonst active-backup. LACP braucht eine passende Konfiguration auf dem Switch des Providers (bei einem Dedicated Server heißt das: etwas, das mit Ihrem Host abzustimmen ist, nicht einfach lokal einzuschalten); active-backup funktioniert mit jedem Switch und liefert reines Failover. Beachten Sie, dass ein einzelner TCP-Flow unter LACP nie die Geschwindigkeit einer physischen Verbindung übersteigt; Bonding vervielfacht die aggregierte Bandbreite, nicht die pro Flow. Und wenn Sie später clustern: Corosync mag manche Bond-Modi nicht; geben Sie dem Cluster-Traffic eine eigene ungebondete NIC oder active-backup.

Wo die SDN-Schicht ansetzt

Alles oben konfiguriert einen einzelnen Host. Die SDN-Funktion von Proxmox (vollständig unterstützter Kernbestandteil seit 8.1, konfiguriert unter Datacenter → SDN) wendet Netzwerkdefinitionen clusterweit an: Eine Zone und ihre VNets werden einmal definiert, und jeder Node bietet sie konsistent an. Die Zonentypen entsprechen dem jeweiligen Anspruch:

• Simple: isolierte Bridges pro Node mit optionalem, clusterverwaltetem IPAM/DHCP; die verwaltete Version von bridge-ports none.
• VLAN: das VLAN-Setup von oben, einmal für den gesamten Cluster definiert.
• QinQ: gestapelte VLAN-Tags, für den Fall, dass Sie VLANs an Mandanten weitergeben.
• VXLAN: Layer-2-Netzwerke, getunnelt über beliebige Layer-3-Verbindungen zwischen Nodes; die Standardantwort auf "ein privates Netzwerk, das Server ohne gemeinsamen Switch überspannt". MTU beachten: VXLAN kostet 50 Byte Overhead, also entweder die MTU des Underlay anheben oder die des VNets senken.
• EVPN: VXLAN plus BGP-basierte Control Plane und verteiltes Routing; Rechenzentrums-Fabric-Territorium.

Faustregel: einzelner Host oder eine Handvoll statischer Bridges → einfach /etc/network/interfaces, dieser Artikel. Cluster mit mehr als ein paar gemeinsamen Netzwerken, oder jede Form von Mandantenfähigkeit → einmal in SDN definieren. (PVE 9 hat "Fabrics" hinzugefügt, automatisch konfigurierte geroutete Underlays, ein Hinweis darauf, wohin sich diese Schicht entwickelt.)

Sich nicht selbst aussperren

Jede Horrorgeschichte über Proxmox-Netzwerke ist dieselbe Geschichte: eine Bridge-Änderung, angewendet auf die Schnittstelle, über die die SSH-Sitzung läuft. Die Disziplinen:

• Live und atomar anwenden. /etc/network/interfaces bearbeiten, dann ifreload -a (ifupdown2 wendet das Delta live an). Der Pending-Changes-plus-"Apply Configuration"-Ablauf der GUI macht dasselbe, mit einem Kontrollschritt dazwischen.
• Die Konsole bereithalten, bevor Sie sie brauchen. IPMI-/KVM-over-IP-Zugriff (bei unseren Servern inklusive) macht aus "ich habe mir den Uplink weggebridged" statt eines Ausfalls eine Zwei-Minuten-Korrektur an der Konsole. Prüfen Sie Ihren Zugriff, bevor Sie etwas ändern.
• Eine Schicht nach der anderen ändern. Erst den Bond, prüfen; dann die Bridge auf den Bond legen; dann die VLANs. Zusammengesetzte Änderungen erzeugen zusammengesetzte Fehlerbilder.
• Den Host nicht versehentlich firewallen. Proxmox hat eine eigene Firewall (Ebenen Datacenter → Node → VM). Wenn Sie sie aktivieren, bestätigen Sie zuerst die Management-Regeln (SSH, 8006), bevor Sie sie auf Node-Ebene anwenden. Dieselbe Aussperr-Logik wie in unserem Leitfaden zu Firewall-Grundregeln, eine Ebene höher.

Häufig gestellte Fragen

Sollte ich Linux-Bridges oder Open vSwitch verwenden?

Linux-Bridges, außer Sie haben eine konkrete OVS-Anforderung. Sie sind Proxmox' Standardweg und am besten dokumentiert, das VLAN-aware-Flag deckt die Segmentierungsfälle ab, für die früher OVS bemüht wurde, und die gesamte SDN-Schicht baut auf Linux-Bridges mit ifupdown2 auf. OVS bleibt für alle unterstützt, die dessen Extras brauchen, aber bei einem typischen Dedicated-Server-Einsatz bringt es zusätzliche Komplexität, ohne Funktionen zu liefern, die Sie tatsächlich nutzen.

Wie gebe ich einer VM ihre eigene öffentliche IP?

Zwei Wege. Bridged: Die VM an vmbr0 anbinden und eine zusätzliche IP konfigurieren, die Ihr Provider Ihrem Server zugewiesen hat (unter Einhaltung von dessen MAC-Richtlinie; in unserem Netzwerk gehören zusätzliche IPs zum Server dazu, und das ist die Standardlösung). Routed: Die MAC-Adresse zum Provider hin bleibt die des Hosts, VMs stehen hinter einer internen Bridge, und das Subnetz wird zu ihnen geroutet. Funktioniert unter jeder Switch-Richtlinie, auf Kosten dessen, dass der Host das Forwarding übernimmt.

Warum ist das Netzwerk meiner VM ausgefallen, als ich VLAN-Tagging aktiviert habe?

Fast immer einer von drei Gründen: Die Bridge ist nicht VLAN-aware (bridge-vlan-aware yes fehlt), der physische Pfad transportiert den Tag nicht (der Switch des Providers oder das private LAN muss dieses VLAN durchlassen), oder es liegt ein MTU-Mismatch beim Tunneling vor (die 50 Byte Overhead von VXLAN). Debuggen Sie in dieser Reihenfolge: erst die Bridge-Flags, dann den Tag-Transport von Ende zu Ende mit tcpdump -e vlan, dann die MTU mit einem Do-not-fragment-Ping in der Größe des Limits.

Braucht irgendetwas davon einen Cluster?

Nein. Alles bis zum SDN-Abschnitt ist Single-Host. SDN funktioniert auch auf einem einzelnen Node (Simple-Zonen mit verwaltetem DHCP sind auch solo wirklich nützlich), aber der Nutzen wächst mit der Anzahl der Nodes. Steht Clustering auf Ihrer Roadmap, lohnt sich früh die Netzwerkentscheidung, eine NIC (oder zumindest ein VLAN) für den Cluster-Traffic zu reservieren: Corosync will niedrige Latenz und verträgt sich schlecht mit konkurrierendem VM-Massenverkehr; Details in unserem Leitfaden zu Cluster und HA.

Deployment bei Serverside

Die Muster in diesem Leitfaden übertragen sich direkt auf das, was ein Proxmox Dedicated Server von uns bietet: zusätzlicher öffentlicher IP-Raum für bridged VMs, privates Networking zwischen Ihren Servern, das Ihre VLANs trägt (die oben beschriebenen Multi-Host-Segmentierungs- und DMZ-Muster), KVM-over-IP für furchtlose Netzwerkänderungen, und durchgehende DDoS-Mitigation vor allem anderen, bereitgestellt mit vorinstalliertem Proxmox VE in unter einer Minute auf ASN 55285.

Setzen Sie die Serie fort mit wie Sie Ihre ersten VMs und Container einrichten, LXC vs. KVM: wann Sie was nutzen und Backup-Strategien mit vzdump und PBS.