OpenVPN konfigurieren: Client-to-Site und Site-to-Site (Linux-Server u. Windows-Client)

Unter Virtual Private Network (VPN) versteht man im Allgemeinen eine verschlüsselte Verbindung zwischen zwei entfernten Standorten oder Netzwerken. Über diese Verbindung – auch Tunnel genannt – wird auf die am entfernten Standort verfügbaren IT-Dienste zugegriffen oder es wird die gesamte Verbindung zum Internet (z.B. Zugriff auf Web-Seiten) über den entfernten Standort umgeleitet. Dabei wird zwischen verschiedenen Arten von VPN unterschieden:

  • meist kostenpflichtige Angebote von Dienstanbietern zur Anonymisierung (z.B. Steganos, CyberGhost, HideMyAss, …)
  • VPN-Verbindungen in Unternehmen, um Mitarbeiter von außen oder unterwegs in das Firmennetzwerk zu integrieren. Bei dem Unternehmes-VPN wird zusätzlich noch zwischen Client-To-Site und Site-To-Site VPN unterschieden. Client-To-Site würde bedeuten, dass die VPN-Gegenstelle sich im Gerät des Benutzers (PC, Laptop, Smartphone) befindet und die Verbindung eher temporär ist. Bei Site-To-Site wird die VPN-Verbindung zwischen zwei fest installierten Geräten (z.B. VPN-Router) dauerhaft aufgebaut. Die Benutzer benötigen keine Tools auf ihren Geräten und bemerken von dem VPN nichts.

In dieser Anleitung wird die Konfiguration eines Unternehmens-VPN (Client-To-Site und Site-To-Site) mit der freien/kostenlosen Software OpenVPN beschrieben. Es gibt auch kostenpflichtige Angebote von dem Unternehmen OpenVPN, diese sind jedoch hier nicht Thema.

OpenVPN ist in verschiedenen Linux-Distributionen in den Standard-Repositories enthalten. Aber auch für Windows – insbesondere für Windows 10 – gibt es von OpenVPN Installer-Binaries ( Community Downloads ). In dieser Anleitung wird OpenVPN unter Debian Linux 9 installiert, die beschriebene Konfiguration ist jedoch unabhängig vom Betriebssystem. Prinzipiell gibt es bei OpenVPN immer einen Client und einen Server. Der Client baut die Verbindung zum Server auf. Bei der Installation von Client und Server gibt es keinen Unterschied – das OpenVPN-Programm unterscheidet anhand des Konfigurationsfiles, ob es Client oder Server ist. Der Server benötigt eine von außen erreichbare feste IP-Adresse (oder einen DynDNS-Dienst, falls die IP dynamisch vergeben wird).

Es gibt auch OpenVPN-Software für mobile Geräte (z.B. Android). Wer jedoch einen festen OpenVPN-Server oder Client (für eine Aussenstelle) aufbauen möchte, kann z.B. einen ganz normalen Linux-Server oder einen Open Source Firmware Router (z.B. WRT) einsetzen. Prinzipiell lässt sich auch ein Raspberry Pi verwenden.

Ausgangspunkt ist das Szenario einer OpenVPN-Verbindung von einem Client zu einem Server und (nur !) die damit verbundene Anbindung Server-eigenen Dienste (Teil II). Es ist also eine etwas eingeschränkte Version von Client-To-Site. Dann wird das Szenario schrittweise erweitert, so dass zunächst das gesamte Server-/Firmen-Netzwerk erreichbar ist (Teil III) und später auch das Netzwerk des OpenVPN-Clients/der Aussenstelle Teil des VPNs ist (Teil IV). Dieses finale Szenario könnte man dann als echtes Site-To-Site VPN bezeichnen.

Installation unter Debian 9 (Server) und Windows 10 (Client)

Unter Debian 9 kann OpenVPN mit dem Befehl

# apt-get install openvpn

installiert werden, sowohl auf dem Server als auch auf dem Client. Im folgenden gehen wir jedoch von einem Windows-Client aus. Das Installer-Binary für den Windows 10 – Client befindet sich unter dem folgendem Link: https://openvpn.net/community-downloads/ (Windows 10 Installer). Der Windows-Installer zeigt am Ende der Installation die Meldung „Installation Complete“ an.

