Offene Verschlusssache
OpenVPN bringt verbindet einzelne Rechner über das Internet, koppelt Netze und gewährt Heimarbeitern sicheren Zugang zum Firmennetze. Und dafür genügt ihm eine TCP- oder UDP-Verbindung – notfalls sogar durch einen Proxy.
OpenVPN ist eine vergleichsweise neue VPN-Technik, mit der man ebenso einzelne Rechner übers Internet miteinander verbinden wie komplette Netze koppeln oder Heimarbeitern sicheren Zugang zum Firmennetz gewähren kann. Auch bei der Zugangskontrolle und Verschlüsselung in Funknetzen oder für die Fernwartung leistet es gute Dienste. Anders als bei Hamachi hat man dabei die komplette Infrastruktur unter seiner Kontrolle, wodurch sich OpenVPN auch für den professionellen Einsatz eignet. Außerdem läuft es auf nahezu allen Plattformen, insbesondere auf Windows 2000/XP und Mac OS X.
Die Kehrseite ist etwas Aufwand beim Einrichten, das sich jedoch bei weitem nicht so kompliziert gestaltet wie bei IPSec. OpenVPN eignet sich somit zwar nur bedingt für Laien, aber mit ein wenig Computer- und Netzwerk-Know-how lässt es sich – auch wegen der ausgezeichneten Dokumentation – recht problemlos aufsetzen und in Betrieb nehmen.
Praktischerweise genügt OpenVPN eine einzige TCP- oder UDP-Verbindung zwischen den beteiligten Rechnern, sodass es auch hinter NAT-Routern und Firewalls ohne Verrenkungen seinen Dienst verrichtet. Bei Bedarf kann man sogar eine vollwertige Netzwerkverbindung über einen HTTP-Proxy herstellen. Dies sollte allerdings nur in Absprache mit der Netzwerk-Administration geschehen, da man sonst möglicherweise Sicherheitsbestimmungen verletzt und damit eine Kündigung riskiert.
Solide Basis
Für Verschlüsselung und Authentifizierung setzt OpenVPN auf Secure Socket Layer (SSL) beziehungsweise dessen Nachfolger Transport Layer Security (TLS). Diese werden seit vielen Jahren unter anderem für die Verschlüsselung von https-Web-Seiten und die Absicherung von Diensten wie E-Mail per IMAP eingesetzt. Damit nutzt es für diese grundlegenden, sicherheitsrelevanten Funktionen bewährte Protokolle und Bibliotheken wie OpenSSL, die sehr gut untersucht und getestet sind.
Wer möchte, kann die Authentifizierung zwar auch über Passwörter beziehungsweise Passphrases abwickeln. Doch solche statischen Pre-Shared Keys sind deutlich unsicherer als die Authentifizierung über Zertifikate. Deren Erstellung mit openssl vereinfacht OpenVPN über eine Skript-Sammlung namens Easy-RSA. Mit wenigen Befehlen kann man sich Zertifikate für eine eigene Certification Authority, den Server und die Clients erstellen. Die notwendigen Schritte sind im OpenVPN-Howto detailliert erläutert. Zu beachten ist, dass man auf einem Server, der den OpenVPN-Dienst automatisch starten soll, den geheimen Schlüssel nicht mit einem Passwort versieht. Bei den Clients hingegen empfiehlt es sich, diese durch ein Passwort zu schützen, damit nicht jeder das VPN missbrauchen kann, der irgendwie Zugang zu dem Rechner erlangt.
Wer OpenVPN in etwas größerem Maßstab einsetzen will, kann natürlich auch ein separates Tool wie TinyCA einsetzen. Es packt auf Wunsch alle erforderlichen Dateien inklusive Schlüssel, CA- und Client-Zertifikat in eine PKCS12-Datei client.p12, die OpenVPN direkt verwenden kann.
Einrichtung
Tunnelbau
Unter Windows installiert man OpenVPN am besten im Paket mit dem OpenVPN GUI. Damit lässt sich der VPN-Tunnel wie eine normale Netzwerkverbindung über das Kontext-Menü des Tray-Icons verbinden und trennen. Bei der Konfiguration selbst bietet es leider keine Hilfe; will man an den Einstellungen etwas ändern, muss man die Textdateien von Hand editieren. Unter Mac OS X leistet das Paket Tunnelblick Ähnliches. Unsere Versuche mit den Linux-GUIs verliefen eher frustrierend, sodass dort eine einfache Verknüpfung auf dem Desktop vorzuziehen ist, die OpenVPN in einem eigenen Terminal-Fenster startet.
OpenVPN hat eine Menge Schrauben, an denen man drehen kann. Das Schöne daran ist, dass man die meisten davon in der Regel nicht braucht. Will man nur zwei Rechner über ein VPN miteinander verbinden, genügt es, den OpenVPN-Server mit der mitgelieferten Beispielkonfigurationsdatei server.conf zu starten. Anpassen muss man gegebenenfalls die Namen und Pfade zu den Schlüssel- und Zertifikatsdateien, die OpenVPN standardmäßig im aktuellen Verzeichnis sucht. Unter Windows empfiehlt es sich, die Dateiendung in .ovpn zu ändern, damit die Datei dem richtigen Programm zugeordnet wird. Auf Debian-Systemen ist der Eintrag group von nobody auf nogroup zu setzen. OpenVPN reduziert unter Unix so bald wie möglich seine Rechte auf die dieser unprivilegierten Gruppe und des Users nobody. Den Befehl
openvpn server.conf
quittiert OpenVPN mit einer Reihe von Statusmeldungen, die in einem "Initialization Sequence Completed" kulminieren. Auf der anderen Seite muss man entweder die IP-Adresse oder den Namen des Servers unter "remote" in der Beispieldatei client.conf eintragen. Nach dem Start mit
openvpn client.conf
fragt das Programm nach dem Passwort für den geheimen Schlüssel und sollte nach dessen Eingabe ebenfalls ein "Initialization Sequence Completed" konstatieren. Damit steht die VPN-Verbindung und man kann den Server in der Beispielkonfiguration mit ping 10.8.0.1 erreichen. Analog sollten auch andere Dienste wie Webserver oder Dateifreigaben auf der Gegenstelle zu erreichen sein, falls dies nicht durch eine restriktive Konfiguration oder eine Firewall unterbunden wird.
Die IP-Adresse der Clients vergibt der Beispiel-Server dynamisch aus dem Bereich 10.8.0.0/24, der erste bekommt in der Regel die 10.8.0.6. Man kann die Adresse aus den Statusmeldungen entnehmen; auf dem Server zum Beispiel "MULTI: Learn: 10.8.0.6", auf einem Linux-Client /sbin/ifconfig tun0; bei Windows-Clients meldet das GUI die IP-Adresse des Clients. OpenVPN merkt sich diese Zuordnungen, sodass man bei erneuter Einwahl wieder dieselbe Adresse erhält. Alternativ beschreiben die Kommentare in der Datei und das Howto, wie man Clients auch feste IP-Adressen zuweisen kann.
Für einen OpenVPN-Server mit dynamischer Internet-Adresse kann man als remote einen DynDNS-Namen eintragen, wie man ihn beispielsweise bei DynDNS.org bekommt. Viele Router können sich bei jeder Einwahl selbst dort anmelden, ansonsten erledigen das Tools wie DeeEnEs. Steht der Server hinter einem Router, muss man dort den UDP-Port 1194 an den Rechner weiterleiten, der als Server fungieren soll.
Steht "hinter" dem OpenVPN-Server ein privates Netz, das der Client erreichen können soll, kann ihm der Server eine passende Netzwerk-Route übermitteln. Dazu ist in server.conf die Zeile
;push "route 192.168.10.0 255.255.255.0"
anzupassen und das führende Semikolon zu entfernen. Das funktioniert ohne weitere Tricks allerdings nur unter zwei Voraussetzungen: Erstens darf auf der Client-Seite nicht derselbe Adressbereich zum Einsatz kommen. Und zweitens muss sichergestellt sein, dass die Pakete aus dem LAN den richtigen Weg zum VPN-Client finden. Das passiert automatisch, wenn der OpenVPN-Server auch das Standard-Gateway für die Rechner im Server-LAN ist. Ansonsten muss entweder das Gateway eine passende Route haben, die Pakete für 10.8.0.0/24 an den OpenVPN-Server weiterleitet, oder diese Route muss auf allen Clients eingetragen werden.
OpenVPN kennt darüber hinaus viele weitere Optionen und Zusatzfunktionen, mit denen man sich nur bei Bedarf beschäftigen muss. So kann man Windows-Clients über DHCP-Optionen die Adressen von DNS- und WINS-Servern übermitteln oder die Clients anweisen, alle ausgehenden Pakete durch den VPN-Tunnel zu routen. Die einzelnen Optionen sind in der Beispielkonfiguration und der Dokumentation gut erklärt. Im Folgenden sollen ein paar konkrete Einsatzszenarien und deren spezielle Erfordernisse etwas genauer erläutert werden.
Administrator- und root-Rechte
Rechthaberei
OpenVPN benötigt unter anderem zum Konfigurieren der Tunnelendpunkte und dem Setzen der Routen Administratorrechte. Wer unter Windows ohne diese arbeitet, kann folglich OpenVPN nicht ohne weiteres starten. Die notwendigen Rechte verschafft eine Verknüpfung auf dem Desktop mit
runas /u:Administrator openvpn-gui.exe
Das fragt dann beim Start zunächst nach dem Administrator-Kennwort. Will man das dem Anwender nicht geben, wird es etwas komplizierter. Denn es ist zwar möglich, OpenVPN als Dienst zu installieren, den der Anwender dann starten und beenden darf, dieser kann dann aber nicht nach dem Passwort für den Schlüssel fragen. Der Autor von OpenVPN GUI empfiehlt in dieser Situation, den Schlüssel in den MS Certificate Store zu importieren, auf den OpenVPN zugreifen kann (--cryptoapicert).
Mit OpenVPN 2.1, das bereits als beta-Version erhältlich ist, entfallen diese Klimmzüge. Das TAP-Device können darin auch Nicht-Administratoren ansprechen. Zum Setzen der Routen unter XP Professional genügt ohnehin die Mitgliedschaft in der Gruppe der "Netzwerkkonfigurations-Operatoren".
Unter Linux sorgt der sudo-Mechanismus für die notwendigen Root-Rechte:
/usr/bin/sudo /usr/sbin/openvpn /etc/openvpn/client.conf
Damit das ohne Passworteingabe funktioniert, trägt der Administrator über visudo in /etc/sudoers folgende Zeilen ein
User_Alias VPN = ju, dab
VPN ALL= NOPASSWD: /usr/sbin/openvpn /etc/openvpn/client.conf
ersetzt dabei aber die User-Kennungen ju und dab durch die eigenen.
Bridge-Modus
Brückenbau
In der Standardkonfiguration arbeitet OpenVPN im Routing-Modus. Das heißt, das VPN nutzt ein eigenes Transfernetz – per Default 10.8.0.0/24. Die Tunnelendpunkte haben dabei Adressen aus diesem Netz und alle VPN-Pakete werden durch diesen Tunnel geroutet. Dazu setzt OpenVPN virtuelle TUN-Interfaces ein, die eine Punkt-zu-Punkt-Verbindung auf IP-Ebene erlauben.
In manchen Situationen ist dieser Umweg jedoch hinderlich, beispielsweise wenn man OpenVPN zur Fernwartung eines kleinen Firmennetzes einsetzt. Dabei steht der OpenVPN-Server oft hinter einem einfachen Router direkt im Firmennetz, der zwar das notwendige Port-Forwarding beherrscht, aber beispielsweise keine statische Route auf das virtuelle 10er-Netz zum OpenVPN-Server setzen kann. Außerdem wäre es für Diagnosezwecke nützlich, sich quasi direkt im lokalen Netz zu befinden, statt wie in der Standard-Konfiguration nur über geroutete Pakete dorthin zu gelangen.
Für solche Zwecke kann OpenVPN auch Netze überbrücken und als Bridge arbeiten. Dazu erzeugt es virtuelle Netzwerkkarten, die so genannten TAP-Devices. Eine Bridge vermittelt zwischen den TAP-Devices und dem LAN-Interface derart, dass es für alle Beteiligten so aussieht, als wäre eine weitere Netzwerkkarte direkt an das Ethernet angeschlossen. Das TAP-Interface bekommt folglich auch eine IP-Adresse aus dem Bereich des Firmennetzes, beispielsweise 192.168.10.0/24. Das hat eine Reihe von Vorteilen. So kommen beispielsweise alle Broadcasts im Netz auch auf dem VPN-Client an und man kann deshalb Windows-Dateifreigaben auch ohne WINS- oder Samba-Server browsen. Des Weiteren ist es damit möglich, über das VPN auch Nicht-IP-Protokolle wie IPX oder Appletalk einzusetzen. Dafür ist es weniger effizient als das Routing, skaliert nicht so gut und ist zumindest auf der Server-Seite etwas schwieriger aufzusetzen.
In einem einfachen Setup reserviert man für die VPN-Clients einen Bereich aus dem Block der Netzwerkadressen im LAN, beispielsweise 192.168.10.230-250, die für den lokalen DHCP-Server tabu sind. In server.conf kommentiert man die Einträge für dev tun und server und aktiviert stattdessen dev tap0 und server-bridge:
dev tap0
;dev tun
;server 10.8.0.0 255.255.255.0
server-bridge 192.168.10.2 255.255.255.0 192.168.10.230 192.168.10.250
Dabei ist die 192.168.10.2 die Adresse des Servers im LAN; den VPN-Clients weist der Server dynamisch Adressen aus seinem Privat-Pool zu. Windows findet das passende TAP-Device selbst, sodass hier nur tap ohne die 0 einzugeben ist. Nun ist noch das Bridging zu aktivieren. Unter Windows XP geht das vergleichsweise einfach, indem man in den Netzwerkverbindungen die Netzwerkkarte und das TAP-Interface auswählt und "Verbindungen überbrücken" ausführt.
Unter Linux muss man die Bridge wie in der Dokumentation beschrieben von Hand einrichten. Wer einen c't-Debian-Server einsetzt, muss lediglich in /etc/networks/interfaces ein weiteres tap-Device erstellen und bei br0 unter bridge_ports eintragen. Wichtig ist es, auch in client.conf dev tap zu verwenden, da sich TUN- und TAP-Modus nicht vertragen.
OpenVPN in IPCop
Wachtmeister
Für die Linux-Firewall IPCop hilft das OpenVPN-Paket Zerina beim Tunnelbau. Es integriert die komplette OpenVPN- inklusive Zertifikatsverwaltung in das IPCop-Web-Frontend. Der Clou ist die Möglichkeit, für Clients eine ZIP-Datei mit allen notwendigen Dateien herunterzuladen. Howtos erklären die notwendigen Schritte, um beispielsweise zwei Netze miteinander zu verbinden oder den WLAN-Clients im "blauen" Netz sicheren Zugang zum LAN zu verschaffen. Zerina befindet sich zwar noch in einem recht frühen Entwicklungsstadium, arbeitet jedoch schon sehr zufriedenstellend und stabil.
Ab Version 2.0 kann man OpenVPN auch mit OpenWRT einsetzen, einer Linux-Distribution für WLAN- und DSL-Router. Bei der Installation des kleinen Pakets spielt das Paketmanagement zusätzlich die Krypto-Bibliothek OpenSSL sowie die Komprimier-Bibliothek lzo ein und installiert das TUN-Interface als Kernelmodul kmod-tun. Aufgrund des geringen Speicherplatzes der Router fehlen der OpenVPN-Portierung für die MIPS-Architektur die Easy-RSA-Skripte zum einfachen Erzeugen der Schlüssel und Zertifikate. Alternativ lässt sich das auch von Hand mit OpenSSL erledigen, oder auf einen vollwertigen Linux- oder Windows-Rechner auslagern. Die Konfiguration von OpenVPN gleicht der unter einer normalen Distribution. Unter Umständen ist es sinnvoll, die MTU auf beispielsweise 1400 herabzusetzen, wenn Performance-Probleme auftreten.
OpenVPN kommt der Idealvorstellung von VPN schon ziemlich nahe: mächtige Technik, aber dabei nicht unnötig kompliziert, und das alles nicht nur kostenlos, sondern auch komplett offen gelegt. Schwachpunkte sind die noch nicht sonderlich weit entwickelten grafischen Frontends und der noch im Beta-Stadium befindliche TAP-Treiber für Windows, bei dessen Installation das Betriebssystem auch darauf hinweist, dass er nicht von Microsoft zertifiziert ist. Ein abstürzender Treiber kann das gesamte Betriebssystem in den Abgrund reißen, beim Einsatz in der Redaktion verzeichneten wir allerdings bislang keine Probleme. Vom Sicherheitsstandpunkt lässt OpenVPN ebenfalls kaum Wünsche offen. Neben den bereits erwähnten Punkten überzeugt die Möglichkeit, das Programm zumindest auf Unix-Systemen in eine chroot-Umgebung einzusperren und eine zusätzliche TLS-Authentifizierung vorzuschalten, die die Angriffsfläche weiter reduziert.
So macht Netzwerken Spaß. (je) ()
