Zu
Hause die selben Netzlaufwerke nutzen wie auf der Arbeit ?
Mit OpenVPN gibt es eine Lösung, die sich z.B. für Schulserver recht gut einrichten lässt und einen sicheren Zugang von außen bietet.
Mit OpenVPN lässt sich ein anderer Zugang zum Server einrichten, anders als mit den bekannteren Lösungen mittels ssh (putty) und sftp (WinSCP). In einem Bild: es wird ein gesicherter Tunnel durch das unsichere Gelände des Internets gelegt. Oder sprachlich etwas genauer: „Bezeichnung für vertrauliche, gegen unerwünschte Zuhörer oder Eindringlinge abgesicherte Vernetzung über das ungesicherte Internet".
Ein großer Vorteil: die Arbeitsweise muss dabei
nicht umgestellt werden. Programme öffnen Dateien normal über den Arbeitsplatz
/ Explorer / XY-Commander. Gespeichert wird auf ein Laufwerk, auch wenn sich
dies weit entfernt befindet. Z.B. wird in Office eine Datei in T:\ geöffnet und
auch dort abgespeichert, also direkt auf dem Server. Es ist kein Umweg
über einen Browser nötig.
Für die Clients auf Windows-PC gibt es ein Programm, das mit einem Klick auf "Connect" alles startet, was benötigt wird (siehe Abb. rechts); nur ein Passwort muss der Nutzer zu Hause noch eingeben. So können mit OpenVPN auch Menschen arbeiten, die keine Freaks sind. Alternativ dazu kann OpenVPN als Windows-Dienst (Systemsteuerung/Verwaltung/Dienste) automatisch gestartet werden; damit ist es etwas einfacher, als Nutzer mit eingeschränkten Rechten eine Verbindung herzustellen.
Soll OpenVPN für ein kleines Netzwerk auf einem Windows-Rechner als Server laufen hilft vielleicht ein Artikel der Zeitschrift c't weiter.
Sehr grob lässt sich die Vorgehensweise in 4 Schritte unterteilen:
# Installation der Programme (falls notwendig)
Normalerweise wird mit TUN-Devices gearbeitet; damit können z.B. Sambafreigaben des entfernten Servers (z.B. "T:\") gut eingebunden werden. Möchte man dagegen OpenVPN auch zur Fernwartung einsetzen, muss es als Bridge arbeiten und dazu TAP-Devices verwenden. (vgl. c't 7/2006 S.112)
# Anpassung der config-Dateien für Server und Client
# Anfertigung der Schlüssel und Zertifikate
# Feinheiten
== Kontrolle bei möglichen Schwierigkeiten ==
Die Hinweise unten beziehen sich serverseitig auf einen Arktur-Schulserver.
Das TUN/TAP-Modul muss geladen sein. „lsmod|grep tun" muss als Antwort etwa „tun 9344 0" ergeben. Oder „ifconfig" zeigt etwa
tun0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
inet addr:10.8.0.1 P-t-P:10.8.0.2 Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1
RX packets:92550 errors:0 dropped:0 overruns:0 frame:0
TX packets:51517 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:120893147 (115.2 MiB) TX bytes:4067445 (3.8 MiB)
Sonst mit „modprobe tun" versuchen, dieses Modul zu laden.
Auf der Client-Seite darf nicht derselbe Adressbereich wie auf dem Server zum Einsatz kommen: "192.168.178.0" auf dem Client und "192.168.0.0" auf dem Server würde also funktionieren.
Auf den Clients kann eine Firewall blockieren. Z.B. hat ZoneAlarm nicht nachgefragt, dafür aber blockiert. Sowohl die beiden Programme „openvpn.exe" und „openvpn-gui.exe" müssen freigegeben werden als auch evtl. die Sicherheitszone reduziert werden (unsichtbar funktionierte bei ZoneAlarm nicht).
Sowohl auf dem Server wie auf dem Client muss in der log-Datei ein "Initialization Sequence Completed" stehen!!! Sonst gibt es dort Hinweise, an welchen Stellen es hakt.
In der Datei "client.ovpn" muss entsprechend "dev tun" oder "dev tap" verwendet werden; TUN- und TAP-Modus vertragen sich nicht.
Der Befehl „openvpn" hat folgende Optionen
openvpn {start|stop|restart|condrestart|reload|reopen|status}
Das jeweilige Ergebnis sollte in openvpn.log angezeigt werden und mit einem "Initialization Sequence Completed" enden, dann ist alles ok.
Ist ein „ping" vom Server zum Client und umgekehrt möglich? Also z.B. „ping 10.8.0.1" zum Server hin... (10.8.0.1 muss evtl. an die eigene Server-Adresse angepasst werden)
Ein "net view \\10.8.0.1" sollte die Freigaben des Servers anzeigen.
/etc/samba/smb.conf entsprechend
http://openvpn.net/howto.html#samba überprüfen; evtl. muss Samba neu gestartet werden. Das hat manchmal geholfen, wenn "ping" bereits funktionierte, aber keine Verbindung mit Netzfreigaben erfolgte.
Werden auf einem Windows-Client alle Internet-Verbindungen langsamer sollte, in Systemsteuerung / Netzwerkverbindungen die LAN-Verbindung für VPN (TAP-Win 32-Adapter) kontrolliert werden: Eigenschaften / TCP/IP / Erweitert: dort muss "Standardgateway für Remotenetzwerk verwenden" deaktiviert sein.