Teil I: Erzeugung der Schlüssel

OpenVPN verwendet SSL/TLS für die sichere Kommunikation. Dafür müssen eigene Schlüssel erzeugt werden, welche dann Teil einer sogenannten Public Key Infrastructure (PKI) sind.

Welche Schlüssel kommen in OpenVPN zum Einsatz?
OpenVPN verwendet eine asymmetrische Verschlüsselung, also verschiedene Schlüssel zum ver- und entschlüsseln. Verschlüsselt wird mit dem öffentlichen Schlüssel, entschlüsselt mit dem privaten Schlüssel. Client und Server besitzen also jeweils ein Schlüsselpaar. Neben Server und Client gibt es auch noch eine Zertifizierungsstelle/ Certificate Authority (CA), die auch ein Schlüsselpaar besitzt. Diese Stelle bzw. deren Schlüssel werden benötigt, damit Client und Server den von der Gegenstelle empfangenen öffentlichen Schlüssel überprüfen können (Integrität und Authentizität). Hierbei kommt eine von der Zertifizierungsstelle erzeugte Signatur zum Einsatz. Diese Signatur ist im Prinzip eine Verschlüsselung (diesmal mit dem privaten Schlüssel) des Hash-Wertes des zu signierenden Zertifikats von Client oder Server. Das signierte Zertifikat kann später dann mittels des öffentlichen Schlüssels der Zertifizierungsstelle überprüft werden. Die öffentlichen Schlüssel werden im Folgenden nur noch als Zertifikat bezeichnet.

Im Folgenden wird die Erzeugung der benötigten Schlüssel schrittweise besprochen. Die Schlüssel werden alle auf dem OpenVPN Server erzeugt. Möglich wäre auch, hierfür einen weiteren/anderen Server zu verwenden.

Schritt 1 (Vorbereitung): Zum Erzeugen der Schlüssel werden bestimmte Skripte benötigt. Diese werden mit dem Paket easy-rsa ausgeliefert, das zusammen mit OpenVPN auf dem Server schon installiert ist. Auf dem Server geben wir noch den folgenden Befehl ein, um diese Skripte in das angegebene Verzeichnis zu kopieren:

# make-cadir /etc/openvpn/easy-rsa

Jetzt befinden sich die Skripte für die Schlüsselerzeugung im Verzeichnis /etc/openvpn/easy-rsa.

Schritt 2 (Schlüssel für Zertifizierungsstelle erzeugen)

Wir wechseln in das Verzeichnis mit den Skripten:

# cd /etc/openvpn/easy-rsa

Dort gibt es eine Datei mit dem Namen vars, die bestimmte Umgebungsvariablen für die Erzeugung des CA-Zertifikats setzt. Um diese Datei erfolgreich einlesen zu können, erzeugen wir folgenden Softlink:

# ln -s openssl-1.0.0.cnf openssl.cnf

Nun lesen wir die Datei vars ein und führen danach das Skript clean-all aus. clean-all löscht bereits vorhandene Zertifikate und erzeugt das Verzeichnis /etc/openvpn/easy-rsa/keys :

# source ./vars

# ./clean-all

Man erhält die Meldung „Note: If you run ./clean-all, I will be doing a rm -rf on /etc/openvpn/easy-rsa/keys“. Jetzt erzeugen wir die Schlüssel der Zertifizierungsstelle:

# ./build-ca

Bei Rückfragen des Skripts wählen Sie die Default-Werte. Nur auf die Frage des Common Name sollte ein beliebiger, sinnvoller Name gewählt werden, z.B. OpenVPN-CA (welche Rolle spielt der???). Als Ergebnis erhalten wir die beiden Dateien ca.cert und ca.key in dem Verzeichnis /etc/openvpn/easy-rsa/keys.

Schritt 3 (Schlüssel f. Server):

Nun erzeugen wir die Schlüssel für den Server:

#. /build-key-server   server

