Foro: Thomas Franzky, Fotolia

Virtualbox bietet gleich drei verschiedene Arten, eine virtuelle Maschine ans Netzwerk zu koppeln. Wer volle Kontrolle möchte, muss aber auf die Kommandozeile abtauchen und kryptische Befehle eingeben.

Wenn virtuelle Maschinen mit einem realen Netzwerk verkuppelt sind, surft es sich wie in einer Sandbox sicher im Internet, ohne Angst vor Viren, Rootkits oder anderen Eindringlingen, die das produktive Hostsystem sehen oder beschädigen könnten. Bei Bedarf tauscht der Benutzer schnell das Plattenimage gegen eine frühere Version.

Admins und Software-Entwickler testen mit virtuellen Netzen gefahrlos verschiedene Konfigurationen, ohne dabei Chaos im echten LAN zu produzieren. Webhoster profitieren von den Vorteilen, indem sie kurzerhand die Internetauftritte ihrer Kunden in jeweils eigene virtuelle Maschine sperren. Die einzelnen Gastsysteme kommen sich nicht ins Gehege und lasten die Hardware besser aus.

Fisch oder Fleisch?

Stetig wachsender Beliebtheit erfreut sich unter den Virtualisierungsvarianten die virtuelle Schachtel aus dem Hause Innotek [1]. Deren Lösung Virtualbox existiert in zwei Geschmacksrichtungen: Während private User die geschlossene kommerzielle Variante kostenlos einsetzen, steht die alternative “Open Source Edition” komplett unter der GPL.

Open Source oder kommerziell?

Die beiden Schachtelinhalte unterscheiden sich bei der Unterstützung für USB-Geräte und der Remote-Desktop-Funktion, die Innotek ausschließlich der Closed-Source-Variante spendiert hat. Beide Ausgaben unterstützen von Linux über OS/2 und Windows/DOS eine Vielzahl von Betriebssystemen, die Administration erfolgt über eine grafische Benutzeroberfläche.

Die Open-Source-Kiste erweist sich unter Linux als sperrig, zumindest was die Installation angeht (siehe Kasten “Installation der Open-Source-Variante”). Besser integriert sind die Pakete aus den Distributions-Repositories, meist bietet bereits das Paketmanagement Virtualbox an, mit den richtigen Installations-Quellen reicht etwa unter Ubuntu »apt-get install virtualbox«, unter Suse »zypper in virtualbox«.

Ein Klick oder der Befehl »VirtualBox« startet das GUI, das Icon »Neu« erstellt eine virtuelle Maschine, ein Assistent führt durch die Einrichtung. Als Ersatz für eine echte Partition dient eine Datei mit einem Festplattenimage. Hier erweist es sich als eine gute Wahl, für deren Größe die Einstellung »dynamisch« zu wählen, dann wächst sie mit den Inhalten mit und spart wertvollen Plattenplatz. Sobald die Emulation läuft, fängt das zugehörige Fenster den Mauszeiger vollständig ein, die rechte [Strg]-Taste funktioniert als so genannter Host-Key und gibt ihn wieder frei.

./configure
source ./env.sh
kmk all

cd out/linux.x86/release/bin/src
make
sudo make install

LD_LIBRARY_PATH=. ./VBoxSVC&
LD_LIBRARY_PATH=. ./Virtualbox

Vier gewinnt

Nach der Installation markiert der Benutzer im GUI die virtuelle Maschine, deren Netzwerkeinstellungen er konfigurieren möchte, und wählt Optionen aus dem Menü »Maschine | Ändern«. Auf der linken Seite führt dann der Eintrag »Netzwerk« zu den Einstellungen (Abbildung 1). Für jede virtuelle Maschine stehen bis zu vier virtuelle Netzwerkkarten bereit, »Adapter 0« bis »Adapter 3«. Standardmäßig erhält jede aber erst einmal nur eine NIC, für alle weiteren braucht\’s ein paar Klicks auf den entsprechenden Registerkarten.

Abbildung 1: Die Einstellungen der virtuellen Netzwerkkarten. Standardmäßig ist der NAT-Modus aktiv. Benutzer generieren hier eigene MAC-Adressen, und für schnelle Tests lässt sich sogar das virtuelle Netzwerkkabel ziehen.

