Aufbau einer VPN-Verbindung mit Windows 2000 zu
einem
FLI4L mit dem OPT_VPND
von Lutz Lisseck
Inhalt
Vorwort
Im 1. Teil dieses Dokumentes geht es darum, einen VPN-Server auf dem
FLI4L (unter 2.0.7 oder 2.0.8)
einzurichten, über den sich Windowsclients mit den Bordmitteln von
Windows in das Netz hinter dem FLI4L einwählen können. Im 2. Teil
dieses Dokumentes wird dazu auch die Einrichtung der Clients unter
Windows 2000 beschrieben.
Hat ein Client per VPN eine Verbindung zu unserem Netzwerk aufgebaut,
so erscheint ihm das FLI4L-Netzwerk quasi als lokales Netzwerk. Darüber
lassen sich dann Anwendungen und Spiele fast so betreiben, als wäre der
Client direkt an das FLI4L-Netzwerk angeschlossen. Allerdings mit
einigen Einschränkungen:
- Die Geschwindigkeit ist von der Internetanbindung beider Seiten
abhängig und damit meistens langsamer als im LAN
- Broadcasts werden nicht ohne weiteres weitergeleitet. Daher
werden Netzwerkfreigaben oder LAN-Spiele nicht automatisch gefunden,
gibt man aber direkt die IP ein, so funktioniert die Verbindung
normalerweise trotzdem
Besonders interessant ist eine VPN-Verbindung, wenn mindestens eine
Seite hinter einem Router liegt, der keine eingehenden
Verbindungsanfragen durchlässt. Beim VPN hat nämlich jeder eine eigene
IP Adresse, so dass damit auch Server hinter dem Router wieder
erreichbar werden. Durch eine VPN-Verbindung lässt sich z.B. ganz
einfach eine Netmeeting- oder eine VNC-Verbindung herstellen, ohne das
dazu erst umständlich Ports geöffnet werden müssten. Ausserdem wird
sämtlicher Datenverkehr durch diese Verbindung ein wenig verschlüsselt
(normalerweise mit 128 Bit), so das der sonst unverschlüsselt laufende
Verkehr von VNC o.Ä. nicht so leicht abgehört werden kann.
Variablenkonzept
Um
auch Personen ohne Kenntnisse der VPN und FLI4L-Einstellungen eine
einfache Erstellung einer VPN-Verbindung zu unserem Server zu
ermöglichen, wird in diesem Dokument ein Variablenkonzept verwendet.
Derjenige, der den VPN-Server unter FLI4L einrichtet, erstellt dazu
eine separate Textdatei ("VPN-Daten.txt"), in die er zunächst den
folgenden Inhalt einkopiert:
# aus VPND.TXT übernehmen:
VPND_USER_1_USER =''
VPND_USER_1_PASS =''
VPND_USER_1_IP =''
# Route auf dem Windows-Client (für jeden Client verschieden!)
VPNROUTE_1 ='route add 192.168.6.0 MASK 255.255.255.0 192.168.10.32'
# aus BASE.TXT
DOMAIN_NAME ='lan.fli4l'
# Hiermit ist der VPN-Server aus dem Internet zu erreichen
Öffentliche-VPN-Serveradresse ='irgendwas.dyndns.org'
# Hiermit ist der VPN-Server aus dem internen Netz zu erreichen
# (zu Debugzwecken
Interner-VPN-Servername ='fli4l'
Interne-VPN-ServerIP ='192.168.6.1'
|
Im weiteren Verlauf der Servereinrichtung werden dann nicht nur die
Config-Dateien vom FLI4L angepasst, sondern auch die soeben erstellte
Textdatei "VPN-Daten.txt". Um Variablen aus der FLI4L-Config-Datei von
den Variablen der VPN-Daten.txt unterscheiden zu können, sind letztere
mit geschweiften Klammern {Variable}
versehen. Am Ende der
FLI4L-Konfiguration braucht man dann nur noch dieses Dokument zusammen
mit der Datei "VPN-Daten.txt" den Benutzern weiter zu geben, den man
den VPN-Zugang zu seinem Server ermöglichen will.
Derjenige, der unter Windows 2000 oder höher eine VPN-Verbindung zum
FLI4L-Server aufbauen will, braucht sich dann nicht mehr um die genaue
Bedeutung der Parameter zu kümmern. Taucht im Text dann ein Verweis auf
den Inhalt einer Variblen auf (gekennzeichnet durch {Varible}), so
braucht man an der entsprechenden Stelle nur den Inhalt der Variablen
aus der "VPN-Daten.txt" OHNE die '-Zeichen zu übernehmen.
Einrichtung
des VPN-Servers unter FLI4L mit dem OPT_VPND
1. Möglichkeit
VPN-Clients und FLI4L-Netz haben separate Subnetze
+ einfaches Routing (aber leider auf
der Seite der VPN-Clients)
- Broadcasts über Subnetze prinzipiel problematisch
2. Möglichkeit
VPN-Clients bekommen eine IP aus dem gleichen Subnetz des FLI4-LANs
+ Broadcasts haben etwas bessere
Chancen (auch wenn trotzem erst
weitere Tricks gebraucht werden, um diese ermöglichen)
+ auf den VPN-Clients müssen normalerweise keine weiteren Routen
eingerichtet werden
- auf den Clients im FLI4L-Netz müssen zumindest von den Clients, die
mit den über VPN angebundenen Rechnern kommunizieren wollen, die Routen
angepasst werden
- umständliches Routing, meist nur mit Host-Routen zu realisieren
- Vorgehensweise wird hier nicht
beschrieben, da diese Variante insgesamt deutlich komplizierter in der
Einrichtung ist
Vogehensweise zur 1. Möglichkeit
Die Vorgehensweise zur Einrichtung des VPN-Servers soll hier anhand
einer Beispielkonfiguration
durchgeführt werden, die wie folgt aussieht:
- FLI4L hat IP 192.168.6.1
- LAN-Clients sind alle im selben
Subnetz
192.168.6.0
- Das Subnetz für die VPN-Clients
wurde auf 192.168.10.0 festgelegt
- Die VPN-Clients erhalten
IP-Adressen zwischen 192.168.10.32 bis 192.168.10.40
- Zunächst werden nur 3 Clients
("otto", "lisa" und "gast") mit den IP's .32, .33 und .34 auf dem
Server eingerichtet
Ausgehend von der vorhandenen IP-Konfiguration des FLI4L-Netzwerkes
wird ein weiteres Subnetz für die VPN-Clients ausgewählt. Nach
Möglichkeit sollte hier ein Subnetz gewählt werden, das weder im
eigenen, noch im LAN der VPN-Clients bereits verwendet wird.
Als
nächstes sollte man für alle zukünftigen VPN-Cliens einen Hostnamen,
ein Passwort sowie eine IP aus dem VPN-Subnetz auswählen. Ein
Namengebungsschema für die Hostnamen wie z.B. "Gast" + ([letzte_IP_Ziffer]) + "-" +
[VPN_Server] erleichert später die Zuordnung der
VPN-Verbindungen. Es wird
empfohlen, für zur Zeit noch nicht bekannte VPN-Clients auch ein paar
Gast-Accounts anzulegen, und für diese einfach ein zufälliges
Passwort zu vergeben. Wenn später ein bis dato
unbekannter Benutzer einen VPN-Zugang benötigt, nimmt man
einfach die Daten eines solchen Gast-Zugangs und braucht nicht extra
den FLI4L
neuzustarten.
Alle diese Daten werden zunächst in der vpnd.txt eingetragen. Es sei
dringend empfohlen, allen Benutzern hier auch eine feste IP zuzuordnen.
Die Einträge für unsere Beispielkonfiguration würden dann wie folgt
aussehen:
# vpnd.txt
VPND_USER_N='3' # Anzahl der User
VPND_USER_1_USER='otto-fli' # username for the PPTP Connection
VPND_USER_1_PASS='bunTsTift' # password for the PPTP Connection
VPND_USER_1_IP='192.168.10.32' # IP adress for user - leave blank if dynamic
VPND_USER_2_USER='lisa-fli' # username for the PPTP Connection
VPND_USER_2_PASS='HegGenScheeRe' # password for the PPTP Connection
VPND_USER_2_IP='192.168.10.33' # IP adress for user - leave blank if dynamic
VPND_USER_3_USER='gast34-fli' # username for the PPTP Connection
VPND_USER_3_PASS='an5djj3xVs' # password for the PPTP Connection
VPND_USER_3_IP='192.168.10.34' # IP adress for user - leave blank if dynamic
Bitte nicht vergessen, auch VPND_USER_N anzupassen!
Damit sich die Benutzer später leichter ansprechen lassen, fügen wir
die Benutzernamen mit ihren IP-Adressen auch noch der base.txt hinzu:
# base.txt
HOST_10='192.168.10.32 otto-fli'
HOST_11='192.168.10.33 lisa-fli'
HOST_12='192.168.10.34 gast34-fli'
Auch hier bitte HOSTS_N anpassen.
In der vpnd.txt trägt man jetzt unter VPND_REMOTE ein, welchen
IP-Bereich man den
VPN-Verbindungen zuordnen möchte. Dieser Bereich muss mindestens alle
soeben vergebenen VPN-IP-Adressen abdecken, darf aber auch etwas größer
ausfallen.
Jetzt fehlen noch die restlichen Einstellungen in der vpnd.txt.
OPT_VPND setzen wir auf 'yes', VPND_DEBUG auf 'no' und VPND_NTDOMAIN
lassen wir leer, sofern wir keinen wirklich guten Grund haben, hier
etwas einzutragen.
Damit die Namensauflösung auch klappt, wird dem VPN-Client automatisch
ein Namensserver mitgegeben. Dieser Namensserver ist normalerweise der
FLI4L-Router, daher wird die IP-Adresse des FLI4L unter VPND_IPADDR
eingetragen.
Möchten wir den VPN-Clients automatisch die IP-Adresse eines
WINS-Servers aus unserem Netzwerk mitgeben, so muss diese unter
VPND_WINSADDR eingetragen werden. Mit Hilfe eines WINS-Servers kann man
erreichen, dass auf den VPN-Clients die Windows-Netzwerkfreigaben aus
dem FLI4L-Netz auch in der Netzwerkumgebung angezeigt werden. Wie man
einen solchen Server mit dem OPT_SAMBA_LPD einrichtet, wird in einem
Unterkapitel hier später beschrieben. Für den Anfang sollte man aber
erst das VPN vernünftig ans laufen bekommen, daher sollte man diese
Einstellung zunächst leer lassen.
Für unsere Beispielkonfiguration sähe der Anfang der vpnd.txt nun so
aus:
# vpnd.txt
OPT_VPND='yes' # install VPN Daemon
VPND_DEBUG='no' # enable debugging, 'yes' or 'no'
VPND_IPADDR='192.168.6.1' # IP address of fli4l router
VPND_REMOTE='192.168.10.32-40' # IP address of the VPN Client
VPND_NTDOMAIN='' # NT domain name, if domain accounts are used
VPND_WINSADDR='' # IP address of WINS server, if any
Damit die VPN-Verbindung aber auch wirklich auf das FLI4L-Netzwerk
Zugriff bekommt, müssen das FLI4L- und das VPN-Subnetz noch in der
base.txt unter FORWARD_TRUSTED_NETS eingetragen werden. Da wir ein
Klasse-C Subnetz mit der Maske 255.255.255.0 verwendet haben, also in
der Maske 24 Bits auf 1 gesetzt haben, muss man hinter die IP des
Subnetzes diese Maske mit /24 angeben. Ausserdem müssen alle Bits, die
in der Maske 0 sind, auch im IP-Teil der Subnetzadresse auf 0 gesetzt
sein, so das die 4. Ziffer der IP hier immer mit 0 angegeben werden
muss. Für unsere Beispielkonfiguration ergibt sich der folgende Eintrag:
# base.txt
FORWARD_TRUSTED_NETS='192.168.6.0/24 192.168.10.0/24' # but allow forwarding between LANs
Soweit ist die FLI4L-seitige Konfiguration für den VPN-Server nun
fertig. Zunächst aber sollten wir noch die Variablen für das
Variablenkonzept ("VPN-Daten.txt") ausfüllen.
Aus der vpnd.txt übernehmen wir zunächst die Namen, Passwörter und
IP-Adressen der VPN-Clients in die Variablen {VPND_USER_n_USER}, {VPND_USER_n_PASS}und {VPND_USER_n_IP}.
Für die Namensauflösung ist aus der base.txt noch der Eintrag
DOMAIN_NAME wichtig, der auf später bei der Client-Konfiguration
angelegt werden muss. Im Beispiel wurde der FLI4L-Standard "lan.fli4l"
übernommen.
Ebenfalls in der base.txt ist der {Interner-VPN-Servername}
unter
HOSTNAME sowie die {Interne-VPN-ServerIP}
bei IP_ETH_x_IPADDR zu finden.
Für die Variable {Öffentliche-VPN-Serveradresse}
gehe ich davon aus,
dass der FLI4L unter einem festen Namen aus dem Internet zu erreichen
ist. Bei den meisten Internetverbindungen wechselt die IP-Adresse mit
jeder Einwahl, eine Dynamischer-DNS-Anbieter kann dieses Problem lösen,
wobei das Paket OPT_DYNDNS hilfreich sein kann. Dazu gibt es aber genug
andere gute Dokumente. Im Notfall kann man die dynamische IP auch jedes
mal von Hand dem Verbindungspartner z.B. telefonisch übermitteln und
auf dem Windows-VPN-Client eintragen...
Windows-Route
Als letztes müssen wir für die Windows-Clients einen Route-Befehl
vorbereiten. Dieser ist notwendig, da der VPN-Client nach dem
Verbindnungsaufbau zunächst nur Zugriff auf das VPN-Subnetz hat. Mit
dem Route-Befehl teilen wir dem Windows-Client mit, dass er alle
Verbindungen zu einer IP-Adresse im FLI4L-Subnetz auch über die
VPN-Verbindung erreichen kann. Da die Route jedes mal erneut gesetzt
werden muss, nachdem die VPN-Verbindung auf dem Client aufgebaut wurde,
schreiben wir diese in eine Batch-Datei, die wir griffbereit auf dem
Desktop anlegen. Der Route-Befehl, den wir zunächst unter {VPNROUTE_n} hinterlegen, wird
wie folgt aufgebaut:
route add FLI4L_SUBNETZ MASK 255.255.255.0 VPN_IP
Das FLI4L_SUBNETZ ist die {Interne-VPN-Server-IP},
wobei die letzte Ziffer eine 0 sein muss. Zu beachten ist, dass die
VPN_IP für jeden Client verschieden ist {VPND_USER_1_IP}, und daher die
Route für jeden Client angepasst werden muss. Leider gibt es hierfür
keine bessere Möglichkeit.
[@Experten: Dem VPN-Tunnel auf beiden Seiten eine IP-Adresse aus
dem VPN-Subnetz zuzuweisen, und dann die VPN-Server-IP als Routingziel
anzugeben, hatte bei mir den Haken, das Windoof diese Route nur an
nimmt,
wenn man die Schnittstelle beim Route-Befehl mit angibt, was die Sache
wegen der kryptischen Schnittstellenbezeichnungen unter Windows nur
noch schlimmer macht.]
Wichtig ist, das man am besten vor und hinter dem "MASK 255.255.255.0"
nicht ein, sondern zwei Leerzeichen setzt, weil Windoof die Route sonst
gerne nicht an nimmt!
Für unsere Beispielkonfiguration ergibt sich daher folgende Zeilen in
VPN-Daten.txt:
# VPN-Daten.txt
VPNROUTE_1 ='route add 192.168.6.0 MASK 255.255.255.0 192.168.10.32'
VPNROUTE_2 ='route add 192.168.6.0 MASK 255.255.255.0 192.168.10.33'
VPNROUTE_3 ='route add 192.168.6.0 MASK 255.255.255.0 192.168.10.34'
In die Batchdatei (auf dem Desktop einfach eine txt-Datei erstellen,
editieren, und nach VPN-Route.bat o.Ä. umbenennen) kommt natürlich nur
der Teil aus {VPNROUTE_1},
der zwischen den '-Zeichen steht.
Am besten gibt man seinen VPN-Gästen neben der angepassten VPN-Daten.txt (oder
soll der
VPN-Benutzer auch die Passwörter der anderen Benutzer haben?!) auch
direkt die fertige Batch-Datei mit.
OK, für's erste sollte man probieren, mit diesen Einstellungen den
Router zu aktuallisieren und eine VPN-Verbindung dazu mit Windows
herzustellen.
Einrichtung
der VPN-Verbindung auf dem Gast-PC unter Windows 2000
und höher
Der folgende Abschnitt beschreibt, wie
man einem Gast-PC, der nicht direkt in unserem Netzwerk liegt, den
Zugang zu unserem Netzwerk per VPN ermöglicht. Der Gast-PC benötigt
dazu nur "Bordmittel" von Windows 2000, sowie einen funktionierenden
Internetzugang (dabei ist es egal, ob dieser direkt über ein Modem oder
aber einen Router wie FLI4L hergestellt wird), durch den Windows dann
den verschlüsselten "Tunnel" zum VPN-Server gräbt.
Windows 2000
Unter "Systemsteuerung" -> "Netzwerk- und DFÜ-Verbindungen"
auf "Neue Verbindung erstellen" klicken. Es sollte sich nun ein Fenster
öffnen, in dem man, nachdem man den Willkommensgruß zum Assitenten
weggeklickt hat, zunächst den Netzwerkverbindungstyp auswählen kann.
Wir möchten eine VPN-Verbindung mit einem privaten Netzwerk herstellen,
also wählen wir den Punkt "Verbindung mit einem privaten Netzwerk über
das Internet herstellen".
Im nächsten Schritt fragt der Assistent, ob eine Anfangsverbindung
automatisch gewählt werden soll, bevor die VPN-Verbindung hergestellt
wird. Im Zweifel empfehle ich hier, den Punkt "Keine Anfangsverbindung
automatisch wählen" auszuwählen. Wenn die Verbindung zum Internet direkt durch den PC hergestellt
wird (also wenn unser Gast-PC ohne einen Router direkt am Modem
angeschlossen ist), auf dem wir gerade die VPN-Verbindung einrichten,
kann man hier als Anfangsverbindung die Verbindung zum Internetprovider
einstellen. Das erspart einem dann den manuellen Verbindungsaufbau.
Danach fragt der Assitent nach der Zieladresse, zu der die
VPN-Verbindung aufgebaut werden soll. Haben wir eine VPN-Daten.txt
bekommen, so kommt hier der Inhalt zwischen den
'-Zeichen der {Öffentliche-VPN-Serveradresse}
- Variablen hinein. Ansonsten gibt man die Adresse ein,
unter der der FLI4L-Router mit dem VPN-Server aus dem Internet zu erreichen ist.
Normalerweise ist dies eine Hostadresse bei einem DYNDNS-Anbieter,
unter der der VPN-Server, z.B. mit Hilfe des OPT_DYNDNS, seine
dynamische (d.h. bei jeder Einwahl wechselnde) IP-Adresse hinterlegt
hat.
Noch einen Schritt weiter fragt einen der Assistent, ob die
VPN-Verbindung, die wir gerade erstellen, auch für andere Benutzer zur
Verfügung gestellt werden soll. Nutzen z.B. auch Familienmitglieder
unter einem anderem Profil den Computer, so kann man hier entscheiden,
ob diese auch die VPN-Verbindung nutzen dürfen. Hier ist es ihre
Entscheidung, ob sie z.B. auch ihren Kindern die VPN-Verbindung zu
ihrem Arbeitsplatzrechner in der Firma zur Verfügung stellen...
Im letzten Schritt des Assistenten geben wir der VPN-Verbindung noch
einen aussagekräftigen Namen, z.B. wieder nach dem Schema
BENUTZER-HOST. Ausserdem empfiehlt es sich, hier ein Häkchen bei
"Verknüpfung auf dem Desktop hinzufügen" zu setzen, damit wir die
VPN-Verbindung nicht immer erst aus den Tiefen der Systemsteuerung
herraus suchen müssen.
Sofern sich mit der Fertigstellung des Assistenten nicht auch schon das
"Verbindung mit ... herstellen"-Fenster geöffnet hat, können wir dieses
über die neu hinzugekommende Verknüpfung auf dem Desktop öffnen.
Bevor wir aber eine VPN-Verbinung aufbauen können, müssen noch ein paar
weitere Einstellungen gemacht werden. Dazu müssen wir die Eigenschaften
der VPN-Verbindung editieren, zu denen wir mit einem Klick auf den
"Eigenschaften"-Button im "Verbindung mit ... herstellen"-Fenster
gelangen.
In dem sich darauf hin öffnenden Fenster befinden sich ganz oben ein
paar Reiter. Je nach Betriebsystemversion können sich die Anzahl oder
die Beschriftung der Reiter etwas unterscheiden. Das soll uns aber
nicht weiter stören. Im folgenden erkläre ich, was unter welchem Reiter
eingestellt sein sollte.
Allgemein
- Hier sollte die zuvor eingestellte Zieladresse des VPN-Servers
stehen {Öffentliche-VPN-Serveradresse}
- "Symbol in Taskleiste anzeigen, wenn Verbindung hergestellt ist"
sollte man aktivieren, um die Verbindung später einfacher wieder
abbauen zu können.
Optionen
- "Status während des Wählens anzeigen" sollte aktiviert sein
- "Name, Kennwort, Zertifikat usw. abfragen" sollte aktiviert sein
- "Windows-Anmeldedomäne einbeziehen" sollte deaktiviert sein
- Wahlwiederholungsoptionen so eingestellt lassen, wie Windows es
vorgibt
Sicherheit
- Sicherheitsoptionen "Erweitert (benutzerdefinierte
Einstellungen)" auswählen
- Auf "Einstellungen" klicken, im folgenden Fenster nun folgendes
einstellen
- Datenverschlüsselung: "Erforderlich (Verbindung trennen, falls
Server dies ablehnt)
- Folgende Protokolle zulassen: Hier nur "Microsoft CHAP, Version
2 (MS-CHAP v2) aktivieren
- Der Punkt "Für MS-CHAP-basierte Protokolle automatisch eigenen
Windows-Anmeldenamen und -Kennwort ([...]) verwenden" sollte deaktiviert sein
Gemeinsame Nutzung
- Gemeinsamer Zugriff sollte deaktiviert
sein, da sonst Windows beim Herstellen der VPN-Verbindung evtl. die
vorhandene Netzwerkkonfiguration des Gast-PC's durcheinanderbringt
Netzwerk
- Typ des anzurufenden VPN-Servers
auf "Point-to-Point-Tunneling-Protokoll (PPTP)" einstellen.
- Unter "Aktivierte Komponenten werden von dieser Verbindung
verwendet"
ist es wichtig, das von den Protokollen,
erkennbar an dem
Netzwerkkabelicon, nur das Internetprotokoll (TCP/IP) aktiviert
ist. Andere Protokolle wie IPX können den erfolgreichen Aufbau der
VPN-Verbindung verhindern. Die Services, erkennbar am Computersymbol
mit der Hand darunter, dürfen hier aktiviert bleiben. Wer die
Dateifreigabefunktionen von Windows verwenden will oder auf
Samba-Shares vom FLI4L per VPN zugreifen möchte, sollte hier die
"Datei- und Druckerfreigabe für Microsoft-Netzwerke" sowie den "Client
für Microsoft-Netzwerke" aktivieren.
- Unter dem Reiter "Netzwerk" wird nun das Internetprotokoll
(TCP/IP)
selektiert und der "Eigenschaften"-Button angeklickt, um noch
tiefgreifendere Einstellungen am TCP-Protokoll vornehmen zu können.
- Hier sollte es nur einen Reiter mit der Bezeichnung "Allgemein"
geben. Wir wählen hier aus "IP-Adresse automatisch beziehen", da der
VPN-Server uns die IP automatisch übermittelt.
- Auch die DNS-Serveradresse wird vom VPN-Server automatisch
übertragen, wir wählen daher "DNS-Serveradresse automatisch beziehen"
aus.
- Auf dieser Karte, wo wir gerade die DNS-Serveradresse eingegeben
haben, klicken wir jetzt auf den Button "Erweitert...". Wieder
erscheint ein neues Fenster, diesmal sollte es zumindest die Reiter
"Allgemein", "DNS" und "WINS" haben. Falls es noch einen
"Optionen"-Reiter gibt, lassen wir die Einstellungen dort unberührt.
Allgemein
- Das Kontrollkästchen "Standardgateway für das Remotenetzwerk
verwenden" sollte unbedingt deaktiviert
werden, da man sonst nach der Verbindung zum VPN-Server keinen direkten
Zugriff mehr auf das Internet hat. Die einzige Grund, dieses Kästchen
hier zu aktivieren, wäre, wenn man über die Internetverbindung des
VPN-Servers ins Internet möchte...
DNS
- Normalerweise benötigen wir keine weiteren DNS-Serveradressen,
daher bleibt "DNS-Serveradressen in Verwendungsreihenfolge" leer.
- Wir wählen den Radiobutton "Primäre und verbindungsspezifische
DNS-Suffixe anhängen" und aktivieren darunter die Option "Übergeordnete
Suffixe des primären DNS-Suffixes anhängen".
- Unter "DNS-Suffix für diese Verbindung" tragen wir ein, was auf
dem VPN und DNS-Server FLI4L in der base.txt unter DOMAIN_NAME steht
(typischerweise lan.fli4l). Haben wir eine VPN-Daten.txt, so kommt hier
der Variableninhalt von {DOMAIN_NAME}
rein.
- Wir aktivieren "Adressen dieser Verbindung in DNS registrieren"
- Wir deaktivieren
"DNS-Suffix dieser Verbindung in DNS-Registrierung verwenden"
WINS
- Normalerweise wird auch die IP-Adresse des WINS-Servers
automatisch übertragen. Daher bleibt hier das Feld leer.
- Das Kästchen "LMHOSTS-Abfrage aktivieren" sollte deaktiviert sein.
Wir bestätigen nun alle soeben geöffneten Dialogfenster mit "OK", bis
wir wieder bei dem Fenster "Verbindung mit ... herstellen" angelangt
sind.
Dort geben wir nun den Benutzernamen {VPND_USER_1_USER} und das
Kennwort {VPND_USER_1_PASS}
ein, dass auf dem VPN-Server für uns eingerichtet wurde.
Nach einem Klick auf den "Verbinden"-Button sollte die VPN-Verbindung
hergestellt werden und sich als Symbol im Systemtray anlegen.
Doch bevor wir die Verbindung wirklich nutzen können, müssen wir noch
die Batchdatei mit der Route starten, die wir vom
VPN-Server-Administrator bekommen haben. Haben wir nur die
VPN-Daten.txt, so müssen wir den in '-Zeichen stehenden Teil hinter der
Variablen {VPNROUTE_1} in
eine neue Text-Datei kopieren, die wir zuvor auf dem Desktop angelegt
haben. Nach dem Speichern der Datei benennen wir diese nach
VPN-Route.bat um.
Die Batch-Datei zum setzen der Route muss übrigens JEDES MAL nach dem
Aufbau der VPN-Verbindung gestartet werden.
Testen der
Verbindung vom Windows VPN-Client
Nach dem Aufbau der VPN-Verbindung und setzen der Routen sollte die
eigene VPN-IP {VPND_USER_1_IP}
anpingbar sein. In der Windows-Eingabeaufforderung lässt sich das mit
"ping {VPND_USER_1_IP}"
prüfen. Dort müssten sich sofort Antworten sehen lassen. Wenn das schon
nicht klappt, ist an den Einstellungen der VPN-Verbindung unter Windows
etwsa faul.
Als nächstes pingen wir den VPN-Server, zunächst mit "ping {Interne-VPN-ServerIP}" in der
Eingabeaufforderung. Wenn das nicht klappt, ist meistens die Route
nicht richitg gesetzt, was man sich mit "route print" anzeigen lassen
kann. Dort sollte nämlich die Route aus aus der VPN-Route.bat eine
Eintragung mit dem entsprechenden Netzwerkziel hinterlassen haben.
Testweise kann man die Zeile aus der VPN-Route.bat mal in der
Eingabeaufforderung eingeben. Wenn Windows diese Route nicht annimmt,
stimmen wohl irgendwelche IP-Adressen darin nicht (beim Routen ganzer
Subnetze wie es hier normalerweise der Fall ist, muss die IP des
Netzwerksziels normalerweise mit der Ziffer 0 enden) oder man hat die 2
Leerzeichen zwischen der Maskenangabe nicht gesetzt. In extremen Fällen
hat es auch geholfen, die Schnittstelle (so eine 0xX000000X-Nummer) mit
anzugeben, was aber wirklich nur für sehr abgedrehte Routen nötig ist.
Auch eine Personal-Firewall auf dem Windows-PC hat schon oft das
erfolgreiche Pingen verhindert. Im Zweifel für diese Zeit ganz
abschalten.
Nun testen wir, ob auch die Namensauflösung klappt. Dazu pingen wir den
VPN-Server anhand seines Names mit "ping {Interner-VPN-Servername}" an.
Idealerweise löst Ping nun diesen Namen in seine IP-Adresse auf, indem
es den DNS-Server auf dem VPN-Server abfragt und an den Namen die
Domain-Suffix {DOMAIN_NAME}
anhängt. Dazu sollte beim Ping-Versuch schon als erste Zeile etwas wie
"Ping xxx.lan.fli4l [192.16..." erscheinen. Wenn nicht, stimmt bei der
VPN-Verbindung meist etwas auf der Registerkarte "DNS" nicht. Ansonsten
kann auch etwas am DNS-Server auf dem VPN-Server kaputt sein.
Auch ohne die Einrichtung eines Wins-Servers oder einem Broadcast-Relay
sollte man im Windows-Explorer auf entfernte Netzwerkfreigaben
zugreifen können. Dies klappt allerdings nur über die IP-Nummer und
nicht über einen Namen. Im Explorer gibt man dazu in der Adresszeile
einfach etwas in der Form "\\IP-Adresse" ein, also z.B.
"\\192.168.6.2". Nach kurzer Zeit sollten die Freigaben auf dem Rechner
dieser IP sichtbar werden.
Wenn der Aufbau der VPN-Verbinung
nicht klappt
Wir beim Aufbau der VPN-Verbindung eine Fehlermeldung ausgegeben, so
sollte zunächst geprüft werden, ob der VPN-Server überhaupt mit seiner
öffentlichen Adresse zu erreichen ist. Ein "ping {Öffentliche-VPN-Serveradresse}"
in der Eingabeaufforderung schafft darüber Klarheit.
Ist auch der Loginname und das Passwort nochmal genau überprüft, so
sollte man nochmal die von dieser Verbindung verwendeten Komponenten in
den Eigenschaften der VPN-Verbindung überprüfen. Im Zweifel für den
Anfang alles ausser dem TCP/IP-Protokoll hier deaktivieren.
Testen der Verbindung
vom FLI4L
Wurde eine VPN-Verbindung erfolgreich zum FLI4L aufgebaut, so muss in
der Ausgabe zum Befehl "ifconfig" in der Konsole des FLI4L ein weiteres
ppp-Device erscheinen, welches die P-t-P-IP der VPN-Verbindung enthält.
Ob der VPN-Server überhaupt läuft, darüber sollte der Befehl "ps -a |
grep pptpd" Klarheit schaffen, bei der eine Zeile der Art
"/usr/local/sbin/pptpd" ausgegeben werden sollte.
Vom FLI4L aus sollte ein eingewählter VPN-Client ebenfalls anpingbar
sein, hierbei hilft der Befehl "ping -c 4 {VPND_USER_1_IP}". Klappt dies
nicht, obwohl beim ifconfig ein ppp Device mit genau dieser IP dabei
ist, klemmt es meistens am Windowsclient (und dort oft an einer
Firewall). Aber auch, wenn auf dem Windowsclient die Route nicht
gesetzt wurde, schlägt dieser Ping oft fehl.
Wenn es immer noch nicht klappt, ist auch mal mit "ipchains -L" zu
prüfen, ob sich entsprechende Einträge sowohl im input, als auch im
forward-chain befinden, die eine Kommunikation zwischen den Subnetzen
zulassen. Wenn nicht, ist vielleicht etwas am Eintrag
FORWARD_TRUSTED_NETS in der base.txt falsch.
An der Routing-Tabelle des FLI4L-VPN-Servers muss man normalerweise
nicht Hand anlegen, da dort automatisch der Eintrag für die VPN-Route
eingetragen wird, sobald die Verbindung aufgebaut wurde. Daher gehört
auch in die base.txt kein zusätzlicher IP_ROUTE Eintrag.
Auch braucht in der base.txt KEIN Eintrag unter ROUTE_NETWORK gemacht
werden (entgegen den Angaben im OPT_VPND), da FORWARD_TRUSTED_NETS die
IPCHAINS bereits korrekt ausfüllt.
Es würde aber auch nur mit ROUTE_NETWORK klappen, nur würden dann die
FORWARD_DENY_PORT-Regeln aus der base.txt auch auf die VPN-Verbindungen
angewendet, so das die Netzwerkfreigaben unter Windows keine Chance
mehr haben.
Testen der
Verbindung von einem Rechner im lokalen Netzwerk des FLI4L
Das man auf den Rechnern im lokalen Netzwerk des FLI4L normalerweise
keine weitere Route anlegen muss, liegt daran, das dort die
Standardroute auf den FLI4L-Rechner gesetzt ist, der ja weiss, wohin
die Pakete aus dem VPN-Subnetz gehen sollen. Daher sollte ein "ping {VPND_USER_1_USER}" bzw. "ping {VPND_USER_1_IP}" auch von hier
sofort klappen.
Ist auf den Rechnern eine andere oder keine Standardroute gesetzt, so
muss natürlich auch hier noch eine Route gesetzt werden. Im
Variablenkonzept geschrieben lautet der entsprechende Befehl hier
"route add VPN_SUBNETZ MASK 255.255.255.0 {Interne-VPN-ServerIP}", wobei
sich VPN_SUBNETZ wieder aus der {VPND_USER_1_IP}
mit letzter Ziffer gleich 0 bildet.
Netzwerkfreigaben
den VPN-Clients sichtbar machen
Bei stehender VPN-Verbindung sollte es möglich sein, von beiden Seiten
auf Netzwerkfreigaben über die IP-Adresse zuzugreifen (über
\\192.168....). Die Rechnernamen mit ihren Freigaben dürften aber noch
nicht automatisch erscheinen, da die zum Aufbau dieser Liste benötigten
Netzwerkbroadcasts nicht in das Subnetz der VPN-Verbindung
weitergeleitet werden. Dies ist zunächst ein generelles Problem,
welches mit der Architektur des IP-Protokolls zu tun hat - es wurde
einfach so festgelegt, ansonsten würde man mit einem Broadcast an
255.255.255.255 alle Rechner im Internet erreichen, was einen
unmöglichen Traffic verursachen würde.
Obwohl es vielleicht auch möglich ist, mit Hilfe des OPT_BCRELAY zu
erreichen, dass die Rechner im Netzwerk auch hinter der VPN-Verbindung
sichtbar werden, so soll hier nur auf die Methode eingegangen werden,
wie dieses Problem mit Hilfe des OPT_SAMBA_LPD angegangen werden kann.
Damit wird auf dem Router ein WINS-Server eingerichtet, der die
Rechnernamen im LAN einsammelt und dann an die WINS-Clients, in diesem
Fall die Rechner hinter einer VPN-Verbinung, direkt weitergibt.
Das OPT_SAMBA_LPD muss eingebunden werden und im Bereich NMB müssen
folgende Einstellungen vorgenommen werden:
# samba_lpd.txt
#------------------------------------------------------------------------------
# Optional package: NMBD
#------------------------------------------------------------------------------
OPT_NMBD='yes' # install nmbd as SMB Nameserver
# local master, prefered master
NMBD_MASTERBROWSER='yes' # act as a masterbrowser: yes or no
# domain master : Sammelt auch über Broadcastgrenzen die Namen
NMBD_DOMAIN_MASTERBROWSER='no' # Hiermit wir dieser Router zum DOMAIN_Masterbrowser
# und sammelt von allen unter EXT_WINSServer angegebenen
# Router die "Browselisten" ein
# wins support
NMBD_WINSSERVER='yes' # act as an WINS-Server: yes or no
NMBD_WINSCLIENT='no' # act as an WINS-Client: yes or no
# wins server
NMBD_EXTWINSIP='' # IP address of the external WINS-Server
# wins proxy
NMBD_WINSPROXY='yes' # act as an WINS-Proxy : yes or no
# dns proxy
NMBD_DNSPROXY='no' # der Nmbd deamon macht mit 'No' keine DNS-Abfragen mehr
# (Ist in dieser Samba Version standardmäßig aktiviert in den neueren nicht mehr.
# remote announce, remote browse sync
# hier direkte Adressen angeben, wo broadcasts sonst nicht getunnelt werden
NMBD_EXTWINSSERVER='' # Diesen parameter wird für die samba optionen
# Remotebrowsesync und Remoteannounce verwendet.
# Hier müssen alle externen router angegeben werden.
Der Router arbeitet also nun als WINS-Server und sammelt durch die
MASTERBROWSER-Option die Rechnernamen im LAN ein. DOMAIN_MASTERBROWSER
und EXTWINSSERVER brauchen wir normalerweise nicht, da wir keine
weiteren WINS-Server im LAN haben. Ebensowenig können wir gleichzeitig
WINS-Server und WINS-Client sein, daher muss WINSCLIENT auf 'no' stehen
und eine EXTWINSIP gibts daher auch nicht.
Damit die VPN-Clients auch etwas von dem WINS-Server wissen, tragen wir
die IP-Adresse des Routers {Interne-VPN-ServerIP}
in der vpnd.txt unter VPDN_WINSADDR
ein.
# vpnd.txt
VPND_WINSADDR='192.168.6.1' # IP address of WINS server, if any
Die
Clients bekommen so automatisch den WINS-Server zugewiesen und es muss
dort eigentlich nichts an den Einstellungen der VPN-Verbindung geändert
werden. Nach dem Aufbau der VPN-Verbindung und setzen der Routen
sollten nach einiger Zeit die Rechner aus dem FLI4L-Netzwerk in der
Netzwerkumgebung des VPN-Clienten erscheinen.
Achtung: Andersherum
klappt das leider nicht, d.h. in der Netzwerkumgebung der Rechner des
FLI4L-Netzwerkes wird der VPN-Client leider nicht erscheinen. Warum der
Winsclient seinen Namen nicht beim Server partout nicht anmeldet, ist
mir ein Rätsel, wenn jemand daran was ändern kann (es muss doch
irgendeine Option in der smb.conf dafür geben...), möge er mir das
mitteilen.
Broadcasts
weiterleiten mit BCRELAY
Wie
bereits erwähnt, bleiben Broadcasts normalerweise auf ein Subnetz
beschränkt und werden selbst innerhalb eines Subnetzes nicht zu den
VPN-Clients weitergeleitet. Unter Broadcasts versteht man normalerweise
UDP-Pakete, die als Zieladresse eine Broadcastadresse (typischerweise
eine IP-Adresse die auf .255 endet), haben. Wird ein UDP-Paket z.B. an
die Adresse 192.168.6.255 über Port 8777 gesendet, so kann es von allen
Hosts empfangen werden, deren Adresse mit 192.168.6 beginnt und die auf
dem Port 8777 lauschen. Ebenso können Broadcasts auch an die Adresse
255.255.255.255 gesendet werden, in diesem Fall ist die IP-Adresse des
Empfängers dann egal.
Broadcasts sind im Netzwerk eigentlich die einzige Möglichkeit,
Informationen direkt ins gesamte Subnetz zu verbreiten, ohne zu wissen,
welche Stationen überhaupt existieren. Erstellt man z.B. im lokalen
Netzwerk ein Netzwerkspiel (Server), das nicht auf einen Server im
Internet angewiesen ist, so werden normalerweise Broadcasts benutzt, um
diesen Server auf anderen Stationen im LAN anzukündigen. Startet man
nun einen Netzwerkserver, und möchte, das dieser Server auch auf den
Rechnern der Clients hinter einer VPN-Verbindung sichtbar wird, so muss
man also dafür sorgen, dass die Broadcasts des Netzwerkservers auch an
die VPN-Clients weitergeleitet werden.
Ein Tool, welches dabei unter FLI4L hilfreich sein kann, ist
OPT_BCRELAY. Allerdings ist der Einsatz dieses Paketes mit einigen
Fallstricken verbunden, die man kennen sollte. Warum nämlich trotz der
Nutzung von BCRELAY die Netzwerkumgebung leer bleibt und keine
vorhandenen Spieleserver im Netzwerk angezeigt werden, kann viele
Ursachen haben:
1. Fehler im Paket BCRELAY-OPT.0.3
Hier ist leider ein Fehler im OPT,
wodurch das Relayen nicht
funktioniert. Der Fehler liegt in der Datei opt\etc\rc.d\rc766.bcrelay.
Dort sollte man die Zeile
/usr/local/sbin/bcrelay $bcport "\"$BCRELAY_INTERNALNET|ppp[$start-9][0-9]*\""
ersetzen durch
/usr/local/sbin/bcrelay $bcport "$BCRELAY_INTERNALNET|ppp[$start-9][0-9]*"
damit das Relayen funktioniert.
2. Broadcastports
Man sollte beachten, dass sich die
Broadcastports für LAN-Anwendungen oft von den für Internetanwendungen
unterscheiden. Manchmal hilft nur ein Netzwerksniffer wie z.B.
Etherreal (unter grafischen Oberflächen) oder TCPDUMP
(Linuxkommandozeile), um die benutzten Portnummern herraus zu bekommen.
3. Falsche IP-Adressen über VPN
Schneidet man den Netzwerkverkehr mit,
der auf dem FLI4L an einem der VPN-Verbindungen (typischerweise ppp1)
entsteht, so muss man leider feststellen, das hier häufig völlig
falscheAbsender IP-Adressen von den Windowsclients in den Tunnel
gesendet werden. Typischerweise gelangen Pakete durch den Tunnel,
vorallem Broadcastpakete, die als Absender-IP nicht die Adresse des
VPN-Endpunktes enthalten, sondern die Adresse irgendeiner
Netzwerkkarte, die noch im Windows-PC steckt. Leitet man solche Pakete
mit BCRELAY weiter, kommen die zwar im LAN des FLI4L an, können von den
Clients jedoch aufgrund der falschen Absenderadresse nicht beantwortet
werden oder bleiben damit gleich in den Firewallregeln des Routers
stecken.
Für dieses Problem kenne ich leider noch keine Lösung, hier müsste man
die Absenderadressen auf der FLI4L-Seite irgendwie wieder richtig
biegen oder Windows dazu bringen, die richtigen IP-Absenderadressen
einzutragen.
Wie man sieht, sind Broadcasts trotz BCRELAY über Subnetzgrenzen hinweg
mit FLI4L noch eine sehr steinige Angelegenheit, für die es Aufgrund
des Problems 3 teilweise noch gar keine Lösung gibt. So habe ich für
Unreal ausfindig gemacht, dass dort neben den Ports 7777-7787 auch die
Ports 8777-8787 eine Rolle spielen. Wegen Problem 3 sieht ein
VPN-Client einen Server im FLI4L-Netz aber trotzdem nicht, wärend ein
Server hinter einer VPN-Verbindung im FLI4L-Netz mit BCRELAY sichtbar
wird...
Sonstiges
Unter Windows lässt sich mit einer VPN-Verbindung normalerweise NUR der
Rechner ins FLI4L-Netzwerk bringen, der die VPN-Verbindung herstellt.
Selbst wenn am VPN-Client noch ein ganzes Netzwerk hängt, gibt es keine
einfache Methode, auch die anderen Rechner aus dem Netzwerk des
VPN-Clienten über die bestehende VPN-Verbindung ins FLI4L-Netzwerk zu
bringen. Die Optionen auf den Eigenschaftsseiten der VPN-Verbindung
unter "Gemeinsame Nutzung" sind mit Vorsicht zu geniessen, da dadurch
einfach die IP des Rechners geändert wird, was oft unangenehme
Konsequenzen hat.
Am einfachsten ist es daher, auf mehreren Clients im entfernten
Netzwerk eine VPN-Verbindung aufzubauen, anstatt zu versuchen, eine
Verbindung für alle zu benutzen.
Wer unbedingt IPX über VPN benutzen will, der kann am einfachsten auf
das Windows-Tool Gamers-Interent-Tunnel (GIT) von http://www.morpheussoftware.net/git/
verwenden, das dann auf einer Seite im FLI4L-Netzwerk und auf der
anderen Seite auf dem VPN-Client laufen muss. Unter Umständen kann man
damit sogar mit nur einer VPN-Verbindung eine IPX LAN-zu-LAN Verbindung
aufbauen, so das es reicht, wenn nur auf einem Rechner im entfernten
LAN der GIT läuft, um trotzdem dem ganzen entfernten LAN IPX
Verbindungen zu ermöglichen.
Schlusswort
Ich betreibe seit geraumer Zeit einen FLI-Router, mit dem ich sowohl
ein ganzes Netzwerk über OPT_CIPE dauerhaft mit einem anderen FLI
verbunden habe, als auch temporäre VPN-Verbindungen zu einzelnen Host
mit OPT_VPND zu meinem Netzwerk gewähre.
Diese Dokument unterliegt der GNU FDL und kann damit
im Rahmen dieser Bestimmungen weiterverbreitet und bearbeitet werden.
Anregungen zu diesem Dokument sowie neue Erkenntnisse im Zusammenhang
mit VPN-Verbindungen unter FLI4L nehme ich gerne entgegen.
Version 1.00, Februar 2004 - (C) 2004, Lutz Lisseck, lutz.lisseck bei
gmx.de
Klicken Sie hier, um
die Seite auszudrucken.
