pixel
Seite wählen

Proxmox Routed NAT für die NWS Openstack Cloud, Hetzner uva.

von | Feb 10, 2022 | Virtualisierung

Warum Proxmox? Weil Du damit einen robusten AGPL3-Lizenz basierten, sicherheits- und privacy-technisch (Debian) unbedenklichen, KVM-Hypervisor bekommst, der Out-of-the-Box LXC kann, was extrem ressourcenfreundlich ist, und Du damit wie gewohnt Deine Linux-Befehle abfeuern und automatisieren kannst.

Unter Debian befinden sich die direkt greifenden Kern-Netzwerkkonfiguration unter /etc/network/interfaces und nachfolgender Teil basiert darauf. Auskommentierte Parameter werden wie gewohnt durch # dargestellt – an einigen Teilen habe ich Parameter auskommentiert gelassen, die aber zum Testen & Debuggen wichtig waren und die ich auch für Zukünftiges oder Nachzuschlagendes nicht verstecken möchte.

Bridged-Home

Eine default Proxmox Konfiguration für Zuhause sieht z.B so aus:

auto lo
iface lo inet loopback

iface ens3 inet manual

auto vmbr0
iface vmbr0 inet static
address 10.77.15.38/24
gateway 10.77.15.254
bridge-ports ens3
bridge-stp off
bridge-fd 0

Erklärung: Wie Du siehst läuft alles über einen virtuellen Netzwerkadapter vmbr0, der IP & Gateway behandelt: das eigentlich echte Interface ens3 wird hier nur auf manual geschalten, während das vmbr0 auf static gesetzt ist. Dieses vmbr0 Interface wirst Du auch pro VM / LXC -Container dann jeweils auswählen, und eine passende IP vergeben bzw. vergeben lassen. Beachte allerdings den Punkt bridge-ports ens3 , machst Du so etwas bei einem externen VPS/Bare-Metal Provider, musst Du eventuell zusätzlich eine gekaufte virtuelle MAC mitgeben – oder könntest offline genommen werden, da nun über mehrere MACs mehrere reelle IPS laufen würden, wo die Sicherheitsfeatures des Gateways des Providers Alarm schlagen sollten. Daher folgender Routed-NAT Ansatz:

Routed-NAT in der Cloud

Metadata

Hinweis: Nachfolgendes im OpenStack mit Metadaten ist minimal hacky, aber es “tut”, ob Du so etwas in der Production benutzen willst ist Dir überlassen. Bei LXC-Containern wirst Du genauso Performanz haben wie nativ in Deiner Instanz da diese CGroup basierend sind.

Willst du maximales Vertrauen und maximale Sicherheit nimmst Du Dir eine eigene Proxmox ISO und lädst diese hoch – was bei NWS kein Problem ist: Noch besser, Du lädst ein eigenes Debian 11 Bullseye hoch, installierst und verschlüsselst dieses, und installierst Proxmox on Top.

Nach dem Hochladen der ISO findest Du die Möglichkeit Metadata-informationen anzupassen, um die VM im Openstack Hypervisor auf  Virtualisierung einzustellen. Nachfolgende Flags zu setzen hat für mich funktioniert:

Du kannst nun Deinen Server hochfahren, und kannst danach nach dem Booten, über “Console” die Installation starten. Du solltest im Anschluss das Boot-ISO unmounten, sonst kommst du nach dem Reboot wieder zur Installation, tust Du es nicht, kannst Du aber auch einfach über Rescue-Shell die Proxmox-Instanz starten. In meinen Tests wurden DHCP und Gateway automatisch angezogen und die Installation lief problemlos durch.

Proxmox Routed-NAT Konfiguration

auto lo
iface lo inet loopback

auto ens3
iface ens3 inet static
address 10.77.15.38/24
gateway 10.77.15.254
# pointopoint 10.77.15.254

auto vmbr0
iface vmbr0 inet static
address 10.77.15.38/24
netmask 255.255.255.0
gateway 10.77.15.254
bridge-ports none
bridge-stp off
bridge-fd 0
pre-up brctl addbr vmbr0
up route add 10.10.10.2/32 dev vmbr0
up route add 10.10.10.3/32 dev vmbr0

