Workshop: SSL-VPN auf Linux – Mit »OpenVPN« erhalten Anwender eine VPN-Implementierung auf Basis von SSL. Das System ist leicht zu konfigurieren und läuft auf allen relevanten Betriebssystemen.

Virtual-Private-Networks (VPN) auf Basis von SSL (Secure-Socket-Layer) laufen den etablierten VPN-Verfahren allmählich den Rang ab. Verständlicherweise, denn SSL-VPNs kennen keine Probleme mit NAT (Network-Adress-Translation) und verschlüsseln Ende-zu-Ende, statt am Gateway zu terminieren. Dies macht SSL-VPNs wie das quelloffene Open-VPN nicht nur für die Sicherung von VoIP-Gesprächen zunehmend attraktiv. Auch Smartcards unterstützt das System, wodurch es sich nahtlos in ein IAM-Konzept (Identity- und Access-Management) einbinden lässt. Das Marktforschungsinstitut IDC prognostiziert demnach bis 2009 Umsatzzuwächse von 35 Prozent bei SSL-VPNs, während der VPN-Gesamtmarkt lediglich um 5 Prozent wachsen werde.

Als großen Vorteil gegenüber anderen VPN-Produkten kann eine SSL-VPN-Lösung für sich beanspruchen, keine Probleme mit NAT respektive dynamischen IP-Adressen zu haben. Open-VPN ist zudem nicht auf Linux als Plattform beschränkt. Auch Solaris, die BSD-Varianten, Mac OS X sowie Windows 2000/XP/2003 lassen sich als Open-VPN-Server oder -Client einsetzen. Für Windows oder Mac OS X steht ein grafischer Client zur Verfügung, der sich bereits nach kurzer Einführung bedienen lässt. Windows-Anwender bemerken den Client als Icon im Systemtray. Die Kommunikation mit Windows erfolgt über die TAP-Win32-Schnittstelle. Somit bekommt der Verwalter eine flexible Lösung, die sich unternehmensweit etablieren lässt.

Wer allerdings eine Hardware-Appliance als Tunnel-Endpunkt einsetzt, dürfte darin nur selten SSL/TLS-Unterstützung haben. Somit lässt sich auf der anderen Seite, etwa einer Außenstelle, Open-VPN nicht einsetzen, da die Software nicht mit IPsec-, PPTP- oder L2TP-Verfahren zusammenarbeitet.

Virtual-Private-Networks sind eigentlich dazu gedacht, komplette Netzwerke an verschiedenen Standorten über das Internet zu verbinden. Die Computer in den lokalen Netzwerken (LANs) sind mit privaten IP-Adressen konfiguriert, die Internet-Router nicht weiterleiten. Was für einzelnen Netzwerke sehr angenehm ist, kann beim Zusammenschluss mehrerer LANs über ein VPN zum Problem werden, wenn die Netzwerke dieselben IP-Blöcke benutzen. Bevor der Administrator Open-VPN konfiguriert, müssen die beteiligten Netzwerke auf solche Konflikte abgeklopft werden.

Das Open-VPN-Howto auf http://openvpn.net/howto.html empfiehlt daher, auf Subnetze in selten benutzte Blöcke wie 10.0.0.0/8 zurückzugreifen. Der Verwalter umgeht damit Konflikte mit den häufig eingesetzten Blöcken 192.168.0.0/24 und 172.16.0.0/12 bereits von vornherein. Auch Benutzer, die sich von WLAN-Hotspots oder anderen öffentlichen Zugangsknoten im VPN einloggen, bekommen keine Probleme mit den dortigen Subnetzen, die meist eine Adresse aus 192.168.0.0/24 einsetzen.

PKI ist Voraussetzung
Ein wesentlicher Baustein der verschlüsselten Kommunikation in einem VPN sind digitale Zertifikate, mit denen sich eine Public-Key-Infrastruktur (PKI) bauen lässt. Open-VPN 2.0 unterstützt die bidirektionale Authentifizierung, bei der Server und Client das jeweilige Zertifikat des anderen erst bestätigen müssen, bevor sich der Tunnel etabliert. Dazu benötigt das Unternehmen eine Certificate-Authority (CA), die ein Master-Zertifikat ausstellt, und einen Schlüssel, mit dem sich die Server- und Client-Zertifikate signieren lassen. Diese Zertifikate entsprechen dem öffentlichen Schlüssel (Public-Key). Dazu kommt noch ein privater Schlüssel (Private-Key) für den Server und alle Clients.

