Virtualisierung bei Hetzner - bitte mit 'sicher'

[Der_W]

Servus Leute,

derzeit habe ich bei besagtem Provider einen Dedicated Server, auf welchem Debian läuft - plain&simple. Das Ding hat genug Power, i7 mit VT-d/x und 16, bzw sogar 32GB RAM und 6TB Platz.

Im Zuge meines Spieltriebes würde ich aber auch gern öfters ein paar Sachen ausprobieren, und da wirds bei nem Root doch langsam ungemütlich. Mein Gedanke war also, eine Virtualisierung aufzusetzen und mittels NAT mir dahinter gemütlich meine Guests zu verteilen - Produktion, Integration, Testumgebung und so weiter. Deployment der Konfigurationen würde von einem ebenfalls virtualisierten puppetmaster kommen, Guests wären quasi nur Debian-Maschinen - die Anzahl kann ich jetzt nicht direkt abschätzen, pauschal werdens aber über die Zeit wohl mehr, grad auch weil ich ab und an mal Schulungen im Betrieb mache. Flups, 6 Maschinen hoch und wieder runter ziehen geht dann halt einfach.

Folgende Probleme:

Ich habe auf der Kiste eine, maximal zwei IP-Adressen. Ein bridged-Betrieb fällt also flach, ich muss NAT einsetzen (oder die Clients nur per IPv6 erreichbar machen - da habe ich schließlich ein ganzes /64er).

• welche Virtualisierungslösung ist interessant? Plain KVM, Xen, Proxmox, OpenVZ? Vielleicht sogar gleich OpenStack?
• Wie sichere ich das richtig ab? Zugriff nur von lokal erlauben, demzufolge via SSH-Tunnel oder OpenVPN, fail2ban sowieso - mir wirds etwas mulmig dabei, Webinterfaces von ProxmoxVE direkt ans Netz zu hängen...
• Wegen der Sicherheit () soll der ganze Quark eh verschlüsselt laufen - im Idealfall also einfach ne crypted LVM erstellen, mounten und da drauf meine Maschinen?

 

[Localhorst]

Wieso denn diesen Weg gehen? Ich habe den selbigen Root auf Hetzner und verfolge da eine komplett andere Strategie:

Auf dem Root Server ist der VMWare ESXi 5.1 Host installiert. Und dort liegen dann jegliche Maschinen für den Einsatzzweck (HTTP, FTP, Mail usw.). Ok, ich habe 4 Außen-IPs bestellt aber hey, warum auch nicht

Die letzte IP muss ich auch NATen, also habe ich eine VM mit IPFire eingerichtet. Das ist eine kostenlose Firewall Distri mit der ich wunderbar meine DMZ einrichten konnte.

 

[Der_W]

ESXi wäre natürlich auch ne Lösung, nur fehlt mir da ein bisschen die Erfahrung. Wie sieht es mit der Stabilität dieser Distris aus? Performance?

 

[X-Coder]

Habe bereits Erfahrungen mit Vmware, Xen und OpenVZ gemacht. Hier ist mal eine kurze Übersicht.

In deinem Fall würde ich wahrscheinlich OpenVZ verwenden, das ist keine vollwertige Virtualisierung, sondern ein Containersystem das auf den Host darunter aufsetzt. Zugriff auf die Hardware erfolgt direkt ohne Virtualisierung. Da sind neue Gäste dann auch sehr schnell (wenige Sekunden) aufgesetzt und es ist einfach zu konfigurieren, gerade wenn wie in deinem Fall auf den Gästen das gleiche Linux wie im Host laufen soll. Ein Haken dabei ist nur, dass keine Kernel-Experimente im Gast möglich sind, da der des Hosts verwendet wird.

Soll auch Windows oder anderes in die Gäste, dann würde ich Xen nehmen, OpenVZ geht dann nicht. Vmware hat bei mir unter Linux immer irgendwo Zicken gemacht, spätestens bei Upgrades hatte ich immer mal wieder das Problem das sich eines von den Vmware-Kernelmodulen plötzlich nicht mehr kompilieren ließ und ich dann Stunden damit beschäftigt war, das wieder hinzubiegen.

 

[Der_W]

