Virtualisierung

Auswirkungen VMWARE ESXI Spectre & Meltdown VMkernel.Boot.hyperthreadingMitigation

von

Für alle, die sich fragen, welchen Impact das Aktivieren des ESXI Parameters VMkernel.Boot.hyperthreadingMitigation haben kann, 2 Diagramme (Readytime), aus der VCenter-Überwachung. Wichtig hierbei ist, dass der Wert so niedrig wie möglich sein sollte und möglichst nicht über rund 1500ms.

 

Wie oben ersichtlich, liegen wir bei einem Host mit 2 CPUs, je 8 Cores  – in Summe also 16-Cores, ohne Hyperthreading bei einem Wert von teilweise !!! 15.000ms !!! Dies hatte massive Auswirkungen auf die Performance des Hosts, auf dem 12VMs laufen. Insgesamt sind 38vCpus zugeordnet.

Der gleiche Host, mit deaktivierter Option „VMkernel.Boot.hyperthreadingMitigation“ und aktivem Hyperthreading:

Nicht täuschen lassen! Die Kurve scheint optisch extremer, aber schaut mal nach links zur Legende. Hier haben wir jetzt eine Wert von „nur“ noch max. 1.750ms. Danach pendelt sich der Wert ein. Dies hatte zur Folge, dass der Host und die darauf installierten VMs wieder normal liefen.

Hier wird man aufgrund der Situation dann zwangsläufig mit der Frage / Entscheidung konfrontiert, ob Sicherheit oder Leistung wichtig ist. In dem Fall habe ich mich (aufgrund der Begleitumstände, dass die Systeme in einer recht sicheren Umgebung laufen) für die Leistung entschieden. Allerdings hätte ich mir nie gedacht, dass der Parameter derartige Auswirkungen hat. Anzumerken ist auch, dass es sich hierbei um relativ alte CPUs handelte, nämlich: Intel(R) Xeon(R) Silver 4110 CPU @ 2.10GHz (Marktstart: 3. Quartal 2017)

Xenserver 7: Sicherheit erhöhen – Rootserverbetrieb

von

Wenn der Xenserver auf einem Rootserver im Internet installiert wird, ist dieser über die ihm zugeordnete offizielle IP Adresse erreichbar. Dies bedeutet, dass das Managementnetzwerk / Managementinterface grundsätzlich von jedem aufrufbar ist.

Um dieser Problematik etwas entgegenzuwirken, kann man die iptablesfirewall umkonfigurieren bzw. den SSH-Port verschieben.

Mir ist bewusst, dass das nur ein Tropfen auf den heißen Stein ist, jedoch jedenfalls besser wie nichts.

SSH Port verlegen

Per XenCenter Serverkonsole sind folgende Anpassungen durchzuführen.

Im Verzeichnis /etc/ssh/sshd_config wird der Port verlegt. Standardmäßig läuft SSH auf Port 22. Dies verlegt man z.B. auf Port 2232.

Iptables anpassen

Nun muss natürlich die Firewall angepasst werden, damit Verbindungen auf Port 2232 erlaubt werden.

Das anzupassende File namens iptables findet sich im Ordner /etc/sysconfig. Es beinhaltet bereits einige Regeln. Unter anderem findet sich auch die Regel für den Standardport (22) in dieser Datei. Diese wird entsprechend angepasst, sodass sie dem „neuen“ SSH-Port entspricht.

Schließlich ist die Datei noch zu speichern und iptables und sshd neu zu starten.

service iptables restart && service sshd restart

hosts.deny und hosts allow einsetzen

Genaugenommen eigentlich ein MUSS in einer solchen Netzwerkkonstellation.

Sofern der PC, mit dem man auf den Xenserver einsteigt, mit einer statischen offiziellen IP-Adesse ins Internet geht, gibt es eine elegante Methode, den Zugriff auf den Xenserver einzuschränken.

In der Datei /etc/hosts.allow wird definiert, welche IPs auf den Server zugreifen dürfen. Die anzuführenden IPs sind neben der localhost IP (127.0.0), auch noch die statische IP, von der aus man den Xenserver managed.

