Mit OpenVPN bleiben Sie zumindest virtuell immer zu Hause: Sie kommunizieren auch von unterwegs abhörsicher und angriffsgeschützt mit den Rechnern im heimischen LAN, als wären Sie dort.

Im Hotel die Mails checken, aus dem Internetcafé aufs heimische LAN zugreifen, im Ausland Daten aus dem Firmennetzwerk abrufen – das alles zählt heute zum Alltag. Doch wer in fremden Netzen unterwegs ist, sollte keinesfalls darauf vertrauen, dass seine Daten schon nicht in die falschen Hände fallen. Neugierige Behörden, kopierfreudige Geschäftspartner oder fiese Identitätsdiebe gelüstet es nach fremden Informationen. Virtuelle private Netzwerke (VPNs) machen derartigen Zeitgenossen das Leben schwer. Die freie VPN-Lösung OpenVPN [1] lässt sich leicht einrichten und unkompliziert benutzen.

OpenVPN

OpenVPN wurde erstmals 2001 von James Yonan vorgestellt, die erste stabile Version erschien 2002. Momentan liegt OpenVPN in der Version 2.2.1 vor. Im Vergleich zu anderen VPN-Lösungen bietet OpenVPN viele Vorteile: Die modular aufgebaute Software läuft im Userspace und basiert auf dem Universal-TUN/TAP-Treiber [2] und OpenSSL [3]. OpenVPN unterstützt Firewalls und Proxies, erlaubt im Servermodus mehrere Clients auf einem Port und kann Protokolle der OSI-Schichten 2 und 3 tunneln.

Wo viel Licht ist, gibt es freilich auch auch Schatten: OpenVPN ist inkompatibel zu den weitverbreiteten IPSec-VPNs und nicht in Form einer Hardware-Lösung zu haben. Das bedeutet, dass OpenVPN einen laufenden Rechner erfordert. Im Test diente ein Sheevaplug als OpenVPN-Server, aber auch Router mit OpenWRT oder einem Media-Server lassen sich mit OpenVPN bestücken.

Mittels OpenVPN setzen Sie schnell ein eigens virtuelles privates Netzwerk auf, das allen Sicherheitsanforderungen gerecht wird. Es unterstützt verschlüsselte Datenübertragung ebenso wie eine auf dem Public-Key-Verfahren basierende Authentifizierung. Sowohl Verschlüsselung als auch Authentifizierung nutzen die OpenSSL-Bibliothek, die es für jedes gängige Betriebssystem gibt. Die VPN-Teilnehmer verfügen im Idealfall über einen privaten und einen öffentlichen Schlüssel – letzterer liegt im folgenden Beispiel in Form eines Zertifikats vor.

Signiert ein Teilnehmer eine Nachricht mit seinem geheimen Schlüssel, lässt sich der öffentliche Schlüssel zur Prüfung der Signatur heranziehen. So prüfen Sie, ob ein Netzwerkteilnehmer wirklich derjenige ist, für den er sich ausgibt. Für die Datenübertragung verzichtet OpenVPN auf asymmetrische Verschlüsselung und setzt stattdessen auf einen starken symmetrischen Schlüssel.

OpenVPN verwendet Zertifikate, um die Identität eines Netzteilnehmers zu prüfen. Das bedeutet, dass eine vertrauenswürdige Zertifizierungsstelle – in unserem Fall Sie als Betreiber des OpenVPN-Servers – einen Schlüssel zertifiziert und so dessen Echtheit bestätigt. Bei einer Verbindungsanfrage prüft OpenVPN die Zertifikate und akzeptiert nur bei positivem Ergebnis die Anfragen.

Zertifikate lassen sich auch gezielt widerrufen. Fällt beispielsweise ein Gerät mit gültigem Zertifikat einer nicht berechtigten Person in die Hände, unterbinden Sie auf diesem Weg schnell den Zugriff.

OpenVPN einrichten