Mit dem Schalter »Netzwerkkabel angeschlossen« zieht der Admin den virtuellen Netzwerk-Stecker. Dabei erscheint die Karte weiterhin als in der virtuellen Maschine eingebaut, lediglich die Verbindung zur Außenwelt ist unterbrochen, so als hätte das Putzpersonal mal eben das Netzwerkkabel aus der Schachtel herausgezogen. Das eignet sich gut für Tests oder Re-Initialisierungen bei Hotplug-fähigen Gästen.

Jede der vier Netzwerkkarten läuft in einem von drei möglichen Betriebsmodi, der im Listenfeld »Angeschlossen an« festgelegt ist. Er bestimmt, mit wem die virtuelle Netzwerkkarte kommuniziert und welche anderen Computer sie sieht. Zur Auswahl stehen:

• Internes Netzwerk
• Network Adress Translation (NAT)
• Hostinterface-Modus

Internes Netzwerk

Für die Netzwerkkarten simuliert Virtualbox auf Wunsch ein komplettes internes LAN. In diesem virtuellen Netz dürfen beliebig viele virtuelle Maschinen hängen, sie bleiben dort vollständig unter sich: Weder kommt der Host hinein, noch erreichen die angeschlossenen Gastsysteme einen Computer außerhalb ihres internen Netzes (Abbildung 2).

Abbildung 2: Ein internes Netz bleibt ausschließlich den virtuellen Maschinen vorbehalten, wie in einer Sandbox sind sie vor dem Internet geschützt. Online-Updates sind damit aber auch nicht möglich.

Auf den ersten Blick erscheint das interne Netz damit von recht eingeschränktem Nutzen. Für seinen Einsatz sprechen aber sogar mehrere gute Gründe: Da das virtuelle LAN vollständig von der Außenwelt abgeschottet ist, bleibt es ungestört. Ideale Bedingungen für Tests oder Fehlersuche also.

In den anderen beiden Betriebsmodi fließen die gesendeten Daten zwangsweise immer auch über das Netzwerkinterface des Hosts. Wenn zwei virtuelle Maschinen Daten austauschen, dann bringt dieser Umweg fast immer auch Geschwindigkeitseinbußen oder Sicherheitsprobleme mit sich. Wer eine virtuelle Netzwerkkarte mit dem internen LAN verbinden will, wählt dementsprechend in der grafischen Oberfläche »Internes Netzwerk« unter »Angeschlossen an«.

Was Virtualbox so alles verschweigt

Alle so konfigurierten Adapter aus sämtlichen virtuellen Maschinen hängen dann an einem simulierten Switch in demselben virtuellen Netz. Leider steht in diesem Modus kein DHCP-Server bereit, die IP-Adressen der Gäste muss der Admin per Hand vergeben. So einfach die Einrichtung ist – an dieser Stelle unterschlägt die Benutzeroberfläche jedoch eine interessante Funktion: Virtualbox kann mehrere, voneinander unabhängige interne Netzwerke erstellen und parallel betreiben.

Um diese virtuellen LANs besser voneinander unterscheiden zu können, erhält jedes einen eindeutigen Namen. Die über die Oberfläche angestöpselten Netzwerkkarten landen dabei per Default immer im internen Netz mit der Bezeichnung »intnet«.

Vboxmanage

Wenn weitere LANs erforderlich sind, muss das Kommandozeilenwerkzeug »VBoxManage« herhalten. Es stellt nicht nur eine vollständige Alternative zur Oberfläche dar, sondern kennt auch weitaus mehr Einstellungsmöglichkeiten. Allerdings funktioniert es nur über recht unhandliche, lange und kryptische Parameterketten.

Um beispielsweise eine zweite Schnittstelle (»nic2«) der virtuellen Maschine »UbuntuVM« an das interne LAN mit dem Namen »Mein Netz« zu hängen, modifiziert die Funktion »modifyvm« die entsprechenden Einstellungen via:

VboxManage modifyvm "UbuntuVM" -nic2 intnet -intnet2 "Mein Netz"

Das interne Netz bildet die geschlossene Schachtel, aus der heraus es dem Gast nicht ohne weitere Interfaces möglich ist, im Internet zu surfen oder aufs LAN zuzugreifen.

Network Adress Translation

