Bei der Virtualisierung auf Hetzner-Servern ist es aus mehreren Gründen sinnvoll bzw. notwendig, die VMs an einen separaten virtuellen Switch anzuschließen und das so entstehende Netz über eine Router-VM mit dem Hetzner-Netz zu verbinden.
- Wir haben so eine zentrale Firewall und können auf einfache Weise Portfreischaltungen und komplexere Netzstrukturen (DMZs, VPN, private Netze) realisieren. Speziell bei Windows-VMs sollte man sich nicht auf den OS-eigenen Paketfilter verlassen, sondern eine vorgeschaltete Firewall verwenden.
- Hetzner arbeitet bei IPv4 mit einer strengen IP-MAC-Bindung. Jeder Server, der ans Hetzner-Netz angeschlossen wird, muß eine (oder mehrere) ihm fest zugewiesene IP und MAC-Adresse verwenden. Subnetze allerdings erhalten keine eigenen MAC-Adressen, sondern werden auf eine der existierenden Einzel-IPs geroutet.
Dieser Abschnitt beschreibt, wie wir eine Router-VM auf Basis von “pfSense” einrichten. Es gibt natürlich unzählige weitere Routerlösungen. Wir haben uns für pfSense entschieden, weil diese sehr stabil läuft, einen großen Funktionsumfang bietet und eine komfortabel zu bedienende GUI aufweist.
Anlegen der VM
Wir loggen mit dem vSphere-Client am ESXi ein und erstellen eine neue virtuelle Maschine.
Grundkonfiguration
Configuration | Custom |
Name | pfSense |
Destination Storage | datastore1 |
Virtual Machine Version | 8 |
Guest OS: | Other / FreeBSD (64-bit) |
Number of virtual sockets | 1 |
Number of cores per socket | 1 |
Memory | 256 MB |
Netzwerkkonfiguration
- Wir benötigen drei virtuelle Netzkarten: eine für das Hetzner-Netz, eine für das Subnetz mit öffentlichen IPs, und eine für das private Netz.
- Wir weisen die zuvor im ESXi angelegten vSwitches entsprechend zu.
- Als Adapter wählen wir E1000, da pfSense mit diesem am effizientesten arbeitet.
- “Connect at power on” lassen wir ausgeschaltet, da wir die Autodetection-Funktion des pfSense-Setups nutzen wollen
Storage-Konfiguration
SCSI Controller | LSI Logic Parallel |
Type of disk | Create a new virtual disk |
Disk Size | 5 GB |
Disk Provisioning | Thick Provision Lazy Zeroed |
Location | Store with the virtual machine |
Virtual Device Node | SCSI (0:0) |
Mode | “Independent” unchecked |
Abschließende Konfiguration
- New Floppy: Remove
- New CD/DVD: Datastore ISO file (wir wählen das pfSense ISO) und Connect at power on
- pfSense-2.0.1-RELEASE-amd64.iso –LINK–
- Wichtig: bei der NIC “External Net” müssen wir die MAC-Adresse konfigurieren.
- MAC Address manual, und die MAC der zusätzlichen Einzel-IPv4-Adresse eintragen
Installation von pfSense
- Ein Konsolenfenster öffnen und die VM starten
- Mit ESC ins Bootmenü springen und von CD booten
- Die erste Bootoption “1. Boot pfSense (default)” mit Enter bestätigen
- Bei Aufforderung (Press I to launch the installer) “i” drücken
- Einstellungen im pfSense-Installer:
- Change Keymap -> german.cp850.kbd
- Quick/easy install
- (Custom Install würde Paritionierung etc. bieten, was wir nicht brauchen. PFSense erkennt außerdem VMWare automatisch und paßt sich daran an.)
- Symmetric multiprocessor kernel
Konsolen-Konfiguration
Die VM rebootet, bootet von Festplatte und startet die Konfigurationsphase von pfSense. Zunächst werden die Interfaces eingerichtet.
- pfSense stellt einen “mismatch” der Interface-Zuordnung fest und startet das Interface assignment
- Die Frage nach Set up VLANs now verneinen
- Auto-detection for WAN interface: a wählen.
- Es erfolgt eine Aufforderung, das WAN Interface jetzt zu connecten.
- Wir rufen Edit settings / Network adapter 1 auf und setzen den Haken bei Connected und Connect at power-on
- Der Installer erkennt das “link-up event” und weist das Interface zu
- Den Vorgang wiederholen für LAN (Subnet) und “Optional 1” (Intranet)
- Bei der Frage nach “Optional 2”: einfach Return drücken (finish)
- Das Assignment bestätigen
- Das WAN-Interface bezieht dann per DHCP von Hetzner seine IP-Adresse
Erreichbarmachen des Webinterface
Das Webinterface ist per Default nur vom LAN-Netz aus erreichbar. Daher müssen wir, falls wir nicht bereits eine VM mit Webbrowser auf dem Server haben, als erstes den Zugriff von außen, also vom WAN-Netz aus, erlauben.
- An der PFSense-Konsole Funktion 12 (Developer Shell) aufrufen
- Kommando eingeben und Shell beenden:
[bash]playback enableallowallwan
exit[/bash]
Konfiguration via Webinterface
Hinweis: Wir beschreiben hier nicht, wie man eine Firewall in allen Details konfiguriert, sondern gehen auf die Dinge ein, die wir speziell für unser Ziel benötigen.
Allgemeine Konfiguration
Hostname und DNS-Server
- Einloggen per Browser mit Default-Login “admin / pfsense”
- Als erstes ein Kennwort für den User “admin” setzen: System / User Manager : “admin” -> Edit user. Password zweimal eintragen und “Save”klicken.
- Unter System / General Setup den Hostname und DNS Server etc. eintragen.
Firmware-Update
- Unter System / Firmware / Updater Settings stellen wir die Update-Quelle um.
- Dann Lasche Auto-Update wählen und Invoke Auto Upgrade klicken.
- Nach automatischem Reboot stehen IPv6-Optionen zur Verfügung.
Pakete installieren
Wir installieren zwei benötigte Zusatzpakete unter System / Packages / Available Packages. Wir brauchen “Open-VM-Tools” und “OpenVPN Client Export Tool”.
WAN-Interface-Setup
Die WAN-Interface-Parameter können prinzipiell auch auf DHCP belassen werden; die Adreßzuweisung von Hetzner funktionier i.d.R. gut. Wir bevorzugen aber statische Zuweisungen für unsere Router.
Folgende Reihenfolge ist beim Konfigurieren des WAN-Interface einzuhalten.
- Zunächst legen wir ein neues IPv4-Gateway in System/Routing an (pfSense läßt das Umbenennen existierender Gateways nicht zu)
- Als Adresse verwenden wir die Gateway-Adresse aus den Hetzner-IP-Mails.
- Dann konfigurieren wir das WAN-Interface
- Die IPv4-Adresse und Maskenbreite entnehmen wir der zusätzlichen IPv4-Adresse unseres Servers
- Wichtig: Das konfigurierte Gateway muß ausgewählt werden, sonst ist der Router nicht mehr erreichbar!
- Die IPv6-Adresse ist die ::2 des “verwendbaren Bereichs” unseres ersten IPv6-Netzes. Die Maskenbreite ist die Angabe bei der Gateway-Adresse in der Hetzner-Mail. Das Gateway selbst bleibt hier noch auf “None”.
- Dann legen wir das IPv6-Gateway an (dies geht erst, nachdem wir IPv6 am Interface eingeschaltet haben).
- Schließlich tragen wir dieses Gateway noch beim WAN Interface ein.
Routing zu Switchnachbarn für IPv4
Wir müssen dafür sorgen, daß Traffic zu unserem eigenen WAN-Subnetz (im Beispiel 5.9.86.86/27) über das Gateway läuft, anstatt direkt zugestellt zu werden wie es normalerweise ja passiert. Wir erreichen dies, indem wir zwei statische Routen anlegen, für jeweils eine Hälfte dieses Netzes, und das Hetzner-Gateway als Gateway angeben. Diese Routen haben dann, da sie “spezifischer” sind (längere Netzmaske /28), gemäß IP-Routingregeln Vorrang vor der Route ins eigene Subnetz (Netzmaske /27).
Der Screenshot zeigt das Setup, einzurichten unter System / Routing / Routes.
Unterteilung des zweiten IPv6-Subnets
Wir haben uns dazu entschlossen, aufgrund der IPv4-Knappheit ein Intranet mit privaten IP-Adressen einzurichten, in welches wir virtuelle Maschinen setzen, die nicht unbedingt eine öffentliche IPv4-Adresse brauchen.
Damit diese VMs auch per IPv6 erreichbar sind, unterteilen wir unser /64 Subnetz in zwei “Sub-Subnetze”. Diese weisen wir dem “Subnet” und “Intranet” Interface zu. Um es beim Aufschreiben einfacher zu haben, verwenden wir zwei /80 Subnetze mit den Adressen 2a01:4f8:162:1ffc:1::/80 und 2a01:4f8:162:1ffc:2::/80.
Subnet Interface-Setup
- Wir benutzen die erste verfügbare IPv4-Adresse aus unserem Subnetz als Router-IP. Dies kann natürlich auch eine beliebige andere Adresse aus dem Subnetz sein, es hat sich aber eingebürgert, die erste zu nehmen.
- Für IPv6 nehmen wir die Adresse ::2 aus dem ersten der beiden oben beschriebenen /80 Subnetze.
Intranet Interface-Setup
- Als IPv4-Range nehmen wir das Netz 10.0.10.0/24.
- Für IPv6 nehmen wir die Adresse ::2 aus dem zweiten der beiden oben beschriebenen /80 Subnetze.
Pingtest
Zeit für einen Pingtest! Die IPv4 und IPv6 Adressen von WAN und Subnet Interface sollten jetzt von außen pingbar sein.
[bash]
|——————————————————————————————|
| WinMTR statistics |
| Host – % | Sent | Recv | Best | Avrg | Wrst | Last |
|————————————————|——|——|——|——|——|——|
| 10.10.30.1 – 0 | 7 | 7 | 0 | 0 | 0 | 0 |
|static.193.36.40.188.clients.your-server.de – 0 | 7 | 7 | 1 | 1 | 3 | 3 |
| hos-tr3.juniper2.rz10.hetzner.de – 0 | 7 | 7 | 0 | 0 | 0 | 0 |
| hos-bb2.juniper3.rz16.hetzner.de – 0 | 7 | 7 | 0 | 0 | 0 | 0 |
| hos-tr1.ex3k21.rz16.hetzner.de – 0 | 7 | 7 | 1 | 2 | 5 | 5 |
|static.193.182.9.5.clients.your-server.de – 0 | 7 | 7 | 0 | 0 | 1 | 0 |
|________________________________________________|______|______|______|______|______|______|
WinMTR v0.92 GPL V2 by Appnor MSP – Fully Managed Hosting & Cloud Provider[/bash]
[bash]
|——————————————————————————————|
| WinMTR statistics |
| Host – % | Sent | Recv | Best | Avrg | Wrst | Last |
|————————————————|——|——|——|——|——|——|
| 10.10.30.1 – 0 | 7 | 7 | 0 | 0 | 0 | 0 |
|static.193.36.40.188.clients.your-server.de – 0 | 7 | 7 | 1 | 1 | 4 | 1 |
| hos-tr3.juniper2.rz10.hetzner.de – 0 | 7 | 7 | 0 | 0 | 1 | 0 |
| hos-bb2.juniper4.rz16.hetzner.de – 0 | 7 | 7 | 0 | 12 | 60 | 0 |
| static.97.86.9.5.clients.your-server.de – 0 | 7 | 7 | 1 | 6 | 27 | 3 |
|________________________________________________|______|______|______|______|______|______|
WinMTR v0.92 GPL V2 by Appnor MSP – Fully Managed Hosting & Cloud Provider[/bash]
VMs den Netzen zuweisen
- Die VMs auf dem Server werden an den virtuellen Switch “Subnet” oder “Intranet” angeschlossen, je nachdem, ob sie eine öffentliche oder nur eine private IPv4-Adresse bekommen sollen.
- Im “Subnet” werden ihre IPs aus folgenden Bereichen entnommen:
- IPv4: 5.9.182.194 bis 5.9.182.198
- IPv6: 2a01:4f8:162:1ffc:1::3 bis 2a01:4f8:162:1ffc:1:ffff:ffff:ffff:ffff
- Das IPv4-Gateway ist die 5.9.182.193, Netzmaske ist /29.
- Das IPv6-Gateway ist die 2a01:4f8:162:1ffc:1::2, Netzmaske ist /80.
- Für das “Intranet” sind es folgende Bereiche:
- IPv4: 10.0.10.2 bis 10.0.10.254
- IPv6: 2a01:4f8:162:1ffc:2::3 bis 2a01:4f8:162:1ffc:2:ffff:ffff:ffff:ffff
- Das IPv4-Gateway ist die 10.0.10.1, Netzmaske ist /24.
- Das IPv6-Gateway ist die 2a01:4f8:162:1ffc:2::2, Netzmaske ist /80.
VPN-Konfiguration
Wir wollen ein VPN einrichten (Roadwarrior-Szenario), um mit OpenVPN-Clients auf unserem Arbeitsrechner einen Tunnel zum Router aufzubauen. Damit können die VMs im Intranet direkt erreichen, und den Zugriff auf Subnet-VMs per Firewall-Regeln einschränken (z.B. Netbios-Zugriff nur per VPN).
Wir wollen den Authentifizierungsmodus “SSL/TLS ohne User Auth” verwenden und TLS-Pakete authentifizieren lassen. D.h. jeder User erhält ein eigenes Zertifikat, muß sich aber nicht zusätzlich mit Kennwort anmelden. Für TLS-Auth wird ein Shared Key verwendet.
Zum Glück bietet pfSense eine komfortable GUI, um alle nötigen Schritte durchzuführen.
Zertifikate generieren
- Zunächst benötigen wir eine Certificate Authority. Wir könnten unsere Zertifikate natürlich auch von einer “offiziellen” CA signieren lassen, aber das wäre teurer Overkill für unser Vorhaben. 🙂 Unter System / Cert Manager / CAs legen wir eine “Internal CA” an und füllen die Felder aus, wie auf dem Screenshot dargestellt.
- Der OpenVPN-Server benötigt selbst ein Server-Zertifikat, das wir unter System / Cert Manager / Certificates wie auf dem Screenshot dargestellt generieren.
- Für jeden User, der das VPN benutzen soll, müssen wir ein User-Zertifikat generieren. In unserem Beispiel tun wir dies nur für einen “User 1”. Die Generierung erfolgt unter System / Cert Manager / Certificates, wie auf dem Screenshot dargestellt.
- Da Zertifikate, die einmal an User herausgegeben wurden, im Gegensatz zu Kennwörtern nicht mehr so einfach zu “löschen” sind, existieren sogenannte Certificate Revocation Lists. In diese können wir Zertifikate eintragen, die aus irgendwelchen Gründen nicht mehr akzeptiert werden sollen. Nutzung dieser Liste ist nicht zwingend notwendig, aber für unser Beispiel legen wir unter System / Cert Manager / Certificate Revocation eine Liste an. Wir tragen einen wählbaren “Descriptive name” ein uns lassen die restlichen Einstellungen auf Default.
Server anlegen
Damit haben wir alles beisammen, was wir zur Konfiguration des VPN-Servers benötigen. Unter VPN / OpenVPN / Server fügen wir einen neuen Server ein.
- Als Tunnel-Netzwerke verwenden wir 10.1.10.0/24 für IPv4, und fd68:ac63:923b:1::/64 für IPv6. Gemäß RFC 4193 sollten solche privaten IPv6-Netze aus der Range fd00::/8 stammen und einen zufälligen /48 Präfix haben.
- Unter “Tunnel Settings” geben wir unser IPv4-Subnetz und das erste IPv6 /80 Subnetz ein. Das IPv4-Intranet und das zweite IPv6 /80 Subnetz fügen wir bei der “Advanced Configuration” in Form von “push route”-Direktiven hinzu.
User anlegen
Für jeden einzurichtenden User führen wir folgende Schritte durch:
- Unter System / User Manager / Users legen wir einen neuen User an. Username ist einzugeben, ebenso Password, obwohl wir letzteres nicht benötigen. Der User wird per Zertifikat zum VPN verbinden, aber der User Manager läßt ein leeres Kennwort nicht zu. Den Rest des Formulars lassen wir leer.
- Nachdem der User erzeugt ist, klicken wir auf Edit User. Erst dann können wir ihm unter User Certificates das vorab erstellte Zertifikat mittels Choose an existing certificatezuweisen. Noch einmal Save klicken, dann kann der User direkt am VPN connecten.
- Unter VPN / OpenVPN / Client Export – Client Install Packages’ können wir auf komfortable Weise eine fertige Konfigurationsdatei für den OpenVPN Client herunterladen, oder sogar – falls auf dem Zielrechner noch kein Client existiert – einen vorgefertigten Windows-Installer.
- Mit Configuration erhalten wir eine .ovpn-Datei, die nur die Konfigurationsdirektiven umfaßt.
- Inline Configuration ist eine .ovpn-Datei, in der neben der Konfiguration auch die Zertifikate enthalten sind.
- Configuration archive ist eine .zip-Datei, in der eine .ovpn (nur Konfiguration) und Zertifikate in separaten Dateien enthalten sind.
Hallo Herr Timmermann,
erstmal vielen Dank für die Anleitung.
Wir haben uns nun auch einen “ESXi” bei Hetzner zugelegt. Eigentlich läuft dieser auch problemlos. Allerdings ist mir gerade aufgefallen, dass die Server nach draußen die IP der Router-VM nutzen (sprich die Zusätzliche IP) und nicht die jeweilige IP aus dem Subnetz.
Wie bekommen wir es hin, dass er die “richtige” IP-Adresse nach draußen verwendet?
Vielen Dank im Voraus für Ihre Antwort.
Hallo Florian,
da fehlt dann wohl das 1:1 NAT.
Firewall -> NAT -> 1:1
Und hier die fehlenden Informationen eintragen, dann sollte es funktionieren.
Viele Grüße
Sven