32.8 Virtuelle private Netzwerke mit OpenVPN

Virtuelle private Netzwerke (kurz VPNs) haben innerhalb der letzten Jahre enorm an Bedeutung gewonnen. Im Folgenden geben wir Ihnen daher eine Einführung in diese Thematik.

Bei einem VPN handelt es sich um ein virtuelles Netzwerk innerhalb eines realen Netzwerks. Die Verbindungen und Systeme eines bestehenden Netzwerks werden dabei so verwendet, dass Sie innerhalb dieses Netzwerks noch ein weiteres aufbauen können. Die Netzwerkdaten eines VPN werden dabei innerhalb von Protokollen des bestehenden Netzwerks untergebracht. Diesen Vorgang bezeichnet man als Tunneling. VPNs werden oft verschlüsselt eingesetzt, um Daten, die geheim gehalten werden sollen und normalerweise nur über ein Firmennetzwerk transportiert werden sollen, über ein unsicheres Netz zu transportieren.

[zB]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 entsprechende 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 darauf konfiguriert sein, dass die Datenübertragung zwischen ihnen verschlüsselt und/oder authentifiziert wird. Der Mitarbeiter und die Firma können nun vertraulich konferieren.

Eine weitere häufig genutzte VPN-Software ist OpenVPN. Sie 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. Weder ein zwischengeschalteter Proxy noch NAT erzeugen dabei ein Problem. Besonders hervorzuheben ist, dass es Clients für alle gängigen Betriebssysteme gibt und ihre Konfiguration recht einfach ist.

Auf der Homepage von OpenVPN – www.openvpn.org – findet man Clients für alle wichtigen Betriebssysteme sowie eine ausführliche Dokumentation mit einfachen Beispielen. Außerdem finden sich in den meisten Linux-Distributionen bereits vorgefertigte Pakete für OpenVPN, so dass Sie die Software nicht einmal mehr von Hand installieren müssen.

32.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. Diese Einrichtung ist zwar recht einfach – schließlich braucht man keine X.509-PKI-Infrastruktur für die Zertifikate einzurichten --, bietet aber nur begrenzte 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 die Pre-shared Keys von OpenVPN diese Eigenschaft nicht besitzen, kann ein Angreifer nach Veröffentlichung der Schlüssel alle vergangenen Sitzungen entschlüsseln. [Fn. Zertifikate nach X.509 dagegen verwenden zur Laufzeit erstellte Sitzungsschlüssel und bieten daher PFS.]

Um einen Schlüssel in OpenVPN zu erstellen, reicht folgender Aufruf auf der Kommandozeile:

Listing 32.8 Key erstellen

$ openvpn --genkey --secret key.dat

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:

Listing 32.9 Konfiguration Server

dev tun
ifconfig 192.168.100.1 192.168.100.2
secret key.dat

Listing 32.10 Konfiguration Client

remote vpn.example.com
dev tun
ifconfig 192.168.100.2 192.168.100.1
secret key.dat

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 ansprechbar. Den Tunnel testen kann man somit über ein einfaches ping der Gegenstelle.

Sollte der Test fehlschlagen, so liegt es mit ziemlicher Sicherheit an den Einstellungen der Firewall an einem der Endpunkte. OpenVPN nutzt standardmäßig den UDP-Port 1194, dieser sollte also nicht geblockt werden. Auch ein zwischengeschaltetes NAT muss entsprechend konfiguriert werden, so dass 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, bauen Sie folgende Zeile in die Konfiguration des Clients ein:

Listing 32.11 Routing zum Server

route 192.168.1.0 255.255.255.0

Auf der Serverseite müssen Sie – sofern der OpenVPN-Server nicht der Standard-Gateway der Rechner im Netzwerk ist – noch die Route zum Client eintragen: Schließlich ist der Server der Gateway für den Client.

32.8.2 Zertifikate mit OpenSSL

Eine einfache PKI aufbauen

Das Beispiel mag zum Testen ausreichend sein, für ein professionelles Setup wird man die Authentifizierung jedoch über Zertifikate durchführen wollen. Diese sind vor allem vom sicheren HTTPS-Protokoll bekannt, werden jedoch auch hier 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 man braucht, um eine komplette Zertifizierungsstelle einzurichten.

Ein Zertifikat ordnet einer Person oder einem Rechner einen öffentlichen Schlüssel zu. Eine Zertifizierungsstelle (CA, für englisch 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 des Skripts 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 Parameter -sign. 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.

32.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 auf 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 ihn 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« Fluss- und Fehlerkontrolle kann zu unerwarteten Effekten wie deutlichen Geschwindigkeitseinbußen führen.
• dev tun / dev tap
  Hier kann man die Art des Tunnels bestimmen. Die Option 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 die Option 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. Andernfalls 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 erkennen, 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 beim Starten von OpenVPN eventuell ein Passwort angegeben werden, um den verschlüsselten Key laden zu können.
• dh dh1024.pem
  Für den Schlüsselaustausch sind Diffie-Hellman-Parameter zuständig. [Fn. Diffie-Hellman bezeichnet ein nach seinen Erfindern benanntes kryptografisches Verfahren zum Schlüsselaustausch.] Es reicht aus, diese Parameter einmal mit folgendem Aufruf zu erstellen:

Listing 32.12 openssl dhparam

openssl dhparam -out dh1024.pem 1024

• server 192.168.2.0 255.255.255.0
  Mit diesem Befehl legt man das Subnetz für alle VPNs fest. Natürlich ist dies nur für geroutete IP-Tunnel (dev tun) interessant. In diesem Beispiel erhalten alle VPN-Clients IPs aus dem Netz 192.168.2.0/24. Dieses Segment sollte in der bisherigen Infrastruktur noch nicht vorkommen!

Netze freigeben

• push "route 192.168.2.0 255.255.255.0"
  Mit diesem Aufruf teilt man dem Client mit, dass er das Netz 192.168.2.0/24 hinter dem VPN-Gateway finden kann. Hier können auch mehrere Netzwerke weitergeleitet werden – selbst 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. Andernfalls können die VPN-Clients zwar Daten ins Netzwerk senden, die Antwortpakete werden aber den Weg zurück nicht finden. [Fn. 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, somit »sehen« die Clients nur den Server (und eventuell die gerouteten Netze).

Installiert man OpenVPN als RPM- oder DEB-Paket unter Linux, so ist ein Init-Skript zum automatischen Starten des Servers schon beigefügt. [Fn. Unter Windows muss man den Dienst noch als automatisch startend in der Diensteverwaltung markieren.]

32.8.4 OpenVPN als Client

Das Setup des Clients entspricht im Wesentlichen der Serverkonfiguration. 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.

VPN-Gateway

• remote vpn-gateway.example.com 1194
  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, sonst schlägt die Authentifizierung fehl. Es ist ratsam, jedem Client ein eigenes Zertifikat zu geben – so gibt es beim Widerrufen eines Zertifikats keine Probleme. [Fn. 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 dieses Vorgehen aber trotzdem nicht.]

Mit 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 letzten Nerv rauben – kann man auf diese Weise 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. :-)

Ihr Kommentar

Wie hat Ihnen das <openbook> gefallen? Wir freuen uns immer über Ihre freundlichen und kritischen Rückmeldungen.