OpenVPN lässt sich wahlweise so einrichten, dass sich Clients via IP oder via Ethernet mit einem entfernten Netz verbinden. Geräte, die sich auf IP-Ebene verbinden, nutzen das TUN-Device und befinden sich in einem eigenen Subnetz, das es über Routing-Einträge mit anderen Netzen zu verbinden gilt.

Ethernet arbeitet auf der OSI-Schicht 2, ist einfacher zu konfigurieren und genügt für die meisten privaten Anforderungen. Bei Ethernet-Verbindungen erhält das TAP-Device eine virtuelle IP-Adresse. Clients können so unkompliziert mittels Masquerading oder Bridging auf alle anderen Maschinen zugreifen, die sich im Netz befinden. Allerdings skaliert dieses Verfahren etwas schlechter als der IP-Modus, das der komplette Netzwerkverkehr übertragen wird. Dafür können Sie sich von außen über fast jedes Protokoll schnell mit ihrem Heimnetzwerk verbinden, ohne sich den Kopf über das Routing zerbrechen zu müssen.

Da heutzutage die meisten Nutzer mehrere mobile Geräte verwenden und alle Familienmitglieder unterwegs sicheren Zugriff auf das Heimnetzwerk erhalten sollen, bietet sich das Public-Key-Verfahren an. OpenSSL enthält alles, was Sie brauchen, um als Zertifizierungsstelle (Certificate Authority, CA) zu fungieren. Dank der Zertifikate lassen sich neue Road-Warriors ohne viel Aufwand dem Netz hinzufügen. Als Road-Warriors bezeichnet man Clients, die von außen via VPN auf das heimische Netz zugreifen.

CA einrichten

Einzelne Schlüssel lassen sich zwar separat signieren, müssen dann in der Praxis aber jedem Client bekannt gemacht werden. Vor allem, wenn Sie mehrere Serverdienste via SSL anbieten und viele Clients bedienen möchten, lohnt sich eine eigene Zertifizierungsstelle: Die Clients müssen dann nur noch das CA-Zertifikat kennen, um alle Zertifikate dieser Stelle zu akzeptieren. Sie sollten die Zertifizierungsstelle aus Sicherheitsgründen keinesfalls auf dem selben Rechner betreiben, der als VPN-Server dient. Listing 1 enthält alle Befehle, um die Struktur einer eigenen CA im Home-Verzeichnis des Nutzers einzurichten, der die CA betreibt.

#! /bin/bash
mkdir /home/User/Meine_CA
cd /home/User/Meine_CA
cp /etc/[ssl/]openssl.cnf ./ca.cnf
mkdir certs crls newcerts
mkdir -m700 private
touch index.txt
echo 01 > serial
echo 01 > crlnumber

Die index.txt dient später als Datenbank für neue und gesperrte Zertifikate. Die Dateien serial und crlnumber nehmen die zu Zertifikaten gehörigen Seriennummern und Sperrlisten auf. Nach dem Erstellen der Grundstruktur müssen Sie noch einige Sektionen der ca.cnf anpassen (Listing 2). Anschließend generiert der Befehl

$ openssl req -config ./ca.cnf -new -x509 -newkey rsa:2048 -days 3650 -keyout private/ca.key -out ca.crt

einen 2048 Bit langen privaten Schlüssel der CA und ein Stammzertifikat, das zehn Jahre gilt (Abbildung 1). Der Befehl

$ openssl x509 -in ./ca.crt -noout -text

gibt das frisch erstellte Zertifikat aus. Nur der Erzeuger sollte es lesen können, wofür der Befehl chmod 600 ca.crt sorgt. Mit

$ openssl dhparam -out dh1024.pem 1024

legen Sie noch der Diffie-Hellman-Parameter für den temporären Schlüsselaustausch an. Nun können Sie das Stammzertifikat auf jeden Rechner in das Verzeichnis /etc/openvpn/certs/ übertragen; die Datei dh1024.pem benötigen Sie nur auf dem OpenVPN-Server.

