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:
[bash language=”language”]
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
[/bash]
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
[bash language=”language”]
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
[/bash]
