VMWARE ESXI auf Webtropia

Update: 12.11.2015 — So funktionierts dann doch mit dem Portforwarding und Zusatz-IPs… falls man nicht an untenstehender Story interessiert ist 🙂

 

Bei Webtropia wird VMWARE Esxi erst ab dem „PowerServer“ zur Verfügung gestellt. Das Schöne daran ist, dass man zwischen der automatischen Installation von ESXI 5.5 und ESXI 6.0 wählen kann. (Nein, man muss kein ISO Image uploaden!)

Als NIC kommen INTEL I350 zum Einsatz. Neben den Intelnetzwerkkarten verrichtet eine Intel Xeon CPU D-1540 @ 2.00 GHZ ihren Dienst und wird dabei von 1TB SSD Festplatten (SATA) unterstützt.

Ein schönes Feature des Powerserver ist, dass ILO (Remote-Management über separate IP) möglich ist. Geht per VMWARE nichts mehr, kann man sich immer noch direkt auf den Server hängen und die Sachlage prüfen.

Netzwerkkonfiguration

Ich gehe hier jetzt gar nicht genauer auf die Installation von virtuellen Maschinen ein, sondern eher auf die Netzwerkeinstellungen.

Grundsätzlich bin ich bislang mit meinem Vorhaben pfSense als Firewall-Router einzusetzen gescheitert. (Dies wiederum liegt nicht unbedingt an Webtropia, vermutlich mache ich einfach irgendwo einen Fehler und komme nicht dahinter).

Die Idee, die ich primär hatte war (ähnlich wie bei meinem Hetzner-Artikel) zumindest eine WAN Schnittstelle und eine DMZ per IPSense zur Verfügung zu stellen und externe Anfragen von aussen (WAN) nach innen (DMZ) gefiltert weiterzuleiten.

Probleme…

Ab Bestellung bekommt man 2 IP Adressen. Eine IP Adresse wird für das ESXI Management „verbraten“, die andre liegt am ILO an.

Die IP, die für den ESXI Host verwendet wird, hat einen entsprechend zugehörigen Gateway im gleichen Subnet.

zusätzliche IP Adressen

Bestellt man sich nun zusätzliche IP Adressen, bekommt man selbige zwar sehr zackig zugeteilt, jedoch befinden sie sich in einem ganz andren Subnet wie die Haupt-IP. Ungeachtet dessen, haben Sie aber den gleichen Gateway wie die Haupt-IP. Der Gateway liegt aber in einem andren Subnetz wie die zusätzliche IP.

Modus der zusätzlichen IP Adressen

Im Kundenbackend von Webtropia hat man bei den zusätzlichen IPs 2 Varianten, wie mit diesen umgegangen werden soll:

1.) Server IP, hier wird geroutet

2.) Virtualisierungs-IP, hier wird gebridged

 

Server-IP Konfiguration

Die Adresse wird als Alias angelegt:

auto eth0:1
iface eth0:1 inet static
address aaa.bbb.ccc.ddd
netmask 255.255.255.255

Virtualisierungs-IP

Die Adresse wird in einem point-to-point Setup angelegt:

auto eth0
iface eth0 inet static
address 10.0.2.100
netmask 255.255.255.255
pointopoint 10.0.1.1
gateway 10.0.1.1

Woran ich mir bislang die Zähne ausbeisse…

Genau hier scheitere ich mit der Konfiguration von pfSense. Ich hätte ja den ESXI auf die Hauptadresse des Server gelegt, denn ich gehe davon aus, dass im routed Modus meine Zusatz-IPs über die Server-IP geroutet werden.

Somit könnte ich eingehende Anfragen je nach IP auf virtuelle Server in der VM / DMZ leiten.

ABER: Sobald ich dem ESXI-Host seine IP wegnehme, ist dieser nicht mehr erreichbar.

Wenn ich ihm eine Zusatz IP gebe, kann ich den ESXI host ebenso nicht mehr erreichen, da hier eine entsprechende Netzwerkkonfiguration (siehe am Beispiel Debian point-to-point) notwendig ist, die ich am ESXI Host direkt nicht umsetzen kann.

 