Der angefügte Name „server“ gibt den Dateinamen für die Schlüssel an. Bei Rückfragen wählen wir wieder die Default-Werte. Auf die Frage nach dem Common Name wählen wir wieder einen sinnvollen Namen, z.B. OpenVPN-Server. Ein Name ist hier wieder obligatorisch. (es kann auch der Domain-Name des Servers oder der DynDNS-Name hier gewählt werden. Darüber wird später auf den Server zugegriffen ???) Die Fragen „Sign Certificate“ und „…commit“ sind mit Ja zu beantworten. 

Im Verzeichnis /etc/openvpn/easy-rsa/keys befinden sich nun (u.a.) die Dateien server.crt und server.key.

Schritt 4 (Schlüssel f. Client):

Nun erzeugen wir die Schlüssel für den Client oder für mehrere Clients:

./build-key client

./build-key client2

client und client2 geben hier wieder den Dateinamen der Schlüssel vor. Bei der Frage nach dem Common Name bitte wieder einen sinnvollen Namen wählen, z.B. den Default-Namen client oder client2. Die Fragen „Sign the Certificate“ und „…commit“ werden wieder mit Yes beantwortet. Natürlich können hier auch für weitere clients Schlüssel erzeugt werden (z.B. für client3, client4 usw.). Alternativ zu dem Befehl build-key kann auch build-key-pass verwendet werden. In diesem Fall würde der Schlüssel mit einem Passwort geschützt werden, das bei Verwendung des privaten Keys einzugeben ist.

Schritt 5: Dieffie-Hellman-Parameter

In diesem Schritt werden bestimmte Parameter erzeugt, die der Server benötigt:

# ./build-dh

Die Erzeugung kann mehrere Minuten dauern. Ergebnis ist die Datei dh2048.pem im Verzeichnis /etc/openvpn/easy-rsa/keys.

Was sind Diffie-Hellman-Parameter?
hier kommt noch eine Erklärung für Interessierte

Schritt 6: Kopieren der Schlüssel

In diesem Schritt kopieren wir die Schlüssel und Parameter in die vorgesehenen Verzeichnisse. Auf dem Server kopieren wir die folgenden Dateien vom Verzeichnis /etc/openvpn/easy-rsa/keys/ nach /etc/openvpn/:

  • die Schlüssel der CA ca.crt und ca.key
  • die Schlüssel des Servers server.crt und server.key
  • Die Datei für die Diffie-Hellman-Parameter dh2048.pem

Vom Server kopieren wir die folgenden Schlüssel vom Verzeichnis /etc/openvpn/easy-rsa/keys/ zu dem jeweiligen Client:

  • den öffentlichen Schlüssel der CA ca.crt
  • die beiden Client-Schlüssel client.crt und client.key
  • gleichermaßen weitere Client-Schlüssel, falls vorhanden

Bei einem Windows-Client ist das Zielverzeichnis c:\programme\openvpn\config. Um Dateien vom Server zum Windows-Client zu kopieren, bietet sich das Programm WinSCP an. Allerdings müssen bestimmte Berechtigungen vorhanden sein, die über folgenden „Umweg“ gelöst werden können:

  • Kopieren Sie die Schlüssel auf dem Server zunächst in ein User-Home-Verzeichnis, auf das Sie SSH-Zugriff haben (mit Befehl cp). Setzten Sie dort die Rechte so, dass der entsprechende User die Schlüssel lesen kann (chmod u+r DATEINAME).
  • Kopieren Sie dann die Schlüssel mittels WinSCP (Protokoll SFTP) von dem obigen User-Home-Verzeichnis zunächst in ein beliebiges Windows-Verzeichnis, das Sie neu anlegen, z.B. auf den Desktop in das Verzeichnis keys.
  • Um nun die Schlüssel in das Verzeichnis c:\programme\openvpn\config kopieren zu können, benötigen Sie Administrator-Rechte. Starten Sie dafür den Explorer mit Admin-Rechten:
    • Explorer aufrufen mit Windows + E
    • Wechseln Sie in c:\Windows
    • explorer.exe als Administrator starten (rechte Maustaste)
  • Nun können Sie die Schlüssel mit dem privilegierten Explorer vom Desktop in das Verzeichnis c:\programme\openvpn\config kopieren.

Teil II: Konfiguration von Server und Client

Szenario Client-To-Server: OpenVPN-Server mit einem oder mehreren (mobilen) Clients.