Die Authentifizierung verläuft dann nach folgendem Schema: Server und Client authentifizieren sich gegenseitig, indem sie prüfen, ob die Certificate-Authority das jeweilige Zertifikat signiert hat. Anschließend testen beide Seiten, ob die Informationen im Zertifikat-Header wie beispielsweise der Zertifikat-Typ zusammenpassen.

Vorteil dieses Verfahrens ist, dass der Server lediglich sein eigenes Zertifikat benötigt statt zusätzlich jedes einzelne Zertifikat der Clients, die sich eventuell verbinden.

Wichtiger ist, dass der Server nur solchen Clients die Verbindung erlaubt, deren Zertifikate von der CA signiert wurden. Das ist ein großer Sicherheitsgewinn, denn der Server benötigt für die Prüfung keinen Zugriff auf den privaten Schlüssel der CA. Dieser muss sich nicht einmal auf der VPN-Maschine befinden, wodurch das sensibelste Teil der PKI in Sicherheit ist.

Auch wenn ein privater Schlüssel kompromittiert ist, zeigt dieses Verfahren Stärke. Das Zertifikat lässt sich ganz einfach deaktivieren, indem es der Administrator auf einer Rückrufliste (Certificate-Revocation-List) platziert. Dadurch muss der Server nur das betreffende Zertifikat zurückweisen, statt der Verwalter die gesamte Public-Key-Infrastruktur neu aufbauen.

Die CA lässt sich auf verschiedenen Betriebssystemen unterschiedlich anlegen. Für Linux steht das Paket »OpenSSL« (www.openssl.org) zur Verfügung, das den Verwalter mit zahlreichen Skripten bei der Konfiguration unterstützt. Windows-2003-Server baut die CA sowie das Stammzertifikat während der Installation auf. Gleiches gilt für Linux-Distributionen, die auf den Enterprise-Markt abzielen wie RHES oder SLES.

Server konfigurieren
Benutzen Sie die mitgelieferten Beispieldateien, haben Sie eine recht unkomplizierte Konfiguration vor sich. Die Beispiele befinden sich im Verzeichnis »/etc/openvpn/sample-config-files«. Die Konfigurationsdateien heißen konsequenterweise »server.conf« (Listing 1, siehe nächste Spalte) und »client.conf« (Listing 2, Seite 52).

Zuerst konfiguriert der Administrator den Server. Dieser soll am UDP-Port 1194 auf Verbindungswünsche warten und aus dem virtuellen Subnetz 10.8.0.0/24 Adressen an die VPN-Clients verteilen.

Für die effizientere Verbindung per Routing sorgt das virtuelle TUN-Interface (dev tun). Es stellt User-Space-Programmen wie Open-VPN die zwei Schnittstellen »/dev/tunX« (Character-Device) und »tunX« (virtuelles Punkt-zu-Punkt-Gerät) zur Verfügung. Das TUN/TAP-Device ist als optionaler Treiber im Kernel enthalten und liegt auf den meisten Distributionen als Modul vor.

Bevor Sie »server.conf« produktiv einsetzen können, passen Sie die Pfade zum Root-Zertifikat an, dem Server-Zertifikat »cert«, dem Server-Schlüssel »key« sowie den DH-Parametern »dh« an. Zudem sollten Sie die Direktiven »user nobody« und »group nobody« benutzen. Damit mappt der VPN-Server jeden Benutzer auf die Pseudo-User »nobody« mit der UID 65534 respektive jede Gruppe auf »nobody« mit GID 65534. Dadurch verliert Benutzer »root« seine Privilegien.

Listing 1: /etc/server.conf
# OpenVPN 2.0 server.conf
# Explizites Setzen des Server-Ports

port 1194

# UDP als Transportprotokoll

proto udp

# Routing-Modus mit /dev/tun

dev tun

