Proxmox VE auf VPS/Root Server, pfsense, NAT, WAN, LAN

Eine Kaskade der Virtualisierung mit nur einer öffentlichen IP-Adresse

Mit diesen Tipps klappt die Konfiguration!
Und darum geht’s. Anstatt im Speicherplatz bei einem Internet Provider nur einen einzigen Server einzurichten, kann man mit Proxmox VE eine komplexe Virtualisierungsumgebung mit weiteren nachgelagerten und verschachtelten Instanzen konstruieren. Das gelingt auf einem Virtual Private Server oder einem Root Server, bei dem eine fortgesetzte Verschachtelung der Virtualisierung erlaubt ist. Viele, aber nicht alle Internet Provider bieten diese Funktionalität.

Am Ende kann es zum Beispiel aussehen, wie in der nachstehenden Grafik gezeigt.

Zugegeben, man muss dafür eine Menge an Settings überblicken. Aber wenn man das Grundprinzip einmal verstanden hat, hilft es weiter. Und mit dem Template weiter unten auf dieser Seite für die network/interfaces kann man, wenn man soweit ist und Proxmox installiert hat, sofort loslegen.

Grundprinzip

Das Grundprinzip sieht aus wie folgt. Im ersten Schritt installiert man Proxmox auf dem VPS oder Root Server.

Danach ist eine Netzwerkbrücke vmbr0 mit dem Interface eth0/ens3 verknüpft und lauscht auf der öffentlichen IP-Adresse a.b.x.y. Das bedeutet, man kann den Server bzw. die Proxmox-Installation auf dieser Adresse sowie über die Ports 22 (SSH) und 8006 (HTTPS Web Interface) erreichen.

Über einen dieser Zugänge konstruiert man im nächsten Schritt noch weitere zwei Netzwerkbrücken vmbr1 und vmbr2. Der Sinn ist, sämtliche Anfragen an den Server, welche nicht auf Port 22 oder 8006 eintreffen, direkt durchzuleiten (DNAT).

Daher erstellt man im folgenden Schritt eine virtuelle Maschine, z. B. eine pfsense Firewall. Den WAN-Port verbindet man mit der Netzwerkbrücke vmbr1. Alles, was nicht Proxmox (in der ersten Reihe) beantwortet, erreicht jetzt die Firewall. Je nach Regel werden IP-Pakete dort abgelehnt oder weitergeleitet. Im Falle einer Weiterleitung reicht die pfsense Firewall zugelassene Anfragen schließlich über den LAN-Port weiter an die Netzwerkbrücke vmbr2.

Nun wird es richtig spannend. Denn hinter dieser Netzwerkbrücke, im „LAN“ auf dem VPS, hinter der KVM/QEMU-Firewall auf dem VPS/Root-Server, kann man – je nach Speicherplatz – viele VMs oder Container installieren.

Konfiguration der Interfaces und Netzwerkbrücken

In der Vorlage für die Datei /etc/network/interfaces sind nur wenige Anpassungen erforderlich. Natürlich müssen die IP-Adresse vom Server a.b.x.y, die Netzmaske /22 sowie die Adresse vom Gateway korrekt sein.

auto lo
iface lo inet loopback

iface ens3 inet manual

auto vmbr0
iface vmbr0 inet static
	address a.b.x.y/22
	gateway a.b.x.1
	bridge-ports ens3
	bridge-stp off
	bridge-fd 0
	post-up iptables -t nat -A PREROUTING -i vmbr0 -p tcp -m multiport ! --dport 22,8006 -j DNAT --to-destination 10.1.1.2
	post-up iptables -t nat -A PREROUTING -i vmbr0 -p udp -j DNAT --to-destination 10.1.1.2

auto vmbr1
iface vmbr1 inet static
	address 10.1.1.1/30
	bridge-ports none
	bridge-stp off
	bridge-fd 0
	post-up   iptables -t nat -A POSTROUTING -s '10.1.1.0/30' -o vmbr0 -j MASQUERADE
	post-down iptables -t nat -D POSTROUTING -s '10.1.1.0/30' -o vmbr0 -j MASQUERADE

auto vmbr2
iface vmbr2 inet static
	address 192.168.3.1/24
	bridge-ports none
	bridge-stp off
	bridge-fd 0

Die Adressen im Transfer-Netz (10er-Block) kann man ändern, könnte man aber auch so lassen.

Dann gibt man der Bridge vmbr2 noch eine Adresse, zum Beispiel 192.168.3.1/24. In diesem Netzbereich lässt sich ein separates Netzwerk aufspannen (VM-LAN). Aktiviert und konfiguriert man den DHCP-Server in pfsense entsprechend, erhalten alle virtuellen Maschinen und Container automatisch eine IP-Adresse aus diesem Adressbereich.

Es ist zu erkennen, dass die Konfiguration der Interfaces auch Anweisungen für die iptables Firewall in Proxmox beinhaltet. Durch Destination-NAT erreicht man die angesprochene Umleitung aller (TCP und UDP) IP-Pakete an die pfsense-Firewall, die nicht auf Port 22 oder 8006 eintreffen.

Weiterleitung von IP-Paketen im Kernel aktivieren

Im Kernel muss die Weiterleitung von IP-Paketen aktiv sein. Dazu kann man in der Datei /etc/sysctl.conf den Wert net.ipv4.ip_forward=1 setzen. Dadurch ist die Weiterleitung automatisch beim Booten eingeschaltet.

