15.12.2018 | 21:31 Uhr
 
Kommentieren       print
Tutorial Point-to-Point-VPN-Tunnel über OpenVPN
(für Windows und Linux anhand eines einfachen Beispiels by TM)

Seite 2:
Tutorial Bridged-OpenVPN-Tunnel mit PKI

Das graphisch dargestellte Beispiel bauen wir nachfolgend mit der freien OpenSource Software OpenVPN nach.

Beispiel eines VPN-Tunnels mittel OpenVPN

Sie wollen mit Ihrem Notebook (sicher) von ausserhalb (unsicher) auf Ihren heimischen Computer (sicher) über das Internet (unsicher) - z.B. per RDP oder VNC oder auf dessen Freigaben - zugreifen. Sie sind sozusagen ein klassischer IT-Nomade :-) Diese Übertragung würde jedoch ohne weitere Massnahmen unverschlüsselt erfolgen, d.h. es wäre prinzipiell möglich, die Daten unterwegs abzufangen (z.B. das Passwort zur Authentifizierung einer evtl. Remote-Verbindung oder beim Zugriff auf Freigaben). Deshalb entscheiden Sie sich für den Einsatz der kostenlosen Open-Source-Software OpenVPN, um eine sichere, verschlüsselte Verbindung aufzubauen.


1. Installation (Download): Für Windows gibt es eine Installationsroutine (.exe) und für Linux neben rpm’s auch distributionsabhängige Pakete (siehe z.B. apt-get unter Debian oder emerge unter Gentoo) oder man bedient sich “./configure make install” über den angebotenen Source-Tarball-Download. Unter Linux weist OpenVPN die Abhängigkeiten zu openssl-devel, lzo-devel und pam-devel auf, d.h. die Pakete sind davor zu installieren, sofern noch nicht vorhanden.

OpenVPN sollte unter Linux in das Verzeichnis /etc/openvpn/ installiert werden. Unter Windows installiert sich das Programm in C:\Programme\OpenVPN bzw. unter Vista und Windows 7 in C:\Program Files (x86)\OpenVPN , sofern nichts anderes vorgegeben wird.

Für Windows gibt es auch ein grafisches Interface (GUI), was hernach installiert werden kann, siehe Downloadseite.

2. Zur Authentification der beiden Computer verwenden wir die symmetrische Methode über einen statischen Schlüssel (Preshared Key), d.h. dieser muss auf dem VPN-Server wie -Client identisch vorhanden sein und möglichst sicher gespeichert werden (siehe dazu im weiteren Verlauf mehr). Zum Generieren geben wir ein:

Windows-Kommandozeile (Administrator):
openvpn --genkey --secret <Pfad_zum_Speicherort>static.key
In unserem Beispiel:
openvpn --genkey --secret C:\Programme\OpenVPN\config\static.key

Linux-root-Shell:
openvpn --genkey --secret <Pfad_zum_Speicherort>static.key
In unserem Beispiel:
openvpn --genkey --secret /etc/openvpn/static.key

Nun muss der static.key auch - über einen weiteren sicheren Weg - auf dem OpenVPN-Client „deponiert“ werden. Wir wählen im Beispiel die gleichen Verzeichnisse wie auf dem OpenVPN-Server:
Windows:
C:\Programme\OpenVPN\config\static.key
Linux:
/etc/openvpn/static.key

Zur Sicherheit des preshared static.key siehe auch den Punkt Gedanken zur Sicherheit weiter unten.

3. Anlegen der OpenVPN-Konfigurations-Dateien. Diese lauten “server” und “client” mit der Endung “.ovpn” (unter Windows) bzw. “.conf” (unter Linux) und weisen OpenVPN an, wie zu verfahren ist. Starten Sie einen Texteditor Ihrer Wahl und geben folgende Parameter ein oder laden das fertige Config.-File im Anschluss an die Beschreibung herunter:

3.1 server.conf | server.ovpn (zum obigen Beispiel):

# die lokale IP-Adresse des physikalischen Netzwerkadapters (nur bei mehreren aktiven Adaptern
# erforderlich), der verwendet werden soll, in unserem Bsp deaktiviert
# (zur Aktivierung Semikolon löschen):
;local 192.168.1.10