[ CA_default ]
dir         = /home/User/Meine_CA
certificate = $dir/ca.crt
private_key = $dir/private/ca.key
...
[ req_distinguished_name ]
countryName_default         = DE
stateOrProvinceName_default = Bundesland
localityName_default        = Ortschaft
organizationName_default    = Organisation
commonName_default          = CA
emailAddress_default        = email@adresse.de

Abbildung 1: Mit OpenSSL erstellen Nutzer Schlüssel, Certificate Signing Requests und signierte Zertifikate.

Zertifikate erstellen

Sobald das Stammzertifikat existiert, können Sie Schlüssel und Zertifikate für den Server sowie die einzelnen Clients erstellen. Der Ablauf dabei ähnelt dem Erstellen des Stammzertifikats. Mit dem Befehl aus Zeile 1 von Listing 3 erstellen Sie einen 1024 Bit langen Schlüssel sowie einen Certificate Signing Request (CSR) für ein Zertifikat, dass ein Jahr lang gültig bleibt.

Der Parameter -nodes verhindert, dass eine Passphrase verlangt wird. So lässt sich das Zertifikat später nutzen, ohne jedesmal ein Passwort angeben zu müssen. Der Gewinn an Komfort geht mit einer Abnahme der Sicherheit einher: So kann jeder das Zertifikat einsetzen, solange Sie es nicht widerrufen.

Bei den Zertifikaten für Server und Clients sollten Sie eigene Common Names und Organizational Unit Names vergeben (siehe Listing 2), um die Bezeichnungen innerhalb einer Organisationseinheit unterscheiden zu können. Bei den Common Names verzichten Sie tunlichst auf Leer- und Sonderzeichen. Es bietet sich an, die Hostnames der verwendetet Endgeräte zu nutzen, die innerhalb eines Netzwerks in der Regel eindeutig ausfallen.

Die fertigen Zertifikats-Anträge unterschreiben und beglaubigen Sie zu guter Letzt als CA, was der Befehl aus Zeile 2 von Listing 3 erledigt. Der Rechner verlangt bei diesem Schritt nach der Passphrase der CA. Nach deren Eingabe wird das Zertifikat erstellt, im Verzeichnis newcerts mit der Datei 01.pem eine Kopie angelegt, ein Eintrag in die Datenbank index.txt getätigt und die Nummer in serial hochgezählt.

Anschließend müssen Sie noch Schlüssel und Zertifikat sicher auf den Zielrechner übertragen, wofür sich im heimischen Netzwerk Scp anbietet (Listing 3, Zeile 3 und 4).

$ openssl req -config ./ca.cnf -new -nodes -newkey rsa:1024 -keyout private/OpenVPN_Server.key -out OpenVPN_Server.csr -days 365
$ openssl ca -config ./ca.cnf -in OpenVPN_Server.csr -out certs/OpenVPN_Server.crt -notext
$ scp private/OpenVPN_Server.key root@IP_Zielrechner:/etc/openvpn/private/
$ scp certs/OpenVPN_Server.crt root@IP_Zielrechner:/etc/openvpn/certs/

OpenVPN einrichten

OpenVPN ermöglicht mehrere Verbindungsarten. Bei den Punkt-zu-Punkt-Verbindungen (P2P) unterscheidet man zwischen den Betriebsarten Gateway-zu-Gateway (G2G) oder Client-zu-Gateway (C2G). Bei P2P-Verbindungen kann sich allerdings immer nur ein Client am Gateway anmelden.

Sie möchten jedoch sicherlich, dass sich an Ihrem VPN-Server mehrere Clients gleichzeitig anmelden dürfen – kein Problem für OpenVPN, das grundsätzlich Hunderte paralleler Verbindungen erlaubt. Dazu brauchen Sie eine Multi-Client-Verbindung. Bei diesen unterscheidet man zwischen den Varianten Client-zu-Netzwerk (C2N) und Netzwerk-zu-Netzwerk (N2N).