# Name und Pfad der Zertifikate/Schlüssel-Dateien
ca /etc/openvpn/easy-rsa/keys/ca.crt
cert /etc/openvpn/easy-rsa/keys/server.crt
key /etc/openvpn/easy-rsa/keys/server.key

# Schlüssellänge des Diffie-Hellman: 1024
dh /etc/openvpn/easy-rsa/keys/dh1024.pem

# VPN-Subnetz für Clients; Server benutzt 10.8.0.1

server 10.8.0.0 255.255.255.0

# Zuordnung von Client-IP-Adressen zu
# VPN-Adressen in ipp.txt führen.
# Wichtig für Re-Connects.

ifconfig-pool-persist ipp.txt

# In ccd liegen Client-spezifische Konfigurationen

client-config-dir ccd

# Route zum Subnetz hinter dem Client setzen für
# Multi-Client-Zugriff
route 192.168.40.128 255.255.255.248

# Ein Ping-ähnlicher Mechanismus prüft alle 10
# Sekunden, ob die Gegenseite noch da ist. Nach # 120 Sekunden gilt die Verbindung als getrennt.

keepalive 10 120

# Clients im selben Subnet können auch andere
# Clients sehen

client-to-client

# Kompression benutzen

comp-lzo

# Anonyme Benutzer/Gruppe nobody mit
# UID/GID 65534

user nobodygroup nobody

# Bei unerwartetem Verlust der Verbindung:
# Schlüssel behalten und Interface nicht
# herunterfahren.

persist-keypersist-tun

# Protokolliere alle momentanen Verbindungen

status openvpn-status.log

# Meldungen an Syslog mit Verbose-Level 3

verb 3

Client konfigurieren
Die Konfiguration des Clients ist mit noch weniger Aufwand verbunden. Passen Sie in »/etc/openvpn/client.conf« ebenfalls die Pfade bei »ca«, »cert« und »key« an. Denken Sie daran, dass jeder Client ein eigenes Zertifikat-/Schlüssel-Paar benötigt. Ein vorher angelegtes Zertifikat lässt sich nicht auf andere Maschinen übertragen. Lediglich das Root-CA-Zertifikat »ca« ist im gesamten Open-VPN gültig.

Füllen Sie anschließend die »remote«-Anweisung mit der IP-Adresse und Port-Nummer des Open-VPN-Servers aus. Sofern der VPN-Server keine statische öffentliche IP-Adresse besitzt respektive hinter einer Firewall oder einem NAT-Gateway steht, gehen Sie so vor: Tragen Sie die Adresse des NAT-Gateways ein und leiten Sie den Port »1194/udp« zum dahinter stehenden VPN-Server (Forwarding).

Bekommt das NAT-Gateway die IP-Adresse dynamisch zugewiesen, wie das häufig in kleinen Büros oder im privaten Netzwerk der Fall ist, greifen Sie am besten auf die Dienste eines DynDNS-Providers zurück. Dieser synchronisiert die momentane öffentliche IP-Adresse beispielsweise mit dem Host »gateway.dyndns.net« und trägt diesen temporär in einen DNS-Record ein. So lässt sich das Gateway immer über »gateway.dyndns.net« erreichen, obwohl sich die IP-Adresse bei jeder Einwahl beim Provider ändert. Dann benutzen Sie wieder das Forwarding, um den VPN-Server anzubinden.

Zum Schluss prüfen Sie, ob sich die Einträge in client.conf« mit denen der Server-Konfiguration decken. Besonders wichtig sind das Device tun« sowie das Transportprotokoll UDP.

Listing 2: /etc/client.conf
# OpenVPN 2.0 client.conf
# Die Maschine ist Client

client

# UDP als Transportprotokoll

proto udp

# Routing-Modus mit /dev/tun

dev tun

# IP-Adresse oder FQDN des Open-VPN-Servers
# sowie Port 1194

remote gateway.dyndns.net 1194

# Unendlich versuchen, den Hostnamen des
# Servers zu ermitteln. Hilfreich bei nur temporär # mit dem Internet verbundenen Rechnern.

resolv-retry infinite

# Keine Bindung an lokale Portnummer

nobind

