Solange ein Betrieb einen einzigen Proxmox-Server hat, ist das Netzwerk schnell erklärt: Die virtuellen Maschinen hängen an einer Bridge, vielleicht noch mit ein paar VLANs für Server, Büro und Kasse. Kommen ein zweiter und dritter Server dazu oder ein zweiter Standort, wird es mühsamer. Jedes neue Netz muss auf jedem Server und auf jedem Switch angelegt werden, und eine virtuelle Maschine kann nur dorthin umziehen, wo ihr Netz auch existiert. Genau dafür gibt es in Proxmox VE das Software-Defined Networking, kurz SDN.
Was das SDN in Proxmox macht
Mit dem SDN legen Sie Netze einmal zentral für den ganzen Cluster an, im Menü unter Rechenzentrum und SDN. Proxmox verteilt die Einstellungen dann auf alle Server. Seit Version 8.1 sind die nötigen Pakete bei jeder Installation dabei. Wer von einer älteren Version aktualisiert hat, sollte prüfen, ob in der Datei /etc/network/interfaces die Zeile source /etc/network/interfaces.d/* steht, denn dort schreibt das SDN seine Netze hinein.
Das SDN kennt drei Begriffe. Eine Zone legt fest, wie die Netze technisch transportiert werden. Ein VNet ist ein einzelnes Netz in dieser Zone, an das Sie virtuelle Maschinen hängen. Ein Subnetz gibt dem VNet einen IP-Bereich und auf Wunsch ein Gateway. Änderungen gelten erst, wenn Sie auf Anwenden klicken. So können Sie mehrere Netze vorbereiten und auf einmal ausrollen.
VLAN reicht, solange kein Router zwischen den Servern sitzt
Die einfachste Zone ist die VLAN-Zone. Sie nutzt eine vorhandene Bridge und trennt die Netze über VLAN-Nummern. Das funktioniert auch über mehrere Switches hinweg, solange die VLANs auf allen Verbindungen zwischen den Switches durchgereicht werden und die Server im selben Layer-2-Netz stehen. Für die meisten kleinen Cluster ist das die richtige Wahl. Schluss ist, sobald zwischen den Servern geroutet wird, etwa weil sie in verschiedenen IP-Netzen oder an verschiedenen Standorten stehen. VLANs kommen über einen Router nicht hinweg. Außerdem muss jedes neue VLAN auf allen Switches eingerichtet werden. Bei drei Netzen ist das kein Problem, bei zwanzig wird es fehleranfällig.
VXLAN: Netze als Tunnel über das vorhandene Netzwerk
Eine VXLAN-Zone verpackt den Verkehr der virtuellen Maschinen in UDP-Pakete auf Port 4789 und schickt sie über das vorhandene Netzwerk zu den anderen Servern. Die Server müssen sich dafür nur per IP erreichen können, auch über Router hinweg. Die Switches und Router dazwischen müssen von den einzelnen Netzen nichts wissen. Ein neues VNet ist damit in Proxmox angelegt, ohne dass jemand am Switch etwas ändert. In der Zone tragen Sie die IP-Adressen aller beteiligten Server ein, in jedem VNet eine eigene Nummer, die VXLAN-ID.
In der Konfiguration unter /etc/pve/sdn sieht das zum Beispiel so aus:
vxlan: buero
peers 10.10.0.11,10.10.0.12,10.10.0.13
mtu 1450
vnet: kasse
zone buero
tag 100010
Zwei Dinge werden dabei gern übersehen. Erstens die MTU: Die VXLAN-Verpackung kostet 50 Byte. Bei einem normalen Netzwerk mit 1500 Byte bekommen die virtuellen Maschinen also nur 1450 Byte. Stimmt das nicht, laufen einfache Tests wie ein Ping, aber große Übertragungen brechen ab oder hängen. Besser ist es, wenn die Switches größere Pakete (Jumbo Frames) erlauben und die Server untereinander mit einer höheren MTU arbeiten. Zweitens verschlüsselt VXLAN nichts. Innerhalb eines Serverraums ist das in Ordnung. Zwischen zwei Standorten gehört der Tunnel in ein VPN. Seit Proxmox VE 9.2 kann das SDN dafür auch selbst verschlüsselte Verbindungen zwischen den Servern per WireGuard aufbauen.
EVPN mit BGP: wenn die Netze auch geroutet werden sollen
Reines VXLAN verbindet die Netze auf Ebene 2, als hingen alle Maschinen am selben Switch. Sobald Verkehr zwischen zwei VNets fließen soll oder ins Internet, braucht es einen Router. In einer EVPN-Zone übernimmt das Proxmox selbst. Die Server tauschen per BGP untereinander aus, welche virtuelle Maschine mit welcher MAC- und IP-Adresse gerade auf welchem Server läuft. Dafür läuft auf jedem Server die Routing-Software FRRouting.
Das bringt zwei Vorteile. Jeder Server ist für seine Maschinen gleichzeitig das Gateway, mit derselben IP-Adresse auf allen Servern (Anycast-Gateway). Verkehr zwischen zwei Netzen wird also direkt dort geroutet, wo die Maschine läuft, und muss nicht erst zu einem zentralen Router. Und eine Maschine behält bei einer Live-Migration ihr Gateway, weil es auf dem Zielserver dieselbe Adresse hat.
Für die Verbindung nach draußen legen Sie Exit-Nodes fest. Das sind die Server, die den Weg ins restliche Netzwerk kennen und ihn den anderen mitteilen. Mit einem zusätzlichen BGP-Controller können diese Exit-Nodes die Netze der virtuellen Maschinen an Ihren Router oder Ihre Firewall melden. Dann weiß auch das Büro-Netz, wie es die Server erreicht, ohne dass jemand statische Routen pflegen muss. Für die BGP-Nummern (ASN) empfiehlt Proxmox die privaten Bereiche, etwa 65000.
Damit das funktioniert, wird auf allen Servern das Paket frr-pythontools installiert und der Dienst frr aktiviert. Wichtig für den Einsatz im Betrieb: Das Routing über FRRouting und die Controller führt Proxmox noch als Tech Preview, also als Vorabversion. Das Gleiche gilt für die automatische IP-Verwaltung mit DHCP für virtuelle Maschinen. Laufen kann das, aber wer es produktiv nutzt, sollte es vorher gründlich testen und die Updates von Proxmox im Blick behalten.
Bis zur Firewall und zum Switch: OPNsense und Hardware-VTEPs
Die Netze müssen nicht an den Proxmox-Servern enden. Bei einer OPNsense als Firewall ist der saubere Weg das Routing per BGP. Die Exit-Nodes melden die Netze der virtuellen Maschinen über den BGP-Controller an die OPNsense, die dafür das Plugin os-frr bekommt. Die OPNsense kennt damit alle VM-Netze, routet den Verkehr aus dem Büro dorthin und filtert ihn mit ihren eigenen Regeln. Über Route-Maps und Prefix-Listen legen Sie auf beiden Seiten fest, welche Netze angenommen werden. Selbst Mitglied der EVPN-Zone kann die OPNsense nicht werden, denn ihr Routing-Plugin spricht BGP, OSPF und RIP, aber kein EVPN.
Ein VXLAN direkt bis zur OPNsense ist ebenfalls möglich, dort unter den Schnittstellen als eigener Typ. Die Einschränkung steckt im darunterliegenden FreeBSD: Im Unicast-Betrieb sendet eine VXLAN-Schnittstelle an genau eine Gegenstelle. Broadcasts wie ARP-Anfragen erreichen dann nur einen Proxmox-Server, und Maschinen auf den anderen Servern sind nicht zuverlässig erreichbar. Mehrere Gegenstellen gehen nur über Multicast im Netz darunter, das SDN von Proxmox arbeitet bei VXLAN aber mit einer festen Liste von Gegenstellen. Bei einem einzelnen Proxmox-Server funktioniert der direkte Tunnel, bei einem Cluster ist BGP der bessere Weg.
Switches, die VXLAN selbst beherrschen, können als Hardware-VTEP noch einen Schritt weiter gehen. Sie hängen ein VLAN am Switch an dieselbe VXLAN-ID wie ein VNet in Proxmox. Drucker, Kassen oder Telefone an diesem Switch landen dann im selben Netz wie die virtuellen Maschinen, egal auf welchem Server diese gerade laufen. Mit statischem VXLAN tragen Sie dazu den Switch in die Liste der Gegenstellen in Proxmox ein und alle Proxmox-Server in die Liste am Switch. Beherrscht der Switch EVPN, tauscht er die Adressen per BGP direkt mit dem EVPN-Controller von Proxmox aus. Dann müssen ASN, VXLAN-IDs und Route-Targets auf beiden Seiten zusammenpassen. Proxmox leitet die Route-Targets automatisch ab, für abweichende Werte gibt es in der EVPN-Zone die Einstellung Route-target Import. Weil EVPN in Proxmox noch Vorabversion ist und die Hersteller EVPN unterschiedlich umsetzen, sollte das Zusammenspiel vorher im Testaufbau laufen.
Wann sich das für einen kleinen Betrieb lohnt
Für einen einzelnen Proxmox-Server brauchen Sie kein SDN. Stehen alle Server im selben Layer-2-Netz, auch verteilt auf mehrere Switches, ist die VLAN-Zone meist die beste Wahl, weil sie einfach ist und keine Vorabfunktionen nutzt. VXLAN lohnt sich, wenn zwischen den Servern geroutet wird, wenn Sie viele Netze brauchen oder den Switch nicht für jedes neue Netz anfassen möchten. EVPN mit BGP spielt seine Stärken aus, wenn mehrere Standorte zusammenkommen, wenn virtuelle Maschinen zwischen Standorten umziehen sollen oder wenn ohnehin schon ein Router mit BGP im Netz steht.
Egal welche Zone: Schalten Sie für die VNets die Proxmox-Firewall ein. Laut Dokumentation reicht die Isolierung einzelner Ports nicht aus, sobald Netze über mehrere Server laufen. Die Regeln für das VNet sorgen dafür, dass etwa die Server mit den Kassendaten nicht aus jedem anderen VNet erreichbar sind.
Proxmox-Cluster und Netzwerk mit ITHeld24
Wir planen und betreuen Proxmox-Umgebungen für kleine Betriebe, vom einzelnen Server bis zum Cluster über mehrere Standorte, und richten das Netzwerk so ein, dass es zu Ihrem Betrieb passt und nicht komplizierter wird als nötig. Wie wir mehrere Standorte ausfallsicher verbinden, zeigt unser Projekt mit einem Gastronomiebetrieb, dessen drei Außenstellen über ein Mesh-VPN mit OSPF verbunden sind. Mehr dazu auf unserer Seite zur EDV-Infrastruktur und in unseren Referenzen.
Rufen Sie uns an unter 0361 34949224 oder schreiben Sie uns über das Kontaktformular. Im kostenlosen EDV-Check schauen wir gemeinsam auf Ihre Server und Ihr Netzwerk.