VNC-Verbindung
VNC ist die Abkürzung für Virtual Network Computing und ermöglicht es von einem Computer aus einen anderen zu steuern. Dabei wird der Bildschirminhalt des zu steuernden Computers an den VNC-Client übertragen und dieser kann mit Maus- und Tastaturbefehlen den Rechner bedienen. Nachteile einer solchen Steuerung sind u.a. die hohe Datenrate (da der komplette Bildschirminhalt übertragen werden muss) und die dadurch bedingte Latenzzeit (Verzögerung).
Es gibt verschiedene Softwaretypen mit denen ein solches Vorgehen möglich ist, dabei muss immer auf dem zu steuernden Rechner eine Serverversion installiert und gestartet sein und auf dem Steuercomputer ein Viewer (”Betrachter” bzw. “Client”). Die Softwares die ich verwende sind für den nicht-kommerziellen Bereich freie Software:
- RealVNC
- UltraVNC
- TeamViewer
Der RealVNC ist ein Open-Source-Projekt und ist auf Ubuntu bereits vorinstalliert und heißt dort simpel “vncviewer”. Unter Windows muss man die Software zunächst installieren, um sie benutzen zu können.
UltraVNC ist eine andere Software und ist deshalb in meiner Auswahl, weil sie eine besonderes Feature mitbringt, das ich bei RealVNC noch nicht entdeckt habe, nämlich die Möglichkeit auch ohne Portforwarding auf dem Serverrechner Zugriff zu ermöglichen. Hier wären wir auch schon bei dem ersten Problem des Arbeiten mit VNC angelangt, dem Portforwarding.
Was sind Ports?
Ports kann man sich wie Türen vorstellen, die auf einem Computer eine Verbindung ermöglichen. Die Datenpakete, die über das Netzwerk (egal ob Internet, LAN, WLAN, VPN …) gesendet werden, kommen beim Rechner an und sind an einen bestimmten Port “adressiert”. Ein Computer, der als Server fungiert muss die benötigten Ports “offen” haben, sonst kann er keine Datenpakete empfangen. Für HTTP-Anwendungen (also z.B. surfen im Browser) ist der Port 80 standardmäßig zuständig. Auf jedem Webserver, der Internetseiten anbietet ist dieser Port “offen” und es werden Anfragen von außen angenommen und verarbeitet. Hätte der Webserver diesen Port nicht offen, käme bei dem, der die Internetseite ansehen möchte eine Zeitüberschreitung, weil er keine Antwort vom Server bekommt. Weitere Standardports sind z.B. 21 für FTP-Verbindungen, 110 für POP3-Verbindungen (eMail-Server), 25 für SMTP-Verbindungen (ebenfalls für eMails), etc…
Für RealVNC wird standardmäßig der Port 5900 benutzt, und da fängt das Problem bereits an.
Normale Heimcomputer, ohne großartigen Aufwand eingerichtet, meist an einen Router angeschlossen, werden durch die Konfiguration dieses Routers vor ungewollten Zugriffen “von außen” geschützt. In diese Kompaktgeräte sind Firewalls eingebaut, die alle nicht standardmäßigen Ports abblocken. Da die wenigsten Benutzer einen Webserver oder einen FTP-Server auf ihrem Computer installiert haben sind selbst die Ports 21 und 80 in der Regel nicht geöffnet. Der Computer nimmt Kontakt mit einem Server auf und teilt ihm mit, auf welchem Port er die Antwort senden soll (das ist Teil der Datenpakete), somit müssen keine Standardports offen sein und die normale Kommunikation findet auf zufälligen Ports statt. Von 1 bis 65555 können alle Ports verwendet werden wobei in der Regel die Ports, die für eine Anwendung standarisiert sind nicht benutzt werden. Deshalb findet der normale Datenverkehr in der Regel auf den Ports zwischen 40000 und 60000 statt, ausreichend viele um normales Surfen und Downloaden und eMailen und chatten zu ermöglichen. Kurzum: der normale Anwender braucht sich um irgendwelche Ports keine Gedanken zu machen. Der Computer kann “von innen” die benötigten Ports selbst öffnen.
Das Einrichten von Portforwarding
Dies ändert sich jedoch, sobald wir einen Server für irgendeine Anwendung installieren wollen, was wir ja durchaus vorhaben, denn der zu steuernde Rechner stellt einen VNC-Server zur Verfügung und muss auf dem entsprechenden Port erreichbar sein, d.h. “von außen”.
Nehmen wir an, der Router ist mit dem Internet verbunden und hat die IP-Adresse 89.54.145.100 | Im lokalen Netzwerk hat unser Server die IP 192.168.0.5 und es ist ein VNC-Server installiert, der quasi hinter dem Port 5900 auf eine Verbindung “wartet”, dann muss derjenige, der den Rechner steuern will (der Client) den Server auch erreichen können. Dies wird aber vom Router in aller Regel verhindert. Wenn nicht von ihm, sollte die Firewall (die auf jedem Windows-Rechner vorhanden sein sollte!) diesen Port blocken. Wir müssen also dem Router beibringen, dass er erlauben soll, dass von außen kommende Anfragen auf Port 5900 an unseren Server mit der IP 192.168.0.5 weitergeleitet werden sollen. Dazu muss man im Routermenu eben dies einstellen. Leider unterscheiden sich die Router verschiedenster Hersteller so gravierend voneinander, dass eine generelle Anleitung dazu nicht möglich ist. Zu finden ist solch eine Portforwarding-Konfiguration jedoch meist in Untermenus von “NAT” oder “Network”, manchmal sogar in einem eigenen “Forwarding”-Menu.
Ist man im richtigen Menu angelangt, wird nach folgenden Angaben gefragt:
- Quellport / Source-Port /
- Zielport / Destination-Port
- Quell-IP / Source-IP
- Ziel-IP / Destination-IP
- Protokoll
- Quellport ist der Port, der nach außen hin abgehört werden soll, also 5900.
- Zielport ist der Port, an den im internen Netzwerk das Paket weitergeleitet werden soll, in unserem Fall ebenfalls 5900
- Quell-IP ist nicht immer vorhanden, es wird davon ausgegangen, dass die IP gemeint ist, die der Router im Internet hat.
- Ziel-IP ist die IP, an die das Paket weitergeleitet werden soll, in unserem Fall die des Servers (192.168.0.5)
- Das Protokoll für unseren VNC-Server ist TCP, was das ist, wird hier nicht näher erläutert.
Ist so ein Forwarding eingerichtet (nicht vergessen auf Speichern oder ähnliches zu klicken!) haben wir unserem Router nun folgendes beigebracht:
Leite alle TCP-Pakete, die aus dem Internet (IP 89.54.145.100) auf dem Port 5900 kommen an den Rechner mit der IP 192.168.0.5 auf Port 5900 weiter. Wenn noch eine Firewall installiert ist, sollte man dieser ebenfalls beibringen, dass sie diese Pakete zulassen soll. Oft reicht eine generelle Erlaubnis für das Programm als Server fungieren zu dürfen.
Thema Sicherheit
Kommt nun tatsächlich eine VNC-Verbindungsanfrage auf diesem Port, wird der installierte Server reagieren und eine Verbindung zulassen. Und schon kann man mit einem VNC-Viewer den Computer fernsteuern. Natürlich sollte man ein Passwort einrichten, dass nicht jeder, der einen VNC-Viewer hat (und die Internet-IP kennt), einfach den eigenen Rechner fernsteuern kann. Zudem ist es möglich bzw. empfehlenswert - als zusätzliche Sicherheitsvorkehrung - die Ports zu variieren, also anstatt 5900 einen anderen beliebigen zu benutzen. Das Abweichen vom Standard minimiert die Wahrscheinlichkeit, dass jemand unbefugt eindringen kann, denn woher soll ein Außenstehender einen willkürlichen Port erraten? Wer wirklich eindringen will, kann sich natürlich an Softwares bedienen, die sogenannte Portscanns durchführen, um herauszufinden welche Ports “offenstehen”. Sofern jedoch der Server korrekt konfiguriert ist und beispielsweise Passwortabfragen durchführt oder sonst eine Authentifizierung erwartet, kommt der “Hacker” nicht viel weiter als um das Wissen, dass auf diesem Port Kommunikation stattfinden könnte, wenn man den korrekten Schlüssel bzw. das richtige Passwort wüsste.
Wenn kein Server läuft, d.h. die VNC-Software nicht gestartet ist, dann “wartet” bzw. “lauscht” auch kein Programm auf dem entsprechenden Port. In diesem Fall geht ein ankommendes Paket leer aus und wird quasi verloren. Der Sendende erhält auch keine Antwort auf die von ihm gesendete Anfrage. Am Sichersten ist es also den Server nur dann zu starten, wenn man ihn braucht, dann hat kein Eindringling die Chance z.B. das Passwort zu erraten, während der Server im Leerlauf ist. Das “lauschen” auf Pakete auf einem Port nennt man übrigens tatsächlich so, aus dem englischen von “to listen”.
In weiteren Kapiteln beschreibe ich noch das Benutzen von VNC-Verbindungen und die Besonderheit des UltraVNC. Auch interessant ist das völlig konfigurationsfreie Team-Viewer, wozu ich auch einen kurzen Absatz geschrieben habe.