Um OpenVPN sowohl auf dem Server als auch auf den Clients komfortabel zu starten, bietet sich der Einsatz eigener Konfigurationsdateien für die jeweiligen Verbindungen an. Alternativ könnten Sie OpenVPN die einzelnen Parameter beim Start auch direkt übergeben, was sich in der Praxis aber zu aufwändig erweist. Listing 4 zeigt eine Beispielkonfiguration für den Server.

# OpenVPN-Config für Server
server 192.168.100.0 255.255.255.0
proto udp
port 1194
dev tap
ca /etc/openvpn/certs/ca.crt
cert /etc/openvpn/certs/OpenVPN_Server.crt
key /etc/openvpn/private/OpenVPN_Server.key
dh /etc/openvpn/dh1024.pem
persist-key
persist-tun
keepalive 10 60
push "route 192.168.10.0 255.255.255.0"
user nobody
group nogroup
daemon
log-append /var/log/openvpn.log
verb 3

Diese sieht vor, dass OpenVPN im Server-Modus startet und alle Rechner im VPN im Netz 192.168.100.0/24 liegen. Der OpenVPN-Server erhält die virtuelle IP-Adresse 192.168.100.1, die Clients bekommen höhere Adressen zugewiesen. Der Server erzeugt ein TAP-Device erzeugt und lauscht am OpenVPN-Standardport 1194 auf Verbindungen über das Protokoll UDP. Weiterhin finden sich in der Konfigurationsdatei die Pfade zu den Zertifikaten und dem Diffie-Hellman-Parameter.

Die Parameter persist-key und persist-tun sorgen für einen problemlosen Restart, push route zeigt den Clients den Weg ins heimische Netz 192.168.10.0/24 hinter dem OpenVPN-Server. Die Anweisung daemon schickt den OpenVPN-Prozess in den Hintergrund, wichtige Ereignisse protokolliert der Server in der Datei /var/log/openvpn.log. Was genau OpenVPN ins Log schreibt, stellen Sie über verb ein (siehe Tabelle “Verbose-Level”).

Schließlich finden sich in der Konfiguration die Anweisung, OpenVPN mit den Rechten des Nutzers nobody und der Gruppe nogroup auszuführen. Das erhöht die Hürde für Angreifer, falls es diesen einmal gelänge, den Prozess zu kapern.

Die Konfigurationsdatei für die Clients gestaltet sich deutlich einfacher als die für den Server. Ein Beispiel zeigt Listing 5. Der Schalter remote gibt an, wie sich der Server erreichen lässt. Im Beispiel nutzt er eine DynDNS-Adresse, wie sie sich bei den meisten Routern für Heimnetzwerke einrichten lässt.

#OpenVPN-Konfig für Client
client
proto udp
remote OpenVPN_Server.dyndns.org
port 1194
dev tap
nobind
ca   /etc/openvpn/certs/ca.crt
cert /etc/openvpn/certs/Client.crt
key /etc/openvpn/private/Client.key
daemon
log-append /var/log/openvpn.log
verb 3

Damit die Road-Warriors den OpenVPN-Server hinter dem heimischen Router auch erreichen, müssen Sie dort noch den Port 1194 für UDP (in unserem Beispiel), TCP oder beide Protokolle freigeben.

Auf dem Server wie auf dem Client verwenden Sie zum Starten von OpenVPN den Befehl

# openvpn --config /Pfad/zur/Conf-Datei.conf

Anschließend sollte ifconfig auf dem Client ein TAP-Device mit einer Adresse aus dem vorgegebenen IP-Bereich (siehe Listing 4) anzeigen und sich die Rechner im VPN anpingen lassen.

Einige Distributionen – darunter auch Debian – bringen ein Startskript mit, das je eine OpenVPN-Instanz für alle in /etc/openvpn/ verfügbaren Conf-Dateien startet. Dieses Verhalten passen Sie in der Datei /etc/default/openvpn an.

