Proxmox-Netz auf einem Root-Server: eine öffentliche IP, viele VMs

Zu Hause hängt ein Proxmox-Knoten an einem Router, der Adressen verteilt, und jede VM ist einfach im Netz. Auf einem gemieteten Root-Server ist das anders: Du bekommst eine öffentliche IP, vielleicht ein paar zusätzliche, und der Hoster lässt oft nur Verkehr durch, der von der bekannten MAC-Adresse des Servers kommt. Dahinter ein internes Netz mit NAT aufzubauen ist der übliche Weg, und er ist mit ein paar Zeilen in /etc/network/interfaces erledigt.

Vor jeder Änderung: der Weg zurück

Ein Fehler in der Netzkonfiguration sperrt dich aus. Vorher prüfen, dass die Konsole (KVM/IPMI) oder das Rettungssystem deines Anbieters funktioniert, und die alte Datei sichern: cp /etc/network/interfaces /root/interfaces.vorher. Proxmox nutzt ifupdown2; ifreload -a übernimmt Änderungen ohne Neustart.

Der Ausgangspunkt: eine Bridge mit der öffentlichen IP#

Nach der Installation hängt die öffentliche Adresse meist schon an vmbr0:

# /etc/network/interfaces (Ausschnitt)
auto lo
iface lo inet loopback

iface eno1 inet manual

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

Adressen und Schnittstellennamen hier sind Beispiele. Eine VM, die du direkt an vmbr0 hängst, würde mit ihrer eigenen MAC-Adresse nach außen sprechen, und genau das blockieren viele Hoster. Deshalb das interne Netz.

Internes Netz mit NAT#

Eine zweite Bridge ohne physische Schnittstelle, mit einer privaten Adresse, und der Knoten leitet den Verkehr nach außen weiter und übersetzt die Absenderadresse:

auto vmbr1
iface vmbr1 inet static
    address 10.10.10.1/24
    bridge-ports none
    bridge-stp off
    bridge-fd 0
    post-up   echo 1 > /proc/sys/net/ipv4/ip_forward
    post-up   iptables -t nat -A POSTROUTING -s 10.10.10.0/24 -o vmbr0 -j MASQUERADE
    post-down iptables -t nat -D POSTROUTING -s 10.10.10.0/24 -o vmbr0 -j MASQUERADE

ifreload -a

VMs hängst du jetzt an vmbr1 und gibst ihnen Adressen aus 10.10.10.0/24 mit Gateway 10.10.10.1, von Hand oder per Cloud-Init. Einen DHCP-Server gibt es auf vmbr1 nicht, außer du richtest einen ein.

Mit aktivierter Proxmox-Firewall

Ist die Proxmox-Firewall für die VMs aktiv, braucht NAT eine Ergänzung, sonst gehen Antworten verloren. Die Proxmox-Dokumentation nennt dafür Verbindungszonen:

post-up iptables -t raw -I PREROUTING -i fwbr+ -j CT --zone 1
post-down iptables -t raw -D PREROUTING -i fwbr+ -j CT --zone 1

Mehr zur Firewall selbst in Proxmox-Firewall und SDN.

Ports weiterleiten#

Ein Webserver in der VM 10.10.10.21 soll von außen erreichbar sein:

    post-up   iptables -t nat -A PREROUTING -i vmbr0 -p tcp --dport 443 -j DNAT --to 10.10.10.21:443
    post-down iptables -t nat -D PREROUTING -i vmbr0 -p tcp --dport 443 -j DNAT --to 10.10.10.21:443

Für mehr als eine Handvoll Dienste ist ein Reverse-Proxy in einer eigenen VM die bessere Lösung: ein weitergeleiteter Port (443), dahinter verteilt der Proxy nach Hostnamen.

Zusätzliche öffentliche IPs: routen statt brücken#

Hast du beim Hoster zusätzliche Adressen gebucht, gibt es zwei Wege:

