Generell vergibt Hetzner bei der Serverbestellung nur eine offizielle IP Adresse. Hat man vor, ESXI auf dem Hetznerserver zu betreiben, sollte man gleich noch eine weitere IP Adresse dazu bestellen. Wie in vielen anderen Tutorials erwähnt, sollte man bei Bestellung unbedingt angeben, dass die zweite IP Adresse für Virtualisierungszwecke verwendet wird (Router-VM).
Anmerkung: Ich denke jedoch, wenn man per pfSense ein Portforwarding WAN <-> LAN realisiert, reicht auch eine offizielle IP. So kann man z.B. Anfragen die auf Port 80 kommen per pfSense an eine bestimmte IP (VM) innerhalb des „LAN“ weiterreichen, auf der ein Webserver läuft, Port 25 auf eine VM, auf der ein SMTP Server lauscht etc.
Grundsätzliche Idee
Installation von VMWARE ESXI 5.1 (bitte dieses Image zur Installation verwenden) mit Upgrade auf 5.5, da zumindest in dem von uns verwendeten Server (EX40) eine Realtekkarte läuft, die sonst nicht (ohne ein Customimage) erkannt wird.
Ich gehe hier nicht auf die grundlegende Installation ein. Kurz zusammengefasst: ESXI kann nicht per Robot installiert werden, sondern muss per LARA, nach Einbindung eines entsprechenden ISO-Files installiert werden. (Stichwort Virtual Media).
Die ISO-Files liegen auf einem Mirror von Hetzner, der in der LARA entsprechend konfiguriert werden muss.
Meiner Erfahrung nach (und auch nach Aussagen des Supportes), gibt es wohl immer wiedermal Probleme mit der Einbindung des ISOs per Lara. Konkret funktioniert sporadisch die Tastatur nicht mehr in der Remote Konsole der „LARA“, wenn ein Virtual Media eingebunden ist. Dies wiederum macht eine Installation unmöglich.
Lösung: Dem Support mitteilen, dass das ISO bitte auf einen USB-Stick „gebannt“ und an den Server angesteckt wird.
Dann kann per Lara (F11-Bootmenü-> Boot from USB-Stick) die Installation gestartet werden. Der Haken dabei ist, dass diese Aktion zur Zeit EUR 25,00 (einmalig) kostet.
Managementnetzwerk im Internet und Sicherheit
Anfangs wird das Managementnetzwerk (Vsphere Client) über die offizielle IP angesprochen, welche von Hetzner standardmäßig bei der Bestellung vergeben wird. (Dies wird jedoch aus Sicherheitsgründen geändert und auf Zugriff per Openvpn umgestellt – d.h. kein Zugriff mehr aus dem Internet direkt!).
Abgesehen vom Zugriff über VPN könnte man in der Hostkonfiguration das Sicherheitsprofil insofern anpassen, dass Zugriffe auf u.a. den vSphereclient nur von fixen IP Adressen zugelassen wird.
Wenn pfSense (weiter unten) dann mal läuft: So installiert man Openvpn in pfSense.
Anmerkung: In dieser Konfiguration ist ein Zugriff auf das Managementnetzwerk nur möglich, wenn a.) Der VPN Tunnel steht und b.) die pfSense-VM läuft. Man sollte daran denken, die pfSense-VM in den Autostart zu geben.
Mehrere VMs, obwohl nur eine NIC vorhanden ist
Pfsense wird u.a. als Routervm, aber auch für Openvpn, diverse Portforwardingregeln und vieles mehr genutzt. So kann man, wenn alles eingerichtet ist, sowohl eine PAT als auch ein NAT auf verschiedene VMs innerhalb des LAN bewerkstelligen.
pfSense Installation
Das Bindeglied zwischen dem isolierten vSwitch (LAN) und dem zweiten vSwitch (WAN) bildet pfsense. (Router/Firewallfunktionalität).
Anmerkung: Es werden im HowTo 3 NICs konfiguriert, ich habe das mit 2 NICs realisiert.
Konfiguration des Netzwerkes
Die pfSense-VM bekommt 2 virtuelle NICs zugeordnet (im Beispiel: VMNetwork und Intranet):
Auf dem ESXI Server benötigen wir einen Vswitch (im Bild unten VM Network) der mit der physischen NIC verbunden ist. pfSense liegt hier mit dem WAN-Port an, dem die zweite offizielle IP, die wir von Hetzner angefordert haben, zugeordnet ist.
Dem isolierten vSwitch (vSwitch ohne NIC) ist schließlich die vNIC „Intranet“ (LAN) des pfsense zugeordnet. Hier werden dann auch alle VMs angeschlossen. (Im Beispiel eine Ubuntu-VM).
Anmerkung: In der obigen Darstellung ist das Managementnetzwerk bereits auf das interne Netzwerk verschoben (IP: 192.168.1.2). D.h. der vSphere Client ist von aussen nicht mehr erreichbar. (Zuvor muss eine VPN-Verbindung aufgebaut werden!)
Das Managementnetzwerk wird „verschoben“ in dem man einen neuen VMkernelport erstellt:
und diesen dann dem isolieten vSwitch zuweist (in unsrem Fall vSwitch2):
In den vSwitcheinstellungen (Eigenschaften) muss dann bei der Konfiguration des VMKernelports die korrekte interne IP + korrektem internen Gateway angegeben werden:
Mittels Bearbeiten / Reiter IP Einstellungen müssen die korrekten Werte für IP/Subnet/Gateway hinterlegt werden:
Danach sollte mittels vSphereclient, nach Aufbau der VPN Verbindung, ein Management über die IP 192.168.1.2 möglich sein. Erst wenn dass verifiziert worden ist, kann das Managementnetzwerk, welches noch auf dem vSwitch0 anliegt und bei der Installation des ESXI automatisch installiert wurde, entfernt werden. Dies unterbindet dann den Zugriff über die offizielle IP.
Obwohl ich wie immer versucht habe, an alle Eventualitäten zu denken, kann ich keine Garantie für die Sicherheit dieser Konfiguration übernehmen!
Update: Wie sich zumindest bei mir herausgestellt hat, funktioniert die Einbindung des Subnet nicht stabil. Sprich die Subnet-IPs sind mal erreichbar, dann wieder nicht. Ein installiertes Owncloudserver auf einem Debian funktioniert zwar grundsätzlich, jedoch verliert u.a. der Owncloud-Client immer wieder die Verbindung.
Ich habe zwar schon einige Recherchen betrieben und auch bei Hetzner nachgefragt, doch bin zu keiner Zufriedenstellenden Lösung gekommen…
Hallo,
vielen Dank für diesen Artikel. Ich habe das bei mir auch genau so eingerichtet, inkl pfsense. Läuft alles in allem sehr stabil, lediglich die Datentransferrate ist mit 4,5MB/s etwas mau…
Aber was ich eigentlich sagen wollte: der link ist tot: https://virtpro.eu/vmware-esxi-firewall-pfsense/
Danke für die Info!
Ich habe genau das gleiche Problem: Owncloud verliert sporadisch die Verbindung und Plesk ist nicht erreichbar.
Hast du bereits eine Lösung für das Problem finden können?
Hallo Felix,
leider habe ich für das Problem bei Hetzner keine Lösung finden können, weshalb ich dann auf den Mitbewerb umgestigen bin. Welche NIC ist denn bei deinem Server verbaut? Ich hatte ja die Vermutung dass es bei mir daran lag, dass ich im Server keine Intel sondern eine Realtek karte im Einsatz hatte.
Beim Server des Mitbewerbers war dann eine von ESXI unterstützte NIC verbaut. Da hat es dann ohne Troubles geklappt.
Hallo Daniel,
ich habe extra darauf geachtet, dass eine Intel NIC verbaut ist (habe den über die Serverbörse bestellt). Die funktioniert mit ESXi ja deutlich zuverlässiger als Realtek.
Interessant ist, dass nur der Mac Client Probleme macht. Unter Windows funktioniert ownCloud einwandfrei. Die Fehler sind sehr verschieden, mal „Socket Error“ oder einfach nur „Timeout“. Kann auch zufällig an anderen Dingen liegen, aber es ist entspricht deinem Problem mit gleicher Konfiguration (bis auf die NIC) 😉
Hallo,
und den Client am Mac kannst du ausschließen? Was mir damals noch aufgefallen ist: Die Owncloud Website (ich meine damit meine damalige Installation auf dem Webserver) war auch immer wiedermal kurz nicht erreichbar, oder eben stark „verzögert“. Ist das bei dir auch der Fall?
Ja ganz ausschließen natürlich nicht, aber diese Probleme sind erst seit dem Server Umzug. Kann wie gesagt auch zufällig ein anderes Problem sein.
Lange Ladezeiten habe ich bei ownCloud nicht aber bei Plesk. Wenn ich eine Domain mit HTTPS und Port 8443 öffne, dauert das ab und zu Ewigkeiten.