Der Eintrag kann z.B. so aussehen:

ALL: 127.0.0 89.163.225.17

D.h. diese IPs dürfen sämtliche Services auf dem Xenserver nutzen.

Nun muss in /etc/hosts.deny noch für alle anderen ALLES verboten werden. Dieser Eintrag ist recht simpel gehalten und sieht folgendermaßen aus:

ALL: ALL

Durch diese Einstellungen wird jedem Client der Zugriff verweigert, solange nicht die Ausnahmeregelung in den hosts.allow greift.

Nachteil

Natürlich bedingt dies, dass man immer mit den angeführten IP Adressen auf den Xenserver zugreift. Blöd nur, wenn man gerade „irgendwo“ ist und man nicht von seiner gewohnten IP-Adresse aus aufs Internet zugreift.

Workaround

Sollte neben dem Dedicated Root(Xen)Server noch ein weiterer Server mit statischer offizieller IP im (Inter)net aktiv sein, kann man diese IP ebenso in die hosts.allow eintragen. Schließlich könnte dann der Umweg über den zusätzlichen Server genommen werden.

Sprich also:

Client mit dynamischer IP -> ssh zu zusätzlichem Rootserver (IP steht am Xen in den hosts.allow) -> ssh zu Xenserver.

 

 

 

Xenserver 7: NFS ISO-Store von Synology NAS einrichten

von

XENSERVER auf einem dedicated Rootserver

Ich möchte hier kurz beschreiben, wie man ein NFS-Share von einer Synology NAS, die in einem lokalen Netzwerk steht, einem XENSERVER (dedicated Rootserver), zur Verfügung stellt.

Die ISO-Dateien werden von einem beliebigen PC im lokalen Netzwerk auf das Share abgelegt und stehen dem Xenserver, nach Einbindung des ISO-Repositories zur Verfügung.

Ports (Virtual Server)

Da die Synology-NAS in meinem internen Netzwerk steht und ich aus dem Internet heraus (vom dedicated Rootserver) auf die NFS-Freigabe zugreifen will, muss eine entsprechende Portweiterleitung erfolgen.

Auf meinem TP-Link Router nennt sich dies „Virtual Server“.

Die Weiterleitungen sind folgende:

NFS-Server (Synology NAS)

Als NFS-Server fungiert meine Synology NAS mit DSM 6.0.1-7393 Update 2.

Damit NFS überhaupt funktioniert, muss in der Systemsteuerung der Synology unter Dateidienste NFS aktiviert werden. Optimalerweise setzt man auch gleich das Häkchen bei „NFSv4-Unterstützung“ aktivieren.

Nachdem das  NFS-Service nun „scharf geschaltet“ ist, muss noch eine Freigabe erstellt werden. Zu diesem Zweck, wechselt man in der Synology Systemsteuerung zu den Gemeinsamen Ordnern.

Über den Button „Erstellen“ erfolgt die Konfiguration der Freigabe.

Im Folgefenster können Berechtigungen für lokale Benutzer gesetzt werden. Da man mit einem PC (z.B. SMB-Share) auf die Freigabe zugreift, um ISO-Files abzulegen, muss hier ein User mit entsprechenden Berechtigungen gewählt / oder zuvor angelegt und die Berechtigungen entsprechend gesetzt werden.

Wichtig ist jedoch vor allem der Reiter „NFS-Berechtigungen“, denn dort wird definiert, welche IP-Adressen auf den NFS-Server (die Freigabe) zugreifen dürfen.

In das Feld Hostname oder IP wird die Adresse des NFS-Client eingetragen. (Somit darf nur von dieser IP aus auf NFS zugegriffen werden!) Der NFS-Client ist in diesem Fall der XenServer. Die Privilegien müssen auf Lesen/Schreiben gesetzt sein.

Somit ergeben sich folgende Einstellungen.

