RDP4Help

Die hier beschriebene Lösung oder Software gibt es (noch) nicht und ich werde Sie persönlich vermutlich auch nicht entwickeln können.

Es gibt hunderte Programme zur Fernwartung. Einige davon funktionieren mit einer direkten Verbindung zwischen den Teilnehmern (X11, Netmeeting, RDP, VNC, Windows Remote Unterstützung etc.). Andere nutzen ein Gateway (z.B. RDP) oder einen Proxy im Internet. Gerade kommerzielle Anbieter (Teamviewer, GotoAssist, FastViewer etc.). Auch Meeting-Lösungen durchtunneln immer häufiger Firewalls (z.B. Lync Sharing). Daher ist die Frage berechtigt, warum das Rad nun noch mal neu erfunden werden sollte.

Ich habe mir einfach "Gedanken" gemacht, warum eine Fernsteuerung auch immer noch den Code für das Bildschirmabgreifen, Tastaturkapern etc. enthalten muss, wo doch zumindest neuere Betriebssysteme schon per RDP fernsteuerbar sind. Zugegeben wird man nun sicher nicht alle Server per "RDP" über das Internet erreichbar machen wollen. Schließlich könnte sich dann jeder zumindest auf den Anmeldedialog verbinden. Andererseits ist RDP aber eine sehr nette Möglichkeit ein System zu steuern. RDP enthält alles. für den Zugriff aus dem Internet gibt es natürlich das RDP-Gateway, womit aber wieder ein Dienst veröffentlich werden muss.

Umgekehrt macht es Sinn

Ein RDP-Server (also ein Windows Server aber auch z.B.: ein Windows 7 Client) wartet auf Port 3389 auf eingehende Verbindungen, wenn dieser Zugriff "zugelassen", d.h. konfiguriert wurde. Nur werde ich natürlich diese Bereitschaft nicht z.B. über das Internet bereit stellen. Interessant wäre ein Programm oder Dienst, welcher auf diesem PC gestartet wird, welcher eine ausgehende verschlüsselte Verbindung zu einer bekannten Gegenstelle aufbaut und damit von innen einen Tunnel an ein Gateway beim Dienstleister bereit hält. Der Dienstleister kann dann auf seinem Gateway lokal eine Verbindung starten, die dann als Antwort an den entfernten Server gesendet wird.

Das Gateway "wüsste" also immer genau, welche entfernten Systeme gerade mit ihm sprechen und könne diese Liste natürlich legitimierten Clients auch bereitstellen, z.B. per Weboberfläche oder als WebService für eine angepasste Clientanwendung, die dann letztlich RDP nutzt.

Komponenten

Für das Zusammenspiel sind drei Komponenten erforderlich:

Komponete Beschreibung

RDP4HELP Agent

Wird auf dem zu erreichenden Server entweder interaktiv oder als Dienst gestartet und baut die Verbindung zu dem angegebenen Gateway an. Das Gateway kann optional konfiguriert werden. Das Programm muss das Zertifikat der Verbindung prüfen und kann Informationen über die Verbindung anzeigen (z.B. den Namen des Gateways und den dort bereit gestellten TCP-Port. So kann ein Supporter direkt dann per RDP den Port ansprechen und das System erreichen.

Das Programm verbindet sich beim Eingang von Daten über das Gateway mit dem lokalen RDP-Port 3389. für den Einsatz in Verbindung mit der "Windows RemoteUnterstützung" wäre es eine mögliche Erweiterung, wenn das Gateway eben diese kurzfristige Verbindungsfreigabe aktivieren und die Anmeldedaten zum Gateway übergeben kann.

Optional könnte dieser Agent auch lokale Serverdaten (Name, Windows Version, Windows Updatestand etc.) erfassen und mit an das Managementgateway melden.

Wird der Agent nicht als "Dienst" installiert sondern interaktiv ausgeführt, dann muss er Anwender natürlich dem Supporter die "Portnummer" sagen, damit dieser sich dann per RDP verbinden kann. Sollen beide den gleichen Desktop nutzen, dann sollte die Windows Remote Unterstützung dazu genutzt werden. für die Fernwartung reicht es das kleine Programm zu laden, was nichts anderes als ein HTTPS zu TCP-Proxy darstellt und entsprechend einfach und sicher zu entwickeln sein dürfte.

RDP4HELP Gateway

Diese Serverkomponente läuft auf einem System des Dienstleisters und nimmt die Anfragen der verteilten Agenten an. Jedem aktiven Agent ordnet es lokal einen eigenen freien TCP-Port zu, über den sich der Standard MSTSC einfach verbinden kann.

Es wäre eine nette Funktion, wenn sich diese Portzuordnung auch nach einen Neustart nicht ändern würde, z.B.: indem das Gateway beim Start einfach die Anzahl der Ports schon reserviert. Ich denke dass auch 1000 oder 10000 Ports kein Problem wären. So könnten sogar RDP-Tools wie MREMOTE oder VisionApp damit funktionieren.

RDP4HELP Client

Eigentlich sollte die Lösung komplett ohne Client funktionieren, da der normal Microsoft Terminal Services Client eingesetzt wird.

Auch wenn der primäre Ansatz dieser Idee eine einfache "Fernwartung" ist, so könnte durchaus mehr daraus werden. Interessant bei der Funktion ist, dass keine "Treiber" o.ä. auf dem zu steuernden System zu installieren sind und auch keine Ports geöffnet werden.

Optionale Erweiterungen

Interessant könne es z.B. sein, dass die Hilfsapplikation auf dem Server einen Status überprüft und das Ergebnis ebenfalls mit an das Gateway sendet. Das Gateway könnte dann eine Alarmierungskette auslösen oder zumindest den Status anzeigen. Auch könnten "Ausbleibende Systeme" entsprechend gemeldet werden.

Da auch RDP einfach genutzt wird, könnte ich mir sogar vorstellen, dass ThinClients über diesen Weg einen Zugang zum Server erhalten könnten.

Warum nicht ...

Alternative Bewertung

...Windows RDP-Gateway

Dieser Weg würde natürlich gehen und "kostet" auch wenig, wenn man eh schon Windows 2008 hat, aber das Gateway würde an der Grenze zum "Kunden" stehen und müsste dort die Dienste anbieten.

... Stunnel

Stunnel ist schon lange dafür bekannt, TCP-Verbindungen durch HTTPS-Verbindungen zu tunneln. Allerdings wird es ebenfalls "falschrum" eingesetzt. Auch hier ist der Stunnel-Server im Internet und der Client wird vom Anwender gesteuert, um über das Internet mit dem Server eine Verbindung zu einem nachgelagerten System aufzubauen. Also ähnlich wie das RDP-Gateway nur universeller

SSH

Auch SSH kann einen "Tunnel" aufbauen, auch wenn die Verbindung dann über SSH (22) geht und nicht per HTTPS. Ansonsten ist es aber die gleiche Betriebsart wie Stunnel.

...VPN

Der Aufbau eines VPN ist natürlich ein Weg, von extern dann "wie intern" auszusehen und direkt mit den Gegenstellen Kontakt aufzunehmen. Aber auch hier muss auf "Kundenseite" ein Gateway betrieben und im Internet veröffentlicht werden.

Weitere Links