Verbindung ok, was nun?
Hat man erfolgreich die VPN-Verbindung aufgebaut, bekommt der "Gast" eine IP-Adresse aus dem Adressraum des Servers. Faktisch befinden sich damit beide Rechner im gleichen lokalen Netz. Sofern Dateifreigaben für den angemeldeten Benutzer sichtbar sind, kann er auf diese über Netzwerkumgebung auch zugreifen.
Startet nun der Client oder Server ein Spiel, welches über TCP/IP im lokalen Netz spielbar ist, sollten sich beide Rechner auch hier finden.
Am besten sind beide Rechner in der gleichen Arbeitsgruppe. Der entfernte Rechner taucht meist nicht direkt in der Netzwerkumgebung auf, da die dafür notwendigen Broadcast-Daten nicht über VPN übertragen werden. Man kann den entfernten Rechner aber dennoch mit UNC-Pfadangaben über die Adresszeile im Arbeitsplatz / Explorer über \\IPADRESSE bzw. \\IPADRESSE\FREIGABE ansprechen, also z.B. \\192.168.1.11\Dokumente. Alternativ kann auch der Rechnername statt der IP verwendet werden.
Es lassen sich auch Netzwerklaufwerke verbinden. Diese gibt man wieder über UNC-Pfade an.
|
Ab.22 Netzwerklaufwerke über UNC verbinden
| Remote Control
Ein ganz anderes Betätigungsfeld ist die RemoteControl des Servers. Nachdem eine VPN-Verbindung zum Server herstellt wurde, kann man über das Programm "Remotedesktopverbindung" den Server komplett fernsteuern. Wie dies im Detail funktioniert und was es hierbei zu beachten gilt, beschreibt der Artikel Fernsteuerung von Windows XP von PCDMicha.
Eine (Software-)Firewall bzw. ein Router stellt oft ein Problem bei gescheiterten VPN-Verbindungen dar. Damit die Verbindung reibungslos klappt, muss die (Software-)Firewall bzw. der Router in der Lage sein, VPN-Verbindungen zu den Clients und dem Server zuzulassen. Die Clients sind kein Problem. Spezielle Freigaben sind hier im Regelfall nicht erforderlich. Microsoft beschreibt im KB-Artikel 314076, welche Ports geöffnet werden müssen:
Für PPTP reicht auf der Serverseite der Port 1723 TCP, d.h. dass dieser Port an den VPN-Server durchgereicht werden muss.
Im Idealfall sollte man dem Server-Rechner eine feste IP-Adresse zuweisen, welche man im Router für den Port 1723 freigeben kann (im Beispiel hier 192.168.1.11). Die Einstellungen nimmt man über die Eigenschaften der Netzwerkverbindung vor:
Dennoch klappt nicht mit allen Routern die Verbindungsaufnahme. Damit der VPN-Server hinter dem Router erreichbar ist, muss der Router für eintreffende PPTP-Verbindungen diese ins lokale Netz weiterleiten (Port Forwarding) bzw. die Firewall diese durchlassen. PPTP verwendet jedoch nicht TCP/UDP sondern GRE (Generic Routing Encapsulation) als Transportprotokoll (Protokollnummer 47). Dies können nicht alle Router an einen VPN-Server weiterleiten. Viele Hersteller meinen mit VPN-Fähigkeit lediglich, dass der Router mit einem VPN-Server verbinden kann, nicht aber vor einem VPN-Server funktioniert.
Das Problem ist daher der Router/die Firewall vor dem VPN-Server. Entweder muss hier auch das GRE-Protokoll für den Server-Rechner weitergeleitet werden oder der Rechner komplett von der Firewall (bzw. der des Routers) freigestellt werden (nennt sich meist DMZ, wenn es auch eher ein Exposed Host darstellt). Die 2. Lösung macht den Rechner aber für alle Angriffe von außen angreifbar und sollte daher nur eine Notlösung darstellen.
Problemlos funktioniert ein VPN-Server zu Beispiel an Vigor-Routern von Draytek oder der Fritz-Fon-Box DSL. Einige Routertypen bieten sogar einen eingebauten VPN-Server, den man aber zu Gunsten des Windows-VPN-Servers abschalten kann.
Bei anderen Herstellern hilft nur Ausprobieren: Eventuell lässt sich das GRE-Protokoll unter Angabe seiner IP-Protokollnummer 47 zum VPN-Server weiterleiten. Für die Kerio-Firewall z.B. lässt sich GRE über Advanced, Protokoll "Other" und Protokollnummer 47 hinzufügen.
Am Beispiel der Fritz-Fon-Box DSL hier die richtigen Freigaben (gelb markiert) :
|
Ab.23 Port 1723 wird an den VPN-Server 192.168.1.11 weitergeleitet und GRE für diesen Rechner geöffnet
|
|
