Thema: VirtualBox: Verschiedene Gast-OS (Linux/*NIX oder Windows) im "Headless" Modus

In diesem Tutorial möchte ich die Einrichtung und Verwaltung sowie einige kleine, praktische Scripte vorstellen, die den Betrieb verschiedener, virtueller Maschinen mittels VirtualBox im so genannten "Headless Modus" verbunden mit der Möglichkeit des entfernten Zugriffs mittels SSH und/oder RDP auf selbige zum Ziel haben.

Die Netzwerkeinrichtung der virtuellen Maschinen wird dabei mit NAT (Standardeinstellung) vorgenommen, im Prinzip geht das auch mit einer der anderen Methoden, was mir persönlich an der NAT-Methode gefällt, man hat praktisch automatisch eine "Firewall", da der Host wie ein NAT-Router für den Gast agiert.

Die Einrichtung wird dadurch vielleicht etwas "komplizierter", aber dafür hat man mehr Kontrolle über den Gast, was z.B. auch bei Betriebssystemen aus dem Hause Microsoft von Vorteil sein kann, wenn das OS in der Standardinstallation alles an Ports öffnet, was bei drei nicht auf dem Baum ist und wovon die meisten Benutzer so gut wie gar nichts benötigen, aber als "Lösung" für diese IMHO eindeutige Fehlkonfiguration dann eine "Personal Firewall" davor schalten, die Dienste vor dem Zugriff schützt, die man eh nicht laufen lassen will.

Warum diese Dienste per default nicht einfach _ausgeschaltet_ sind, entzieht sich zwar meiner Logik, aber wahrscheinlich ist meine Logik in der Minderheit, denn >90% Marktanteil müssen schließlich logischer sein als etwas gesunder Menschenverstand.

Des weiteren wird auf eine sichere Möglichkeit des Zugriffs auf die "kopflosen" VMs Wert gelegt indem SSH bzw. RDP mit externer Authentifizierung eingerichtet und verwendet werden.

Als Host wurde openSUSE 11.1 (sowohl i586 als auch x86_64) verwendet, prinzipiell sollte sich dieses Tutorial aber auf alle Linuxdistributionen übertragen lassen.

0. Was ist dieser "Headless Modus" überhaupt?

Im so genannten Headless Modus läuft die virtuelle Maschine "im Hintergrund" ohne daß ein GUI-Fenster vorhanden ist, des Weiteren kann solch eine VM logischerweise auch dann gestartet und "remote" benutzt werden, wenn auf dem Host _kein_ X-Server läuft.

1. Und was bringt mir das?

Eines der Szenarien ist z.B., daß man einen kleinen Testserver in einer VM statt auf "echtem Eisen" laufen lassen möchte und dieser aber "von außen" wie ein Server auf einer "richtigen" Maschine erreichbar sein soll, ohne die Sicherheit des Hosts zu gefährden.

Eine weitere Möglichkeit ist auch, daß man ein anderes OS ab und zu für Testzwecke braucht, dieses aber nicht immer in einem Fenster auf dem Desktop/in der Taskleiste herumliegen haben sondern bei Bedarf darauf zugreifen möchte.

2. Aber wenn kein Fenster offen ist, wie kann ich dann auf die VM zugreifen?

Je nach Gast-OS gibt es mehrere Möglichkeiten, *NIX-artige Systeme bieten natürlich mit SSH eine einfache und sichere Methode, bei Windows greift man am einfachsten über RDP (Remote Desktop Protocol) zu (was auch für *NIX-artige Gast-OS zur Verfügung steht).

Da VirtualBox seine eigene RDP-Implementierung mitbringt, ist dies eine sehr einfache Möglichkeit (und für Windows-Gäste die einzige ohne Nachinstallieren irgendwelcher, weiterer Software auf dem Gast) um auf jegliche Art von VM via GUI zugreifen zu können. Zur Absicherung des Zugriffs über RDP wird Authentifizierung über das PAM-System des Hosts verwendet, für die Absicherung des SSH-Zugangs für *NIX-artige Gäste konsultiere man eines der zahlreichen Tutorials (Stichwort Pubkey statt Passwort).

3. Einrichten des Zugriffs über RDP mit externer Authentifizierung

1) Davon ausgehend, daß man schon eine (oder mehrere) virtuelle Maschinen hat, hier die Einrichtung von VRDP über das Standard-Interface von VirtualBox, die entsprechende VM darf dabei _NICHT_ laufen!

Code:

VirtualBox

(oder über einen entsprechenden Eintrag im Startmenü aufrufen)

=> Maschine auswählen => Anzeige => Fernsteuerung => Server aktivieren [x] ankreuzen => Einen Port > 1024 wählen (wichtig!) => "Authentisierungsmethode" von "Null" auf "Extern" umstellen => Server aktivieren [ ] Kreuz entfernen (das Regeln wir später über unsere Startscripte) => OK

Wer das Ganze von Hand machen will, der schaue im Handbuch nach und lese die Ausgaben von "VBoxManage --help"

2) Einrichtung von PAM für externe Authentifizierung

Die default-Einstellung für VRDP Authentifizierung lautet "Null" und das ist auch in etwa das, was sie aus Sicherheitsaspekten wert ist, denn so könnte _jeder_ lokale Nutzer auf die laufende VM zugreifen (sollte man den entsprechenden Port nach außen freigegeben haben/freigeben wollen, dann könnte das auch jeder Hansel aus dem Internet), das ist natürlich indiskutabel.

Nun müssen wir aber PAM beibringen, daß es für diese externe Authentifizierung auch zu Rate gezogen wird.

Hierzu werden zwei Dateien benötigt, die wir als root an den entsprechenden Platz legen müssen.

Code:

# enable PAM-Authentification for VBOX-RDP  
export VRDP_AUTH_PAM_SERVICE="vbox_vrdpauth"

#######################################################################################
## Don't forget to create a file /etc/pam.d/vbox_vrdpauth with the following content ##
##                                                                                   ##
## auth    required        pam_unix.so                                               ##
## account required        pam_unix.so                                               ##
#######################################################################################

Diese Datei als /etc/profile.d/vbox_vrdpauth.sh ablegen, sie muss _nicht_ ausführbar aber lesbar für alle Nutzer sein (0644).

Code:

auth    required        pam_unix.so
account required        pam_unix.so

Diese Datei als /etc/pam.d/vbox_auth ablegen, auch hier sollten die Dateirechte 0644 sein.

Nun entweder einmal abmelden/anmelden oder als normaler User einmalig

Code:

source /etc/profile.d/vbox_vrdpauth.sh

aufrufen.

4. Test des Zugriffs über RDP mit externer Authentifizierung

Nun starten wir eine virtuelle Maschine im "Headless Modus" für die wir unter 3. RDP-Zugriff eingerichtet haben, hierzu muss ihr Name bekannt sein.
Dieser entspricht dem Namen, den wir auch im VirtualBox-GUI sehen bzw. dem Namen des entsprechenden Ordners unter ~/.VirtualBox/Machines/.

Eine meiner Maschinen heißt "WindowsXP", also starte ich diese mit:

Code:

 VBoxHeadless -s WindowsXP -vrdp on&

und erhalte folgende Ausgabe:

Code:

 VirtualBox Headless Interface 3.0.10
(C) 2008-2009 Sun Microsystems, Inc.
All rights reserved.

Listening on port 3389

Der RDP-Server für diese Maschine läuft also auf Port 3389, der Parameter "-s NameDerMaschine" ist eigentlich selbsterklärend und "-vrdp on" sollte auch klar sein. Wer mehr wissen will, liest das Handbuch und/oder die Ausgabe von "VBoxHeadless --help".

Nun kann man sich mit dieser Maschine (lokal) verbinden, VirtualBox liefert einen RDP-Client mit, wer möchte, kann aber auch "rdesktop" statt "rdesktop-vrdp" verwenden (im Paket "rdesktop" enthalten).

Code:

 rdesktop-vrdp -p - localhost:3389
Autoselected keyboard map de
Password:

Die Optionen "-p -" sorgen dafür, daß man nach dem Passwort per STDIN (also Eingabe über Tastatur) gefragt wird, Zugriff erfolgt über localhost auf Port 3389.

Dies kann man prüfen mit,

Code:

netstat -tulpen

es sollte eine Zeile wie diese angezeigt werden.

Code:

tcp        0      0 0.0.0.0:3389            0.0.0.0:*               LISTEN      1000       945121     -

Das dabei abgefragte Passwort ist _mein_ Nutzerpasswort auf dem _Host_, also das Passwort mit welchem ich mich an meiner Kiste anmelde (deshalb auch "externe" Authentifizierung), es scheint aber so, daß sich nur der Nutzer anmelden kann, der diese VM auch gestartet hat und natürlich kann auch immer nur ein Zugriff zur gleichen Zeit erfolgen.

Wer also mehreren Nutzern Zugriff ermöglichen möchte, der sollte einen extra Nutzer anlegen, welcher die entsprechenden VMs startet z.B. mit su:

Code:

su - NamedesSpezialnutzers -c "VBoxHeadless -s NamederMaschine -vrdp on&"

und dessen Zugangsdaten den potentiellen Nutzern zur Verfügung stellen.

Wenn der Zugriff funktioniert, dann ist Teil 1 dieses HowTos abgeschlossen; sollte die "Headless"-Maschine mit ACPI installiert worden sein, so kann man sie nicht nur durch Anmelden über rdesktop und dann entsprechendes Herunterfahren ausschalten, sondern auch (meistens, nicht immer, sollte auf der Windowskiste gerade jemand angemeldet sein, dann fragt Windows erst nach, ob man wirklich herunterfahren möchte) mit

Code:

VBoxManage controlvm NamederMaschine acpipowerbutton

was dem Drücken des (wie der Parameter acpipowerbutton schon andeutet) "Power"-Schalters an einem "echten" PC entspricht, also in meinem Beispiel ein

Code:

VBoxManage controlvm WindowsXP acpipowerbutton

und das virtuelle XP fährt herunter.

Dieser Teil des Tutorials ist von der Einrichtungsmethode des Netzwerks für den Gast unabhängig, wer nun auch Zugriff von außen auf die Maschine per RDP erlauben möchte, der muss nur noch den/die entsprechende(n) Port(s) in seiner Firewall/Router freischalten/weiterleiten.

Eine weitere Möglichkeit besteht darin, den entsprechenden Port _nicht_ frei zu schalten und Zugriff über einen SSH-Tunnel auf den Host zu ermöglichen, dann kann auch die Umstellung der Authentifizierung auf "Extern" weggelassen werden. Hierzu konsultiere man entsprechende HowTos/Literatur zum Thema SSH-Tunnel.

Im zweiten Teil des Howtos werden wir uns mit Zugriff über SSH, den entsprechenden "Port Forwarding"-Regeln für die NAT-Implementierung von VirtualBox und einigen Scripten beschäftigen, die das Ganze etwas erleichtern.

Greetz,

RM

Im zweiten Teil dieses Tutorials möchte ich die Einrichtung von "Port-Forwarding" über VBoxManage erklären, mit welcher es möglich ist in einem über NAT eingerichteten Gast einen Serverdienst "nach außen" verfügbar zu machen.

Dies wird am Beispiel eines SSH-Servers zur Fernwartung geschehen, es kann jedoch auch auf beliebige, andere Serverdienste übertragen werden.

Ich möchte erneut betonen, daß dies auch (und möglicherweise sogar "einfacher") über eine alternative Einrichtungsmethode (Bridged/Host-Only, etc.) machbar ist, der "Charme" der NAT-Methode liegt darin, daß man gezielt Ports über VirtualBox freigeben kann, welches wie ein NAT-Router für den Gast agiert.

Als "Schmankerl" wird zusätzlich erklärt, wie man über eine einfache "REDIRECT"-Regel in SuSEfirewall2 einen im Gast auf Port 22 (=default) laufenden SSH-Server nach außen hin ebenfalls auf Port 22 verfügbar machen kann, ohne die entsprechende virtuelle Maschine als root starten zu müssen (was ein absolutes "No-go" wäre).

Dieses Prinzip kann natürlich auch auf andere Serverdienste angewendet werden (HTTP/FTP/*you-name-it*).

0. Vorarbeiten

Zu allererst empfiehlt es sich die jeweilige Konfigurationsdatei für alle Fälle der virtuellen Maschine zu sichern, diese findet sich normalerweise unter /home/Euer_Username/.VirtualBox/Machines/NAME_DER_MASCHINE/NAME_DER_MASCHINE.xml.

Da es (noch) keine Möglichkeit gibt, die entsprechenden Einstellungen über das VirtualBox-GUI vorzunehmen, müssen wir mit der Konsole und dem (sehr mächtigen) Konfigurationswerkzeug "VBoxManage" arbeiten.

Ich empfehle zusätzlich _vorher_ folgende Kapitel im VirtualBox Handbuch (im openSUSE-RPM unter "/usr/share/doc/packages/VirtualBox/UserManual.pdf" zu finden) zu lesen:

"Configuring port forwarding with NAT"

"Fine-tuning the VirtualBox NAT engine"

(Zur Zeit der Entstehung dieses Tutorials sind dies die Kapitel 6.4.1 und 9.12, die verwendete Version von VirtualBox ist 3.0.10)

Für die hier beschriebenen Einstellungen benötigen wir

a) den Namen der virtuellen Maschine

b) den Typ (pcnet oder e1000) und die Nummer (1-4) der virtuellen Netzwerkkarte des Gastes*

c) den Port auf welchem der entsprechende Server im Gast läuft (SSH = 22)

d) einen im Hostsystem noch nicht von einem Serverdienst benutzten Port > 1024 (das sollte das geringste Problem sein)

und last but not least

e) der entsprechende Dienst muss natürlich im Gast eingerichtet und aktiviert werden, hierzu verweise ich erneut auf entsprechende Tutorials z.B. zur sicheren Einrichtung eines SSH-Servers unter (openSUSE) Linux

*Anmerkung: Wer trotz korrekt eingerichteten Port-Forwardings Probleme mit einem Adapter aus der "Intel E1000"-Reihe hat (Verbindung läuft in einem Timeout ohne Rückmeldung), der sollte sich diesen Thread ansehen.

VBox 3.0.X - NATted Network, kein SSH-Zugriff im Headless Modus - linuxforen.de -- User helfen Usern

1. Einrichten einer Portweiterleitung über VBoxManage

Wichtig:

Die Einstellungen sollten bei _nicht_ laufendem Gast vorgenommen werden!

Hierzu öffnen wir als der Nutzer, welcher die virtuellen Maschinen eingerichtet hat und starten soll ein Terminal und geben folgende Befehle ein (allgemeine Syntax):

Code:

VBoxManage setextradata "NAME_DES_GASTES" "VBoxInternal/Devices/TYP_DER_NETZWERKKARTE/NUMMER_DER_NETZWERKKARTE_MINUS-1/LUN#NUMMER_DER_NETZWERKKARTE_MINUS-1/Config/FREI_WÄHLBARER_NAME_DES_DIENSTES/Protocol" TCP

Diese "einleitende" Regel legt fest für welches Protokoll die Weiterleitung eingerichtet werden soll (für SSH ist das eben TCP) und wie wir den Dienst intern in der entsprechenden Konfiguration unserer virtuellen Maschine nennen wollen.
Drei Dinge sind hier zu beachten:

a) Der frei wählbare Name des Dienstes muss (logischerweise) eindeutig sein und für alle weiteren regeln, die _diesen_ Dienst betreffen verwendet werden

b) Im VirtualBox-GUI werden die virtuellen Netzwerkkarten von 1 beginnend gezählt, VBoxManage beginnt die Zählung bei 0, deshalb auch "NUMMER_DER_NETZWERKKARTE_MINUS-1".

c) Zur Zeit werden _nur_ TCP und UDP als Protokolle unterstützt, wer also irgendwelche "exotischen" Protokolle nutzen möchte kann dies nicht mit NAT tun.

Nun folgt die zweite Regel, mit welcher wir festlegen, welchen Port auf dem Gast wir erreichbar machen wollen.

Code:

VBoxManage setextradata "NAME_DES_GASTES" "VBoxInternal/Devices/TYP_DER_NETZWERKKARTE/NUMMER_DER_NETZWERKKARTE_MINUS-1/LUN#NUMMER_DER_NETZWERKKARTE_MINUS-1/Config/FREI_WÄHLBARER_NAME_DES_DIENSTES/GuestPort" PORT_DES_LAUFENDEN_DIENSTES_AUF_DEM_GAST

(Tipp: Wer hier die "History"-Funktion der Bash mittels "Pfeil-Auf"-Taste verwendet, erspart sich viel Tipparbeit.)

Abschließend die dritte Regel, mit welcher wir festlegen auf welchen Port des Hostsystems weitergeleitet werden soll.

Code:

VBoxManage setextradata "NAME_DES_GASTES" "VBoxInternal/Devices/TYP_DER_NETZWERKKARTE/NUMMER_DER_NETZWERKKARTE_MINUS-1/LUN#NUMMER_DER_NETZWERKKARTE_MINUS-1/Config/FREI_WÄHLBARER_NAME_DES_DIENSTES/HostPort" FREIER_PORT_GROESSER_1024

(Auch hier wieder, "Pfeil-Auf" erspart Tipparbeit.)

Auch wenn die Eingaben etwas "länglich" erscheinen, so sind sie doch in ihrer Vorgehensweise nachvollziehbar. Wir müssen festlegen für welche Maschine (Name) welcher Dienst auf dem Gast (GuestPort) auf welchen Port des Hosts (HostPort) über welches Interface (Nummer der Netzwerkkarte) für welches Protokoll (Protocol, TCP/UDP) weitergeleitet werden soll und diesem Regelsatz einen eindeutigen Namen verpassen.

2. Anwendungsbeispiel

Genug der grauen Theorie, hier nun ein Anwendungsbeispiel, welches der Konfiguration einer meiner virtuellen Maschinen entspricht, die ich per SSH erreichen möchte.

a) Vorgaben

- der Gast hat den Namen "openSUSE-11.2-64" (selbsterklärend)

- auf dem Gast läuft ein sicher (nur Pubkey, kein Rootlogin, AllowUsers, etc., pp.) eingerichteter openSSH-Server auf Port 22

- ich möchten den Gast über den (freien) Port 22222 des Host erreichen können

- die virtuelle Netzwerkkarte des Gastes ist Nummer 1, als Typ wurde eine "Intel PRO/1000 MT Server" (also aus der e1000-Familie) gewählt (ich verweise erneut auf obigen Link zu linuxforen.de) und diese mit NAT eingerichtet =>

- den Dienst nenne ich "GastSSH" und SSH verwendet bekanntermaßen TCP als Protokoll

b) Einrichtung über VBoxManage

Backup der Konfigurationsdatei.

Code:

cd ~/.VirtualBox/Machines/openSUSE-11.2-64/
cp openSUSE-11.2-64.xml openSUSE-11.2-64.xml.bak

Damit ergeben sich folgende Befehle zur Einrichtung der Portweiterleitung, sich aus der obigen Aufgabenstellung ergebende Parameter sind farbig hervorgehoben:

Code:

VBoxManage setextradata "openSUSE-11.2-64" "VBoxInternal/Devices/e1000/0/LUN#0/Config/GastSSH/Protocol" TCP
VBoxManage setextradata "openSUSE-11.2-64" "VBoxInternal/Devices/e1000/0/LUN#0/Config/GastSSH/GuestPort" 22
VBoxManage setextradata "openSUSE-11.2-64" "VBoxInternal/Devices/e1000/0/LUN#0/Config/GastSSH/HostPort" 22222

c) Überprüfen der Einrichtung

- Zunächst prüfen wir "offline" (also ohne laufende VM), ob die Einrichtung korrekt übernommen wurde, hierzu wechseln wir in den entsprechenden Unterordner "/home/Username/.VirtualBox/Machines/NAME_DER_MASCHINE" (in diesem Fall "openSUSE-11.2-64") und suchen in der Einrichtungsdatei "NAME_DER_MASCHINE.xml" (also hier "openSUSE-11.2-64.xml") mittels grep nach dem Namen, den wir unserem Regelsatz gegeben haben (in diesem Fall "GastSSH"):

Code:

cd ~/.VirtualBox/Machines/openSUSE-11.2-64/

grep GastSSH openSUSE-11.2-64.xml
      <ExtraDataItem name="VBoxInternal/Devices/e1000/0/LUN#0/Config/GastSSH/Protocol" value="TCP"/>
      <ExtraDataItem name="VBoxInternal/Devices/e1000/0/LUN#0/Config/GastSSH/GuestPort" value="22"/>
      <ExtraDataItem name="VBoxInternal/Devices/e1000/0/LUN#0/Config/GastSSH/HostPort" value="22222"/>

Das sieht schon mal gut aus.

Anmerkung:

Wem diese "bandwurm-artigen" Eingaben mit "VBoxManage" zu viel sind, der kann diese Zeilen auch in abgeänderter Form (zumindest mit anderem HostPort, sonst gibts Ärger!) auf die entsprechende Konfigurationsdatei einer weiteren Maschine oder eines weiteren Dienstes in der selben Maschine (hier natürlich sowohl anderer Name als auch HostPort und GuestPort!) adaptieren und dort per Texteditor eintragen.

c) Funktionstest

Nun starten wir die Maschine (wer mutig ist, startet die VM gleich "Headless", siehe Teil 1 des Tutorials) und prüfen zunächst, ob auf dem "HostPort" 22222 ein Dienst hört.

Code:

VirtualBox --startvm openSUSE-11.2-64&

netstat -tulpen |grep 22222
(Es konnten nicht alle Prozesse identifiziert werden; Informationen über
nicht-eigene Processe werden nicht angezeigt; Root kann sie anzeigen.)
tcp        0      0 0.0.0.0:22222           0.0.0.0:*               LISTEN      1000       373336     -   

Das sieht schon mal gut aus, nun noch ein paar Sekunden (BTW: die 11.2 bootet wirklich verdammt zackig!) warten und dann versuchen wir unser Glück über ssh (da wir auf dem Host angemeldet sind, kann man das über die gute, alte 127.0.0.1 machen) auf Port 22222.

Code:

ssh 127.0.0.1 -p 22222
Enter passphrase for key '/home/MEIN_USERNAME/.ssh/id_rsa':
Last login: Sat Nov 14 12:50:12 2009 from 10.0.2.2
Have a lot of fun...

Voilà.

Damit haben wir nun (zumindest direkt vom Hostsystem aus) "entfernten" Zugriff auf den Gast mittels SSH.

Der einfachste Weg den Gast auch "von außen" erreichbar zu machen, wäre nun den HostPort (in diesem Fall 22222) über SuSEfirewall2 bzw. durch eine entsprechende Portweiterleitung in Eurem Router zugänglich zu machen (sofern das überhaupt erwünscht ist).

3. Erreichbarkeit des Servers im Gast "von außen" auf (s)einem Standardport (SuSEfirewall2 + "REDIRECT"-Regel im Host)

Nun läuft aber der SSH-Server durch die über VirtualBox eingerichtete Portweiterleitung auf dem "ungewöhnlichen" Port 22222, für SSH ist das Verlegen auf einen "non-standard" Port vielleicht sogar keine so schlechte Idee (auch wenn es -das muss ich nun einfach sagen- _keine_ Sicherheitsmaßnahme ist), aber wie sieht es aus, wenn man z.B. einen im Gast laufenden Serverdienst auf seinem Standardport von "außen" erreichbar machen will und dieser =< 1024 ist?

Weiter oben wurde mehrfach betont, daß man als "HostPort" (und auch für den RDP-Zugriff) einen Port > 1024 wählen soll, der Grund hierfür liegt darin, daß unter Linux ein nicht-privilegierter Benutzer keinen Port zwischen 1 und 1024 öffnen darf (deshalb heißen diese auch "privileged ports").

Welche Lösung gibt es nun für dieses Problem?

a) die offensichtliche und _absolut inakzeptable_ Lösung, daß man auch als "HostPort" einen "privileged port" konfiguriert und dadurch die virtuelle Maschine als root starten muss

b) Eine erneute "Umleitung" mittels netfiler/iptables, welche eingehende Anfragen auf einem "privileged" Port des Hosts auf den entsprechenden "non-privileged" Port "umbiegt", auf welchem der Dienst eigentlich im Hostsystem "lauscht"

Die folgende Anleitung bezieht sich ausschließlich auf die Einrichtung dieser "REDIRECT"-Regel mittels SuSEfirewall2, wer eine andere Distribution als openSUSE oder auf openSUSE ein anderes Frontend zur Verwaltung von iptables verwendet, der möge die entsprechende Dokumentation konsultieren.

Zum Glück bietet SuSEfirewall2 eine sehr einfach zu konfigurierende Einstellungsmöglichkeit für diese Aufgabe an, die Regel nennt sich "FW_REDIRECT" und kann entweder durch Bearbeiten der Datei "/etc/sysconfig/SuSEfirewall2" oder über "YaST => System => /etc/sysconfig-Editor => nach FW_REDIRECT suchen" erledigt werden.

Folgendes findet man als Erklärung zu dieser Regel:

Code:

## Type:        string
#
# 15.)
# Which accesses to services should be redirected to a local port on
# the firewall machine?
#
# This option can be used to force all internal users to surf via
# your squid proxy, or transparently redirect incoming webtraffic to
# a secure webserver.
#
# Format: list of <source network>[,<destination network>,<protocol>[,dport[:lport]]
# Where protocol is either tcp or udp. dport is the original
# destination port and lport the port on the local machine to
# redirect the traffic to
#
# An exclamation mark in front of source or destination network
# means everything EXCEPT the specified network
#
# Example: "10.0.0.0/8,0/0,tcp,80,3128 0/0,172.20.1.1,tcp,80,8080"
#
# Note: contrary to previous SuSEfirewall2 versions it is no longer necessary
# to additionally open the local port
FW_REDIRECT=""

Da wir eingehende Pakete aus dem Internet auf die lokale Adresse des Hosts "umleiten" wollen, würde die entsprechende Regel also allgemein so aussehen.

Code:

FW_REDIRECT="0/0,127.0.0.1/0,tcp,Standardport_des_Dienstes,"HostPort"_des_Dienstes_welcher_über_VBoxManage_festgelegt_wurde"

- Das "Quellnetzwerk" wird als "0/0" festgelegt, damit hat jede IP Zugriff (aka "das Internet"), wer z.B. nur Zugriff aus seinem LAN erlauben möchte, der gibt hier die entsprechenden Daten ein (z.B. 192.168.0.0/24, wenn das eigene LAN aus den Adressen von 192.168.0.1-192.168.0.255 besteht)

- Das Zielnetzwerk ist 127.0.0.1 (aka "localhost"), also die lokale Adresse der Hostmaschine

- Der Quellport ist der Port, über welchen man Zugriff "von außen" erlauben will (bei einem Webserver würde sich z.B. 80 anbieten)

- Der Zielport ist der "HostPort" der zuvor über VBoxManage eingerichteten Weiterleitung

Möchten wir also den SSH-Server unserer virtuellen Maschine, welchen wir lokal auf dem Host auf Port 22222 erreichen können, von außen auf Port 22 verfügbar machen, dann lautet die Regel

Code:

FW_REDIRECT="0/0,127.0.0.1/0,tcp,22,22222"

4. Anwendungsbeispiel: Webserver in einer Gastmaschine auf Port 80 aus dem Internet erreichbar machen

a) Vorgaben

- Auf dem Gast "openSUSE-11.2-64" läuft ein Webserver (z.B. Apache2) auf Port 80

- Der Gast ist in VirtualBox über Netzwerkkarte Nr.1 via NAT eingerichtet, Netzwerkkarte ist aus der e1000-Familie

- Der Webserver soll über Port-Forwarding auf Port 8888 im Host erreichbar sein

- Der Websever soll aus dem Internet auf Port 80 über die externe IP bzw. deren URL (Stichwort DynDNS) des Hosts erreichbar sein

b) Einrichtung der Weiterleitung Gast Port 80 => Host Port 8888 über VBoxManage

Das Ganze Spielchen geht analog zur Weiterleitung des SSH-Servers im vorigen Teil, GuestPort ist 80, HostPort ist 8888 und der Dienst wird "stilecht" als "GastIndianer" bezeichnet:

Code:

VBoxManage setextradata "openSUSE-11.2-64" "VBoxInternal/Devices/e1000/0/LUN#0/Config/GastIndianer/Protocol" TCP
VBoxManage setextradata "openSUSE-11.2-64" "VBoxInternal/Devices/e1000/0/LUN#0/Config/GastIndianer/GuestPort" 80
VBoxManage setextradata "openSUSE-11.2-64" "VBoxInternal/Devices/e1000/0/LUN#0/Config/GastIndianer/HostPort" 8888

c) Einrichtung der "Umleitung" Anfrage aus dem Internet auf Port 80 => Port 8888 auf dem Host via SuSEfirewall2

Das Quellnetzwerk ist also "0/0", das lokale Netzwerk ist localhost (127.0.0.1), Protokoll ist TCP, Quellport ist 80 und Zielport ist 8888.

Man öffnet die Datei "/etc/sysconfig/SuSEfirewall2" als root mit einem Texteditor, sucht nach "FW_REDIRECT" und trägt folgende "Umleitung" ein (farbig markiert),

Code:

FW_REDIRECT="0/0,127.0.0.1/0,tcp,80,8888"

speichert die Datei ab und abschließend sicherheitshalber als root ein

Code:

rcSuSEfirewall2 restart

um diese Regel zu aktivieren.

Danach sollte man auch von "außen" Zugriff auf seinen Webserver in der virtuellen Maschine haben.

Wer hinter einem Router sitzt, muss natürlich noch zusätzlich dort eine entsprechende Portweiterleitung einrichten (man konsultiere hierzu das Handbuch des Routers).

Greetz,

RM

5. Shellscript für die Verwaltung der "Headless" Maschinen

Im letzten Teil dieses Tutorials möchte ich ein einfaches Shellscript vorstellen, welches einem das Starten, Stoppen, Ein-/Ausschalten von VRDP und eine Statusabfrage, ob eine Maschinen gerade "Headless" mit oder ohne VRDP läuft, erleichtert.

Ein Templat des Shellscripts sowie die beiden Dateien zur Einrichtung der externen Authentifizierung (PAM) befinden sich an diesen Beitrag angehängt, folgende Variablen sind anzupassen,

Code:

NAME= #Enter name of your VM
RDP_PORT= #Enter VRDP Port of your VM
USER_ID=$(id -u)
RDP_STATE= # on or off, choose your poison

anschließend sollte man dem Script einen passenden Namen geben (z.B. den der virtuellen Maschine), es ausführbar machen (chmod und ggf. chown) und an einen passenden Platz, welcher sich in $PATH befindet (z.B. /usr/local/bin/ oder /home/Euer_Username/bin/) kopieren.

Aufgerufen wird das Script immer mit einem weiteren Parameter, folgende Parameter stehen zur Verfügung.

start

stop

vrdpon

vrdpoff

status

Bei fehlerhafter Eingabe eines Parameters wird eine kurze Hilfe zur Benutzung des Scripts ausgegeben.


6. Anwendungsbeispiel: Verwaltung eines virtuellen Windows-XP mit dem "VBox-Headless"-Script

a) Vorgaben

- Der Name der Maschine lautet "WindowsXP"

- VRDP ist auf Port 3389 eingerichtet und soll beim Starten ebenfalls aktiviert werden

b) Umsetzung

Das Templat wie folgt bearbeiten (fett markiert),

Code:

#!/bin/bash
# Start/Stop-Script for VBox in Headless Mode

NAME=WindowsXP 
RDP_PORT=3389
USER_ID=$(id -u)
RDP_STATE=on
 
case "$1" in

        start)
        /bin/echo "Starting $NAME"
        /usr/bin/VBoxHeadless -s $NAME -vrdp $RDP_STATE&
        /bin/echo -e
        ;;

        stop)
        /bin/echo "Stopping $NAME"
        /usr/bin/VBoxManage controlvm $NAME acpipowerbutton
        ;;
        vrdpon)
        /bin/echo "Opening VRDP (Port $RDP_PORT) for $NAME"
        /usr/bin/VBoxManage controlvm $NAME vrdp on
        ;;
        vrdpoff)
        /bin/echo "Closing VRDP (Port $RDP_PORT) for $NAME"
        /usr/bin/VBoxManage controlvm $NAME vrdp off
        ;;
        status)
        if (/bin/ps aux|/usr/bin/grep -v -E "grep|$0"|/usr/bin/grep $NAME) &>/dev/null
                then /bin/echo "VM with $NAME is running"
                        if (/bin/netstat -tulpen 2>/dev/null|grep $USER_ID|grep $RDP_PORT) &>/dev/null
                                then echo "VRDP is running on Port $RDP_PORT"
                                else echo "VRDP is not running for this VM"
                        fi
                else /bin/echo "VM with $NAME is not running"
        fi
        ;;
        *)
        /bin/echo "Usage: $0 (start|stop|vrdpon|vrdpoff|status)"
        ;;
esac

exit 0

als "WindowsXP" in /home/Euer_Username/bin/ abspeichern und mit "chmod 755 ~/bin/WindowsXP" ausführbar machen.

Anschließend kann das virtuelle Windows XP mit folgenden Befehlen (fett markiert) verwaltet werden.

Code:

WindowsXP start
Starting WindowsXP with RDP turned on (Port 3389)

VirtualBox Headless Interface 3.0.10
(C) 2008-2009 Sun Microsystems, Inc.
All rights reserved.

Listening on port 3389

----------------------------------------

WindowsXP status
VM with WindowsXP is running
VRDP is running on Port 3389

----------------------------------------

WindowsXP vrdpoff

Closing VRDP (Port 3389) for WindowsXP
VirtualBox Command Line Management Interface Version 3.0.10
(C) 2005-2009 Sun Microsystems, Inc.
All rights reserved.

----------------------------------------

WindowsXP status
VM with WindowsXP is running
VRDP is not running for this VM

----------------------------------------

WindowsXP vrdpon
Opening VRDP (Port 3389) for WindowsXP
VirtualBox Command Line Management Interface Version 3.0.10
(C) 2005-2009 Sun Microsystems, Inc.
All rights reserved.

----------------------------------------

WindowsXP status
VM with WindowsXP is running
VRDP is running on Port 3389

----------------------------------------

WindowsXP stop
Stopping WindowsXP
VirtualBox Command Line Management Interface Version 3.0.10
(C) 2005-2009 Sun Microsystems, Inc.
All rights reserved.

----------------------------------------

WindowsXP status
VM with WindowsXP is not running

und ist per RDP (siehe Teil 1 des Tutorials) erreichbar.

Und ganz ehrlich, wer wollte nicht schon mal auf Linux Windows per Kommandozeile starten?

:-)

Damit möchte ich dieses Tutorial abschließen und wünsche viel Erfolg mit "kopflosen" (virtuellen) Maschinen.

Greetz,

RM