Ein klarer Fall für VNC, doch was macht man wenn – wie heutzutage üblich – das NAT eines Hardware-Routers im Weg steht? Jemandem die Einrichtung einer Portweiterleitung auf einem unbekannten DSL-Router über das Telefon zu erklären ist ein Ding der Unmöglichkeit. Die Lösung dazu nennt man „Reverse-VNC“, dabei baut der VNC-Server zu einem VNC-Client, der im „Listen“-Modus gestartet wurde, aktiv eine Verbindung auf. Auf der Serverseite ist somit keine Portweiterleitung mehr nötig, diese ist nun auf der Seite des Clients – sollte man selber hinter einem Router sitzen – Pflicht. So umgeht man das einrichten einer Portweiterleitung beim „Kunden“.

Die c’t hat dem Thema letztes Jahr einen recht ausführlichen Artikel gewidmet, allerdings gibt es ein paar Stolpersteine, die es zum Umgehen gilt. Dazu ein paar Tipps.

Was braucht man?

Portweiterleitung

Sollte man selber hinter einem Router sitzen, so muss man einen Port vom Router auf den eigenen Rechner weiterleiten. Üblicherweise ist dies für VNC der Port 5500.

DynDNS-Adresse

Im Laufe dieses Artikels muss die eigene Internet-IP in einem Programm fest verdrahtet werden. Da die meisten DSL-Anbieter jedoch nach 24h die Einwahlverbindung trennen und beim erneuten Aufbau der Verbindung eine neue IP zugewiesen wird, macht es wenig Sinn eine IP einzutragen.

Dies lässt sich mit so genannten DynDNS-Anbietern umgehen. Diese – meist kostenlosen – Dienstleister verknüpfen die eigene Internet-IP mit einem Domainnamen. Ein kleines Programm auf dem eigenen Rechner (oder dem DSL-Router) aktualisiert die IP nach einem Wechsel beim DynDNS-Provider. Dadurch ist der eigene Rechner immer unter einer festen URL zu erreichen. Weitere Infos finden sich beispielsweise hier im Wiki von ubuntuusers.de.

Der „One-Click“ VNC-Server

Das alles war bislang nur „Vorspiel“. Nun geht es darum einen speziell angepassten VNC-Server zu erstellen bzw. den VNC-Server unseres Kunden mit den passenden Optionen zu starten. Um es dem Kunden so leicht wie möglich zu machen, wird ein VNC-Server erstellt, der einfach nur ausgeführt werden muss. Der Hilfesuchende muss rein gar nichts einstellen.

Windows/MacOS X

uVNC bietet dafür den PCHelpWare VNC-Server an. Allerdings muss man diesen von Hand über Konfigurationsdateien anpassen. Aufgrund der schlechten Dokumentation ein etwas mühseliges Unterfangen.

Praktischer ist ein Webtool der c’t. Hier müssen nur die eigene DynDNS-Adresse und ein paar erklärende Text eingefügt werden und mit einem Click erzeugt man den Server. Die generierte .exe Datei kann man dem Hilfesuchenden zukommen lassen.

Ist die Datei beim Kunden angekommen, so muss die .exe einfach nur über einen Doppelklick ausgeführt werden. Über einen weiteren Doppelklick auf die Verbindung wird die VNC-Verbindung aufgebaut. Allerdings muss dazu erst der eigene VNC-Client in dem „listen“-Modus gestartet werden, dazu gleich mehr. Der Server muss weder installiert, noch konfiguriert noch – nach Gebrauch und hoffentlich erfolgreicher Problemlösung – deinstalliert werden. Einfach die .exe Datei löschen reicht.

Hinweis: So gut wie jeder Virenscanner meldet bei solchen VNC-Server einen Trojaner. Klar, die Technik wird eben auch von den „Bösen“ angewendet. Daher ist es praktisch unmöglich die .exe per Email zu verschicken. Alle großen Email-Anbieter (ich habe web.de, GMX und Google Mail getestet) filtern das Attachment raus. Daher stellt man den VNC-Server am besten über einen Webserver zur Verfügung und verschickt nur die URL zur Datei.