Schnell und unkompliziert gestattet dagegen der NAT-Modus den Ausbruch aus dem Käfig. Im Listenfeld »Angeschlossen an« ausgewählt, hängt die so konfigurierte virtuelle Netzwerkkarte an einem simulierten DHCP-Server mit Firewall, der gleichzeitig einen Zugang zur Außenwelt vermittelt.

Die Funktionsweise veranschaulicht Abbildung 3: Im ersten Schritt erhält der Adapter in der virtuellen Maschine automatisch eine IP-Adresse vom integrierten DHCP-Server, der gewöhnlich Adressen aus dem Bereich 10.0.x.x. verteilt. Sobald der Gast Datenpakete über die virtuelle Leitung schickt, fängt Virtualbox diese ab, versieht sie mit der IP-Adresse des Hostsystems und entlässt sie in die Weiten des Internets.

Abbildung 3: Im NAT-Modus erhält die virtuelle Maschine eine Adresse vom eingebauten DHCP-Server. Die Firewall verhindert den Zugriff von außen.

Zwar ist die Konfiguration schnell abgeschlossen, aber diese Betriebsart birgt einen funktionellen Nachteil: Die Umsetzung der IP-Adressen (Network Adress Translation, NAT) sorgt im Zusammenspiel mit der eingebauten Firewall dafür, dass das Gastsystem zwar Daten in die Fremde schicken kann, Außenstehenden und sogar dem Host selbst aber der Zutritt verwehrt bleibt. Ausnahmen bilden da der Remote-Desktop der kostenpflichtigen Version oder der kundige Admin legt mit VPN-Tools wie Openvpn einen Tunnel in die Box.

In der virtuellen NAT-Maschine lassen sich produktive Server also nicht wirklich sinnvoll kapseln. Einen Ausweg aus diesem Dilemma bringt die Krücke Port Forwarding. Dabei lauscht Virtualbox an einem Port des Hostsystems und leitet alle dort ankommenden Pakete an einen Port in einer ausgewählten virtuellen Maschine weiter. Für einen anderen Rechner wirkt dies so, als ob er einen Dienst direkt auf dem Host in Anspruch nehmen würde. Das Port Forwarding aktivieren drei Vboxmanage-Befehle vor dem Start der virtuellen Maschine:

VBoxManage setextradata "UbuntuVM" "VBoxInternal/Devices/pcnet/0/LUN#0/Config/meindienst/Protocol" TCP
VBoxManage setextradata "UbuntuVM" "VBoxInternal/Devices/pcnet/0/LUN#0/Config/meindienst/GuestPort" 22
VBoxManage setextradata "UbuntuVM" "VBoxInternal/Devices/pcnet/0/LUN#0/Config/meindienst/HostPort" 2222

Damit leitet Virtualbox alle TCP-Verbindungen auf den Port 2222 des Hosts an den Port 22 des Gastes weiter. »meindienst« ist dabei ein frei wählbarer Name, »UbuntuVM« der Name der virtuellen Maschine. Bleiben beim Aufruf alle Werte leer, schaltet Virtualbox das Port Forwarding wieder ab.

Hostinterface

NAT mit Port Forwarding bringt aber auch einen deutlichen organisatorischen Overhead mit sich. Der Admin muss Ports auf dem Server öffnen und eventuell auch sichern, er muss den Überblick behalten, welche Ports welchem Dienst auf welcher Maschine zugeordnet sind. Komfortableren Betrieb eines Servers gestattet der Hostinterface-Modus (Host Interface Networking) von Virtualbox, der allerdings äußerst umständlich einzurichten ist.

Beim Host Interface Networking erstellt Virtualbox eine zusätzliche, virtuelle Netzwerkkarte auf dem Host, etwa neben dem bekannten »eth0« noch ein »vbox0«. Sobald diese neue Netzwerkkarte steht, verbindet sie Virtualbox über ein virtuelles Kabel mit dem simulierten Adapter im Gast. (Abbildung 4).

Abbildung 4: Die Anfrage aus dem Internet erreicht den Host, der sie über eine TAP-Schnittstelle in die virtuelle Maschine weiterleitet.