Weg	Wie	Wann
Gebrückt mit virtueller MAC	Hoster vergibt eine MAC je IP, VM hängt an `vmbr0`	wenn der Hoster virtuelle MACs anbietet
Geroutet	IP wird auf dem Knoten an eine Bridge geroutet	wenn nur die Server-MAC erlaubt ist

Geroutet sieht so aus, am Beispiel einer einzelnen Zusatzadresse 203.0.113.50:

auto vmbr2
iface vmbr2 inet static
    address 203.0.113.10/32
    bridge-ports none
    bridge-stp off
    bridge-fd 0
    up ip route add 203.0.113.50/32 dev vmbr2

Die VM an vmbr2 bekommt 203.0.113.50/32 mit Gateway 203.0.113.10 und eine Route dorthin. Der Knoten muss IP-Weiterleitung aktiv haben (siehe oben). Die genaue Form hängt vom Hoster ab; viele beschreiben ihr geroutetes Setup in der eigenen Dokumentation, und die hat Vorrang vor diesem Beispiel.

VLANs für getrennte Netze#

Willst du Netze trennen, etwa Verwaltung, Kunden und Datenbanken, brauchst du nicht für jedes eine eigene Bridge. Eine VLAN-fähige Bridge reicht:

auto vmbr1
iface vmbr1 inet static
    address 10.10.10.1/24
    bridge-ports none
    bridge-stp off
    bridge-fd 0
    bridge-vlan-aware yes
    bridge-vids 2-4094

In der VM-Konfiguration trägst du dann an der Netzwerkkarte ein VLAN Tag ein. VMs mit demselben Tag sehen sich, andere nicht. Damit Verkehr zwischen den VLANs fließt, braucht es einen Router, etwa eine eigene Firewall-VM oder Routen auf dem Knoten. Für größere Aufbauten ist das SDN von Proxmox der aufgeräumtere Weg.

IPv6 nicht vergessen#

Die meisten Hoster geben ein IPv6-Netz dazu, oft ein /64. Damit bekommt jede VM eine eigene öffentliche Adresse ohne NAT. Wichtig: Dann ist jede VM auch direkt aus dem Internet erreichbar, und die Firewall muss für IPv6 genauso gepflegt werden wie für IPv4. Mehr in IPv6 auf dem VPS.

Häufige Fragen#

Die VM erreicht das Internet nicht.#

Drei Prüfungen in dieser Reihenfolge: cat /proc/sys/net/ipv4/ip_forward auf dem Knoten zeigt 1? iptables -t nat -L -n -v zeigt die MASQUERADE-Regel mit steigenden Zählern? Hat die VM 10.10.10.1 als Gateway und einen funktionierenden DNS-Server?

Nach einem Neustart ist die Weiterleitung weg.#

Dann stehen die Regeln nicht als post-up in der Bridge-Definition, sondern wurden nur von Hand gesetzt. Alles, was den Neustart überleben soll, gehört in /etc/network/interfaces.

iptables oder nftables?#

Die post-up-Zeilen oben nutzen die iptables-Befehle, die unter Debian auf nftables übersetzt werden. Das funktioniert und ist der Weg, den die Proxmox-Dokumentation zeigt. Wer ohnehin nftables pflegt, kann die Regeln dort anlegen, sollte dann aber nicht beides mischen.

Kann ich die Weboberfläche nur intern erreichbar machen?#

Ja, und das ist empfehlenswert: Port 8006 von außen sperren und über WireGuard zugreifen.

Kurz gesagt#

Öffentliche IP an vmbr0, VMs an eine interne Bridge vmbr1 mit NAT.
Alles in /etc/network/interfaces als post-up, damit es den Neustart überlebt.
Mit Proxmox-Firewall: Verbindungszonen ergänzen.
Zusätzliche IPs geroutet, wenn der Hoster nur eine MAC erlaubt.
Vor jeder Änderung: Konsole prüfen, alte Datei sichern, ifreload -a.