OpenVPN als SSL-VPN-Bridge
Eine Brücke über das Internet
SSL-VPN ist neben IPSec und PPTP eine der verbreitetsten VPN-Techniken. Es basiert auf dem Verschlüsselungsprotokoll TLS (Transport Layer Security), dem Nachfolger von SSL. Im Normalfall findet das Programm OpenVPN für diesen Dienst Verwendung. Es ist auf vielen Betriebssystemen verfügbar und bietet im Gegensatz zu IPSec-VPN eine sehr hohe Flexibilität. In der Regel kommt SSL-VPN für Client-to-Site-VPNs zum Einsatz. Kaum bekannt ist hingegen die Eignung von OpenVPN als SSL-VPN-Bridge.SSL-VPN lässt sich idealerweise im Client-to-Site-VPN einsetzen, da es über einen beliebigen einzelnen TCP- oder UDP-Port nutzbar ist. So kann der Port 443 zum Beispiel am Flughafen oder im Hotelzimmer zum Aufbau einer vollwertigen VPN-Verbindung dienen. Andere VPN-Techniken wie IPSec und PPTP lassen sich nicht nutzen, wenn nur die Ports 80 und 443 verfügbar sind. Doch neben der verbreiteten Verwendung für Client-to-Site-VPNs kann OpenVPN auch zwei komplette Netze (Site-to-Site) verbinden. Die Nutzung von OpenVPN als SSL-VPN-Bridge ist jedoch so gut wie nicht bekannt, im Folgenden wird sie daher beschrieben.
Nutzt ein Unternehmen an verschiedenen Standorten glei-che Subnetze, kann eine SSL-VPN-Bridge die perfekte Lösung sein. Ein Beispiel: Ein Unternehmen verwendet dasselbe Subnetz (192.168.1.0/24) in der Hauptniederlassung und in der Zweigstelle für den Bereich Sales. Die Computer in diesem Netz sollen ihre Konfiguration per DHCP erhalten. Der DHCP-Server in der Hauptniederlassung kann seine Broadcast-Pakete nicht einfach durch ein geroutetes VPN schicken - eine SSL-VPN-Bridge ist notwendig. Diese SSL-VPN-Bridge baut zwischen den Standorten eine Verbindung auf OSI-Layer 2 auf. Für die Administratoren erscheint dieses VPN wie eine Verbindung der lokalen Switches im Subnetz 192.168.1.0/24 (Bild 1). Über eine SSL-VPN-Bridge lassen sich generell auch Nicht-IP-Protokolle wie IPX oder NetBEUI transportieren.
Kommerzielle Firewalls weisen heute eine gut strukturierte Zertifikatsverwaltung und eine übersichtliche Konfiguration der OpenVPN-Dienste (Client-to-Site, Site-to-Site und SSL-Bridge) sowie der einzelnen Verbindungen auf. Die grafische Oberfläche gibt eine einfache Übersicht, während im Hintergrund eine oder gar mehrere Instanzen von OpenVPN laufen und alle Einstellungen sowie Zertifikate an die richtige Stelle kopiert werden.
Ist eine SSL-VPN-Bridge zwischen zwei Standorten aufgebaut, prüft eine Netzwerk-Firewall die Pakete, die diese Verbindung passieren, vollständig. An den Endpunkten kann die Firewall die Pakete bis auf Applikationsebene kontrollieren und zum Beispiel Viren oder Angreifer an der Ausbreitung hindern. Eine übersichtliche Rechteverwaltung wie mit Netzwerk-Firewalls ist mit OpenVPN allein nicht möglich. Versierte Linux-Administratoren können eine reine OpenVPN-Bridge mit frei verfügbaren Open-Source-Komponenten wie Debian Linux und OpenVPN jedoch selbst bauen. Um einen genauen Einblick in sämtliche Konfigurationen zu erhalten, wird im Folgenden die Einrichtung einer OpenVPN-Bridge mit zwei Debian-Rechnern gezeigt. Dies zeigt, wie das SSL-VPN-Bridging einer kommerziellen Firewall unter der grafischen Oberfläche funktioniert.
Mit OpenVPN ist eine Authentifizierung über Pre-Shared Keys (PSK) oder X.509 Zertifikaten möglich. Zertifikate sind zwar in der Erstellung und Einrichtung aufwändiger als ein PSK, der Gewinn an Sicherheit und Übersichtlichkeit (gerade bei vielen Verbindungen) rechtfertigt den Mehraufwand aber in jedem Fall. Zertifikate nach dem Standard X.509 sollte man idealerweise als Public Key Infrastructure (PKI) einrichten. Es werden nicht nur die Zertifikate für die einzelnen Endpunkte erstellt, sondern auch eine eigene Certification Authority (CA), die die Host-Zertifikate signiert. Auf diese Weise fallen keine Kosten für das Signieren der Zertifikate an. Gleichzeitig schafft dies eine Struktur, die auch bei größeren Installationen skaliert.
Auf einer der Firewalls erstellt der Administrator eine CA. Diese besteht wie alle Zertifikate aus einem Private Key und einem Public Key. Der private Schlüssel der CA wird nur auf einer Firewall vorliegen. Auf dieser Firewall werden dann alle weiteren Zertifikate für alle am VPN teilnehmenden Parteien erstellt und auch gleich von der CA signiert. Die zweite Firewall (und alle weiteren) erhalten nur den Public Key der CA, damit sie später andere Zertifikate auf ihre Echtheit überprüfen können.
Um eine OpenVPN-Bridge-Installation mit freier Software nachzustellen, sind zwei Computer mit jeweils zwei Netzwerkkarten und das freie Betriebssystem Debian 6.0 erforderlich. Nach einer Standardinstallation von Debian sind für eine SSL-VPN-Bridge noch die Pakete openvpn und bridge-utils nachzuinstallieren.
Die eine Netzwerkkarte führt in die jeweiligen lokalen Netze. Beide Seiten weisen hier den Adressraum 192.168.1.0/24 auf. Die andere Netzwerkkarte führt zum WAN, zum Beispiel zu einer DSL-Verbindung mit dem Internet. Die Interfaces sind in der Datei /etc/network/interfaces zu konfigurieren. Sie sollte auf den beiden Seiten wie folgt aussehen:
Debian 1: Debian 2:
auto lo
iface lo inet loopback
allow-hotplug eth0 eth1
iface eth0 inet static
address 192.168.10.1
netmask 255.255.255.0
iface eth1 inet static
auto tap0
iface tap0 inet manual
openvpn tls-bridged
iface br0 inet static
address 192.168.1.1
netmask 255.255.255.0
bridge_ports tap0 eth1 auto lo
iface lo inet loopback
allow-hotplug eth0 eth1
iface eth0 inet static
address 192.168.10.2
netmask 255.255.255.0
iface eth1 inet static
auto tap0
iface tap0 inet manual
openvpn tls-bridged
iface br0 inet static
address 192.168.1.2
netmask 255.255.255.0
bridge_ports tap0 eth1
Tabelle 1.
Die ersten Zeilen können wie im Standard-Debian belassen werden (Tabelle 1). Sie setzen nur das Loopback-Interface, welches immer vorhanden sein sollte. Der nächste Block definiert eth0 und eth1, die automatisch nach dem Booten des Systems aktiviert werden sollen. Eth0 erhält eine beliebige IP-Adresse und sollte in der Regel zum Internet (zum Beispiel zum DSL-Modem) führen. Eth1 benötigt keine IP-Adresse, da es Teil der Bridge wird. Das tap0 Interface stellt eine Verbindung zwischen zwei Netzwerken dar. OpenVPN benötigt das TAP-Device für eine Bridging-Verbindung (im Gegensatz zum TUN-Device, das für eine Routing-Verbindung genutzt wird). Zuletzt ist noch die Bridge zu definieren.
Zertifikate werden nur auf einer Seite ("Debian 1") erstellt und an die andere Seite ("Debian 2") exportiert. Auf der Konsole dient dazu das Programm openssl. Zuerst ist eine Verzeichnisstruktur für die Zertifikate erforderlich. Diese Struktur ist von OpenVPN vorgegeben und sollte genau in der Form erscheinen, die Tabelle 2 zeigt.
Debian 1: Debian 2:
mkdir -p demoCA/private demoCA/newcerts demoCA/certs
touch demoCA/index.txt
echo 1000 > demoCA/serial ?
Tabelle 2.
Als nächstes sind die Diffie-Hellman-Parameter für die Zertifikate zu erstellen. Es handelt sich hier um einen Automatismus, der die Primzahl und eine Primitivwurzel für die Beziehung zwischen dem Private- und Public-Teil des Zertifikats erzeugt (Tabelle 3).
openssl dhparam -out dh1024.pem 1024 ?
Tabelle 3.
Danach wird die Certification Authority (CA) eingerichtet. Da die CA den höchsten Punkt der PKI bildet, muss sie sich selbst signieren, also für die eigene Echtheit garantieren (Tabelle 4).
openssl genrsa -out ca.key 2048
chmod 0600 ca.key
openssl req -new -x509 -days 3650 -extensions v3_ca -key ca.key -out ca.pem ?
Tabelle 4.
Anschließend werden erst der RSA Key und ein Request für das Host-Zertifikat des "Debian 1"-Rechners erstellt und von der CA signiert. Das Ergebnis ist das fertige Host-Zertifikat "vpn_server.pem" (Tabelle 5).
openssl genrsa -out vpn_server.key 2048
chmod 0600 vpn_server.key
openssl req -new -key vpn_server.key -out vpn_server.req
openssl ca -cert ca.pem -keyfile ca.key -in vpn_server.req -out vpn_server.pem ?
Tabelle 5.
Derselbe Vorgang ist für das Host-Zertifikat des "Debian 2"-Rechners zu wiederholen, wie Tabelle 6 zeigt.
openssl genrsa -out vpn_client.key 2048
chmod 0600 vpn_client.key
openssl req -new -key vpn_client.key -out vpn_client.req
openssl ca -cert ca.pem -keyfile ca.key -in vpn_client.req -out vpn_client.pem ?
Tabelle 6.
Wie in Tabelle 6 zu sehen ist, arbeitete der Administrator bislang nur auf dem Rechner "Debian 1". Hier liegt nun die gesamte Zertifikatsstruktur. Den Public Key der CA muss er jetzt auf "Debian 2" kopieren. Die Dateien "vpn_client.key" und "vpn_client.pem" kann er komplett auf "Debian 2" verschieben, da sie nur dort erforderlich sind. Sämtliche Echtheitsprüfungen der Zertifikate übernimmt die CA.
Die ".key"-Dateien sind die Private Keys der Zertifikate und dürfen keinesfalls in falsche Hände geraten.
Nachdem nun die Zertifikate vorhanden sind, kann die Konfiguration des OpenVPN-Tunnels beginnen. Hierzu ist die OpenVPN-Konfigurationsdatei /etc/openvpn/tls-bridged.conf in der in Tabelle 7 gezeigten Weise zu erstellen.
Debian 1: Debian 2:
dev tap
tls-client
remote debian2.dyndns.org
ca ca.pem
cert vpn_client.pem
key vpn_client.key
persist-tun
persist-key
user nobody
group nogroup
script-security 2
up „/sbin/ifup br0“
down „/sbin/ifdown br0“
verb 3 dev tap
dh dh1024.pem
ca ca.pem
cert vpn_server.pem
key vpn_server.key
persist-tun
persist-key
user nobody
group nogroup
script-security 2
up „/sbin/ifup br0“
down „/sbin/ifdown br0“
verb 3
Tabelle 7.
Die Konfiguration beginnt mit dem Setzen des TAP-Devices (Tabelle 7). Dies ist für den Betrieb der Bridge durch den OpenVPN-Tunnel notwendig. In der zweiten Zeile konfiguriert der Systemverwalter "Debian 1" als VPN-Client und "Debian 2" als VPN-Server. Der Client muss mit der Zeile "remote debian2.dyndns.org" noch den zu kontaktierenden Server angeben. Als nächstes werden auf "Debian 2" die Diffie-Hellman-Parameter gesetzt und auf beiden Seiten die Zertifikate angegeben. Der Eintrag "persist-tun" sagt nur aus, dass ein Reset auch ohne das Schließen und Wiederstarten des TAP-Devices erfolgen kann; "persist-key" hält den Private Key im Speicher, da OpenVPN mit eingeschränkten Benutzerrechten läuft und diesen Key sonst nicht lesen könnte.
Darunter sind User und Gruppe benannt, unter dem OpenVPN startet. Der Eintrag "script-security" ist auf den Wert "2" gesetzt, damit die beiden folgenden Zeilen die Bridge bei Tunnelaufbau und -abbau starten oder stoppen können. Zuletzt wird das Log-Level auf 3 gestellt, was für das Troubleshooting vollkommen ausreicht.
Nach einem Reboot beider Systeme verbindet eine SSL-VPN-Bridge die beiden lokalen Netzwerke. Die Funktionalität dieser SSL-VPN-Bridge ist identisch mit der einer kommerziellen Firewall. Der Aufwand der Verwaltung von 100 und mehr Tunneln und die gleichzeitige Rechteverwaltung zum Beispiel mit dem Netfilter-Framework (iptables) lassen sich mit dieser Lösung jedoch nicht mehr bewältigen. Zudem prüft dieser Setup wie erwähnt die Pakete, die diese Verbindung passieren, nicht auf Malware oder Angreifer hin.
Lesen Sie mehr zum Thema