Nun zum ersten Stolperstein. Der PCHelpWare VNC-Server arbeitet nur mit der Version 3.3 des VNC-Protokolls, die VNC-Client Programme von Linux jedoch nur mit der Version 4. Startet man also ein VNC-Viewer im Listen Modus, so sieht man außer

$ xtightvncviewer -listen 9500 -encodings "hextile copyrect"
xtightvncviewer -listen: Listening on port 15000
xtightvncviewer -listen: Command line errors are not reported until a connection comes in.
Connected to RFB server, using protocol version 3.8

nichts. Der Desktop des entfernten Rechners erscheint nicht auf dem eigenen Bildschirm. Die Optionen -encodings „hextile copyrect“ sollen angeblich helfen das Problem zu lösen, doch ich kann keine Besserung feststellen.

Die Lösung besteht aus der Installation einer vorkompilierten Version des RealVNC Viewers. Pakete und Archive für Linux lassen sich von hier nach einer Registrierung herunterladen. Hinter den Einträgen von

• VNC Enterprise Edition for Linux (x86), für 32-bit Linuxe
• VNC Enterprise Edition for Linux (x64), für 64-bit Linuxe

findet man Links zu einem „Debian Package“, das sich bequem in Ubuntu oder Debian installieren lässt. Allerdings beinhaltet das Paket den Server wie auch den Client. Alternativ kann man sich nur den Client als .tar.gz Archiv herunterladen.

• VNC Enterprise Edition Viewer for Linux (x86), für 32-bit Linuxe
• VNC Enterprise Edition Viewer for Linux (x64), für 64-bit Linuxe

Sollte man sich für das .deb Paket aus Client und Server entschieden haben, so kann man nun den Viewer über

$ vncviewer -listen 5500 -Protocol3.3

starten. Die Option -Protocol3.3 sagt dem Client dass das ältere Protokoll genutzt werden soll. Sollte man den reinen Client gewählt haben, so gilt das das Archiv zu entpacken, das Binary ausführbar zu machen und den Client dann zu starten

$ gunzip vnc-E4_4_3-x64_linux_viewer.gz
$ chmod +x vnc-E4_4_3-x64_linux_viewer
$ ./vnc-E4_4_3-x64_linux_viewer -listen 5500 -Protocol3.3

Von nun an können Hilfesuchende (Windows-User) uns mit ihren Fragen quälen. Solange ihr Internetzugang funktioniert bekommen sie den Client per Download von meinem Webserver, ich starte meinen VNC-Client und schon sehe ich ihren Desktop.

Linux

Tja fehlt nur noch Linux als System. Hier muss man nicht lange Frickeln. Linux bringt von Haus aus alles mit. Wichtig ist nur die Installation des x11vnc-Servers. Danach muss der Kunde nur ein Kommando ausführen.

$ sudo apt-get install x11vnc
$ x11vnc -connect dyndns.example.com

und der Helfer mit vncviewer -listen vorher seinen VNC-Client im Listen-Modus gestartet haben. Und schon sieht man seinen Desktop. Die Portweiterleitung und der Einsatz von DynDNS sind natürlich nach wie vor nötig. Viel Spaß mit dem höchstpersönlichen Helpdesk.

Noch ein Disclaimer: Natürlich gibt es kommerzielle Dienste wie TeamViewer und Co. die einen ähnlichen Service anbieten. Mir persönlich sind diese Dienste nicht sympatisch bzw. ich halte sie nicht für nötig. Mit dem „One-Click“ VNC-Server lässt sich das Thema ohne einen kommerziellen Dienst mit den Bordmitteln eines Linux lösen. Und Hilfesuchende mit Linux haben eh alles an Bord.