Befasst man sich etwas länger mit dem Thema eines eigenen Servers oder arbeitet mit diesen, stößt man irgendwann auf Proxmox VE oder auf einen seiner bekannteren Kollegen wie Xen. Proxmox dient zur Server-Virtualisierung, aber es ist kein reines Verwaltungs-Tool für die Virtualisierung mit KVM und OpenVZ, sondern eher ein Rundum-sorglos-Paket mit vielen nützlichen Features. Zwei zusätzliche Features sind z.B. HA und Live Migration. Aber nun zum eigentlichen Thema: Möchte man aus seinem Dedicated Server alles herausholen, oder möchte bestimmte Funktionen (Mail-Server, Web-Server, Bouncer etc) oder kritische Anwendung voneinander und/oder zum Internet abschirmen, kann man dies wunderbar mit Virtualisierung lösen. Was ist aber nun, wenn man aus welchem Grund auch immer nur 2 IPs für seinen Server zur Verfügung hat aber man n VMs benötigt? Wenn man bei Google danach sucht, findet man viele Blogeinträge oder Threads in diversen Foren. Mit den dort angebotenen Lösungen, kommt man auch zum Ziel, jedoch finde ich die meisten Lösungen “unschön”. In diesem Post möchte ich auf arno-iptables-firewall eingehen, welches ich für das Umsetzen des oben angesprochenen Problems nutze. Das Ziel ist es eine Bridge aufzusetzen und den VMs über NAT eine private IP zuzuweisen zusätzlich zeige ich noch, wie man dafür sorgt, dass die VMs von außen erreichbar gemacht werden und wie der Host von den VMs “getrennt” wird.

Update vom 11.08.2015: Sollte es bei der Installation zu Problemen mit dpkg kommen, die wie folgt aussehen können:

dpkg: error processing pve-firewall (--configure):
 dependency problems - leaving unconfigured
Errors were encountered while processing:
 pve-cluster
 redhat-cluster-pve
 fence-agents-pve
 libpve-access-control
 librados2-perl
 resource-agents-pve
 pve-firewall
E: Sub-process /usr/bin/dpkg returned an error code (1)

muss überprüft werden, ob die Datei /etc/hosts den richtigen Inhalt hat. Wichtig dabei ist, dass der Hostname des Servers auflösbar ist! Hier ein Beispiel:

127.0.0.1 localhost.localdomain localhost
pub.lic.ip hostname.de hostname pvelocalhost
#The following lines are desirable for IPv6 capable hosts
::1     ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
ff02::3 ip6-allhosts

Für mehr Informationen einfach mal bei Proxmox im wiki vorbeischauen. Nach der erfolgreichen Installation von Proxmox, muss geprüft werden ob das darunter liegende Debian seine IP statisch bezieht oder nicht. Sollte es nicht der Fall sein, muss dies angepasst werden. Hier meine Konfiguration (/etc/network/interfaces):

auto lo
iface lo inet loopback
#node ip
auto vmbr0
iface vmbr0 inet static
        address XXX.XXX.XXX.XXX
        netmask 255.255.255.0
        network XXX.XXX.XXX.0
        broadcast XXX.XXX.XXX.255
        gateway XXX.XXX.XXX.1
        bridge_ports eth0
        bridge_stp off
        bridge_fd 0

Ihr müsst dort einfach eure Daten eintragen und den Server neu starten. Sollte es Probleme nach einem Neustart des Servers geben, sollte man in den Rescue Modus booten und auf eventuelle Tippfehler schauen. Bringt das alles nichts, reicht es meistens den Support zu kontaktieren mit der Bitte um die richtigen Adressen. Anschließend müssen wir ein neues virtuelles Interface erstellen, welches als Bridge dient. Dazu müssen wir der Datei  /etc/network/interfaces folgenden Konfiguration anfügen.

#bridge
auto vmbr1
iface vmbr1 inet manual
        bridge_ports dummy0
        bridge_stp off
        bridge_fd 0

Jetzt müssen wir nur noch dumy interfaces aktivieren und das geht fix mit dem Befehl.

echo "options dummy numdummies=2" > /etc/modprobe.d/local

Wenn der Server jetzt neu gestartet wird sollte alles laufen, womit wir auch beim Host fertig wären.

Update vom 09.09.2015: Ich kann es zwar nicht empfehlen, aber die dummy-interfaces kann man auch ohne Neustart aktivieren. Dazu müssen wir erstmal das Modul dummy “entfernen”

rmmod dummy

Danach laden wir das Modul direkt wieder, allerdings mit der Option numdummies=2

insmod /lib/modules/**aktueller-kernel**/kernel/drivers/net/dummy.ko numdummies=2