#Auf welchen TCP oder UDP Port soll der VPN-Server reagieren? Möchten Sie mehrere OpenVPN-Sessions
# auf derselben Machine betreiben, geben Sie für jede Session einen eigenen Port an. In unserem Beispiel:
port 5000

#Angabe des Transport-Protokolls (UDP oder TCP)
proto udp

#Angabe des Modus: Bridging (TAP-Device) oder Routing (TUN-Device)
dev tun

#Wer verbindet sich (virtuell) mit wem (die getunnelten IP-Adressen)? Zuerst die eigene IP,
#dann die des Client, in unserem Bsp.:
ifconfig 192.168.3.1 192.168.3.2

#Wo befindet sich der statische Schlüssel zum gegenseitigen (symmetrischen) Verschlüsselungs-
#Authentifizierungs-Verfahren <secretPfad_zum_Schlüsselstatic.key>.
#Unter Windows muss in der .ovpn-Datei für den Backslash ein doppelter Backslash
#für Pfade eingegeben werden (unter Windows 7 Pfade: zusätzlich mit Anführungszeichen einfassen!).
#In unserem Bsp.
#Windows:
secret C:\Programme\OpenVPN\config\static.key
#Linux:
secret /etc/openvpn/static.key

#Soll komprimiert werden? Wenn ja:
comp-lzo

#Welcher Verschlüsselungs-Algorithmus soll verwendet werden?
cipher AES-256-CBC

Download der fertigen, betriebsfertigen OpenVPN-Server-Konfigurations-Dateien wie beschrieben:


3.2 client.conf | client.ovpn (zum obigen Beispiel):

# die lokale IP-Adresse des physikalischen Netzwerkadapters (nur bei mehreren aktiven Adaptern
# erforderlich), der verwendet werden soll, z.B. hier deaktiviert (zur Aktivierung Semikolon löschen):
;local 192.168.2.5

#Die (Internet-)IP-Adresse (oder Host) und der Port des VPN-Servers.
# Eine statische Internet-IP-Adresse des Servers wäre hilfreich, ansonsten kann man sich z.B. über eine
# dynamische DNS-Auflösung helfen (z.B. über DynsDNS.org) und den Host angeben
# In unserem Bsp. ist die aktuelle (feste) Internet-IP 217.30.25.18 und es wird der
# Standard-UDP-Port 5000 vom Server verwendet:
remote 217.30.25.18 5000

#Port des Clients (z.B. port 1194). Wird nichts angeben, ist dies standardmässig 1194

#Angabe des Transport-Protokolls (UDP oder TCP) für die gewählten Ports:
proto udp

#Angabe des Modus: Bridging (TAP-Device) oder Routing (TUN-Device)
dev tun

#Wer verbindet sich (virtuell) mit wem (die getunnelten IP-Adressen)? Zuerst die eigene IP,
#dann die des Server
ifconfig 192.168.3.2 192.168.3.1

#Wo befindet sich der statische Schlüssel zum gegenseitigen (symmetrischen) Verschlüsselungs-
#Authentifizierungs-Verfahren <secretPfad_zum_Schlüsselstatic.key>.
#Unter Windows muss in der .ovpn-Datei für den Backslash ein doppelter Backslash
#für Pfade eingegeben werden (unter Windows 7: Pfade zusätzlich mit Anführungszeichen einfassen!).
#In unserem Bsp.
#Windows:
secret C:\Programme\OpenVPN\config\static.key
#Linux:
secret /etc/openvpn/static.key

#Soll komprimiert werden? Wenn ja:
comp-lzo

#Welcher Verschlüsselungs-Algorithmus soll verwendet werden?
cipher AES-256-CBC

Download der fertigen, (fast*) betriebsfertigen Open-VPN-Client-Konfigurations-Dateien wie beschrieben:
*Ersetzen Sie lediglich “mein-vpn-server” mit der (Internet-)IP-Adresse des OpenVPN-Servers

4. Öffnen des gewählten Ports auf NAT-Router des Zielnetzwerks (sog. Virtual Server o. Portforwarding):
Auf einem evtl. vorhandenen Router wäre der gewählte Port an die interne/lokale IP-Adresse weiterzuleiten. In unserem Fall wäre das der Standard-UDP-Port 5000 an 192.168.1.10