auto vmbr1
iface vmbr1 inet static
address 10.9.9.1
netmask 255.255.255.0
bridge_ports none
bridge_stp off
bridge_fd 0
post-up iptables -t nat -A POSTROUTING -j MASQUERADE
post-up iptables -t nat -A POSTROUTING -s '10.9.9.0/24' -o vmbr0 -j MASQUERADE
post-down iptables -t nat -F

# post-up echo 1 > /proc/sys/net/ipv4/ip_forward
# post-down iptables -t nat -D POSTROUTING -s '10.9.9.0/24' -o vmbr0 -j MASQUERADE
# post-up iptables -t nat -A POSTROUTING -o eth0 -s '10.9.9.0/24' -j SNAT --to 10.9.9.1
# 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
Erklärung: Hier siehst Du im Vergleich Routed NAT, welches Du bei jedem VPS, auch bei uns bei NWS, nutzen könntest.
Hinweis: Für Bare-Metal-Instanzen bei Hetzner würdest Du nur noch pointtopoint einkommentieren müssen.
Im Vergleich zu einer Bridged-Konfiguration siehst Du nun bei vmbr0 bridge-ports none auch magst Du Dich wundern wieso denn genau address 10.77.15.38/24 sowie gateway 10.77.15.254 je in ens3 und vmbr0 vorkommen. Das liegt daran dass wir nun im Vergleich zu Bridged keine zweite MAC einholen, sondern alles über iface ens3 inet static durchgeben –  und vmbr0 und vmr1 praktisch routen. Du könntest nun auch vmbr0 benutzen, aber vmbr1 ist in dem Beispiel bequemer, und setzt Dir ein komplettes ‘10.9.9.0/24’-Netz mit entsprechenden NAT-Regeln das mit dem 10.9.9.1 Gateway kommunizieren kann.
Wichtig: Obwohl Du auch hier den ipv4-Forward aktivieren könntest, habe ich es in der /etc/sysctl.conf gemacht via net.ipv4.ip_forward=1  bzw. respektive net.ipv6.conf.all.forwarding=1.
Tipp: Ich persönlich benutze ab dieser Stelle (wo auch immer möglich) Nested-Docker in LXC-Containern um Server-Performanz zu sparen, und lege bequem Wireguard Clients in die jeweiligen Container, um diese von überall aus anzusprechen. Guides zu Wireguard findest Du von Markus und mir hier unserem NETWAYS Blog.
Übrigens: Meine Chefs von NETWAYS Professional Services bieten bald im Portfolio auch Consulting zu Proxmox an, welches von Icinga 2 überwacht werden kann.

 

Patrick Dolinic
Patrick Dolinic
Junior Consultant

Nachdem Patrick sein Psychologiestudium abgeschlossen hat, ist er 2020 zu NETWAYS, wo er nun sein Hobby zum Beruf macht: Endlich kann er sich voll und ganz der Linux-Welt widmen und sein Faible für Computersicherheit ausleben. Wenn er nicht gerade arbeitet, arbeitet oder zockt er. Nebenbei versucht er beim Joggen 8 km zu reißen, schafft aktuell aber nicht mal die ersten 7.
Mehr Beiträge zum Thema Virtualisierung

Quick and Dirty: OpenStack + CoreOS + GitLab Runner

Wer in GitLab die CI/CD-Features nutzen möchte und nicht zufällig einen ungenutzten Kubernetes-Cluster übrig hat, mit dem man GitLab's Auto DevOps Funktion einrichten kann, der benötigt zumindest einen GitLab Runner, um Build-Jobs und Tests zum Laufen zu bekommen. Der...

Mit MyEngineer voll ins Schwarze getroffen

Fachkräftemangel? Keine Ressourcen für neue Hostingprojekte? Mit MyEngineer von Netways kein Thema mehr! Nach Einführung unserer IaaS OpenStack buchen immer mehr Kunden zusätzlich unseren MyEngineer-Service. MyEngineer ist praktisch Ihr persönlicher und erfahrener...