Seite 4: Windows-Feinheiten

Inhaltsverzeichnis

Sackgassen

Sobald der Client-PC mit dem VPN verbunden ist, richtet Windows in der Voreinstellung den VPN-Server als neues Default-Gateway ein und leitet den gesamten IP-Verkehr über den Tunnel – mit der Folge, dass nun die Internet-Verbindung scheinbar nicht mehr funktioniert. Das lässt sich aber in den Eigenschaften der DFÜ-Verbindung zum VPN ändern: Unter XP/2000 findet man auf der Seite "Netzwerk" in den TCP/IP-Eigenschaften unter "Erweitert" den Schalter "Standard-Gateway für das Remotenetzwerk verwenden". Schaltet man ihn ab, sendet Windows nur Pakete über den Tunnel, die für das IP-Netz der privaten VPN-Adresse bestimmt sind. So kann man weiterhin im Netz surfen, während die VPN-Verbindung geöffnet ist.

Wenn der Client-PC an einen Router angeschlossen ist, der ihn mit NAT ins Internet bringt, muss dieser mit ausgehenden PPTP-Verbindungen umgehen können. Damit haben die meisten Hard- und Software-Router aber kein Problem. Man sollte den Router auf Client-Seite aber so einstellen, dass er für das LAN ein anderes IP-Netz verwendet als das vom VPN vorgegebene. Kompliziert wird es, wenn die vom VPN-Server ausgegebene private IP-Adresse aus demselben IP-Netz stammt, das der Client auch lokal verwendet. Das ist beispielsweise immer dann der Fall, wenn beide Seiten die Internet-Verbindungsfreigabe und damit Adressen aus dem Netz 192.168.0.x verwenden. Nur bei Windows 9x kann man ICS mit Änderungen in der Registry dazu überreden, andere Adressen zu verwenden.

Bei einem solchen Adresskonflikt erreicht man nach dem Verbindungsaufbau die VPN-Rechner in der Standardkonfiguration gar nicht: Die für das IP-Netz des VPN bestimmten Pakete schickt Windows weiterhin an die lokale Netzwerkkarte. Als Workaround kann man in diesem Fall wie beschrieben die Verwendung der VPN-Verbindung als Standard-Gateway abschalten. Dann leitet automatisch eine zusätzliche Route die Pakete ins VPN – jedoch erreicht man nun bei geöffnetem Tunnel sein eigenes LAN nicht mehr.

Harte Schale

Wer kein vollwertiges VPN mit PPTP verwenden kann oder will, dem bietet der aus der Unix-Welt stammende Dienst Secure Shell (SSH) eine interessante Alternative. Mit einem SSH-Server richtet man einen Zugang ein, über den sich der PC aus der Ferne via Kommandozeile bedienen lässt. Die Übertragung von Daten und Passwörtern ist auch hier sicher verschlüsselt. SSH benötigt nur einen einzigen TCP-Port, standardmäßig die Nummer 22. Deshalb lässt sich der Server hinter jedem Router nutzen, indem man diesen Port für Verbindungen von außen freigibt. Gleiches gilt für Personal Firewalls, bei XP muss man hier den SSH-Port manuell öffnen.

Es mag auf den ersten Blick nicht besonders nützlich erscheinen, einen Windows-PC per Kommandozeile fernzusteuern – SSH bietet aber noch mehr. Mit dem Protokoll SCP (Secure Copy) nutzt man einen SSH- wie einen FTP-Server, um Dateien zu übertragen. SSH ist wesentlich sicherer als das Protokoll FTP, bei dem sogar die Passwörter unverschlüsselt übermittelt werden. Der Windows-Client WinSCP bietet für den Dateiaustausch eine komfortable Explorer- oder Norton-Commander-Oberfläche. Darüber hinaus kann man über SSH beliebige TCP-Ports tunneln, um beispielsweise Windows mit TightVNC verschlüsselt fernzusteuern.

Ein SSH-Server gehört zum Lieferumfang jedes Unix-Systems. Bei den meisten Linux-Distributionen läuft er schon in der Grundkonfiguration oder lässt sich mit wenigen Klicks im Konfigurationsprogramm einschalten. In Mac OS X genügt es, in den Systemeinstellungen unter "Sharing" den Haken bei "Entfernte Anmeldung" zu setzen.

Ein SSH-Server für Windows ist in der Tool-Sammlung Cygwin enthalten, die Windows zugleich um eine Unix-Umgebung samt neuer Shell und vielen Kommandozeilentools erweitert. Um nur den SSH-Server zu benutzen, ist das volle Cygwin-Paket jedoch Overkill. Erfreulicherweise steh mit freeSSHd ein Softwarepaket bereit, die komfortables Installationsprogramme besitzen.

Maulwurf

Die durch SSH abgesicherte Übertragungsstrecke kann auch anderen Anwendungen als Datenkanal dienen. Dazu lässt man PuTTY auf einem lokalen Port des Client-PC lauschen. Mit der Tunnelfunktion leitet PuTTY diesen Port über die SSH-Verbindung auf einen wählbaren Zielport des Servers oder eines anderen Rechners im LAN hinter dem Tunnel um. Hier kann ein beliebiges Programm die Daten entgegennehmen. So lässt sich beispielsweise der Windows-Remote-Desktop über SSH zum Fernsteuern eines PC verwenden. Wer lieber TightVNC verwenden möchte, leitet den Port 5900 via SSH um.

Einen neuen Tunnel richtet man mit PuTTY unter Connection/SSH/Tunnels ein. Der "Source Port" für den Remote-Desktop ist 3389. Unter Destination gibt man die private Adresse des Servers an, gefolgt von einem Doppelpunkt und dem Zielport, auf dem am anderen Tunnelende der aktivierte RDP-Server lauscht. Diese Konfiguration kann PuTTY zusammen mit der Adresse des Servers und anderen Einstellungen als "Session" abspeichern. Sobald man sich damit eingeloggt hat, erreicht die Client-Software den entfernten Desktop unter der Adresse localhost – bei Windows XP jedoch nur mit einem Trick: Der in XP Professional enthaltene RDP-Client lehnt "localhost" als Server-Adresse ab. Um ihn zu überlisten, lässt man den Tunnel auf Client-Seite nicht unter dieser Adresse beginnen, sondern mit 127.0.0.2. Das Eingabefeld von PuTTY wirkt zu kurz für die Eingabe einer lokalen Adresse, doch man kann sie einfach hineinschreiben. Als "Source Port" gibt man also 127.0.0.2:3389 an und gibt dem RDP-Client dann die Adresse 127.0.0.2 mit.