Ganz unten im Fenster sieht man den Mountpfad, welcher in dieser Konfiguration: /volume1/NFS_ISO lautet. Der Pfad wird später für die Einbindung der Freigabe auf dem Xenserver verwendet.

Somit sind alle Vorarbeiten auf dem NAS abgeschlossen.

ISO Repository auf dem Xenserver einbinden

Für die Verwaltung des Servers, verwende ich OpenXenManager.

Die Serververbindung ist bereits aufgebaut. Nach einem Rechtsklick auf den Server, welcher auf der linken Seite des OpenXenManager aufgeführt wird, wählt man „New Storage Repository“.

Im Folgefenster wird „ISO Library – NFS ISO“ gewählt. (Aufgrund meiner hohen Auflösung und dem angepassten Skalierung sind die Screenshots leider unschön.)

Im Feld „Share Name“ ist die öffentliche IP des NFS-Servers gefolgt vom lokalen Mountpfad des NFS-Share (in diesem Falle /volume1/NFS_ISO) einzutragen.

Genaugenommen also z.B.: 123.456.789.001:/volume1/NFS_ISO

Wobei es sich bei oben angeführter IP nur um eine fiktive Adresse handelt, die durch die korrekte öffentliche IP – über die die Synology NAS anzusprechen ist- zu ersetzen ist.

Das Ergebnis der Übung – ein NFS ISO Store ist eingebunden.

Download und ablegen des ISO Files

Auf dem lokalen PC kann man sich aufgrund dessen, dass auch eine normale SMB Freigabe erstellt wurde, mit dem Share verbinden und legt dort beispielsweise den Debian Netinstaller (ISO) ab.

Eine VM installieren

Nach Ablage des ISO Files im NFS-Share, muss am Xenserver ein Rescan des ISO-Repositories erfolgen.

Danach kann eine neue VM angelegt werden und die zu installierende ISO-Datei vom NFS-Share aus gewählt werden.

Nach dem Start der VM, präsentiert sich der Debian Installer. Die Daten kommen hierbei dann von der ISO Datei, die per NFS-Share eingebunden wurde.

 

 

 

 

Xenserver 7 auf einem dedicated Rootserver

von

Meine bisherigen Virtualisierungserfahrungen habe ich einerseits auf Microsofts Hyper-V und andererseits auf VMWARE ESXI gemacht. Den Xenserver hatte ich bislang komplett aussen vor gelassen.

Grund genug also, den Xenserver zu testen. Für den Test habe ich einen dedicated Rootserver mit 32GB Ram, 1TB Festplattenspeicher und einem I7 Prozessor verwendet.  Verbaut ist ausserdem eine Realtek-NIC (r8169).

Installation

Für die Installation bestelle ich einen kostenpflichtigen Remotemanagement Zugang (KVM Spider). Die ISO Datei des Xenserver lade ich auf meinen lokalen PC. Die Remotekonsole basiert auf Java, weshalb am PC die aktuelle Version des Java Runtime Environment installiert sein muss.

Da die Sicherheitsmechanismes des JRE mittlerweile sehr strikt sind, muss für die IP, oder auch für die Adresse, die für das Remotemanagment verwendet wird, eine Ausnahme erstellt werden.

Java Konfigurieren – Reiter Sicherheit – Ausnahmeliste – Siteliste bearbeiten…

Nun sollte sich die Remotekonsole öffnen lassen.

KVM Spider Probleme mit dem Keyboard

Nachdem das ISO File im Remotemanagement gemountet war, hoffte ich nun auf eine problemlose Installation. Wäre da nicht das Problem mit dem Keyboard gewesen. Ich kannte das schon von einem anderen Hoster. Das Keyboard funktioniert anfangs, nach dem Restart dann jedoch u.U. nicht, oder vielleicht doch… So kann ich jedenfalls nicht vom eingebundenen ISO booten. Ich komme nicht in das Bootmenü des Bios.