Um den Zugriff auf das hinter dem VPN-Server liegende Netzwerk zu ermöglichen, sind noch IP-Forwarding und eine Firewall-Regel nötig. Beides erledigen Sie auf dem Server mit den beiden Befehlen aus Listing 6. Die Einstellungen gehen bei einem Neustart allerdings verloren. Um die Befehle nicht jedes Mal neu eingeben zu müssen, tragen Sie sie in die Startskripte ein, beispielsweise in /etc/rc.local.

# sysctl -w net.ipv4.ip_forward=1
# iptables -t nat -I POSTROUTING -o eth0 -s 192.168.100.0/24 -j MASQUERADE

OpenVPN absichern

Läuft soweit alles (Abbildung 2), können Sie sich daran machen, das VPN weiter abzusichern. OpenVPN bietet dazu mehrere Methoden an: So lässt sich beispielsweise mit der Direktive tls-auth ein Hash-basierender Message Authentication Code (HMAC) einsetzen, um Anfragen an den VPN-Server zu authentifizieren und diesen vor DoS-Attacken zu schützen.

Abbildung 2: Sitzt, wackelt, hat Luft: Nach der erfolgreichen Konfiguration greifen die Clients auf den VPN-Server und über diesen transparent auf die Rechner im lokalen Netz zu.

Dazu kommt ein symmetrisches Schlüsselverfahren zum Einsatz, bei dem Client und Server beim Verbindungsaufbau ihre jeweiligen Schlüssel verifizieren. Schlägt die Überprüfung fehl, wird die Verbindung abgelehnt. Den TLS-Auth-Key erzeugen Sie mit dem Befehl

$ openvpn --genkey --secret ta.key

und kopieren ihn anschließend auf den Server und die Clients ins Verzeichnis /etc/openvpn/. Anschließend ergänzen Sie die OpenVPN-Konfiguration auf dem Server um die Zeile tls-auth /etc/openvpn/ta.key 0, auf dem Client fügen Sie die Zeile tls-auth /etc/openvpn/ta.key 1 ein.

OpenVPN nutzt standardmäßig einen 128 Bit langen, symmetrischen Blowfish-Schlüssel, um die Kommunikation zu chiffrieren. Für die meisten Fälle sollte das genügen. Möchten Sie eine stärkere Verschlüsselung einsetzen, geben Sie dazu das gewünschte Verfahren in der Konfiguration an. Sie können hier jeden Algorithmus verwenden, den OpenSSL unterstützt. Eine Auflistung aller verfügbaren Möglichkeiten liefert der Befehl openvpn --show-ciphers auf der Kommandozeile.

Um einen 256-Bit-AES einzusetzen, fügen Sie beispielsweise in den Conf-Dateien auf Server und Client jeweils die Zeile cipher AES-256-CBC hinzu. Je aufwändiger die Verschlüsselung, desto mehr Rechenzeit benötigen Server und Client. Mit dem Befehl openssl speed -evp Verfahren ermitteln Sie vorab, welche Datenmenge OpenSSL abhängig von der Paketgröße innerhalb einer Sekunde verarbeiten kann.

Die Certificate Revocation List (CRL) dient zum Widerrufen von Zertifikaten. OpenVPN lässt sich dahingehend konfigurieren, bei einer Verbindungsanfrage die zum Client gehörigen Zertifikate auf Gültigkeit zu überprüfen. Um ein Zertifikat zu widerrufen, tragen Sie es in die CRL ein und sperren es nach deren Generieren. Anschließend übermitteln Sie die CRL an den VPN-Server sowie alle VPN-Teilnehmer.

Um ein Zertifikat zu widerrufen, wechseln Sie ins CA-Verzeichnis (im Beispiel Meine_CA) und rufen dort die drei Befehle aus Listing 7 auf. Um OpenSSL anzuweisen, die CRL zu verwenden, genügt die Zeile:

# crl-verify /etc/openvpn/crls/crl.pem

Steht die Anweisung in der Konfigurationsdatei und ist keine CRL vorhanden, weigert sich OpenVPN auf dem Server zu starten. Dem helfen Sie mittels einer leeren CRL ab, die Sie auf den Server kopieren.