Für sinnvolle Anwendungen verbindet Virtualbox normalerweise das reale Netz und das virtuelle über eine Bridge. Der Zusammenschluss verhält sich dann nach außen wie ein einziges großes Netz. Um diesen Aufbau zu verwirklichen, ist aber zunächst für jeden Gast eine virtuelle Netzwerkschnittstelle auf dem Host erforderlich.

Brücken bauen

Linux kennt bereits von Haus aus virtuelle Netzwerkadapter in Form der so genannten TAP-Schnittstellen, auch Virtualbox nutzt diese Variante. Einzige Voraussetzung hierfür ist der freie Zugriff auf die Gerätedatei »/dev/net/tun«, der von Virtualbox eingesetzte Benutzer braucht dafür die entsprechenden Zugriffsrechte. Dann bedarf es noch einer Bridge-Software, etwa der aus dem Paket »bridge-utils«, sowie des Kommandozeilen-Programms »tunctl«. Letzteres versteckt sich bei Open Suse in den »uml-utilities«.

Im Zusammenspiel mit Virtualbox gibt es fürs Bridging zwei mögliche Vorgehensweisen:

• Der Admin richtet eine permanente Schnittstelle ein, mit der
  sich eine virtuelle Maschine nach dem Start verbindet. Dieser Weg
  ist der richtige, wenn stets eine feste Anzahl von Gästen auf
  ihren Einsatz wartet.
• Oder er lässt die virtuelle Maschine selbstständig
  bei ihrem Start eine dynamische Schnittstelle erstellen. Diese
  Variante ist zwar wesentlich flexibler, benötigt jedoch jedes
  Mal das Administratorpasswort.

Permanente oder dynamische Schnittstelle

Für eine permanente Schnittstelle benötigt der Admin eine regelrechte Befehlsorgie. Zunächst richtet er die Bridge ein und verbindet sie mit »eth0«:

brctl addbr br0
ifconfig eth0 0.0.0.0
brctl addif br0 eth0

Im zweiten Schritt aktualisiert er die IP-Adressen. Falls ein DHCP-Server diese vergibt, genügt ein »dhclient br0«, andernfalls setzt er die Adresse manuell mit »ifconfig br0 IP-Adresse«.

Für jede simulierte Netzwerkkarte im Gast ist jetzt noch eine virtuelle Schnittstelle auf dem Host erforderlich, die »VBoxAddIF vbox0 User br0« mit der Bridge verbindet. Das kleine Hilfsskript »VBoxAddIF« erstellt dabei eine TAP-Schnittstelle unter dem Namen »vbox0«, auf die der Benutzer »User« Zugriff erhält. »VBoxAddIF« liegt dem Virtualbox-Paket standardmäßig bei, versteckt sich im ausgepackten Quellcode jedoch etwas ungünstig im Ordner »src/VBox/Installer/linux«.

Abschließend muss Root nur noch die simulierte Karte im Gast mit der TAP-Schnittstelle verbinden. Dazu trägt er ihren Namen in der Konfigurationsoberfläche hinter »Name des Interfaces« ein. Die beiden Zeilen für die Skripte bleiben in diesem Fall leer. Um die Schnittstelle nach Gebrauch wieder freizugeben, hilft »VBoxDeleteIF vbox0« auf der Kommandozeile. Dieses Tool fehlt übrigens der Open-Source-Variante.

Für die zweite Methode benötigt der Admin zwei Skripte. Eins erstellt die TAP-Schnittstelle und verbindet sie mit der Bridge, das andere deaktiviert sie wieder. Listing 1 zeigt in Anlehnung an das Handbuch ein Beispielskript für die Aktivierung einer TAP-Schnittstelle, detailliertere Informationen dazu bietet das Virtualbox-Manual [3].

01 #!/bin/bash
02 # TAP Schnittstelle für den Benutzer klaus erstellen:
03 interface=`VBoxTunctl -b -u klaus`
04 # Die Schnittstelle erschaffen:
05 ifconfig $interface up
06 # Mit der Bridge verbinden:
07 brctl addif br0 $interface

Das Hilfsprogramm »VBoxTuntl« liegt Virtualbox bei. Dahinter verbirgt sich im Wesentlichen nichts anderes als das bekannte »tunctl«. Das Startskript macht der Admin ausführbar und trägt es in der Virtualbox-Konfigurationsoberfläche unter »Programm zum Einrichten« mit einer Sudo-Kombination wie »gtksudo Startskript« ein (Abbildung 5). Wenn keine grafische Oberfläche zur Verfügung steht, hilft:

