23.8 Virtuelle Private Netzwerke mit OpenVPN 
Virtuelle Private Netzwerke (kurz VPNs) haben innerhalb der letzten Jahre enorm an Bedeutung gewonnen. Auch in diesem Buch werden wir Ihnen daher eine Einführung in diese Thematik geben. <Mehr zum Thema erfahren Sie in unserem Buch »Praxisbuch Netzwerksicherheit«.>
Bei einem VPN handelt es sich um ein virtuelles Netzwerk innerhalb eines richtigen Netzwerkes.
Die Verbindungen und Systeme eines bestehenden Netzwerkes werden dabei so verwendet, dass Sie innerhalb dieses Netzwerkes noch ein weiteres aufbauen können. Die Netzwerkdaten eines VPN werden dabei innerhalb von Netzwerkprotokollen des bestehenden Netzwerkes untergebracht, was als Tunneling bezeichnet wird. VPNs werden oft verschlüsselt eingesetzt, um Daten, die geheim gehalten werden sollen und normalerweise nur über ein Firmen-Netzwerk transportiert werden sollen, über ein unsicheres Netz zu transportieren.
Zum besseren Verständnis dieses Themas hier ein Beispiel: Ein Mitarbeiter einer in Deutschland angesiedelten Firma fährt zu Geschäftspartnern nach Schweden. Von dort aus möchte er eine sichere Videokonferenz zum heimischen Unternehmen aufbauen, die über das Internet eingerichtet werden soll. Dazu stellt der Mitarbeiter über eine VPN-Software (also einen VPN-Client) auf seinem Notebook eine Verbindung zum VPN-Router (auch VPN-Gateway genannt) der Firma her. Beide Systeme können nun darauf konfiguriert sein, dass die Datenübertragung zwischen ihnen verschlüsselt und/oder authentifiziert wird. Der Mitarbeiter und die Firma haben damit ein Problem weniger.
Eine weitere häufig genutzte VPN-Software ist OpenVPN. OpenVPN setzt nicht auf neue, eigene Protokolle und Schlüsselaustauschverfahren, sondern nutzt mit dem TLS/SSL-Protokoll ein bekanntes und lange getestetes Verfahren, um die Sicherheit einer Verbindung zu gewährleisten.
Dazu wird über TLS/SSL eine Verbindung zum Server aufgebaut, über die dann der gesamte Netzwerkverkehr getunnelt wird. Dabei ist weder ein zwischengeschalteter Proxy noch NAT ein Problem. Besonders hervorzuheben ist weiterhin, dass es Clients für alle gängigen Betriebssysteme gibt und vor allem, dass die Konfiguration recht einfach ist.
Die Homepage von OpenVPN ist http://www.openvpn.org. Dort findet man Clients für alle wichtigen Betriebssysteme sowie eine ausführliche Dokumenation samt einfacher Beispiele. Außerdem finden sich in den meisten Linux-Distributionen bereits vorgefertigte Pakete für OpenVPN, sodass Sie die Software nicht einmal mehr von Hand installieren müssen.
23.8.1 Pre-shared keys 
Mit OpenVPN kann man die Authentifizierung auf zwei verschiedene Arten regeln: mit Zertifikaten oder mit »pre-shared keys«. Bei Letzteren handelt es sich um eine Art Passwort, das vor der Nutzung auf beiden VPN-Endpunkten eingerichtet wurde. Das ist zwar recht einfach – schließlich braucht man keine X.509-PKI-Infrastruktur für die Zertifikate einzurichten --, aber doch begrenzt in den Möglichkeiten:
Man kann so nur zwei Rechner miteinander verbinden und hat keine Perfect Forward Secrecy:
Ein Kryptosystem mit Perfect Forward Secrecy (PFS) stellt die Integrität auch dann noch sicher, wenn der Schlüssel nach der Kommunikation kompromittiert wird.
Da OpenVPNs pre-shared keys diese Eigenschaft nicht haben, kann ein Angreifer nach der Veröffentlichung der Schlüssel alle vergangenen Sitzungen entschlüsseln. <Zertifikate nach X.509 dagegen verwenden zur Laufzeit erstellte Sitzungsschlüssel und bieten daher PFS. Aber dazu später.>
Um einen Schlüssel in OpenVPN zu erstellen, reicht folgender Aufruf auf der Kommandozeile:
$ openvpn --genkey --secret key.dat
Listing 23.8 Key erstellen
Der erzeugte Schlüssel ist anschließend in der Datei key.dat gespeichert und muss auf »sicherem Weg« – beispielsweise mittels SSH – auf beide zu verbindenden Rechner verteilt werden. Anschließend kann man mit den folgenden kurzen Konfigurationsdateien einen VPN-Tunnel zwischen »Client« und »Server« aufbauen:
dev tun ifconfig 192.168.100.1 192.168.100.2 secret key.dat
Listing 23.9 Konfiguration Server
remote vpn.example.com dev tun ifconfig 192.168.100.2 192.168.100.1 secret key.dat
Listing 23.10 Konfiguration Client
Anschließend kann man den Tunnel mittels openvpn --config Konfigurationsdatei starten. In unserem Beispiel haben die Bezeichnungen »Server« und »Client« nur Bedeutung in Bezug auf den Aufbau des Tunnels: Der OpenVPN-Server läuft im Hintergrund und wartet auf eine Verbindungsanfrage des OpenVPN-Clients. Dazu muss der Client natürlich wissen, wo er den Server finden kann: In unserem Beispiel ist der öffentliche Name des Servers vpn.example.com.
Nach dem Verbindungsaufbau sind beide Seiten allerdings gleichberechtigt und über die IPs 192.168.100.1 beziehungsweise 192.168.100.2 anzusprechen. Den Tunnel testen kann man somit über ein einfaches ping der Gegenstelle.
Sollte der Test fehlschlagen, so liegt es mit ziemlicher Sicherheit an den Firewalleinstellungen eines der Endpunkte. OpenVPN nutzt standardmäßig UDP Port 1194, dieser sollte also nicht geblockt werden. Auch ein zwischengeschaltetes NAT muss entsprechend konfiguriert werden, sodass die Pakete korrekt weitergeleitet werden.
Möchte man einer Seite nun Zugriff auf das Netz der Gegenstelle erlauben, so muss nur noch das Routing richtig aufgesetzt werden. Um zum Beispiel dem Client den Zugriff auf das 192.168.1.0/24-Netz des Servers zu geben, muss man folgende Zeile in die Konfiguration des Clients einbauen:
route 192.168.1.0 255.255.255.0
Listing 23.11 Routing zum Server
Auf der Serverseite muss man – sofern der OpenVPN-Server nicht das Standardgateway der Rechner im Netzwerk ist – noch die Route zum Client eintragen: Schließlich ist der Server das Gateway für den Client.
23.8.2 Zertifikate mit OpenSSL
Eine einfache PKI aufbauen
Obiges Beispiel mag zum Testen ausreichend sein, für ein professionelles Setup wird man die Authentifizierung jedoch über Zertifikate durchführen wollen. Zertifikate sind dabei vor allem vom sicheren HTTPS-Protokoll bekannt, werden hier jedoch in größerem Umfang eingesetzt. So verlangt OpenVPN eine ganze PKI (Public Key Infrastruktur), die aber recht einfach mit der OpenSSL-Suite erstellt und verwaltet werden kann.
Der einfachste Weg, Zertifikate komfortabel zu verwalten, ist openssl. Das Tool findet man in nahezu jeder Linux-Distribution – und hat damit alles, was es braucht, um eine komplette Zertifizierungsstelle einzurichten.
Ein Zertifikat ordnet einen öffentlichen Schlüssel einer Person oder einem Rechner zu. Eine Zertifizierungsstelle (CA, für engl. certification authority) beglaubigt diese Zuordnung durch ihre digitale Unterschrift.
Da das openssl-Programm selbst viele Parameter entgegennimmt, gibt es ein einfaches Skript, das die Benutzung vereinfacht und praktischerweise gleich mit OpenSSL verteilt wird. Das Skript heißt CA.sh und findet sich zum Beispiel unter /usr/lib/ssl/misc. Die wichtigsten Optionen lauten wie folgt:
- CA.sh -newca
- Mit diesem Parameter wird eine neue Zertifizierungsstelle erstellt. Als Ausgabe erhält man unter anderem das Zertifikat mit dem öffentlichen Schlüssel der CA. Als wichtigster Parameter wird ein Passwort abgefragt, mit dem man später neue (Client-)Zertifikate erstellen oder auch widerrufen kann.
- CA.sh -newreq
- Mit diesem Aufruf erstellt man eine Zertifizierungsanfrage. Dies ist nichts weiter als ein Schlüsselpaar sowie einige Daten zum Besitzer – gültig wird dieses Zertifikat jedoch erst, wenn es im nächsten Schritt von der Zertifizierungsstelle unterschrieben wurde.
- CA.sh -sign
- Das Unterschreiben des Requests geschieht mit dem »-sign«-Parameter. Dabei wird man aufgefordert, das Passwort der Zertifizierungsstelle einzugeben. Erst dann ist das Unterschreiben erfolgreich.
Ist man mit den Default-Einstellungen des Skripts nicht zufrieden und möchte zum Beispiel die Gültigkeitsdauer der Zertifikate verlängern, so genügt ein Blick in das Skript selbst – viele Optionen können dank ausführlicher Kommentare leicht angepasst werden.
23.8.3 OpenVPN als Server einrichten
Zertifikate eignen sich besonders für ein »Roadwarrior«-Setup, bei dem man mehreren externen Clients über einen zentralen VPN-Server den Zugriff in das eigene Netz erlauben will – ein typisches Szenario, um Außendienstmitarbeitern den Zugriff auf die Firmen-IT zu gewähren.
Ein guter Ausgangspunkt für die Erstellung eines eigenen Setups ist die OpenVPN- Beispielkonfiguration. Dabei müssen Sie auf die folgenden Punkte achten:
- port 1194
- Der Standard-Port von OpenVPN ist Port 1194/UDP. Eine Firewall sollte diesen Port also nicht blocken, sondern eventuell per NAT an den VPN-Server weiterleiten.
- proto udp / proto tcp
- Man kann wählen, ob man das VPN über UDP oder TCP betreiben möchte. Aber Achtung: Wenn man TCP-Verbindungen über das VPN tunneln möchte – und das wird fast immer der Fall sein – sollte man das VPN über UDP betreiben. Eine »doppelte« Fluß- und Fehlerkontrolle kann zu unerwarteten Effekten wie beispielsweise deutlichen Geschwindigkeitseinbußen führen.
- dev tun / dev tap
- Hier kann man die Art des Tunnels bestimmen. »dev tun« erzeugt einen gerouteten IP-Tunnel: Die Clients befinden sich in einem eigenen Netz und nutzen das VPN-Gateway als Zugang zum internen Netz. Dagegen erstellt »dev tap« einen Ethernet-Tunnel. Die Clients treten also dem Netzwerk bei, und können so auch Broadcast-Nachrichten empfangen. Der damit einhergehende Traffic lässt sich allerdings nur rechtfertigen, wenn spezielle (auf Broadcasts angewiesene) Protokolle einen tap-Tunnel notwendig machen. Ansonsten sollte in den meisten Fällen ein gerouteter Tunnel die richtige Wahl sein.
- ca / cert / key
- Mit diesen Direktiven gibt man die vorher mit OpenSSL erstellten Zertifikate an. Wichtig ist das CA-Zertifikat, da sowohl Server als auch Client die Gültigkeit des jeweils anderen Zertifikats daran überprüfen, ob es von der eigenen CA unterschrieben wurde.
- Das Zertifikat mit dem Schlüssel (»key«) ist geheim zu halten, alle anderen Daten sind öffentlich. Je nach Konfiguration muss eventuell ein Passwort beim Starten von OpenVPN angegeben werden, um den verschlüsselten Key laden zu können.
- dh dh1024.pem
- Für den Schlüsselaustausch sind Diffie-Hellman-Parameter notwendig. Es reicht aus, diese Parameter einmal mit einem Aufruf von openssl dhparam -out dh1024.pem 1024 zu erstellen.
- server 192.168.254.0 255.255.255.0
- Mit diesem Befehl legt man das Subnetz für alle VPNs fest. Natürlich ist das nur für geroutete IP-Tunnel (»dev tun«) interessant.
- In diesem Beispiel bekommen alle VPN-Clients IPs aus dem 192.168.2.0/24er-Netz. Natürlich sollte dieses Segment in der bisherigen Infrastruktur noch nicht vorkommen!
- push »route 192.168.2.0 255.255.255.0«
Netze freigeben
- Mit diesem Aufruf teilt man dem Client mit, dass er das Netzwerk 192.168.2.0/24 hinter dem VPN-Gateway finden kann. Hier können auch mehrere Netzwerke weitergeleitet werden – auch wenn sie nicht direkt mit dem VPN-Gateway verbunden sind. Zu beachten ist nur, dass alle Router auch das VPN-Gateway als Zugangspunkt zum VPN-Netz kennen. Ansonsten können die VPN-Clients zwar Daten ins Netzwerk senden, die Antwortpakete werden aber den Weg zurück nicht finden. <Natürlich tritt dieses Problem nicht auf, wenn man den VPN-Server gleich auf dem Standard-Gateway aufsetzt ;-)>
- client-to-client
- Mit dieser Option kann man festlegen, dass sich verschiedene VPN-Clients auch gegenseitig sehen. Diese Option ist standardmäßig deaktiviert, und so »sehen« die Clients nur den Server (und eventuell die gerouteten Netze).
Installiert man OpenVPN als RPM- oder DEB-Paket unter Linux, so ist ein Initskript zum automatischen Starten des Servers schon beigefügt. Unter Windows muss man den Dienst noch als »automatisch startend« in der Diensteverwaltung markieren.
23.8.4 OpenVPN als Client
Das Setup des Clients ist im Wesentlichen mit der Serverkonfiguration identisch. Es fallen viele (serverspezifische)
Einstellungen weg, zu beachten ist – wieder ausgehend von der Beispielkonfiguration – nur Folgendes:
- client
- Mit dieser Direktive legt man fest, dass dieser Rechner als Client agiert und sich damit wichtige Konfigurationseinstellungen vom Server holt.
- remote vpn-gateway.example.com 1194
VPN-Gateway
- Hier gibt man Server und Port an. Das Protokoll ergibt sich aus der – bei der Serverkonfiguration identischen –
- »proto«-Direktive.
- ca / cert / key
- Natürlich braucht auch der Client eigene Zertifikate. Das CA-Zertifikat muss dabei mit dem Server identisch sein, ansonsten wird die Authentifizierung fehlschlagen. Ansonsten ist es ratsam, jedem Client ein eigenes Zertifikat zu geben – so gibt es beim Widerrufen eines Zertifikates keine Probleme. <Frühere Versionen von OpenVPN setzten sogar voraus, dass jeder Client ein eigenes Zertifikat besitzt. Heute ist es zwar möglich, ein Zertifikat für mehrere Clients zu benutzen, empfehlenswert ist es aber trotzdem nicht.>
Nach diesen einfachen Einstellungen ist das VPN fertig konfiguriert und damit einsatzbereit. Im Gegensatz zu komplizierten IPSec-Setups – die einem gerade bei unterschiedlichen Programmen auf unterschiedlichen Plattformen gern den Nerv rauben – kann man so sehr einfach und kostenlos externe Windows-Clients über einen Linux-VPN-Server an das Firmennetzwerk anbinden. Natürlich sind auch andere Mischformen denkbar – und alle funktionieren. :-)