In diesem Teil konfigurieren wir das Szenario Client-To-Server, bei dem OpenVPN-Clients sich mit dem OpenVPN-Server verbinden und auf Dienste zugreifen, die genau auf diesem Server (zusätzlich) vorhanden sind. Dazu passen wir die von OpenVPN gegebenen Beispiel-Konfigurationen für Server und Client für unser Szenario an.

Schritt 1: Kopieren der Beispielkonfigurationen

In diesem Schritt kopieren wir die Beispielkonfigurationen für Server und Client in die jeweiligen Konfigurationsverzeichnisse. Für den Server:

# cp /usr/share/doc/openvpn/examples/sample-config-files/server.conf.gz   /etc/openvpn

# cd /etc/openvpn

# gunzip server.conf.gz

Auf dem Windows-Client:

In Windows haben die Konfigurationsdateien andere Endungen. Die Dateinamen sind dort server.ovpn und client.ovpn. Wir kopieren mit dem Explorer die Beispielkonfiguration für den Client:

  • c:\Programme\OpenVPN\sample-config\client.ovpn nach
  • c:\Programme\OpenVPN\config

Schritt 2: Anpassen Konfigurationsdateien

In diesem Schritt passen wir die Konfigurationsdateien an:

  • In der Konfigurationsdatei für Server und Client kommentieren Sie jeweils die Zeile mit ta.key aus.
  • In der Client-Konfigurationsdatei passen Sie die remote-Direktive an. Dort müssen die IP oder Domain des OpenVPN-Servers und der OpenVPN-Port stehen (Meldung: Incomplete last line????) : remote DOMAIN-OPENVPN-SERVER PORTNUMMER
  • Ggf. müssen auch die Pfade oder die Namen für die Schlüssel in beiden Konfigurationsdateien angepasst oder eingetragen werden.

Schritt 3: Erster Test

Nun starten wir OpenVPN auf Server:

# openvpn server.conf

Der Windows-Client muss als Administrator gestartet werden. Dann kann über das Icon in der Taskleiste die Verbindung aufgebaut werden (rechte Maustaste).

Nun testen wir die Verbindung mit ping vom Client aus:

# ping 10.8.0.1

Falls der Verbindungsaufbau nicht klappt, lässt sich das log-File des Clients in c:\benutzer\USERNAME\OpenVPN\log\client.log untersuchen.

Befindet sich der Server hinter einem NAT-Router oder einer Firewall, so ist ein UDP-Port-Forward einzurichten. Dabei sollte der Router an der Schnittstelle zum Internet auf dem Port 1194 lauschen und die empfangenen Pakete an den internen VPN-Server weiter leiten.