Ob alles funktioniert hat, kann man ganz einfach mit dem Befehl

ls -al /sys/class/net/ | grep dummy

überprüfen. Die Ausgabe sollte wie folgt aussehen:

lrwxrwxrwx  1 root root 0 Sep 10 00:16 dummy0 -> ../../devices/virtual/net/dummy0
lrwxrwxrwx  1 root root 0 Sep 10 00:16 dummy1 -> ../../devices/virtual/net/dummy1

An diesem Punkt müssen wir das erste Mal in das Webinterface wechseln, das geht einfach mit https://public.ip:8006/. Bevor wir jedoch unsere erste VM erstellen, müssen wir bei unserem Provider eine zusätzliche IP bestellen. Das geht meistens innerhalb von ein paar Minuten, wenn wir unsere neue IP haben, müssen wir im Kundenpanel unseres Providers eine MAC für die zweite IP generieren. Bei Onprovider.com geht das über den Menüpunkt Manage the Server > IP Manage dort dann einfach aus der Liste eurer IPs die neue auswählen und auf Generate MAC klicken, fertig! Wenn wir jetzt zurück ins Webinterface von Proxmox wechseln und auf Create VM klicken, erscheint ein Dialog wo wir die Daten für die VM eintragen müssen. Bei dem Menüpunkt Network “Bridged mode” auswählen und als Bridge vmbr0 wählen und als MAC address die neu generierte MAC eintragen. Wenn der Dialog fertig ausgefüllt und die VM erstellt wurde, wählt sie im linken Menü aus und geht auf den Reiter Hardware, dann auf Add > Network Device wieder Bridged mode wählen und dieses mal als Bridge vmbr1 eintragen, anschließen auf Add klicken. Jetzt sollte im Reiter Hardware ganz unten bei Network Devices zuerst vmbr0 und darunter vmbr1 eingetragen sein, etwa so:

Auf der VM kann jetzt das OS installiert werden, vorzugsweise Debian 😉 Das bei der Installation eine Fehlermeldung kommt, weil die VM kein Internet hat ist normal, einfach Netzwerk unkonfiguriert lassen auswählen und die Installation fertigstellen. Nun einfach als User root einloggen. Damit die VM nun zugriff zum Internet bekommt, müssen wir auch hier die Konfiguration der Interfaces anpassen. Die nachfolgende Konfiguration könnte bei euch nicht funktionieren, wie auch zuvor ist es dann das Beste ein wenig zu probieren oder den Support anzuschreiben und wieder nach den Adressen für die 2 IP fragen, wenn diese als Bridge benutzt wird. Meine Konfiguration sieht so aus.

#The loopback network interface
auto lo
iface lo inet loopback

#vmbr0 with MAC
auto eth0
iface eth0 inet static
        address zweite.ip
        netmask 255.255.255.255
        gateway bei.oneprovider.selber.gateway.wie.beim.host
        pointopoint gleiche.wie.beim.gateway

Wenn das eingetragen wurde, muss die VM einmal neugestartet werden. Wenn wir uns nun wieder einloggen, sollte ping 8.8.8.8 folgendes ausgeben:

~ ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_req=1 ttl=59 time=1.26 ms
64 bytes from 8.8.8.8: icmp_req=2 ttl=59 time=7.52 ms
64 bytes from 8.8.8.8: icmp_req=3 ttl=59 time=6.82 ms
64 bytes from 8.8.8.8: icmp_req=4 ttl=59 time=12.1 ms
64 bytes from 8.8.8.8: icmp_req=5 ttl=59 time=5.01 ms
64 bytes from 8.8.8.8: icmp_req=6 ttl=59 time=24.4 ms

Danach einmal ping google.de versuchen:

~ ping google.de
PING google.de (216.58.211.67) 56(84) bytes of data.
64 bytes from par03s14-in-f67.1e100.net (216.58.211.67): icmp_req=1 ttl=58 time=6.94 ms
64 bytes from par03s14-in-f67.1e100.net (216.58.211.67): icmp_req=2 ttl=58 time=52.9 ms
64 bytes from par03s14-in-f67.1e100.net (216.58.211.67): icmp_req=3 ttl=58 time=46.4 ms
64 bytes from par03s14-in-f3.1e100.net (216.58.211.67): icmp_req=4 ttl=58 time=45.8 ms