Virtuelle Maschine erstellen und pfsense konfigurieren

Über die Serververwaltung von Proxmox mit der Adresse https://a.b.x.y:8006/ erstellt man eine VM mit zwei Netzwerkkarten und installiert darauf pfsense. Bei der Konfiguration von pfsense muss man die richtige Zuweisung vom WAN- und LAN-Port beachten. Im Beispiel erhält das erste Netzwerkinterface (z. B. vtnet0) die Adresse 10.1.1.2 als WAN-Port mit 10.1.1.1 als Gateway.
Die zweite Netzwerkkarte (vtnet1) in der Hardware der pfsense dient als LAN-Port. Sie erhält in diesem Beispiel die IP-Adresse 192.168.3.2. Innerhalb von „VM-LAN“ ist diese Adresse das Gateway für die zukünftigen VMs und Container.

Proxmox stellt für jede VM bzw. jeden Container ein eigenes Terminal bereit. Darüber lässt sich die initiale Konfiguration von pfsense durchführen. Es existiert auch eine Web-Oberfläche für die Administration. Aber diese ist von außen, über den öffentlichen WAN-Port, nicht zu erreichen. Die pfsense Firewall ist aktiv und tut, was sie tun soll – sie blockt. Und auf der Innenseite, quasi im „VM-LAN“, gibt es momentan noch keinen Browser, womit man die pfsense aufgerufen könnte. [Zur Erinnerung: Es ist ein VPS/Root Server, keine Maschine im direkten Zugriff.]

Der Trick ist, im Terminal deaktiviert man die Firewall für einen kurzen Moment. Der Befehl dazu lautet:

pfctl -d

Sofort lässt sich die virtuelle Maschine mit der pfsense Firewall aufrufen unter der Serveradresse https://a.b.x.y/index.php (Port 443).

Damit lassen sich die weiteren Einstellungen vornehmen, Passwörter und Benutzer ändern, Konfigurationen überprüfen, Rules und NAT-Regeln definieren, usw. Nach der Abmeldung sollte man die Firewall wieder einschalten:

pfctl -e

Zack – sofort ist der Zugriff wieder gesperrt. Aber den Trick kann man ja jederzeit wiederholen.

Zwischenfazit

Nach diesen Vorbereitungen laufen proxmox und pfsense auf einem eigenen VPS/Root Server. Es lassen sich weitere VMs und LXContainer installieren. Als Gedankenstütze hier noch einmal die Beispielgrafik.

Ausbau und Anwendungsbeispiele

Eine grafische Benutzeroberfläche wäre ganz nett. In dem Beispiel läuft eine neue virtuelle Maschine mit einer XFCE Desktop Environment auf der Adresse 192.168.3.31. Im Terminal-Fenster mit der Schreibtischoberfläche von diesem System kann man einen Browser öffnen. Unter der Adresse https://192.168.3.2/ erreicht man die pfsense quasi von „innen“, ohne sie deaktivieren zu müssen.

Ein echtes Highlight ist der Application Stack mit Docker, Portainer und Nginx Proxy Manager (und wie man das absichert). Das alles befindet sich wiederum in einem separaten Linux Container mit einem Debian-System.
Hinweis: Da der Proxy Manager beide Ports 80 und 443 für sich beansprucht und darüber auch die Administration der pfsense zu erreichen ist, muss man eine Anpassung vornehmen, um Kollisionen zu vermeiden. Dazu ändert man die Ports, auf denen die Verwaltung der pfsense möglich ist, zum Beispiel von 443 in 55443. Die Adresse der pfsense lautet dann https://a.b.x.y:55443/index.php (extern) bzw. https://192.168.3.2:55443/index.php (intern).

Auf Anfragen über die Ports 80 und 443 reagiert fortan (nur) der Nginx Proxy Manager. Damit ist es möglich, eine WordPress-Installation in einem Docker Container mit einer Domain zu versehen, SSl-Zertifikate von Let’s Encrypt zu beziehen und mit Portainer zu verwalten. Angenommen der WordPress-Container lauscht auf Port 8081. Dann muss man diesen Port in pfsense mit einer Firewall-Regel (NAT) entsprechend ergänzen, damit eine Anfrage mit der URL http://a.b.x.y:8081/ auch bis in diesen Container gelangt.

Fazit

Unübersehbar kann bzw. muss man zahlreiche Software installieren. Daran führt auch kein Weg vorbei. Aber mit Proxmox lassen sich virtuelle Maschinen und Container sehr gut verwalten. Noch vorteilhafter wird es, mehrere Proxmox-Instanzen zu einem Cluster zu verbinden. Denn so lassen sich Snapshots oder Storage leichter managen sowie Backups und komplette Maschinen, sogar im laufenden Betrieb, hin und her verschieben und sichern.
Übrigens, erwähnenswert ist auch das Folgende. In einer Sicherheitsanalyse hat das Bundesamt für Informationssicherheit (BSI) der Virtualisierung mit KVM/QEMU eine Eignung als „technisch ausgereift und sicher“ zugesprochen.
Natürlich gelten die Grundsätze für ein „Server Hardening“ in diesem Fall gleich mehrfach. Für alle Instanzen, Maschinen, Container, Programme usw. sind Sicherheitsmaßnahmen zu treffen, Passwörter und SSH-Keys zu generieren, Firewall-Regeln zu setzen, Zugänge zu überwachen, von Intrusion Detection bis Monitoring etc.