| thunstr. 10 | 3005 bern | tel 031 331 64 04 | fax 031 331 64 05 | info@indato.ch
Von diesem Dokument ist eine aktuell gehaltene Version bei der Firma netnea als PDF verfügbar.
Table of Contents
© 2005, indato GmbH, S.Leupold
Das Dokument untersteht der Creative Commons - Attribution / Share Alike Lizenz.
Ein Virtual Private Network (VPN) ist ein logisches Netzwerk, welches ein physisches Netzwerk zum Transport von Daten benutzt. Das physische Netzwerk kann z.B. das Internet oder ein Wireless LAN (WLAN) sein. VPNs "tunneln" Datenpakete über das Transportnetz. Die Bezeichnung "private" bezieht sich auf die verwendeten Adressbereiche innerhalb des Tunnels. Neben dem reinen Tunneln durch fremde Netze bieten heute viele VPN Implementierungen die Möglichkeit, den Datenstrom zu verschlüsseln. So lassen sich selbst kritische Unternehmensdaten über unsichere Transportnetze übertragen. Typische Anwendungsfälle von VPNs sind daher oft Remote Access via Internet oder sichere Site To Site Verbindungen.
VPN Lösungen lassen sich grob nach Hard- und Softwarelösungen klassifizieren. Spezielle Hardwarelösungen bieten viele namhafte Hersteller von Netzwerkequipment an. Vermehrt trifft man auch auf sogenannte Appliance Lösungen, also fixfertige Blackboxes, die man nur an den Standorten aufstellt und die bereits alle Funktionen eingebaut haben. Auf der anderen Seite gibt es eine Vielzahl von VPN Softwarelösungen. Hier realisiert eine Software oder ein Betriebssystem die Funktion eines VPN Servers bzw. Clients. Viele neue Software VPN Lösungen forcieren SSL/TLS als Technologie, da sich hier Tunneling und Verschlüsselung kombinieren lassen.
Alle VPN Lösungen müssen Methoden enthalten, um einen unautorisierten Zugriff abzuwehren. D.h. es muss geprüft werden, ob der Peer berechtigt ist, Daten über das VPN zu transportieren. Die sichere Authentisierung ist mindestens so wichtig, wie eine gute Verschlüsselung.
Bei der Wahl der optimalen Lösung sollten Kriterien wie Sicherheitsanforderungen, Interoperabilität, Betriebsaufwand und Leistungsfähigkeit in die Entscheidung einfliessen.
OpenVPN [1] ist eine vielversprechende OpenSource Software VPN Lösung basierend auf SSL/TLS. OpenVPN verwendet das bewährte und als sicher eingestufte openssl [2] zur Verschlüsselung und Authentisierung. Damit lassen sich höchste Sicherheitsanforderungen realisieren. OpenVPN benutzt standardmässig das robuste User Datagram Protocol (UDP) als Transportprotokoll. Der Protokoll-Overhead ist sehr gering, was sich günstig auf den Datendurchsatz auswirkt.
OpenVPN bietet eine Reihe von Authentisierungsfunktionen an. Der Anwender kann, je nach Anforderungen, zwischen shared secret, Zertifikat oder Authentisierungs-Plugin wählen. Kombinationen aller Methoden miteinander sind möglich. Shared Secret Authentisierung ist für kleine peer to peer VPN geeignet, bei denen es keine Rolle spielt, wenn mehrere Peers den gleichen Schlüssel verwenden. Eine wesentlich sicherere Methode zur Authentisierung stellen X.509 Client Zertifikate dar. Hier muss der Client ein gültiges Zertifikat vorweisen, um sich am VPN anzumelden. Die Gesamtsicherheit dieser Lösung wird aber vom Client Zertifikatsspeicher massgebend beeinflusst.
OpenVPN kann mit Plugins flexibel auf andere Authentisierungsformen erweitert werden. Beispielsweise kann zusätzlich ein Benutzername und ein Passwort an einem RADIUS oder LDAP Directory Server geprüft werden.
Die komplexen Verschlüsselungs- und Authentisierungsmethoden sind mit OpenVPN vergleichsweise einfach zu verwalten. Eine Konfigurationsdatei steuert alle wichtigen Einstellungen.
Neben dem Tunneling von IP Paketen beherrscht OpenVPN auch Ethernet Bridging. Layer 2 Protokolle (z.B. NetBUI, DHCP) und Broadcasts können so über das VPN transportiert werden. Applikationen, die von diesen Protokollen abhängig sind, können transparent über das VPN benutzt werden.
OpenVPN folgt dem klassischen Client/Server Ansatz. Ein OpenVPN Client initiiert eine Verbindung zum OpenVPN Server. Der OpenVPN Server weist sein X.509 Zertifikat vor, welches der Client auf Echtheit prüft. Die Prüfung erfolgt anhand des public keys der ausgebenden Certificate Authority (CA). Wurde der OpenVPN Server für authentisch befunden, setzt die 1. Stufe der Client Authentisierung ein.
Erfolgt die Authentisierung des Clients mit einem X. 509 Client Zertifikat, prüft der Server das vom Client übermittelte Zertifikat anhand des public keys der ausgebenden CA. Ist das Client Zertifikat gültig und nicht in der Certificate Revocation List (CRL) der CA, ist diese Authentisierungstufe abgeschlossen und die verschlüsselte Verbindung kann beginnen. Standardmässig werden mit SSL/TLS die session keys dynamisch ausgehandelt. Upstream und Downstream verwenden jeweils eigene Keys zum verschlüsseln und signieren.
Wurde ein shared secret konfiguriert, ist die Authentisierung mit der Verschlüsselung gekoppelt. Ohne den richtigen Schlüssel kann keine verschlüsselte Verbindung aufgebaut werden. Bei der shared key Variante wird ein shared key (eigentlich sind es 4 Keys) verwendet, um die Datenpakete zu verschlüsseln und zu signieren.
Optional kann jetzt eine weitere Authentisierungsmethode gestartet werden (plugin). Der Client schickt dem Server den Benutzername und ein Passwort mit, welches das Plugin prüft und das Ergebnis an den OpenVPN Server zurückgibt. Ist auch diese Authentisierung erfolgreich, darf der Client am VPN teilhaben.
Der Client bezieht seine private Adresse vom Server und bekommt alle notwendige Einstellungen (DNS, WINS etc.) über den Tunnel mitgeteilt. Als Tunnelendpunkte werden virtuelle Interfaces (TUN/TAP) verwendet. Die Routingtabelle des Clients wird nunmehr so manipuliert, dass alle Pakete durch den Tunnel geschickt werden.
Serverseitig wird die Kommunikation über ein virtuelles Interface abgehandelt. Die getunnelten IP Pakete werden "ausgepackt" und anschliessend mit network adress translation (NAT) auf eine oder mehrere Adressen (address pool) im lokalen Netz übersetzt.
Anhand eines Beispiels sollen die Ausführungen unter 2.1 illustriert werden. Eine Firma mit einem Firmennetz (10.10.10.0/24) realisiert mit OpenVPN eine Remote Access Lösung über das Internet. Die Mitarbeiter sind am Heimarbeitsplatz (home office) mit ADSL oder Kabel an ihrem lokalen Internet Service Provider (ISP) angeschlossen. Das Heimbüro verwendet den privaten Adressbereich 192.168.10.0/24. Dieser Adressbereich wird vom ISP nicht reroutet, d.h. eine direkte IP Verbindung zwischen dem home office und dem Firmennetz ist nicht möglich. Erst ein OpenVPN Tunnel verbindet die beiden Netze.
Bevor der Client die VPN Verbindung startet, sieht seine Routingtabelle wie folgt aus:
$ netstat -rn Kernel IP routing table Destination Gateway Genmask Flags MS Window irtt Iface 192.168.10.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 127.0.0.0 127.0.0.1 255.0.0.0 UG 0 0 0 lo 0.0.0.0 192.168.10.1 0.0.0.0 UG 0 0 0 eth0
Der Client ist mit einem Ethernet Interface (eth0) am lokalen Netzwerk angeschlossen. Alle Adressen, die nicht im lokalen Netz liegen, werden an den ADSL Router (192.168.10.1) geleitet.
Die VPN Verbindung wird auf der Kommandozeile oder GUI gestartet.
$ /etc/init.d/openvpn start Enter Auth Username: ******** Enter Auth Password: ******** Enter Private Key Password: ********
Nach erfolgreicher Authentisierung und dem Aufbau des Tunnels verändert sich die Routingtabelle des Clients:
$ netstat -rn Kernel IP routing table Destination Gateway Genmask Flags MSS Window irtt Iface 1.2.3.4 192.168.10.1 255.255.255.255 UGH 0 0 0 eth0 10.4.0.1 10.4.0.17 255.255.255.255 UGH 0 0 0 tun1 10.4.0.17 0.0.0.0 255.255.255.255 UH 0 0 0 tun1 192.168.10.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 127.0.0.0 127.0.0.1 255.0.0.0 UG 0 0 0 lo 0.0.0.0 10.4.0.17 0.0.0.0 UG 0 0 0 tun1
Die IP Adresse des OpenVPN Servers (1.2.3.4) wird als statische Route eingefügt. Das Netz 10.4.0.0/24 bildet das logische Netzwerk. Das virtuelle Interface (tun1) bekommt vom OpenVPN Server die Adresse 10.4.0.17 zugewiesen. Die default Route wird auf das virtuelle Interface (10.4.0.17) gelegt, d.h. alle Pakete in fremde Netze werden über dieses Interface geroutet.
Serverseitig werden alle VPN Verbindungen über ein virtuelles Interface (tun) abgewickelt. Routingtechnisch sind hier keine Änderungen erforderlich, da das VPN Netzwerk (10.4.0.0/24) bereits bekannt ist. Ankommende Pakete aus dem VPN werden mit NAT auf eine interne Adresse 10.10.10.10 übersetzt und schon können die Clients mit den internen Ressourcen kommunizieren. Beim Einsatz von iptables als Firewall sieht der NAT Eintrag wie folgt aus:
Chain POSTROUTING (policy ACCEPT) target prot opt source destination SNAT all -- 10.4.0.0/24 10.10.10.0/24 to:10.10.10.10
NAT wird eingesetzt, da im Beispielnetzwerk kein dynamisches Routing konfiguriert ist. Will man ohne NAT arbeiten, muss das VPN Netzwerk auf allen Servern statisch eingetragen werden.
Die Installation des OpenVPN Servers erfordert Administratorrechte auf dem Betriebssystem. Die Quellen der Software sind unter [1] frei verfügbar. Nach dem herunterladen der Quellen wird kompiliert und installiert:
$ ./configure --prefix=/opt/openvpn $ make $ su -c "make install"
Alternativ gibt es bereits fertige Pakete für diverse Distributionen. Das Konfigurationsverzeichnis /etc/openvpn enthält die Serverkonfiguration, Zertifikate und Plugins.
Die zentrale Konfigurationsdatei (Appendix A) des OpenVPN Servers /etc/openvpn/local.conf beinhaltet alle Einstellungen. Der Server verwendet das virtuelle Interface tun1 und wartet auf dem UDP Port 1194 auf Verbindungen.
port 1194 proto udp dev tun1
Der private Key, die CA-und Server Zertifikate sind ebenfalls unter /etc/openvpn abgelegt.
ca cacert.pem cert server.pem key server.pem # This file should be kept secret crl-verify crl.pem dh dh1024.pem
Die Diffie Hellman Parameter werden mit openssl generiert:
openssl dhparam -out dh1024.pem 1024
Mit OpenVPN lassen sich dynamische Adressen für Clients und Server verwenden. Der Benutzer kann "unterbrechungsfrei" weiterarbeiten, wenn die IP Adresse wechselt. Der Server prüft den Status der verbundenen Clients im Intervall von 10 Sekunden. Ist der Client für 120 Sekunden unerreichbar, wird die VPN Verbindung terminiert.
keepalive 10 120
Routing, DNS, WINS und andere Optionen können dem Client mitgeteilt werden. Im Beispiel wird der DNS Server auf 10.10.10.3 gesetzt. "redirect-gateway" bewirkt, dass der default gateway des Clients umgesetzt und der gesamte Netzwerkverkehr über den VPN Tunnel geroutet wird.
push "redirect-gateway" push "dhcp-option DNS 10.10.10.3"
Optional kann eine externe Authentisierung konfiguriert werden. Beispielskripts zur Authentisierung werden mit dem Quelltext mitgeliefert. Eine einfache LDAP Authentisierung ist im Appendix B abgebildet.
auth-user-pass-verify /etc/openvpn/knock.sh via-env
Die Installation und Konfiguration auf einem UNIX Client ist identisch mit der des OpenVPN Servers. Einzig die Konfigurationsdatei /etc/openvpn/local.conf ist verschieden.
OpenVPN wird angewiesen im Client Modus zu arbeiten. Der Client verbindet auf einen OpenVPN Server mit der Adresse 1.2.3.4 auf UDP Port 1194.
client dev tun proto udp remote 1.2.3.4 1194
Die Client-und CA Zertifikate sind unter /etc/openvpn abgelegt.
ca cacert.pem cert client.pem key client.key
Für die Authentisierung mit Benutzername und Passwort muss in der Konfiguration folgender Eintrag gemacht werden:
auth-user-pass
Die Installation unter Windows benötigt Administratorrechte. Nach dem Aufruf des Installationsprogramms openvpn-2.0-install.exe wird man durch die Installation geleitet. Am Ende der Prozedur steht in der Programmleiste ein neuer Eintrag "OpenVPN" zur Verfügung. Unter C:\Programme\OpenVPN\config werden die Konfigurationsdatei local.ovpn und die Client-und CA Zertifikate abgelegt. Die Konfiguration für Windows Clients ist identisch mit der für UNIX Clients. Als virtuelles Interface wird unter Windows "tap" statt "tun" verwendet:
dev tap
Unter Windows wird der OpenVPN Client per rechte Mausklick auf das local.ovpn Symbol gestartet. Die Angabe des Benutzernamens, des Passworts und der Passphrase werden in einem command Fenster gemacht:
Das Thema Sicherheit spielt beim Einsatz von VPN Techniken eine grosse Rolle. Der Einsatz von starker Verschlüsselung und Client Zertifikaten allein bietet noch keine absolute Sicherheit. Sicherheit beginnt und endet beim Benutzer. Entfernt ein VPN Benutzer die Passphrase seines private keys oder speichert Passwörter im Klartext, ist die Sicherheit potentiell gefährdet. Im Fall eines Identitätsdiebstahls, kann auf dem OpenVPN Server das Zertifikat des Clients widerrufen werden (CRL). Firmen, die VPN Lösungen einsetzen, sollten ihre Mitarbeiter auf das Thema Sicherheit sensibilisieren und entsprechend anleiten.
Der Einsatz eines Firewalls ist empfehlenswert, da beim VPN Datenverkehr von aussen ins Firmennetz gelangt. Eine firmenweite Sicherheitspolicy regelt genau, welche Art von Kommunikation zugelassen wird. Virenscanner sollten die Integrität der VPN Clients überprüfen, um auszuschliessen, dass andere Systeme via VPN infiziert werden.
Die VPN Lösung mit OpenVPN hat sich in der Praxis bewährt. Einzig an Bandbreite sollte nicht gespart werden. Die stärkste Performancebremse ist eine zu geringe upload Bandbreite (z.B. ADSL/Kabel). Mit Werten ab 256 kbps lässt sich aber dennoch flüssig arbeiten. Tabelle 1 vergleicht den Durchsatz beim Kopieren einer 10MB grossen Datei über verschiedene Methoden. Der Client ist asymetrisch mit 400/2000kbps (Kabel) und der Server mit 640/1536kbps (ADSL) am Internet angeschlossen. Der geringe Protokoll Overhead von OpenVPN ist deutlich ersichtlich. Die Abweichung der Transferzeiten zwischen getunnelter und ungetunnelter Übertragung ist minimal.
Table 1. Tabelle 1
| Transport über | Transferzeit upload/download in s |
|---|---|
| ftp 100Mbps switched | 1/1 |
| scp 100Mbps switched | 1/1 |
| ftp über openvpn | 217/164 |
| ftp direkt | 206/155 |
| scp über openvpn | 214/167 |
| scp direkt | 204/157 |
Zum Browsen von Informationen eignet sich ein VPN hervorragend. Will man hingegen ein Dokument direkt mit dem Textverarbeitungsprogramm auf dem Share öffnen, stösst man schnell an die Grenzen. Besser fährt man, wenn die Datei temporär auf eine lokale Ablage kopiert wird. Nach dem Bearbeiten wird die Datei auf den Share zurückkopiert.
Haben Sie Fragen oder Anregungen zu diesem Artikel? Kontaktieren Sie uns unter info@indato.ch.
# local.conf openvpn server configuration port 1194 proto udp dev tun1 ca cacert.pem cert server.pem key server.pem # This file should be kept secret crl-verify crl.pem dh dh1024.pem server 10.4.0.0 255.255.255.0 ifconfig-pool-persist ipp.txt push "redirect-gateway" push "dhcp-option DNS 10.10.10.3" keepalive 10 120 comp-lzo persist-key persist-tun status openvpn-status.log verb 1 auth-user-pass-verify /etc/openvpn/knock.sh via-env
#!/bin/sh
#
# a simple ldap auth script for openvpn
#
LDAP_HOST=10.10.10.3
#
# check nach leeren username/password oder [Aa]nonymous
#
if [ "$username" = "anonymous" || "$username" = "Anonymous" || -z "$username" || -z "$password" ] ; then
exit 1;
fi
#
# testen, ob bind mit credentials funktioniert - ungueltige Zeichen werden zu _
#
ldapwhoami -x -h $LDAP_HOST -D uid=$username,ou=users,dc=example,dc=com \
-w $password
#
if [ "$?" = "0" ]; then
exit 0;
else
exit 1;
fi
exit 1;