Proxmox läuft, aber was jetzt?
Im letzten Beitrag ging es um das Warum und grundsätzliche Installieren von Proxmox auf einem VPS. Heute geht es darum, wie man das Netzwerk einrichtet – inklusive Fehler meinerseits – und wie man sicheren Zugriff auf seinen Server bekommt und trotzdem das Fenster so weit aufmacht, dass man auch Webservices darauf betreiben kann.
Updates und Linux Bridge mit Internetzugriff einrichten
Am besten man folgt der Anleitung von der Einrichtung des Servers.
Dann mit pveam update
in der Shell die Containerliste aktualisieren.
Achtung: Hier hat sich schon der erste Fehler eingeschlichen, mir ist erst im Nachhinein aufgefallen, dass Port 80
und 443
für den normalen Web-Verkehr nicht aufzukriegen waren. Mir war unklar was passiert ist, bis ich diesen Proxmox-Forumseintrag gelesen habe, wo ein User eine sehr ähnliche Ausgangslage hat und bei ihm alles in vmbr0
zuhause ist. So ist das Setup auch einfacher.
Das korrekte Setup sieht so aus und wird unter /etc/network/interfaces
eingepflegt:
# Loopback interface
auto lo
iface lo inet loopback
# Assign public IP directly to ens3
auto ens3
iface ens3 inet static
address xx.xx.xx.xx/22
gateway xx.xx.xx.1
# Create vmbr0 for LAN (internal network)
auto vmbr0
iface vmbr0 inet static
address 10.10.10.1/24
bridge_ports none
bridge_stp off
bridge_fd 0
# Enable IP forwarding
post-up echo 1 > /proc/sys/net/ipv4/ip_forward
# Add NAT rules
post-up iptables -t nat -A POSTROUTING -s 10.10.10.0/24 -o ens3 -j MASQUERADE
post-down iptables -t nat -D POSTROUTING -s 10.10.10.0/24 -o ens3 -j MASQUERADE
# Forward HTTP traffic (port 80) to the Caddy container (10.10.10.7)
post-up iptables -t nat -A PREROUTING -i ens3 -p tcp --dport 80 -j DNAT --to-destination 10.10.10.7:80
post-down iptables -t nat -D PREROUTING -i ens3 -p tcp --dport 80 -j DNAT --to-destination 10.10.10.7:80
# Forward HTTPS traffic (port 443) to the Caddy container (10.10.10.7)
post-up iptables -t nat -A PREROUTING -i ens3 -p tcp --dport 443 -j DNAT --to-destination 10.10.10.7:443
post-down iptables -t nat -D PREROUTING -i ens3 -p tcp --dport 443 -j DNAT --to-destination 10.10.10.7:443
# Accept forwarded packets from ens3 to vmbr0 for ports 80 and 443
post-up iptables -A FORWARD -i ens3 -o vmbr0 -p tcp --dport 80 -j ACCEPT
post-down iptables -D FORWARD -i ens3 -o vmbr0 -p tcp --dport 80 -j ACCEPT
post-up iptables -A FORWARD -i ens3 -o vmbr0 -p tcp --dport 443 -j ACCEPT
post-down iptables -D FORWARD -i ens3 -o vmbr0 -p tcp --dport 443 -j ACCEPT
# Allow established and related connections back in
post-up iptables -A FORWARD -i vmbr0 -o ens3 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
post-down iptables -D FORWARD -i vmbr0 -o ens3 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
Das ganze IP-Weiterleitungs-Regelwerk wird etwas klarer weiter unten. Aber ich wollte die Korrektur gleich am Anfang haben und auch transparent mit meinen Fehlern sein, daher auch im folgenden mein Fehler.
{Anmerkung: Die zweite Bridge wird nicht benötigt}
Unter Netzwerk eine Bridge erstellen, Gateway bleibt frei:
Update: man braucht diese IP-Adresse für “IPv4/CIDR”:
Und Durchführen:
{Anmerkung: der folgende Schritt wird jedoch schon benötigt}
Danach startet man mit der Einrichtung von NAT, dazu macht man die Shell im Proxmox Host auf und führt folgenden Befehl aus:
nano /etc/sysctl.conf
Und stellt sicher, dass diese Zeile vorhanden ist und nicht mit #
auskommentiert ist:
net.ipv4.ip_forward=1
So wie hier:
Mit Strg
+ x
schließen und Änderung mit y
und Enter bestätigen. Anschließend noch die Änderungen durchführen mit:
sysctl -p
{Das hier ist jedoch schon von obiger Konfiguration abgedeckt}
Damit das auch funktioniert braucht es noch eine Regel die am Besten mit einem Zusatz unter /etc/network/interfaces
für vmbr0
hinzugefügt
# Enable IP forwarding
post-up echo 1 > /proc/sys/net/ipv4/ip_forward
# Add NAT rules
post-up iptables -t nat -A POSTROUTING -s 10.10.10.0/24 -j MASQUERADE post- down iptables -t nat -D POSTROUTING -s 10.10.10.0/24 -j MASQUERADE
Achtung: vmbr0
muss die öffentliche IP-Adresse haben, wenn nicht, durch den entsprechenden Eintrag ersetzen (kann man unter “Node”, “Network” nachschauen wie der Name ist vom Gerät/Bridge ist, welches die öffentliche IP-Adresse hat).
Jetzt noch den Network Service neustarten mit:
systemctl restart networking
Damit bekommen alle Container im Netz 10.10.10.0/24
Zugriff auf das Internet.
{Anmerkung: Die Container haben ja dadurch tatsächlich Zugriff aufs Netz bekommen, also ganz falsch war es nicht.}
LXC Container mit Tailscale und advertise routes
In einem früheren Beitrag habe ich bereits den Installationsprozess beschrieben (wenn man möchte kann man auch seinen gesamten Internetraffic durchschicken, wie das geht beschreibe ich in diesem Beitrag), daher nur die relevanten Netzwerk- und Containereinstellungen für LXC bei der Erstellung {Anmerkung: Korrekt, bis auf “Bridge: vmbr1” sollte “vmbr0” stehen}:
Hier wird dem Container die statische IP-Adresse 10.10.10.5/24
zugewiesen und als Gateway 10.10.10.1
festgelegt, dank letzterem kann der Container mit dem Host, also Proxmox, kommunizieren.
Bevor man den Container startet kann man gleich noch die notwendigen Änderungen in die Config-Datei, von der Proxmox-Shell aus, hinzufügen. Die Container befinden sich in /etc/pve/lxc/xxx.conf
und man fügt, laut Tailscale-Anleitung, die folgenden Zeilen am Ende hinzu:
lxc.cgroup2.devices.allow: c 10:200 rwm
lxc.mount.entry: /dev/net/tun dev/net/tun none bind,create=file
Dann kann man den Container starten und das Tailscale Installerskript ausführen (genaueres dazu im verlinkten Beitrag):
curl -fsSL https://tailscale.com/install.sh | sh
hier gleich weiter mit dem Durchreichen des lokalen LANs, damit man einfach die IP-Adressen der Range 10.10.10.0/24
nutzen kann. Das geht laut Tailscale-Dokumentation so:
echo 'net.ipv4.ip_forward = 1' | sudo tee -a /etc/sysctl.d/99-tailscale.conf
echo 'net.ipv6.conf.all.forwarding = 1' | sudo tee -a /etc/sysctl.d/99-tailscale.conf
sudo sysctl -p /etc/sysctl.d/99-tailscale.conf
Und dann mit der gewünschten IP-Range hochfahren:
sudo tailscale up --advertise-routes=10.10.10.0/24
In der Admin-Konsole von Tailscale die Einstellung bestätigen:
Und schon läuft es.
Test von Tailscale und Proxmox sperren
Testen kann man das Ganze recht einfach, nämlich indem man im Browser 10.10.10.1:8006
aufruft. Wenn man so auf das Proxmox-Dashboard kommt, Gratulation!
Jetzt kann man den Zugang zusperren und nur noch Port 443
für später, wenn ein Reverse Proxy da ist, offen lassen, sowie Ports für SSH und die WebGUI. Hier ist eine gute Anleitung neben dem offiziellen Wiki-Eintrag von Proxmox selbst.
Achtung: Bei den folgenden Firewall-Einstellungen sind ein paar Sachen schiefgegangen. Ich habe danach noch einmal die Regeln neu gemacht und direkt aus der Konfigurationsdatei rauskopiert.
{Achtung, Achtung: hier irgendwann habe ich gemerkt, dass etwas gröberes nicht passt, denn die beiden Web-Ports wollten um’s verrecken nicht erreichbar sein. Die folgenden Firewall Einstellungen sind zwar prinzipiell nicht falsch, aber unvollständig. Am Ende gebe ich noch die richtigen Einstellungen und vor allem wo die alle hingehören. Also }
Versuch Firewall Einstellungen im WebGUI zu machen
Wir machen das in den Proxmox-Einstellungen mit den Bordmitteln. Zuerst unter “Datacenter” auf “Firewall” und “Add” klicken und folgende Einstellung eintragen (Achtung: in den Screenshots fehlt für Interface vmbr0
):
Damit kann Traffic vom internen Netz (und damit Tailscale) auf Port 8006 zugreifen. Das selbe noch einmal für SSH-Zugang:
Und damit Port 443
offen bleibt:
Dann kann man zusperren und unter “Datacenter” auf “Firewall” und “Options” klicken und dort die Firewall auf Datacenter Level aktivieren (auf dem Node-Level war es bei mir schon aktiv).
Falls man sich, so wie ich zwischenzeitlich, ausgesperrt hat, kann man über die Konsole vom VPS-Anbieter mit diesen Befehlen die Firewall übergangsweise deaktivieren, den Fehler beheben und wieder starten:
pve-firewall stop
pve-firewall start
So, und jetzt die Lösung, die dann funktioniert hat
Funktionierende Einstellung
Eine Lehre aus der Sache war: Nicht wild herumwerkeln, dann vielleicht noch zu sehr auf die Hilfe eines halbseidenen LLMs hoffen und sich dann wundern warum das Werkl auseinanderfällt. Die Dokumentation zur Proxmox Firewall ist empfehlenswert, aber auch dieses Video vom, von mir sehr geschätzten Youtube-Kanal LearnLinuxTV zum Thema Proxmox Firewalls, hilft sehr beim Grundverständnis, wie Firewalls in Proxmox funktionieren.
Erstens, man muss verstehen, dass es bei den drei Ebenen der Firewalls (Datacenter, Node, VM/LXC) verschiedene Gültigkeitsbereiche gibt. Datacenter gilt für alles, auch Node und VM/LXC, außer diese haben ihre eigenen Regeln. Bei Node und VM/LXC gelten die Einstellungen jedoch nur für sich selbst. Um das ganze zu vereinfachen habe ich jetzt “Security Groups” verwendet, diese findet man hier…
… und mit denen kann man eine Art Regel-Vorlage machen, die man dann nur mehr auf Node- oder VM/LXC-Ebene aktivieren muss. Das geht auch ganz gut über die grafische Oberfläche. Die fertigen Einstellungen folgend aber aus den Konfig-Dateien.
Hier die Einstellungen von der Ebene des Datacenters. Konfig unter /etc/pve/firewall/cluster.fw
:
[OPTIONS]
enable: 1
[RULES]
IN Web(ACCEPT) -log nolog
GROUP ping
GROUP WEB
GROUP vmbr1-zugriff
[group ping]
IN Ping(ACCEPT) -log nolog
[group vmbr1-zugriff]
IN ACCEPT -source 10.10.10.0/24 -p tcp -log nolog
[group web]
IN HTTPS(ACCEPT) -log nolog
IN HTTP(ACCEPT) -log nolog
Auf Node-Ebene schaut es so aus (unter `/etc/pve/nodes/{nodename}/host.fw):
[OPTIONS]
enable: 1
[RULES]
GROUP vmbr1-zugriff
GROUP WEB
Und der Tailscale-Container (unter/etc/pve/firewall/{CT/VM-ID}.fw
):
[OPTIONS]
enable: 1
[RULES]
GROUP vmbr1-zugriff
Fazit und Lehre: Traue keinem LLM und Proxmox’sches Unterholz
So einfach, oder so schwer, kann es sein sich einen kleinen Proxmox-Hypervisor auf einem VPS zu installieren. Wenn man weiß was man tut, ist es keine große Hürde alles richtig einzustellen, aber ich habe mich vorher mit den Netzwerkeinstellungen nur ein bisserl und mit den Firewalls noch gar nicht auseinandergesetzt. Insofern war es eine lehrreiche Übung, die auch für weitere Projekte sinnvoll sein wird.
Im nächsten Beitrag geht es dann darum mit LXC-Containern einen kleinen Wordpress-Server aufzusetzen und den auch zugleich hinter einen Reverse Proxy – bei mir Caddy – zu verstecken und so auch die Möglichkeit haben weitere Webservices aufrufbar zu machen. Achja, findige Leser werden es schon in der Konfig oben bemerkt haben, Caddy findet sich darin schon. Mehr dazu beim nächsten Mal!