Nach mehreren erfolglosen Versuchen, die Sachlage mit dem Support zu klären und endlich ein funktionierendes Remotemanagement zur Verfügung gestellt zu bekommen, begebe ich mich selbst auf Ursachenforschung- Schließlich übermittle ich dem Support einige Settings, die man wohl im Bios (USB Einstellungen) vornehmen muss, damit KVM funktioniert.

Endlich, das Setup läuft

Das ISO-File ist eingebunden und das Setup läuft. Da es so geradlinig und selbsterklärend ist, verzichte ich auf Screenshots. Sämtliche Hardware wird out-of-the-box erkannt. Einzig die zu verwendende Festplatte, der Servername, die Netzwerkeinstellungen und das Rootpasswort sind zu konfigurieren bzw. auszuwählen.

Management per XenCenter

Um den Server managen zu können, benötigt man XenCenter, welches – wie der XenServer – kostenlos zur Verfügung steht. Nach der Installation muss der XenServer (Host) noch in XenCenter hinzugefügt werden.

Wenn man will, kann ein Masterpasswort für das XenCenter gesetzt werden. Dies ist allerdings nur dann sinnvoll, wenn man mehrere Hosts betreibt, da die Passwörter aller Hosts im Center gespeichert werden können und die Entsperrung aller Server aufeinmal dann mit dem Masterpasswort geschieht.

Im Funktionsumfang nicht beschnitten

Obwohl es sich bei Xenserver um die kostenlose Version (ohne Support) handelt, ist sie im Funktionsumfang in keinster Weise beschnitten. VMs können migriert, kopiert, verschoben, exportiert, importiert, konvertiert usw. werden.

Festplattenmanager / Storage Repository

Was mir fehlt, ist das Verwalten von lokal am Server installierten Festplatten. Will man eine weitere Festplatte als Storage-Repository einbinden, kann dies nur per Konsole erfolgen.

Verwaltung per Web-Gui  „Xen Orchestra“

Wenn man den Xenserver gerne per Webgui administrieren will, kann man auf Xen Orchestra zurückgreifen. Eine gute Installationsanleitung findet sich auf der Website von tecmind.com.

Fazit

Meiner Ansicht nach stellt Xenserver eine ernstzunehmende Alternative zu den anderen Virtualisierungsplattformen dar. Einzig bei einigen Verwaltungsfunktionen hätte ich gerne eine etwas komfortablere Bedienung per GUI. Soweit von mir bislang korrekt interpretiert, gibt es eine eher geringere Anzahl von Drittanbieter „Backup-/Restoresoftware“.

Ansonsten ist Xenserver ein tolles Produkt!

 

 

VMWARE ESXI auf einem dedicated Server mit IPFire – LAN DMZ und WAN mit Zusatz-IPs

von

Generell würde ich sagen, gehöre ich speziell bezogen auf das IT Umfeld zu einem Menschen, der so gut wie niemals aufgibt. Gut – stimmt nicht – bei Vista und Windows ME habe ich hier eine Ausnahme gemacht ;-).

Geht nicht, gibts nicht…!

Aufgabenstellung:

  • Dedicated Rootserver
  • VMWARE ESXI Version 6.0
  • kompatible NIC (Intel)
  • Servermanagement per Remote (ILO)
  • Einsatz einer Router-VM, um die VMs entsprechend zu schützen und um WAN, LAN und DMZ realisieren zu können.
  • zusätzliche offizielle IP Adressen, um mehrere Server in der DMZ mit IP / FQDN ansprechen zu können.
  • VMs müssen auch ins Internet „raus“ kommen
  • Installation des ESXI sollte auf dem dedicated Server möglichst ohne „Krampf“ durchführbar sein.

Dedicated Rootserver

Ich habe einige bekanntere Rootserver Anbieter getestet. Darunter Hetzner, Server4you und Webtropia.

Server4you

Server4you brüstet sich NICHT damit, ESXI-kompatibel zu sein, bietet aber grundsätzlich recht gute Server und  angenehme Kommunikation. Selbst im Falle einer Kündigung des Vertrages lässt sich dies bequem über das Backend erledigen – keine Bürokratie!

