Diese Anleitung zeigt, wie man internen VMs einen Internetzugang (für Updates, Paketinstallationen usw.) ermöglicht, ohne sie dem öffentlichen Internet auszusetzen.
Design:
vmbr0 = öffentliche Bridge (am Hetzner‑Uplink)vmbr2 = private Bridge (z. B. 10.20.20.0/24) mit NAT (Masquerade) über vmbr0vmbr2 können miteinander kommunizieren; nur VMs auf vmbr0 sind öffentlich erreichbar.Minimalismus: In der Bridge‑Definition sind nur die MASQUERADE‑Zeilen nötig, sofern die FORWARD‑Policy des Hosts auf ACCEPT steht (Proxmox‑Standard) und IPv4‑Forwarding aktiviert ist.
Dauerhaft aktivieren und anwenden:
# Nur schreiben, wenn nicht bereits an anderer Stelle aktiviert
grep -Rqs '^\s*net\.ipv4\.ip_forward\s*=\s*1\s*$' /etc/sysctl.d/ /etc/sysctl.conf || \
printf 'net.ipv4.ip_forward=1\n' >/etc/sysctl.d/99-forwarding.conf
sysctl --system
Prüfen:
sysctl net.ipv4.ip_forward
# → net.ipv4.ip_forward = 1
iptables -S FORWARD
# Erwarteter Proxmox‑Standard: "-P FORWARD ACCEPT"
Falls die Policy DROP ist, explizite FORWARD‑Regeln hinzufügen (siehe Anhang A).
vmbr0) – meist auf Hetzner‑Templates vorhanden; führt Ihren öffentlichen /26, Gateway über Hetzner.vmbr2) – neu; 10.20.20.1/24, kein physischer Port, NAT über vmbr0./etc/network/interfaces bearbeiten und folgenden Abschnitt hinzufügen/anpassen:
auto vmbr2
iface vmbr2 inet static
address 10.20.20.1/24
bridge-ports none
bridge-stp off
bridge-fd 0
post-up iptables -t nat -A POSTROUTING -s '10.20.20.0/24' -o vmbr0 -j MASQUERADE
post-down iptables -t nat -D POSTROUTING -s '10.20.20.0/24' -o vmbr0 -j MASQUERADE
Anwenden:
ifreload -a # oder: ifdown vmbr2 && ifup vmbr2
Prüfen:
ip -4 addr show vmbr2
iptables -t nat -S | grep POSTROUTING
Nur interne VM: Netzwerkkarte mit vmbr2 verbinden.
DHCP verwenden (siehe §5) oder statisch setzen:
10.20.20.x/2410.20.20.11.1.1.1 (oder Ihr Resolver)Öffentliche VM: Netzwerkkarte mit vmbr0 verbinden und eine öffentliche Adresse aus Ihrem Hetzner‑Block konfigurieren.
Ein kleines DHCP für vmbr2 vereinfacht die Einrichtung.
dnsmasq (leichtgewichtiger DHCP + DNS):
apt update
apt install -y dnsmasq
Datei /etc/dnsmasq.d/vmbr2.conf erstellen:
interface=vmbr2
bind-interfaces
dhcp-range=10.20.20.100,10.20.20.200,12h
dhcp-option=3,10.20.20.1 # Gateway
dhcp-option=6,1.1.1.1,8.8.8.8 # DNS
# (Optional) Statische Lease:
#dhcp-host=BC:24:11:9C:57:1C,10.20.20.50
Starten und aktivieren:
systemctl enable --now dnsmasq
(Hinweis: Wenn Sie später auf OPNsense/pfSense migrieren, läuft DHCP typischerweise in der Firewall‑VM – dann dnsmasq auf dem Host deaktivieren.)
Wenn Sie die integrierte Proxmox‑Firewall auf Datacenter‑ oder Node‑Ebene verwenden:
Sicherstellen, dass das Forwarding von vmbr2 nach vmbr0 nicht blockiert wird.
Für einen schnellen Test kann sie temporär gestoppt werden:
pve-firewall stop
# VM auf vmbr2 testen
pve-firewall start
Benötigte Allow‑Regeln anlegen (z. B. „ausgehend erlauben“ für VMs auf vmbr2).
Auf dem Host:
ip r
iptables -t nat -S | grep MASQUERADE
In einer VM auf vmbr2:
ip a
ip r
ping -c2 10.20.20.1
ping -c2 1.1.1.1
curl -I https://example.com
Wenn dnsmasq verwendet wird, Leases einsehen:
cat /var/lib/misc/dnsmasq.leases
Wenn die FORWARD‑Kette standardmäßig DROP ist, explizite Forward‑Erlaubnisse hinzufügen (einmalig zur Laufzeit oder im vmbr2‑Abschnitt):
# Einmalig (zur Laufzeit)
iptables -A FORWARD -i vmbr2 -o vmbr0 -s 10.20.20.0/24 -m conntrack --ctstate NEW,ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -i vmbr0 -o vmbr2 -d 10.20.20.0/24 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
Um sie mit dem Interface‑Lebenszyklus persistent zu machen, vmbr2 so erweitern:
post-up iptables -C FORWARD -i vmbr2 -o vmbr0 -s 10.20.20.0/24 -m conntrack --ctstate NEW,ESTABLISHED,RELATED -j ACCEPT || iptables -A FORWARD -i vmbr2 -o vmbr0 -s 10.20.20.0/24 -m conntrack --ctstate NEW,ESTABLISHED,RELATED -j ACCEPT
pre-down iptables -D FORWARD -i vmbr2 -o vmbr0 -s 10.20.20.0/24 -m conntrack --ctstate NEW,ESTABLISHED,RELATED -j ACCEPT
post-up iptables -C FORWARD -i vmbr0 -o vmbr2 -d 10.20.20.0/24 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT || iptables -A FORWARD -i vmbr0 -o vmbr2 -d 10.20.20.0/24 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
pre-down iptables -D FORWARD -i vmbr0 -o vmbr2 -d 10.20.20.0/24 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
Tipp für Hetzner: Wenn bei großen Downloads merkwürdige Hänger auftreten, eine MSS‑Klammer setzen:
iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
net.ipv4.ip_forward=1
MASQUERADE‑Regel existiert:
iptables -t nat -S | grep '10.20.20.0/24'
VM hat das richtige Gateway (10.20.20.1) und einen funktionierenden DNS.
Proxmox‑Firewall blockiert FORWARD nicht.
Keine kollidierenden statischen Routen auf dem Host.
Bei VLANs/anderen Bridges MTU prüfen und sicherstellen, dass der Uplink (vmbr0) für den Egress verwendet wird.
Annahmen:
vmbr010.20.20.0/24 auf vmbr210.20.20.5054321 auf der öffentlichen Host‑IP soll auf TCP 22 der VM weitergeleitet werdenMinimale Laufzeit‑Regeln:
# DNAT: eingehend auf vmbr0:54321 zur VM auf Port 22
iptables -t nat -A PREROUTING -i vmbr0 -p tcp --dport 54321 -j DNAT --to-destination 10.20.20.50:22
# Falls FORWARD‑Policy DROP ist, Forwarding explizit erlauben:
iptables -A FORWARD -i vmbr0 -o vmbr2 -p tcp -d 10.20.20.50 --dport 22 -m conntrack --ctstate NEW,ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -i vmbr2 -o vmbr0 -p tcp -s 10.20.20.50 --sport 22 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
Persistenz über den Interface‑Lebenszyklus (zum vmbr2‑Abschnitt in /etc/network/interfaces hinzufügen):
# Weiterleitung Host:54321 -> 10.20.20.50:22
post-up iptables -C -t nat PREROUTING -i vmbr0 -p tcp --dport 54321 -j DNAT --to-destination 10.20.20.50:22 || iptables -t nat -A PREROUTING -i vmbr0 -p tcp --dport 54321 -j DNAT --to-destination 10.20.20.50:22
pre-down iptables -t nat -D PREROUTING -i vmbr0 -p tcp --dport 54321 -j DNAT --to-destination 10.20.20.50:22
# Nur wenn FORWARD‑Policy DROP ist:
post-up iptables -C FORWARD -i vmbr0 -o vmbr2 -p tcp -d 10.20.20.50 --dport 22 -m conntrack --ctstate NEW,ESTABLISHED,RELATED -j ACCEPT || iptables -A FORWARD -i vmbr0 -o vmbr2 -p tcp -d 10.20.20.50 --dport 22 -m conntrack --ctstate NEW,ESTABLISHED,RELATED -j ACCEPT
pre-down iptables -D FORWARD -i vmbr0 -o vmbr2 -p tcp -d 10.20.20.50 --dport 22 -m conntrack --ctstate NEW,ESTABLISHED,RELATED -j ACCEPT
post-up iptables -C FORWARD -i vmbr2 -o vmbr0 -p tcp -s 10.20.20.50 --sport 22 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT || iptables -A FORWARD -i vmbr2 -o vmbr0 -p tcp -s 10.20.20.50 --sport 22 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
pre-down iptables -D FORWARD -i vmbr2 -o vmbr0 -p tcp -s 10.20.20.50 --sport 22 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
Testhinweise:
host_public_ip:54321 verbinden; die Verbindung sollte die VM‑SSH erreichen.