5. Anpassung einer evtl. vorhandener Firewall auf VPN-Server- und -Client-System sowie evtl. Router, siehe den Punkt Gedanken zur Sicherheit weiter unten.

6. Starten des OpenVPN-Servers:

  • Windows Über die Eingabeaufforderung (Administrator):
    openvpn Pfad_zur_server.ovpnserver.ovpn
    In unserem Beispiel:
    openvpn c:\Programme\OpenVPN\config\server.ovpn

    Linux über eine root-Shell:
    openvpn /etc/openvpn/server.conf
    In unserem Beispiel:
    openvpn /etc/openvpn/server.conf
     
  • Unter Windows gibt´s noch folgende Möglichkeiten:
    • Rechter Mausklick auf die server.ovpn und „Start ovenvpn on this config file”
    • Über die OpenVPN-GUI (sofern installiert): rechte Maustaste auf OpenVPN-GUI-Symbol im Systemtray und „Connect“ anklicken
    • als Systemdienst (startet ) manuell oder automatisch. ”Automatisch” hat u.a. den Vorteil, das Server-System über eine VPN-Verbindung neu starten zu können (da der Dienst unabhängig einer Benutzeranmeldung läuft, kann die VPN-Verbindung, auch nach einem Reboot des Server-Rechners/Systems, vom Client wieder aufgebaut werden).

7. Starten des OpenVPN-Clients:

  • Windows: Über die Eingabeaufforderung (Administrator):
    openvpn Pfad_zur_client.ovpnclient.ovpn
    In unserem Beispiel:
    openvpn C:\Programme\OpenVPN\config\client.ovpn

    Linux: Über den root-Shell-Befehl:
    openvpn pfad_zur_client.conf/client.conf
    In unserem Beispiel:
    openvpn /etc/openvpn/client.conf
     
  • Unter Windows gibt´s noch folgende Möglichkeiten:
    • Rechter Mausklick auf die server.ovpn und „Start ovenvpn on this config file”
    • Über die OpenVPN-GUI (sofern installiert): rechte Maustaste auf GUI-Symbol im Systemtray und „Connect“ anklicken

8. Testen der Verbindung:

Der OpenVPN-Server sollte diesen Status melden:
Peer Connection Initiated with
Initialization Sequence Completed

Der OpenVPN-Client sollte ebenfalls den Status connected melden.

Der Server oder Client kann nun zum Test angepingt werden (natürlich muss der Router und das OpenVPN-Server-System ICMP-Verkehr zulassen).

9. Starten von (Remote-)Diensten:
Jetzt ist es möglich, den Server sicher über das Internet fernzusteuern (z.B. per RDP, VNC) oder auf dessen Freigaben zuzugreifen (sofern die gewöhnlichen Berechtigungen hierzu vorhanden sind), indem als Zieladresse die virtuelle IP-Adresse angesprochen wird (ohne VPN-Tunnel müsste die physikalische Internet-IP des Routers, der den jeweiligen Port der Remotesoftware an den fernzusteuernden Remote-Server weiterleiten müsste, angegeben werden); in unserem Beispiel wäre das die 192.168.3.1

10. Beenden von OpenVPN:

Unter Windows genügt das Beenden der VPN-Anwendung oder Systemdienstes. Unter Linux muss der Prozess manuell gestoppt werden (z.B. über Befehl killall openvpn mit root-rechten, wenn man die Prozess-ID nicht kennt).