Ein Grund für mich, einen Versuch zu starten…

Wenn ein Rescue-System auf S4Y läuft, könnte man lt. Auskunft (ohne Gewähr) über eine Drittanbieterseite (installserveros) einen Installationsversuch anstossen.

Versucht, gewartet und gescheitert.

Abgesehen davon: Niemand kennt diese Plattform, welches Image würde hier wohl installiert, man muss die Daten des Rescuesystems eingeben, damit die Site Zugriff auf den Server bekommt. Ja und was macht das Script dann? Ich weiß es nicht, …

Die Site funktioniert nicht und ist obendrein eventuell unsicher.

Fazit: Server4you für ESXI – no go!

 

Hetzner

Qualitativ hochwertige Server, sehr professioneller Auftritt. Bereitstellung der Geräte geht normalerweise rasch von der Hand. Mehrmals jedoch scheitere ich an der Verwendung der LARA. Dies ist eine Konsole, mit deren Hilfe man quasi direkten Zugriff auf den Server hat.

Immerwieder reagiert LARA nicht auf Tastatureingaben. Ich muss den Support mehrfach bemühen. (In Summe vergehen hiermit Stunden!).

Nebenbei erwähnt – LARA ist zeitlich limitiert und kostet nach Ablauf des  Gratispensums pro Stunde…

Mit dem Hetznerserver EX40 konnte ich es in weiterer Folge nicht schaffen, eine stabile Verbindung -> EXTERNE Zusatz-IP -> Router-VM -> DMZ -> Owncloud @ Debian zustande zu bringen, obwohl das Routing seitens Hetzner und auch die Konfiguration der Routing-VM stimmig war.

Getestete Routing-VMs: pfSense (mehrfach neu installiert), IP-Cop, ipFire.

Nicht ganz klar war mir, ob die Problematik vielleicht an der verbauten Realtek NIC lag.

Da Hetzner grundsätzlich wirklich gute Geräte anbietet, wollte ich noch einen weiteren Versuch mit einem PX60 (mit Intel-NIC) starten, gab dann aber schließlich auf, nachdem mich die LARA wieder zur Weißglut brachte.

Das Verhalten liegt lt. Hetzner daran, dass es Probleme mit der Einbindung des virtuellen Datenträgers gibt. O-Ton: „Kann funktionieren, aber muss nicht…“

Alternative: Man bittet den Support darum, das ISO File auf USB zu kopieren — Kostenpunkt allerdings EUR 25.00

 

Webtropia

Weiterer Anlauf, anderer Hoster. Wie im vorhergehenden Beitrag erwähnt, bietet meiner Meinung nach auch Webtropia recht gute Hardware. Vor allem Intel NICs (I350). Beim Server, der grundsätzlich als kompatibel zu ESXI 5.5 und 6.0 beschrieben ist, ist ein integriertes Management mit dabei, welches über separate IP und Webinterface (JAVA) ansprechbar ist.

Der Clou dabei: Es funktionierte bislang immer, ohne Ausnahme.

Webtropia bietet einen schönen Installer für diverse OS – und auch ESXI 5.5 und 6.0, der entweder per Backend angestoßen werden kann, oder per Bootmenu! — sehr schön, wie ich finde!

Somit sind die Kriterien:

 

  • Dedicated Rootserver
  • VMWARE ESXI Version 5.5 / 6.0
  • kompatible NIC (Intel)
  • Servermanagement per Remote (z.b. ILO)
  • Installation des ESXI sollte auf dem dedicated Server möglichst ohne „Krampf“ durchführbar sein.

erfüllt.

Konfiguration ESXI

Ich will mehrere Server in der DMZ (mehrere öffentliche IPs, die in die DMZ geroutet werden)

Genau genommen, habe ich mittlerweile aufgrund von Vererbung schon recht wenig Haare am Kopf. Nun, nach der ganzen Aktion habe ich definitiv noch weniger ;-). Nicht, dass es irgendein Problem seitens dem Anbieter (Webtropia) gab… Vielleicht hatte ich einfach einen Knoten im Hirn…

 