Update 12.11.2015

  • Router-VM: IPFire (basierend auf „Linux“).
  • Einstellungen im Kundencenter von Webtropia bezogen auf die IP-Adressen: Virtualisierung
  • Verwenden einer zusätzlich bestellten IP (nicht der Haupt-IP auf dem WAN-Interface der Router-VM).
  • Auch wenn der Gateway in einem andren Netzwerk liegt, kann man ihn auf die WAN NIC binden (WAN-NIC = red0) und dann die Standardroute auf das Gateway setzen.

Im Terminal von IPfire:

route add -host <Gateway-IP> dev red0
route add default gw <Gateway-IP>

Diese Konfiguration wird jedoch nicht gespeichert und sollte u.U. per Skript / Konfiguration (bei Systemstart) hinterlegt werden. Wird IPFire eingesetzt, sind diese 2 Zeilen in die Datei /etc/sysconfig/rc.local einzufügen.

Ein Interessanter Beitrag zum Thema „Gateway befindet sich in anderem Subnet“: http://blog.magiksys.net/pfsense-firewall-default-gateway-different-subnet

 

Was kann man nun mit dieser Konfiguration erreichen

 

  • IP-Fire lauscht auf einer der zusätzlichen IPs.
  • Portforwarding von extern in die DMZ ist ohne weiteres möglich.

 

Fazit zu Webtropia

Generell muss ich bislang festhalten, dass der Server recht schnell zur Verfügung gestanden ist. Bislang habe ich keinerlei Probleme.

Der Support antwortet recht zügig und gibt sich Mühe, um Probleme zu lösen.

VMWare Esxi auf Hetznerservern – Routervm – pfsense

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):

pfsense_settings

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).

netzkonfigswitches

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:

vmkernel

und diesen dann dem isolieten vSwitch zuweist (in unsrem Fall vSwitch2):

vmkernel_switch

In den vSwitcheinstellungen (Eigenschaften) muss dann bei der Konfiguration des VMKernelports die korrekte interne IP + korrektem internen Gateway angegeben werden:

vmkernelkonfig

 

Mittels Bearbeiten / Reiter IP Einstellungen müssen die korrekten Werte für IP/Subnet/Gateway hinterlegt werden:

ipsettings

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…

Sky Go – …kann aus lizenzrechtlichen Gründen nicht wiedergegeben werden (6030)

Es ist zwar offenbar ein alter Hut, jedoch hat SkyGo wohl immer wiedermal Probleme mit dem aktuellsten Silverlight-Plugin. Jedenfalls meldet es zumindest bei mir mit der letzten Silverlight Version den Fehler 6030. Das ganze läuft bei mir unter Windows 10.

Die Lösung scheint zu sein, dass man Silverlight deinstalliert. Danach greift man dann auf eine ältere Version zurück, die man natürlich zuvor installieren muss.

Nun läuft es wieder.

Ich finde es sehr schade, dass Sky hier offenbar immer wieder hinterher hinkt.

Hallo Sky..!

Der Kunde zahlt für das Programm. Bemüht euch doch ein wenig mehr!

 

Zarafaclient Outlookupdate KB3055041 – shared Kalender funktionieren nicht mehr

Dass Microsoft Office- bzw. Outlookupdates die Funktionalität des Outlook-Zarafaclient desöfteren einschränken, oder komplett „abdrehen“ ist weitestgehend bekannt. So verhält es sich nun offenbar auch mit dem Outlookupdate KB3055041.

Um die Funktionalität von Zarafa wiederherzustellen, muss der zarafaclient-7.2.1-51355.msi installiert werden, der zur Zeit allerdings in der Betaversion angeboten wird (aber funktioniert!).

 

Windows 10 Preview, News und Installation

Microsoft wird demnächst Windows 10 freigeben. Genau genommen am 29. Juli 2015. Obwohl ich schon länger beim „Windows Insider Programm“ angemeldet bin, habe ich erst jetzt der Neugierde nachgegeben. Einerseits könnte ich „10“ auch in die VM bannen, andererseits -dachte ich- führt mein relativ junges Asusnotebook ein ruhiges Leben. Zu ruhig!