Gedanken zur Sicherheit:

  • Preshared Key:
        • Der gegenseitige einmalige Austausch des static.key muss auf einem dritten sicheren Weg erfolgen. Sind bei Einrichtung, der Server und Client nicht an einem Ort oder in gleichem sicheren Subnet, empfiehlt sich ein Austausch per verschlüsselter eMail(-Anlage). Bei Kompromittierung muss der Schlüssel (PSK) natürlich durch einen neuen ersetzt werden.
           
        • Die Aufbewahrung muss an einem sicheren Ort erfolgen. Unter Linux bietet sich an, die Benutzerrechte über den root-Befehl chmod auf den User zu begrenzen (Oktalzahl 600). Darüber hinaus sollte der PreShared-Key in einem verschlüsselten Container aufbewahrt werden, der nur zum Zwecke der VPN-Verbindung in das System eingebunden wird. Dazu kann man z.B. die OpenSource-Software TrueCrypt verwenden (siehe dazu unser ausführliches TrueCrypt-Tutorial)
           
        • Zur besseren Sicherheit kann die Authentifizierung (anstatt oder zusätzlich zum PreShared-Key) auch über die assymmetrische Methode erfolgen, d.h. es ist eine dritte Zertifizierungsstelle (Key-Server) mit im Spiel. Das Verfahren ist äquivalent zum asymmetrischem eMail-Verschlüsselungs-Verfahren (z.B. über PGP).
          Ferner kann zusätzlich noch die Eingabe eines Usernamens und Passworts gefordert werden.
           
  • Firewall VPN-Server:
        • Befindet sich auf dem Computersystem des OpenVPN-Servers eine Firewall (davon gehen wir aus!), wäre folgende Regel (IP-Tables) zu erstellen:

          Server-Regel 1 (für OpenVPN):
          IP/Host: wenn bekannt (bei statischer Internet-IP des Clients) einschränken
          Ports (in unserem Bsp.): Remote-UDP 1194 und Local-UDP 5000
          Direction: beides (Incoming/Outgoing)
          Mac-Adresse: Geräte-Nr. (Remote Mac des OpenVPN Client-Netzwerkadapters)
          evtl. noch auf die zugelassene Application “OpenVPN” einschränken

          *verfügt der Client/Anschluss über keine statische IP-Adresse, kann man sich z.B. über eine dynamische DNS-Auflösung helfen (z.B. über DynsDNS.org)

          Server-Regel 2 (für verschlüsselte Dienste):
          IP/Host (in unsrem Bsp.): 192.168.3.2 (Virtuelle IP des VPN-Client)
          Dienste-Ports* (in unserem Bsp. VNC): Remote-TCP 1024-65535 und Local-TCP 5900
          Direction: beides (Incoming/Outgoing)
          Mac-Adresse: Geräte-Nr. (Remote Mac des OpenVPN Client-Netzwerkadapters)
          evtl. noch auf die zugelassene Application (in unserem Bsp. “VNC” einschränken)

          *soll der VPN-Client auch auf die Freigaben zugreifen können, sind auch die entsprechenden lokalen Freigabe-Ports für die IP-Adresse des VPN-Clients (in unserem Fall
          192.168.3.2) zuzulassen.
           
  • Firewall VPN-Client:
        • Befindet sich auf dem Computersystem des OpenVPN-Clients eine Firewall (davon gehen wir aus!), wäre folgende Regel zu erstellen:

          Client-Regel 1 (für OpenVPN)
          IP/Host: wenn bekannt (bei statischer* Internet-IP des Servers) einschränken
          Ports (in unserem Bsp.): Remote-UDP 5000 und Local-UDP 1194
          Direction: ausgehend (Outgoing)
          Mac-Adresse: Geräte-Nr. (Remote Mac des OpenVPN-Server-Netzwerkadapters)
          evtl. noch auf die zugelassene Application “OpenVPN” einschränken

          *verfügt der Server/Anschluss über keine statische IP-Adresse, kann man sich z.B. über eine dynamische DNS-Auflösung helfen (z.B. über DynsDNS.org)

          Client-Regel 2 (für verschlüsselte Dienste):
          IP/Host (in unsrem Bsp.): 192.168.3.1 (Virtuelle IP des VPN-Server)
          Dienste-Ports* (in unserem Bsp. VNC): Remote-TCP 5900 und Local-TCP 1024-65535
          Direction: ausgehend (Outgoing)
          Mac-Adresse: Geräte-Nr. (Remote Mac des OpenVPN Server-Netzwerkadapters)
          evtl. noch auf die zugelassene Application (in unserem Bsp. “VNC” einschränken)

          *soll der VPN-Client auch auf die Freigaben des Servers zugreifen können, ist auch der Verkehr auf den entsprechenden Remote-Freigabe-Ports für die IP-Adresse des VPN-Servers (in unserem Fall 192.168.3.1) zuzulassen.
           
  • Firewall Router o.ä.:
        • Befindet sich auf dem Router (oder anderer Hardware-Lösung) des OpenVPN-Netzwerks (in welchem sich der VPN-Server befindet) eine Firewall, wären auch hier entsprechende Regeln - über das Portforwarding des Routers hinaus - einzutragen

           
  • Remote-Server oder andere Dienste:
        • ein Remote VNC- oder sonstiger RDP-Server (und natürlich auch jeder andere Dienst) kann jetzt auf das Subnet (oder die IP-Adresse des VPN-Client) der virtuellen, verschlüsselten Verbindung - anstatt jedermann - eingeschränkt werden. In unserem Beispiel könnte man einen VNC-Server so konfigurieren:
          Beispiel Einschränkung VNC-Server auf ein Subnet