# Anonyme Benutzer/Gruppe nobody mit
# UID/GID 65534

user nobodygroup nobody

# Bei unerwartetem Verlust der Verbindung:
# Schlüssel behalten und Interface nicht
# herunterfahren.

persist-keypersist-tun

# Name und Aufenthaltsort der Zertifikate/
# Schlüssel-Dateien
ca /etc/openvpn/easy-rsa/keys/ca.crt
cert /etc/openvpn/easy-rsa/keys/client.crt
key /etc/openvpn/easy-rsa/keys/client.key

# Kompression benutzen

comp-lzo

# Meldungen an Syslog mit Verbose-Level 3
verb 3

Zugriff auf Server im VPN-Subnetz
Mit dem Zugriff auf den Open-VPN-Server dürften sich nur die wenigsten Anwender zufrieden geben. Schließlich will der Benutzer Daten von Fileservern oder Datenbanken einsehen oder auf den Client transferieren. Hierzu muss der VPN-Server die Clients auf Hosts im Subnetzwerk umleiten und den Zugriff kontrollieren.

Im Routing-Modus mit »/dev/tun« lässt sich der Server so konfigurieren, dass er die Route zu seinem lokalen Netzwerk den Clients bekannt macht. Dazu ist die Direktive »push« vorgesehen:
push "route 10.99.0.0 255.255.255.0"

Anschließend setzt der Verwalter einen Router auf dem LAN-Gateway, um die Clients aus 10.8.0.0 zum Open-VPN-Server zu leiten.

Um die Konfiguration zu komplettieren, sollen auch mehrere Clients aus einem entfernten Subnetz Zugriff auf die Server hinter dem Open-VPN-Server bekommen. Das folgende Szenario routet alle Clients im LAN 192.168.4.0/24 über das lokale VPN-Gateway zum entfernten VPN-Server. Hier ist vorher wieder besonders darauf zu achten, dass das Client-LAN eine Netzwerkadresse hat, die im restlichen Unternehmen nicht mehr vorkommt.

Jeder Client muss zudem mit einem einzigartigen Common-Name im Zertifikat aufgeführt sein, damit er eindeutig zu identifizieren ist. Der zweite Client benutzt ein Zertifikat mit dem Common-Name »client2«.

Zuerst verweist der Administrator in »server.conf« auf ein Client-Konfigurations- Verzeichnis, indem sich weitere Anweisungen befinden. In diesem Fall steht darin nur die Route zum Server. Open-VPN legt mit »ccd« dazu gleich ein Beispielverzeichnis unter »/etc/openvpn« an. Auf dieses referenzieren Sie mit client-config-dir ccd

Verbindet sich ein Client zum Open-VPN-Server, prüft der Server-Daemon, ob eine Datei existiert, die den Common-Name des Clients enthält. Findet der Daemon so eine Datei, sucht er darin nach weiteren Anweisungen. Der Administrator kann somit eine besondere Konfiguration für Gruppen anlegen, beispielsweise für Außendienst- oder Telearbeiter.

Auch einzelne Clients wie »client2« lassen sich speziell konfigurieren.

Für den Client »client2« legt der Administrator folglich die Datei »client2« im »ccd«-Verzeichnis an. Diese enthält lediglich die Route zum Subnetz 192.168.4.0/24:

iroute 192.168.4.0 255.255.255.0

Fast die gleiche Zeile muss auch die s»erver.conf« aufweisen. Lediglich der Routing-Befehl heißt darin anders:

route 192.168.4.0 255.255.255.0

Die Befehle »iroute« und »route« spielen bestimmte Rollen. Das Kommando »iroute« ist für das Routing vom Open-VPN-Server zu den Clients verantwortlich, während »route« die Routing-Tabelle des Kernels des Open-VPN-Servers setzt.

Optional kann der Verwalter noch erlauben, dass sich die VPN-Clients untereinander austauschen dürfen. Dazu dient die Anweisung »client-to-client« in »server.conf«:
client-to-client
push "route 192.168.4.0 255.255.255.0"

Der Open-VPN-Server übernimmt über das »push«-Statement das Setzen der Route zum Subnetz der Clients.
jr@networkcomputing.de