Xen klingt also schon mal ganz nett (Will mir die Möglichkeit eines eventuellen Windows-Hosts dann doch noch nicht nehmen), der Flexibilität halber würde ich dann aber ein Webinterface verwenden. Irgendwas in Richtung Xen Orchestra - oder spricht da etwas massiv dagegen?

 

[Localhorst]

Also ich bin mit performance und stabilität wirklich zufrieden! Es kann aber auch daran liegen, dass ich nie selber Kernel kompiliere Also für mich persönlich war das die beste Entscheidung

 

[Olize]

Also wen du Windows auch Virtuell laufen lassen willst würde ich zu ESXi greifen.
Die freien Treiber für Windows unter XEN sind meiner Meinung nach nicht so gut wie die vom ESXi/VMware.
VMware ist auch nicht all zu schwer zum einrichten, das geht alles über ein Web Backend.
Einzig wen du Sachen wie Ghettoscrip (ja das heißt wirklich so) zum externen Backup erstellen verwenden willst musst du ein wenig in der Bash arbeiten.

Wen du eine unbeschränkte und quelloffene Lösung nehmen willst würde ich eher zu KVM als zu XEN greifen, da unter KVM die performance ein wenig besser als unter XEN ist. Auch über KVM kannst du Windows VMs laufen lassen.


LG.
Olize

 

[Der_W]

Was mich bei ESXi stört, ist das ich keinen Zugriff auf die darunterliegende Platte habe. Wie sieht es da überhaupt mit Sicherheit aus? In wie fern ist da Hardening notwendig?
Auch fällt das FlexiPack dank ServerBörse weg, wird also wohl eher ein KVM-System...

Unter Debian habe ich einen dropbear-Server, der das restliche System aus der verschlüsselten LVM heraus mountet - selbst wenn einer vor Ort ne Konsole anschließt, sieht er gar nichts...


€: Nach ein wenig einlesen wirds wohl KVM auf Debian-Basis. Spannende Frage an die Experten unter euch:
Mit virt-manager gibt es ja eine schöne Klickibunti-Oberfläche für den Spaß. Kann virt-manager auch in einer Art ThinClient-Modus arbeiten, ähnlich wie Deluge es tut (lokale Deluge Installation mit GUI, auf dem Server läuft nur der Daemon deluged)? Weil irgendwas mit X auf dem Server zu installieren fällt volle Bude flach

Wenn dann nach außen nur SSH auf $port offen ist wär es mir am liebsten, anstatt den Host dann gleich mit Webserver und ähnlichem Krempel zuzuklatschen, nur damit man seine VM nicht per 200-Zeichen Shellbefehl zusammenklöppeln muss.^

Hat jemand zum genannten Setup Performance-Erfahrungen? Auf ein SW-RAID würde ich gern verzichten, die vollen 6TB dürften nützlich sein. Weiterhin will ich zusätzlich Vagrant einsetzen, gerade wenn ich Puppet/Chef teste.

 

[Der_W]

Ich hoffe, ich bekomme jetzt nicht auf die Mütze:
Zielkonfiguration sieht derzeit so aus, das ich wohl virtualbox auf dem Host verwende. So kann ich einerseits meine Boxen schon lokal vorbereiten und dort einfach nur starten, andererseits kann ich auf dem Host selbst dann munter vagrant-en ohne irgendwelche weiteren halbgaren Providerplugins installieren zu müssen.

Einzig die Netzwerkkonfiguration mit VirtualBox auf der shell muss ich mir jetzt noch anschauen...

 

[Localhorst]

WoW, ich lese erst jetzt deine vorherige Frage bzgl. der darunter liegenen Platte. Was meintest du denn damit?

VirtualBox, ajaaaaa was haste denn als Linux drunter laufen?

 

[Der_W]

Eine sehr sehr schmale Debian-Installation. Mit der bin ich vertraut und der Ressourcenaufwand ist vertretbar. Dazu "kann nichts kaputtgehen was nicht da ist".
Remotebox stellt weiterhin das grafische Frontend zur Verfügung, welches ich für die Verwaltung der nicht-Vagrant-Boxen (sprich, Applikationsserver ect) nutzen möchte.

Mit einer "Voll verschlüsselten Platte" meine ich ein System wie DIESES hier.