# openssl ca -config ./ca.cnf -revoke certs/Zertifikatsname.crt
# openssl ca -config ./ca.cnf -gencrl -out crls/crl.pem
# scp crl/crl.pem root@IP-Zielrechner:/etc/openvpn/crls/

Kontakt zwischen Clients

Die obige Konfiguration ermöglicht es mehreren Clients gleichzeitig, sich mit dem Heimnetzwerk zu verbinden. Anwender, die mit mehreren mobilen Geräten unterwegs sind oder mit anderen VPN-Teilnehmern direkt Dateien austauschen wollen, wünschen sich eventuell eine Kommunikation ohne Umwege über den Rechner im heimischen Netz. Auch hier kann OpenVPN helfen: Um andere Clients zu kontaktieren, erweitern Sie die OpenVPN_Server.conf um den Befehl client-to-client.

Datenpakete an einen anderen VPN-Teilnehmer werden auch jetzt von einem Client an den Server geschickt und dort entschlüsselt. Sobald der Server aber erkennt, dass die Pakete für einen anderen Client bestimmt sind, verschlüsselt er sie erneut und leitet sie weiter. Auf dem Antwortweg funktioniert das sinngemäß gleich.

Kommunizieren zahlreiche Clients gleichzeitig auf diesem Weg, bekommt der OpenVPN-Server allerdings alle Hände voll zu tun. Falls Sie die Client-to-Client-Funktionalität also nicht brauchen, sollten Sie zugunsten der Performance darauf verzichten.

Kompression und Traffic Shaping

OpenVPN erlaubt es, Daten komprimiert zu übertragen und so den Datendurchsatz spürbar zu erhöhen. Diese Kompression sollten Sie standardmäßig aktivieren. Dazu fügen Sie in die Konfigurationsdateien des Servers und der Clients die Zeile comp-lzo yes ein.

Als weitere leistungssteigernde Maßnahme können Sie Traffic Shaping einsetzen und, falls gar nichts anderes mehr hilft, die Anzahl der Clients begrenzen. Beides ist nur sinnvoll, wenn der OpenVPN-Server auf einer schwachbrüstigen Maschine läuft oder nur ein langsamer DSL-Upload-Stream zur Verfügung steht sowie die Gefahr besteht, dass sich alle Mitglieder einer Großfamilie mit allen Geräten gleichzeitig anmelden.

In diesem Fall tragen Sie in der Server-Konfiguration die beiden Zeilen max-clients 10 und push "shaper 100000" ein. Dadurch dürfen sich nur noch zehn Clients gleichzeitig anmelden, wobei jeder davon auf eine maximale Datentransferrate von rund 100 KByte/s beschränkt bleibt.

Fazit

In der Praxis zeigt sich immer wieder, dass es durchaus sinnvoll ist, sich ein SSH-Hintertürchen zum OpenVPN-Server offen zu halten. Es gibt mitunter interessant konfigurierte Netze, die beispielsweise alle UDP-Pakete verwerfen. In solch einem Fall lässt sich OpenVPN in wenigen Sekunden auf das TCP-Protokoll umstellen, sofern man denn noch Zugriff auf die Konfigurationsdatei hat. Es ist auch möglich, mehrere Server auf einem Gerät zu betreiben und auf den Clients entsprechende Konfigurationen mitzuführen.

OpenVPN präsentiert sich als leistungsfähige VPN-Lösung, deren einziger Nachteil darin besteht, dass sie auf einem ständig verfügbaren Rechner laufen muss. Betreiben Sie aber in Ihrem Netz ohnehin ein entsprechendes Gerät, etwa einen ständig laufender Server oder ein Router mit OpenWRT, findet OpenVPN darauf noch problemlos Platz. OpenVPN kooperiert mit vielen Betriebssystemen und lässt sich erfreulich leicht konfigurieren. Zudem bietet es Lösungen für so gut wie jedes VPN-Einsatzszenario – ein Blick in die Dokumentation lohnt auf jeden Fall.