VBoxManage modifyvm "NamederVM" -tapsetup1 "gtksudo Startskript"

Listing 2 zeigt das entsprechende Skript zum Ausschalten der TAP-Schnittstelle. Auch hier trägt der Admin den Pfad zum ausführbaren Skript in Virtualbox ins passende Eingabefeld ein, am besten zusammen mit einem Sudo-Aufruf in »Programm zum Entfernen«. Alternativ dient auch hier »VBoxManage«, diesmal aber mit der Option »-tapterminate1«

Sobald die virtuelle Maschine startet, ruft sie das Aktivierungs-Skript für das Erstellen einer TAP-Schnittstelle auf und fragt via »gtksudo« das Root-Passwort ab. Analog löst das zweite Skript die TAP-Schnittstelle beim Herunterfahren des Gastes wieder auf.

Abbildung 5: Bei der von Virtualbox »Hostinterface« genannten Bridging-Variante stehen zwei Eingabefelder für Start und Stopp des virtuellen Interface zur Verfügung. Hier leisten eigene Skripte gute Dienste.

01 #!/bin/bash
02 # Schnittstelle (deren Name steht in $2) von der Bridge abkoppeln:
03 brctl delif br0 $2
04 # Und Schnittstelle entfernen
05 VBoxTunctl -d $2

Remote Desktop

Damit nicht genug: Die kommerzielle Virtualbox-Variante leitet auf Wunsch sämtliche Bildschirmausgaben über das Remote Desktop Protocol (RDP) auf einen anderen Computer um. Von dort aus können Benutzer übers Netzwerk direkt auf den Desktop der virtuellen Maschinen zugreifen, egal welche Netzwerkkonfiguration darin vorliegt. Damit eignet sich Virtualbox auch für Server ohne grafische Oberfläche.

Um diese Remote Display getaufte Funktion zu aktivieren, legt der Admin im GUI zunächst die Portnummer fest, unter der Virtualbox diesen Service auf dem Host bereitstellt. Damit nicht beliebige Personen den Desktop der virtuellen Maschine zu sehen bekommen, sollte er auch eine Authentifikationsmethode vorgeben.

Mit »External« muss sich der Benutzer am Host mit der dort geltenden Methode anmelden, »Guest« bedeutet hingegen eine Anmeldung beim Gastsystem. »Null« schaltet den Authentifizierungszwang komplett ab.

Nachdem er die neuen Einstellungen zum Schluss noch gespeichert hat, startet Root die virtuelle Maschine auf der Kommandozeile mit »VBoxVRDP -startvm« neu. Dann holen sich Benutzer mit »rdesktop« oder jedem anderen RDP-Client die virtuelle Maschine auf den Arbeitsplatz.

Schwierig, stabil und flott

Alle drei von Virtualbox angebotenen Verbindungsarten fürs Networking der virtuellen Maschinen haben Vor- und Nachteile, eine stets optimale Lösung gibt es nicht. Wer aus einer virtuellen Maschine nur schnell ins Internet möchte, greift zum NAT-Betrieb, muss dann aber auf den Remote-Zugriff verzichten. Für einen eingesperrten Serverdienst kommt hingegen nur das umständlich zu konfigurierende Hostinterface mit den Bridging-Tools in Frage.

Weil die grafische Benutzeroberfläche derzeit noch keine Unterstützung dafür bietet, bleibt nur der Wunsch an Innotek, rasch alle Netzwerkeinstellungen im GUI zugänglich zu machen. Tröstlich: Auch die Konkurrenz glänzt da nicht gerade. Bei Xen ist das ähnlich kompliziert und in VMware gibt\’s auch nur ein Befehlszeilen-Tool namens »vmware-config.pl« für virtuelle Netzwerke. Das kann dann allerdings mit wenigen Fragen mehrere NAT-, Host-only- und Bridged-Mode-Netzwerke einrichten.

Aber die Hoffnung ist da, denn Gerüchten zufolge arbeitet Innotek verstärkt an der Netzwerk-Konfiguration. Bis dahin lohnt sich die Mühe: Einmal eingerichtet läuft die Schachtel mit den virtuellen Systemen sehr flott und stabil. (mfe)