Das startet beim hochfahren einen SSH-Server, der erst einmal auf die Eingabe des Passwortes wartet, bis er das eigentliche System nachläd. Sehr elegant, und im Falle eines Umzuges kann ich meine LVM-Container verhältnismäßig einfach abziehen und woanders hochladen.

 

[Localhorst]

Und ich habe gedacht ich habe es kompliziert gelöst

 

[Der_W]

Ich habe so ein System derart verschlüsselt im Moment schon am laufen, und es ist klasse

Außer beim reboot (und das passiert vlt. 3-4mal im Jahr) läuft das System ganz normal, wenn man vom einmaligen Aufwand der Konfiguration absieht. Da muss man halt mal kurz nen Command copy&pasten.

Als Virtualisierungsplattform ist VirtualBox zwar nicht gerade der Burner, aber immerhin muss ich nicht irgendeine sketchy gecrackte Vmware (oder gleich mal 200 Latten für ein Hobbypropjekt blechen!) ans Netz hängen, nur damit die darunterliegende Hardware tut was ich will. Zumal Vmware x.org verlangt, und das ist auf dem Desktop schon eine Pest gewesen.

Nach außen "guckt" dann nur noch ein SSH-Port und der Port für den Manager.

 

[Localhorst]

öhm, Seit wann kostet VMware ESXI etwas und verlangt x.org?!

VMWare ESXi ist für den normal Nutzer kostenlos, da ist kein Crack nötig, wie der VMWare Player um lokal was zu ändern?

 

[Der_W]

ESXI kann nicht routen, d.h. ich brauche auf jeden Fall zwei IPs plus ne LARA zum installieren. Auf die darunterliegenden Files habe ich keinen Zugriff (d.h. ich kann die Platten nicht verschlüsseln), und mit dem Rescue-System bin ich im Notfall angeschissen.

 

[Localhorst]

@Der_W: Kurz zur Aufklärung:

Ja, natürlich braucht man da eine LARA, aber danacher geht ja alles über vSphere Client. Routen kann ESXi:



Wobei eine zweite IP ist nicht teuer und einfacher! Aber wieso solltest du denn das FileSystem von ESXi verschlüsseln? Die VM erhalten ja VDX Platten und dann kann man doch den Inhalt verschlüsseln Aber vllt. bin ich da etwas anders gestrickt als du, weil ich nichts auf Verschlüsselung setze ...

 

[Der_W]

Oh, das der routen kann wusste ich gar nicht

Das mit der Verschlüsselung ist eine essentielle Anforderung von mir, in wie fern die einzelnen Systeme auch nochmal gecrypted werden hängt von deren Datensensibilität ab.

Ich will das System soweit wie möglich gegen Angriffe - auch vor Ort - abdichten, für weiteres schau dir mal DIESE Slides an.

 

[Der_W]

Dann mal als Info wie es derzeit läuft:
Der Root selbst ein ein minimal Debian am laufen, auf dem sich weiterhin ausschließlich Virtualbox befindet.

Eine Vbox läuft mit IPfire als Router-VM, welche ein bridge-Interface auf eth0 vom Host mit einer zweiten IP hat, sowie ein Interface in ein Internal Network. Weitere VM hängen im Internal Network und über Portweiterleitungen kann ich auf die Systeme zugreifen.

Weiterhin stellt IPfire ein OpenVPN-Tunnel ins Interne Netzwerk, damit kann ich dort also auch "geschlossene" Systeme betreiben. NICE!

Der Host hat zwei Platten, wo boot unverschlüsselt ist. via initram kommt Dropbear hoch und ermöglicht einen Unlock der Systempartition und des Rests.
Ich habe zwei Partitionen - einmal den Rest von sda und die komplette sdb - via LUKS verschlüsselt. Auf diesen befinden sich Physical Volumes, welche in einer Volume Group zusammengefasst werden.

Jede Maschine bekommt nun ein eigenes Logical Volume, auf welchem sich alle Daten (VirtualBox-Files) befinden. Zu Sicherungszwecken kann ich also einfach das Logical Volume sichern und habe alles unter einem Dach. bei Bedarf kann ich dazu gern die Scripte zur Verfügung stellen