Switches und Netzwerk im ESXI

Das Managementnetzwerk ist auf die Haupt-IP gebunden und kann über diese IP über den Browser aufgerufen werden. Zu beachten ist hierbei, dass in der Grundkonfiguration JEDER aus dem Internet zumindest bis zum Login kommt.

Schnelle Abhilfe wäre, per Sicherheitsprofil den Zugriff per vSphereclient + sofern aktiv SSH-Server einzuschränken:

sicherheitsprofilesxi

Später sollte man das Managementnetz auf einen „internen Switch“ — (LAN) verlegen und ein VPN aufbauen, um darauf zuzugreifen.

Switches

Wir haben in der Grundkonfiguration 1x vSwitch0 (Managementnetzwerk). vSwitch0 ist an die physische NIC angebunden. Einen weiteren Switch für das LAN + einen Switch für die DMZ. LAN und DMZ-Switches sind sog. isolierte Switches. D.h. sie sind an keine Netzwerkkarte angebunden.

Das sieht dann so aus:

switchesipfire

 

To do, im Webtropia Backend

Über das Backend bei Webtropia bestellen wir uns zusätzliche IP Adressen. (ich hab mir 2 bestellt).

Wichtig: Bei den IPs kann man den Modus im Webtropia-Backend einstellen. Dieser Modus MUSS auf Virtualisierungs-IP stehen!

Noch viel Wichtiger: Man muss dem Support per Ticket mitteilen, dass alle weiteren bestellten Zusatz-IPs bitte auf die IP zu routen sind, die man auf dem WAN (red0) Port des IPfire vergeben hat. Also eine Zusatz-IP ist IPFire und jede weitere muss man auf die IP-Fire-IP routen lassen! Danke Herr Stevens! (Webtropia Support)

Lets fire it up – IPFire Installation

Wir erstellen uns im ESXI eine neue VM für die Installation von IPFire. Hierbei wählen wir „anderes Linux 2.6.x Linuxsystem – 64 Bit“ und folgende Konfiguration:

ipfireesxi

Wie man sieht 3x NICs / 3 Zonen…

Wichtig: Notiert euch die MAC-Adressen der NICs, welche man – während die VM läuft – über die Eigenschaften aufrufen kann. Dies braucht ihr nämlich, um -während des Setup von ipFire- die Interfaces korrekt zuzuordnen!

Netzwerkkonfig (Zonen)