Ein weiterer möglicher Test leitet die Verbindung Ihres Internet-Browsers über den Tunnel um. Installieren Sie dafür auf dem Server den Web-Proxy squid (#apt-get install squid). Nach der Installation lauscht der Proxy sofort auf dem Server auf Port 3128. Es müssen allerdings noch Berechtigungen in squid konfiguriert werden. Ein bestimmtes Netz schalten Sie beispielsweise in /etc/squid/squid.conf frei, indem Sie folgende Zeilen auskommentieren:

acl localnet src 10.0.0.0/8 # RFC1918 possible internal network

http_access allow localnet

Starten Sie squid anschließend neu:

# systemctl restart squid

Stellen Sie auf Ihrem Browser einen Proxy ein mit der IP des Tunneleinganges und dem Port 3128. Testen Sie z.B. mit https://whatismyipaddress.com ,ob Sie nun mit einer anderen IP im Netz unterwegs sind.

Teil III: Zugriff auf das gesamte Firmennetz (Client to Site)

Szenario Client-To-Site. Die Clients können nun auf die im Firmennetz angebotenen Dienste zugreifen.

Bisher konnten wir über den OpenVPN-Tunnel nur auf Dienste zugreifen, die der OpenVPN-Server selber anbietet. Soll auf andere Server im Firmennetzwerk zugegriffen werden, so ist eine Anpassung der Konfiguration des Servers notwendig, und in der Regel sind auch auf dem Firmenrouter statische Routen für den Rückweg der Pakete notwendig.

Schritt 1:

Auf dem Server im File server.conf ist die folgende Zeile notwendig bzw. auszukommentieren und anzupassen, wobei hier auf der Server-Seite die Netzwerk-Adresse 192.168.20.0/24 angenommen wird. Diese ist gemäß der eigenen Gegebenheiten zu ändern:

push „route 192.168.20.0 255.255.255.0“  (Anführungszeichen beide oben bitte)

Dadurch wird ein bestimmtes Netz auf der Serverseite bzw. die Information, dass dieses nun auch erreichbar ist, zum OpenVPN-Client gesendet.

Schritt 2:

Außerdem ist IP-Forwarding auf dem Server zu aktivieren. Dies erfolgt durch folgenden Eintrag in der Datei /etc/sysctl.conf:

net.ipv4.ip_forward=1

Danach diese Änderung einlesen mit dem Befehl #sysctl -p. Überprüft werden kann das mittels dem Befehl „cat /proc/sys/net/ipv4/ip_forward“, der als Ergebnis 1 liefern sollte.

Schritt 3:

Auf dem Firmenrouter ist außerdem die folgende statischen Route einzustellen. Vorausgesetzt wird hier das Firmennetz 192.168.20.0/24 und die IP-Adresse des OpenVPN-Servers mit 192.168.20.2:

  • Zielnetz: 10.8.0.0 / 24
  • Gateway: 192.168.20.2

Diese statische Route sorgt dafür, dass die Antwort-Pakete, die als Ziel-Adresse eine virtuelle IP des Tunnels haben, zurück zum Tunneleingang (auf Serverseite) gelangen.

Teil IV: Einbinden des Client-Netzwerkes (Site to Site VPN)

Szenario Site-To-Site. Es gibt nun eine OpenVPN-Client-Seite, und alle Geräte in dem Client-Netzwerk können nun auch auf das VPN bzw. auf die Dienste im entfernten Standort zugreifen. Natürlich können auch weiterhin mobile Clients vom Internet aus auf die Firmendienste zugreifen.

In der bisherigen Konfiguration kann ein Client auf alle Geräte im Firmennetzwerk zugreifen. Das ist wie in der Einführung gesagt ein Client-to-Site – VPN. Dieses Setup wird in diesem Abschnitt zu einem Site-to-Site VPN erweitert, indem die Geräte, die sich im Client-Netzwerk befinden, nun auch auf das VPN Zugriff erhalten. Dieses Szenario kann also 2 unterschiedliche Standorte miteinander verbinden, so dass von beiden Standorten aus auf das jeweils entfernte Netzwerk zugegriffen werden kann. Nach wie vor gibt es auf einem Standort den VPN-Server, auf dem anderen den VPN-Client. Für ein echtes Site-to-Site sollte auch der VPN-Client fest installiert sein oder dauerhaft laufen.

Schritt 1: IP-Forwarding auf dem OpenVPN-Client

Ähnlich wie auf dem Server, so ist nun auch auf dem Client IP-Forwarding zu aktivieren. Das sorgt dafür, dass der Client als Gateway für das entfernte Netzwerk dienen kann. Folgender Eintrag wird dafür in der Datei /etc/sysctl.conf eingefügt:

net.ipv4.ip_forward=1

Danach diese Einstellung einlesen mit dem Befehl # sysctl -p

Schritt 2: Routing auf dem Server

Auf dem Server wird in der Konfigurationsdatei /etc/openvpn/server.conf eine zusätzliche Zeile eingetragen, die die Netzwerkadresse des Clients enthält. Im folgenden Beispiel wird davon ausgegangen, dass der Client sich im Netzwerk 172.30.0.0/24 befindet:

route 172.30.0.0 255.255.255.0

Pakete an das Netz 172.30.0.0/24 gelangen dadurch vom Kernel des Servers (über das Tunnel-Interface) zu OpenVPN.

Schritt 3: Client Config Dir (ccd) -Verzeichnis auf dem Server

Auf dem Server erzeugen wir ein Verzeichnis /etc/openvpn/ccd. Files in diesem Verzeichnis ermöglichen eine Konfiguration, die spezifisch für bestimmte Clients gültig sein soll. Das Mapping zwischen Client und File erfolgt über den im Client-Zertifikat angegebenen Common Name (CN) und dem Filenamen. In diesem Verzeichnis erstellen wir ein File mit dem Dateinamen client, das für unser Beispiel folgende Zeile enthält:

iroute 172.30.0.0 255.255.255.0

Die iroute-Direktive teilt OpenVPN auf dem Server mit, dass Pakete für das angegebene Zielnetz über den Tunnel an den entsprechenden Client übertragen werden sollen.

Schritt 4: Statische Routen

Auf beiden Standorten sind nun auf den jeweiligen Routern statische Routen zu konfigurieren, damit die IP-Pakete auch zurück geroutet werden. Auf der Client-Seite für unser Beispiel:

  • Zielnetz: 192.168.20.0 / 24 (Netzwerk des OpenVPN-Servers)
  • Gateway: 172.30.0.2 (IP des OpenVPN-Clients)

Auf der Server Seite für unser Beispiel:

  • Zielnetz: 172.30.0.0 / 24 (Netzwerk des OpenVPN-Clients)
  • Gateway: 192.168.20.2 (IP des OpenVPN-Servers)

Schritt 5 (optional): Routen zwischen verschiedenen Clients (client-to-client)

Wenn verschiedene Clients mit dem VPN verbunden sind, so können auch diese miteinander verbunden werden bzw. das Routing zwischen den Clients aktiviert werden. Für ein bestimmtes Client-Netzwerk wird dies auf dem Server in der server.conf eingestellt.

für die betreffenden Clients – also die Clients, die mit dem einen, bestimmten Client-Netzwerk kommunizieren wollen –  in der ccd (s. Teil IV, Schritt 3) eingestellt. Siehe auch Kommentar von Tobelger unterhalb des Artikels.

Der Server gibt dadurch das angegebene Client-Netzwerk allen anderen verbundenen Clients bekannt:

client-to-client

push „route 172.30.0.0 255.255.255.0“ (Anführungszeichen beide oben bitte)

Für das obige Beispiel würde diese Erweiterung allerdings nur Sinn machen, wenn noch eine weitere Aussenstelle zum Szenario hinzugefügt wird. Dann könnten auch die Aussenstellen miteinander über das VPN kommunizieren.

Teil V: Sonstiges

Soll der OpenVPN-Dienst beim Systemstart des Servers bereits aktiviert werden, so kann dies mit systemctl eingestellt werden:

# systemctl enable openvpn

(Für einen Linux-Client würde das genauso funktionieren.) Für unseren Windows-Client lässt sich der Dienst über die GUI von OpenVPN unter Einstellungen aktivieren.

Quellen:

OpenVPN-HowTo: https://openvpn.net/community-resources/how-to/

your text here
Dieser Beitrag wurde unter Allgemein veröffentlicht. Setze ein Lesezeichen auf den Permalink.

2 Gedanken zu „OpenVPN konfigurieren: Client-to-Site und Site-to-Site (Linux-Server u. Windows-Client)

  1. Hi, bezogen auf Schritt 5 Push-Befehl:

    [push „route 172.30.0.0 255.255.255.0“ (Anführungszeichen beide oben bitte)]

    Dieser führt doch auch dazu, dass der Client „Client“ die Route zugewiesen bekommt und somit seine Internen Pakete nicht mehr routet sondern immer an den VPN-Server schickt. Wenn als Client nun ein OpenWrt Router dient, wäre dieser zb nichtmehr über die LAN-IP 172.30.0.1 erreichbar, da Pakete immer nur zwischen Server und Client jeweils umgeleitet werden würden.
    Um dem abzuhelfen wäre es sinnvoll dieses Push-Befehl in die ccd-files zu packen.

    Beste Grüße
    Tobias

    • Stephan Rein sagt:

      Das stimmt. Ich habe es eben auch ausprobiert. Der betreffende VPN-Client war bei diesem Push-Befehl nicht mehr erreichbar, somit funktioniert für das betreffende Client-Netzwerk auch das VPN nicht mehr, weil der VPN-Client ja als Gateway dafür dient. Ich habe in der Anleitung einen Hinweis auf Ihren Kommentar hinzugefügt.

Hinterlasse eine Antwort

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

Du kannst diese HTML Tags und Attribute benutzen:

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>