Sollte die Fehlermeldung ping: unknown host google.de kommen, einfach mit dem Befehel echo “nameserver 8.8.8.8” >> /etc/resolv.conf einen Nameserver eintragen, danach sollte es funktionieren. Da unsere VM nun Zugriff aufs Internet hat, sollten wir die zusätzliche IP die wir gekauft haben einmal anpingen, um zu prüfen ob die VM auch von außen erreichbar ist. Daraufhin wollen wir jetzt das zweite Interface (das haben wir zuvor im Webinterface hinzugefügt) einrichten. Darüber werden die zukünftigen VMs ihre private IP beziehen. Bei mir sieht das wie folgt aus.

#internal interface
auto eth1
iface eth1 inet static
        address 10.10.20.254
        netmask 255.255.255.0
        network 10.10.20.0
        broadcast 10.10.20.255

Den Adressbereich könnt ihr natürlich auch ändern, zum Beispiel in 192.168.0.0. Nun einfach mit

service networking restart

das Netzwerk neu starten, kontrollieren ob es funktioniert hat könnt ihr mit ifconfig. Jetzt haben wir alle Grundsteine gesetzt und müssen uns nur noch um das NATing kümmern. Dazu benutzen wir arno-iptables-firewall. Bei Debian ist das Paket in den offiziellen Repos, also einfach mit apt-get install arno-iptables-firewall installieren. Bei der Installation werdet ihr nach der Konfiguration gefragt, alles einfach unkonfiguriert lassen. Wenn das Paket installiert ist, öffnen wir mit

nano /etc/arno-iptables-firewall/conf.d/00debconf.conf

die Konfigurations-Datei und ersetzen den Inhalt damit:

EXT_IF=“eth0”
EXT_IF_DHCP_IP=0
OPEN_TCP=“22”
OPEN_UDP=“”
INT_IF=“eth1”
NAT=1
INTERNAL_NET=“10.10.20.0/24”
NAT_INTERNAL_NET=“10.10.20.0/24”
OPEN_ICMP=1
NAT_FORWARD_TCP=“”
NAT_FORWARD_UDP=“”

Tragt bei OPEN_TCP unbedingt euren SSH-Port (22) ein, sonst sperrt ihr euch aus! Zeile 1 gibt das externe Interface an, bei uns ist es eht0 über welches unsere VM seine öffentlichen IP bezieht, welche wir zuvor gekauft haben. Zeile 2 deaktiviert DHCP, weil wir wollen das alle VMs von uns eine statische IP haben, welches auch zwingend notwenig ist! Zeile 3 und 4 geben an, welche Ports(TCP oder UDP) nach außen offen sein sollen. In Zeile 5 wird das interne Interface eingetragen (darüber laufen nachher die zusätzlichen VMs). Zeile 6 aktiviert NAT und Zeile 7-8 geben das interne IP-Netz an. OPEN_ICMP=1 in Zeile 10 sorgt dafür, dass unsere aktuelle VM via Ping erreichbar ist. In den letzten beiden Zeilen, müssen wir später eintragen welcher öffentliche Port, zu welcher internen IP+Port weitergeleitet werden soll. Mit 222>10.10.20.11 leiten wir den öffentlichen Port 222 auf die IP 10.10.20.11 weiter, wollen wir das der interne und öffentliche Port unterschiedlich sind, geht das so: 222>10.10.20.11~22 und IP-Ranges geben wir wie folgt an: 17:20 das wären dann Port 17, 18, 19 & 20. Der öffentliche Port muss allerdings auch bei OPEN_TCP oder OPEN_UDP eingetragen werden! Wenn wir nun alles nach unseren Vorstellungen eingestellt haben, starten wir die Firewall so neu:

service arno-iptables-firewall restart

Wenn die SSH-Verbindung bestehen bleibt, haben wir alles richtig gemacht – yay!Das Letzte, das wir nun machen müssen, ist eine neue VM erstellen. Als Bridge wählen wir nun vmbr1(zukünftig für alle VMs) und weisen ihr folgende Netzwerk-Konfiguration zu:

auto lo
iface lo inet loopback
#The primary network interface
allow-hotplug eth0
iface eth0 inet static
        address 10.10.20.1
        netmask 255.255.255.0
        network 10.10.20.0
        broadcast 10.10.20.255
        gateway 10.10.20.254 #interne ip der ersten vm

Ihr solltet bei der NAT-VM in den Firewall-Einstellungen noch einen euch beliebigen Port z.B. 122 auf den SSH-Port der neu erstellen VM weiterleiten. Also bei OPEN_TCP 122 einfügen und bei NAT_FORWARD_TCP 122>10.10.20.1~22 und schon könnt ihr via SSH auf die VM! Ich hoffe ich konnte einen ersten Eindruck vermitteln und die nächsten Schritte schaffst du allein. Falls dann doch mal etwas nicht funktionieren sollte, einfach die Kommentar-Box benutzen 🙂