In IPFire wählen wir während des Setup (welches man nach erfolgter Installation immer wieder mit dem Befehl „setup“ in der IPFire Konsole aufrufen kann die Netzwerkkonfiguration: GREEN (LAN) + RED (WAN) + ORANGE (DMZ).

NIC – Zuordnung

Hier werden die MAC Adressen schlagend. Darauf achten, dass die NICs den entsprechenden Zonen zugeordnet sind, sonst läuft nachher nichts!

nics_ipfire

IP –  Adressenzuordnung

WAN: Eine der georderten Zusatzadressen inkl. Gateway lt. Vorgabe des Hosters.
DMZ: Beliebiger interner IP Bereich. Ich hab hier 10.0.0.0/24 genommen. Gateway = Ipfire = 10.0.0.1
LAN: Ebenso beliebig. Meine Range: 192.169.1.0/24. Gateway = Ipfire = 192.168.1.1.

Hier könnte man dann noch in IP-Fire einen DHCP Server aktivieren, dann wirds ganz bequem. 🙂

DNS: Unbedingt angeben. Dies kann der vom Hoster bereitgestellte DNS sein, oder zb. auch der von Google. (Wenn man das mag…).

Standardgateway: Der Standardgateway zeigt auf den Gateway, der der Haupt-IP zugeordnet ist. (Die Zusatzip hat keinen expliziten Gateway!)

Der Gateway ist aber in einem andren Subnet

In IPFire muss man den Gateway an das red0 (WAN) Port binden und dann eine entsprechende Route setzen. Dies gelingt ausschließlich über die Konsole.

Um die Einstellungen persistent zu machen (Einstellungen überleben auch einen Neustart) ist mittels IPFire Konsole die Datei

/etc/sysconfig/rc.local

zu editieren und folgende Zeilen einzufügen:

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

Anmerkung: red0 = WAN-Port.

Nach einem Neustart des IPFire sollte diese Geschichte gegessen sein. Auch wenn er während des Bootvorganges meckert. Es funktioniert.

Versucht bitte nach erfolgtem Neustart eine IP zu pingen. Zb. den Standardgateway, der der Haupt-IP zugeordnet ist. Oder auch den Google-DNS – 8.8.8.8 (was hab ich nur mit Google?)

Der Routingtable des ipFire sieht bei mir dann so aus:

routing_fire

So, jetzt wo IPFire on fire ist, wirds Zeit für den Zugriff auf die GUI.

IP-Fire GUI Einstellungen – Firewallregeln

IP-Fire ist vom LAN aus von der entsprechend zugeordneten IP auf Port 444 über https zu erreichen.

Ich installiere mir in ESXI also eine VM (Linux Mint in meinem Falle), welche ich auf den LAN-VSwitch hänge. Ist ein DHCP Server konfiguriert, sollte Mint sich von selbst die korrekte IP Adresse holen. ACHTUNG: Es ist wichtig, dass auch der DNS stimmt, sonst liegt man bei Versuch eines WWW-Wellenrittes auf dem trockenen!

Kein DHCP: OK, dann bitte die LAN-IP + Gateway + DNS manuell zuordnen!

Ein Webserver in der DMZ

Weiters installiere ich ein Debian  „LAMP“ in ESXI und ordne es Netzwerkseitig der DMZ zu. Die IP von Debian ist 10.0.0.3 (Anm: Gateway = DMZ-Port von IPFire: 10.0.0.1)

So nun notiere ich mir die zweite Zusatz-IP die ich vom Hoster bekommen habe. Diese lautet in meinem Falle: 89.163.249.243

 

Zurück zur IPFire Gui

In der VM „Linuxmint“ rufe ich per Browser: https://192.168.1.1:444 auf (klick for bigger-Image):

ipfireonfire

Über Netzwerk –> Aliase lege ich dann einen Alias mit meiner Zusatz-IP an:

firealiasund gehe dann auf Firewall -> Firewallregeln -> Neue Regel:

rulesexternal

Weiter unten darauf achten, dass die Regel aktiv ist. (Haken gesetzt).

Der Firewall-Rulesbereich sieht dann so aus. (Anmerkung: ich habe hier noch weitere Rules, die Anfragen „abfangen“ und umleiten die direkt auf die IP von IPFire kommen. Bitte nicht beachten. Unsere Regel ist in Zeile 3 zu sehen:

rules_for_fire

 

Wenn man nun von einem beliebigen PC aus, die dem Webserver zugeordnete offizielle IP – in dem Fall also 89.163.249.243 – aufruft sollte sich Folgendes tun (klick for bigger view):

debian_fire

Tja, das wars dann mal soweit… Die Finger glühen, der Kopf raucht 🙂

Have fun!

Dankeschön + weiterführende Infos

PS: Danke an den Support von Hetzner, Server4you und Webtropia. So muss das laufen. TOP! Sehr bemüht, freundlich und schnell!

Nachsatz: Ein weiterführender Beitrag eines Bloggingkollegen bezogen auf Hetzner (nice!): https://virtpro.eu/vmware-esxi-hetzner-ex4-vorbereitung/

Opensource rules!

Danke an alle Entwickler und Unterstützer! You are awesome!

IPFire: http://www.ipfire.org/
PfSense: https://www.pfsense.org/
IPCop: http://www.ipcop.org/

Nicht vergessen möchte ich in diesem Zusammenhang auch VMWARE – (ESXI) für die unglaublich gute Virtualisierungsplattform!