Remote-Verbindung zum Hyper-V mit Bordmitteln
10. August 2011
Wenn im Bereich der Fernwartung von Windows-Plattformen keine festen IP-Adressen in der Zweigstelle zum Einsatz kommen, stellen die günstigen ADSL-Breitbandverbindungen die Admins oft vor eine Herausforderung:
Denn die vorhandene Internetverbindung wird vom Internet Service Provider in der Regel alle 24 Stunden kurz ab- und darauf wieder angeschaltet. Diese sogenannte Zwangstrennung führt dazu, dass sich die IP-Adresse spätestens alle 24 Stunden ändert.
Mit Hilfe des DynDNS-Dienstes lassen sich diese Probleme meistern und mit den Windows-Bordmitteln (Remote Desktop Protocol, RDP) eine remote Verbindung zum Zielnetzwerk herstellen. Hier wird am Beispiel des Hyper-V in einem Zweigstellen-Netzwerk gezeigt, wie man mit Hilfe des RDP die Fernwartung im Zweigstellen-Netzwerk realisieren kann.
Für Administratoren stellt ein Fernzugriff auf Serversysteme eine herausragende Möglichkeit dar, verschiedene Arbeiten auf entfernten Systemen durchzuführen. Zum Beispiel können normale Wartungsarbeiten erledigt, Backup-Jobs überprüft und Updates eingespielt werden. Auch Notfälle sind so aus der Ferne zu klassifizieren, nach Priorität einzuordnen und dann entweder vor Ort oder gleich per Fernwartung anzugehen. Eine funktionierende Fernwartung ist für die meisten Administratoren in der Regel das erste Mittel, um sich einen Überblick zur momentanen Situation zu verschaffen.
Ebenso zahlreich wie die Einsatzmöglichkeiten sind auch die Möglichkeiten die Fernwartung aufzusetzen. Beispielsweise gibt es verschiedene Software-Lösungen, Firewalls kombiniert mit Virtual Private Networks (VPNs) oder auch eigene Fernwartungsserver. Dabei sind vom Prinzip her zwei Richtungen zu unterscheiden: Zum einen sind Systeme mit einem zentralen Server im Internet (Fernwartungssoftware wie beispielweise Teamviewer) ausgestattet, um die Verbindung herzustellen. Zum anderen wird eine Verbindung direkt in das Ziel-Netz aufgebaut (Firewall mit VPN-Verbindung beispielsweise).
Auf den aktuellen Windows-Systemen sind Bordmittel verfügbar, um den Fernzugriff zu ermöglichen. Hier ist in erster Linie das Remote Desktop Protocol (RDP) zu nennen. Es verfolgt den Ansatz, eine direkte Verbindung in das Zielnetzwerk aufzubauen. Den meisten Administratoren ist dieses Windows-Bordmittel gut bekannt. Damit kann ohne Software eines Drittherstellers eine Verbindung zu einem weiteren Windows-System aufgebaut werden.
Remote Desktop Protocol reicht für Fernwartung
Innerhalb eines Netzwerkes ist die Verbindung (fast) ohne Aufwand einzurichten. Die Fernwartungsfunktion und deren Dienste müssen in Windows Servern (ab Version Windows Server 2000) nur aktiviert werden. Daraufhin ist es bereits möglich, die Verbindung (über den Aufruf des Kommandos mstsc.exe) aufzubauen. Bekannt sein müssen hier nur die IP-Adresse (oder der Hostname) und die entsprechenden Anmeldedaten (üblicherweise sind die im Active Directory hinterlegt), wie etwa Benutzername und zugehöriges Passwort.
Um einen solchen Server über das Internet zu verwalten, müssen einige Punkte im Vorfeld eingerichtet werden. Um den Administratoren einen Leitfaden für die Konfiguration dieser Schritte in die Hand zu geben, stellt das NT4ADMINS-Team einen solchen Fall im Testlabor nach. Ein Hyper-V-Server mit zwei Virtuellen Maschinen (VMs) soll per ADSL-Internetverbindung mittels RDP-Fernsteuerung administrierbar gemacht werden.
Die Gegebenheiten vor Ort
Unser Fall spiegelt ein typisches Anwendungsbeispiel im kleinen Rahmen wieder. Ein Netzwerk in einem Small-Office Home-Office (SOHO), bestehend aus einem Hyper-V-Server, Netzwerkfestplatte (NAS), Netzwerkdrucker und drei Client-Systemen stehen für die täglich anfallenden Arbeiten der Benutzer bereit.
Der Zugang zum Internet wird über einen handelsüblichen Router (Telekom-DSL Anschluss, mit Speedport W 303V) per ADSL-Leitung hergestellt. Der Server soll nun für den zuständigen Systemadministrator (ein externer Dienstleister, denn das Unternehmen verfügt über keinen eigenen Administrator) auch per Internet verfügbar gemacht werden.
Konfiguration des DynDNS
Zunächst gilt es eine Hürde im Zusammenhang mit der DSL-Leitung zu überwinden. Wie die meisten günstigen ADSL-Breitbandverbindungen (Asymmetric Digital Subscriber Line) wird die vorhandene Internetverbindung vom Internet Service Provider Telekom (ISP) alle 24 Stunden kurz ab- und darauf wieder angeschaltet. Diese sogenannte Zwangstrennung führt dazu, dass sich die IP-Adresse spätestens alle 24 Stunden ändert.
Nun sollte unsere Konfiguration sinnvollerweise auch über einen längeren Zeitraum nutzbar bleiben. Dazu bedient sich der Administrator einer sogenannten dynamischen IP Adresse. Ein spezieller Dienst sorgt dafür, dass der sich täglich veränderten IP-Adresse des Routers immer einen gleichbleibender Domänenname zugeordnet wird.Dazu agiert im Router ein spezieller DynDNS-Client, der sich regelmäßig bei www.dyndns.org meldet und sich dort mit der aktuellen IP-Adresse einträgt.
Auf der Internetseite eines entsprechenden Anbieters (beispielsweise www.dyndns.org) registriert sich der Administrator und legt ein Konto an. Hier kann daraufhin eine verfügbare Domäne ausgewählt, und unter bestimmten Voraussetzungen—sprich mit eingeschränkter Funktionalität – kostenlos genutzt werden.
Das NT4ADMINS-Team wählt folglich eine passende Domäne aus (nt4admins.dyndns.org). Nun muss dem Internetrouter mitgeteilt werden, dass der DynDNS-Client eingesetzt werden soll. Hierbei sollte beachtet werden, dass sich die Benennungen der Einstellungen von Gerät zu Gerät unterscheiden. Das NT4ADMINS-Team verwendet im Test den vorhandenen Telekom-Router.
In unserem Beispiel muss zunächst der DynDNS-Client aktiviert und die passenden Zugangsdaten (Benutzername und Passwort; sowie die zugehörige Domäne) eingetragen werden (siehe Bild-1).
Nach dem Abspeichern dieser Einstellungen kann die Funktion des DynDNS-Clients per Kommandozeile (CMD) überprüft werden. Dazu benützen wir den Befehl
ping nt4admins.dyndns.org
und überprüfen die Ausgabe der Kommandozeile (siehe Bild-2). Wenn die Zuweisung klappt, steht hier als zugehörige IP-Adresse unsere momentan gültige IP. Diese lässt sich bei den meisten Routern im Konfigurationsmenü ablesen, oder über entsprechende Seiten im Internet abgleichen (www.wieistmeineip.de). In unserem Beispiel ist der Domäne nt4admins.dyndns.org die passende Adresse zugewiesen worden.
Einrichtung der Port-Weiterleitung
In einem weiteren Schritt ist nun ein sogenanntes Port-Forwarding anzulegen. Diese Aktion stellt sicher, dass die am Router ankommenden Datenpakete der Remotedesktop-Verbindung auch an den entsprechenden Server (das betreffende Hyper-V-System im SOHO) geleitet werden.
Dazu wird im Speedport-Router zunächst im Untermenü der Server als zulässiges Gerät angelegt. Der Administrator gleicht hier die Media Access Control Adresse (MAC Adresse) ab, und vergibt dem Server einen passenden Gerätenamen (siehe Bild-3).
Die MAC-Adresse lässt sich am Server beispielsweise über dem CMD-Befehl
ipconfig /all
ermitteln. Hierbei werden alle Netzwerkadapter im System aufgelistet und deren Eigenschaften (samt MAC-Adressen) angezeigt. Als weiteren Schritt soll nun die Weiterleitung selbst eingerichtet werden, die passende Einstellung im Speedport verbirgt sich hinter dem Menüpunkt „Port-Weiterleitung“ (siehe Bild-4).
Hier definiert das NT4ADMINS-Team eine neue Regel, als weiterzuleitender Port wird TCP 3389 eingetragen (dies ist so standardmäßig von Microsoft vorgegeben, kann aber bei Bedarf angepasst werden). Als Ziel wird unser Hyper-V-Server angegeben und die Regel per Checkbox aktiviert. Somit werden ab diesem Zeitpunkt alle Datenpakete die auf Port 3389 an nt4admins.dyndns.org geschickt werden (und damit am Router ankommen) auf den Hyper-V-Server weitergeleitet.
Letzte Maßnahmen und abschließender Test
Die RDP-Verbindung wird auf dem Windows Server 2008 Release 2 Enterprise aktiviert (Serverrolle hinzufügen: Remotedesktopdienste). Ähnlich wie beim Ping-Test könnte der Administrator nun testweise versuchen, eine Verbindung mit der DynDNS-Adresse herzustellen. Falls diese (Test-) Verbindung fehlschlägt, mstsc.exe allerdings eine Verbindung mittels der lokalen Adresse (siehe Bild-5) herstellen kann, sollte versucht werden von extern auf die dynamische Adresse zuzugreifen.
In unserem Beispiel ist eine RDP-Verbindung von innerhalb des Netzwerkes, die auf die DynDNS-Adresse zielt, nicht möglich. Denn der eingesetzte Speedport-Router kann die Datenpakete, die von einer internen IP auf die DynDNS-Adresse (extern) gesendet, und von dort wiederrum intern weitergeleitet werden sollen, nicht verarbeiten. Eine RDP-Verbindung von einer weiteren ADSL-Leitung im NT4ADMINS-Testlabor bestätigt hier die korrekte Einrichtung der Remotedesktopverbindung.