Was hat man jetzt erreicht?

Die evtl. vorhandene Firewall auf dem Router weist ungültige VPN-Verbindungen ab. In zweiter Instanz macht dies die evtl. vorhandene Firewall auf dem OpenVPN-Server-System.

In dritter Instanz verarbeitet OpenVPN-Server, vom Router weitergeleitete, Anfragen von aussen - in unserem Fall auf UDP-Port 5000 - nur, wenn der verschlüsselte Pre-Shared-Key (static.key) der Verbindungsbeteiligten übereinstimmt, ansonsten wird das Paket fallen gelassen.

In vierter Instanz akzeptiert der Remote-Server (oder jede weitere Dienste) bzw. dessen vorgeschaltete Firewall (Anwendung Regel 2) nur Verbindungen aus dem vorgegebenen VPN-Subnet oder von einer bestimmten
(VPN-)IP-Adresse. In obigem Beispiel IP 192.168.3.2 aus virtuellem Subnet 192.168.3.0 mit Subnetmask 255.255.255.252 - d.h. wurden die vorherigen Hürden nicht genommen (VPN-Tunnel gescheitert), kann auch keine Remoteverbindung aufgebaut werden; nicht einmal aus dem eigenen physischen Subnet (im Bsp. 192.168.1.0).

Wer noch eins draufsetzen möchte:
Der “baut” OpenVPN noch in eine virtuelle Maschine - vielleicht noch in einem vollverschlüsselten (versteckten) Betriebssystem (siehe TrueCrypt-Tutorial) - ein. Dann wäre der lokalen Sicherheit mehr als genüge getan. Solange man selbst den Überblick behält, ist ja alles i.O. :-)


Tipp:
Zum lokalen Testen einer VPN-Verbindung eignen sich am besten zwei lokale Subnets. Beispielsweise ein getrenntes LAN (z.B. Subnet 192.168.1.0) vom WLAN (z.B. Subnet 192.168.2.0). Haben Sie keine Hardware-Ressourcen (zwei Router oder mehrere Rechner) hierfür, kann dies auch mit einem zusätzlichen virtualisierten System auf ein und demselben Computer geschehen.
Sie können dazu obige Beispiel-Konfigurationsdateien verwenden, ersetzen Sie lediglich in der client.(ovpn/conf) die Remote-Adresse mit der lokalen physikalischen IP-Adresse Ihres VPN-Server-Systems (in unserem Beispiel wäre das 192.168.1.10 anstatt der angenommenen Internet-IP 217.30.25.18):

Erstes physikalisches (sicheres) Subnet: z.B. 192.168.1.0 (Phys. Server-IP z.B.: 192.168.1.10)

Zweites physikalisches (unsicheres) Subnet: z.B. 192.168.2.0 (Phys. Client-IP z.B.: 192.168.2.5)
Zum Test ist dies auch ein heimisches Netzwerk. Später - bei Umsetzung obiger Beispielkonfiguration - gibt es gleich zwei unsichere Netzwerke, zum einen das lokale Netzwerk, in welchem sich der Client befindet (z.B. im Hotel, beim Geschäftspartner, auf der LAN-Party...) und zum anderen das Internet (Routing über viele unbekannte Server), über welches letztendlich die Übertragung zum sicheren Netzwerk erfolgt.

Drittes virtuelles Subnet (sicher verschlüsselt/getunnelt):
z.B. 192.168.3.0 (Virtuelle Server-IP z.B. 192.168.3.1 | Virtuelle Client-IP z.B. 192.168.3.2)
Dient dazu, die beiden physikalischen Subnets sicher zu verbinden (im Bsp. die IP 192.168.2.5 aus dem unsicheren Subnet mit 192.168.1.10 aus dem sicheren Subnet)


Seite 2: Tutorial Bridged-OpenVPN-Tunnel mit PKI

Kommentieren