Nach dem Erstellen eines Festplattenimages (vielleicht will ich ja wieder zurück auf das installierte Windows 8.1) und dem Brennen des Windows 10 ISO auf eine DVD, geht es auch schon los.

Zuerst mal von 0 weg

Windows 10 kann als Upgrade für bestehende 7er und 8er Versionen verwenden werden, es kann aber auch eine Neuinstallation durchgeführt werden. Erwähnte Neuinstallation interessiert mich nun beim ersten Anlauf. Welche Treiber „holt“ sich Windows 10 automatisch? Wie sieht es mit der Treiberunterstützung meines ASUS X555L aus?

Die Installation verläuft gewohnt unspektakulär. Möglichst wenig Benutzerinteraktion, gepaart mit sehr geringem Zeitaufwand. Nach wenigen Minuten begrüßt mich der Desktop mit dem „neuen“ Startmenü. Das Menü selbst ist eine Kombination des Windows 7 + Windows 8 Stils (klassisch + Kacheln). Gefällt mir ganz gut.

Schade nur, dass MS diesen Schritt nicht schon bei Windows 8 vollzogen hat. Bereits damals wäre für mich der einzig logische Schritt gewesen, dem Anwender die Wahl zwischen „Classic“ und „New UI“ zu geben bzw. -je nach Endgerät- eine Tabletversion / eine Desktop-PC-Version zur Verfügung zu stellen. Aber gut, dem war nicht so…

Out of the box Treibersupport

Wie es scheint, habe ich nach der Installation jedenfalls eine WLAN Verbindung, die zur Verfügung steht und auch Soundausgabe. Ein Verbindungsversuch mit dem WLAN Router verläuft erfolgreich. Der Blick in den Gerätemanager ist dann doch etwas ernüchternd. Bis auf das WLAN + Sound wurde nichts Essentielles erkannt. Gut, bislang stand ja auch keine Internetverbindung zur Verfügung.

Langer Rede kurzer Sinn: Ich lasse per Gerätemanager über das Internet nach Treibersoftware suchen. Fündig wird das System nur bei der Nvidiagrafikkarte. Damit bin ich nun zwar „im Bilde“, dennoch schlage ich den konventionellen Weg ein und hole mir von der Asusseite die -für das Notebook aktuellsten- Windows 8.1 Treiber…

Beginnen wir doch mit dem Chipsetdriverpaket… Zack… Bluescreen…

…hm… naja 1x probier ichs noch … Bluescreen…

Ein Blick auf die Uhr 00:35 lässt mich die Segel streichen.

Ich bin mir relativ sicher, dass ich – hätte ich mehr Zeit in die Neuinstallation gesteckt – ein läuffähiges (komplett installiertes System) erhalten hätte. Dennoch möchte ich mich im Folgenden dem Upgrade widmen.

Versuchen wirs mit dem Upgrade von Windows 8.1

Dank meines Imagingtools kann ich die Originalinstallation (Windows 8.1) innerhalb von relativ kurzer Zeit wiederherstellen. Direkt aus Windows 8.1 heraus, starte ich anschließend das Setup.exe von der Windows 10 DVD. (Upgrade unter Beibehaltung aller Daten).

Wie auch bei der Neuinstallation, macht das System fast alles im Alleingang. Der Upgradevorgang dauert (logisch) um etliches länger wie die Neuinstallation.

10

 Ich kann an dieser Stelle eigentlich gar nichts Spektakuläres berichten. Die Festplatte rattert, die Prozentanzeige nähert sich irgendwann dann doch der 100% Marke… Am Schluss habe ich ein Asus X555L komplett fertig installiert, wobei alle Treiber von der 8.1 Installation übernommen wurden.

Interessant finde ich ausserdem, dass es wohl eine Art „rolling release“ (Windows Insider) und eine „stable“ Version geben wird…

Kommt mir ja von Debianseite her sehr bekannt vor (testing/stable). 🙂