© reykamensky, 123RF.com

In immer mehr Firmen sind Apple-Geräte Teile des lokalen Netzwerks. Wer dies auch externen Mitarbeitern erleichtern will, ohne teure Cisco-Hardware anzuschaffen, dem hilft ein Linux-VPN-Server. Dieser Artikel zeigt, wie Admins Racoon als IPsec-Server für Apples mobile Geräte konfigurieren.

Apples I-OS bietet schon seit einiger Zeit einen VPN-Client, dessen Konfiguration in den Netzwerk-Einstellungen untergebracht ist (Abbildung 1). Zur Auswahl stehen hier als Protokolle L2TP, PPTP und IPsec. Der Konfigurationsdialog präsentiert dem Anwender neben den VPN-Parametern wie Gegenstelle und Benutzername ein prominent platziertes Cisco-Logo, das suggeriert, die VPNs funktionierten nur mit den Gegenstellen des Netzwerkgiganten [1]. Weil aber die darunterliegende IKE-Komponente das IPsec-VPN in I-OS (wie in OS X auch) mit einer von Apple erweiterten Version des freien IPsec-Stack Racoon [2] implementiert, lässt sich auch ein VPN zwischen Linux und dem iPhone umsetzen – ohne teure Cisco-Router.

Abbildung 1: Der Netzwerk-Dialog in I-OS offeriert drei VPN-Anschlüsse, doch sollte sich niemand vom Cisco-Logo täuschen lassen: Auch Linux-Server funktionieren – mit der richtigen Konfiguration.

Wie bei jeder IPsec-VPN-Konfiguration gilt es jedoch herauszufinden, an welchen der vielen Stellschrauben in der VPN-Konfigurationsdatei »racoon.conf« auf dem Server der Server-Admin drehen muss, damit der Verbindungsaufbau gelingt. Die Komplexität der IPsec-Schichten, des verwendeten IKE-Protokolls und die vielen Optionen machen das bisweilen schon auf Desktop-PCs zu einem langwierigen Try-and-Error-Spiel. Diverse Artikel im Linux-Magazin ([3] bis [7]) mögen bei der Suche nach einer funktionierenden Konfiguration helfen, doch auf mobilen Geräten erschwert meist das Fehlen von Logdateien diese Arbeit.

Straßenkampf-Konfiguration

Anders als bei klassischen Site-to-Site-IPsec-Konfigurationen, die zwei Niederlassungen einer Firma verbinden, kommt für mobile Clients eher die Road-Warrior-Konfiguration zum Einsatz, bei der dem Server die IP-Adresse der Gegenstelle zunächst nicht bekannt ist, zum Beispiel weil sich der Client über DSL, WLAN oder UMTS einwählt. Typischerweise erhalten VPN-Clients in diesen Konfigurationen auch IP-Adressen und weitere Netzwerk-Konfigurationsdaten vom Server dynamisch zugewiesen.

Ebenfalls schwierig für die Anbindung von Smartphones ist, dass die Provider diesen in der Regel (wohl mangels ausreichend verfügbarer IPv4-Adressen) private IPs zuweisen und den Handys so den Internetzugang über meist mehrfach hintereinandergeschaltetes NAT (Network Address Translation, Abbildung 2, [8]) bereitstellen.

Abbildung 2: Ein Traceroute mit Mtr offenbart: Der via WLAN-Hotspot über UMTS angebundene Laptop greift über mehrfach verschachteltes NAT aufs Internet zu. Zeile 3 zeigt die letzte private Adresse von O2.

Auf dem Server offenbart ein Blick auf die Konfigurationsdatei von Racoon »/etc/ipsec/racoon.conf« mehrere Abschnitte. Die erste Zeile definiert die Gesprächigkeit der Logfiles. Für den Normalbetrieb reicht hier zwar »notify« , doch gerade in der Testphase erweist sich »debug« als hilfreich. »path certificate« spezifiziert den Pfad zu dem Verzeichnis, in dem die Zertifikatsdaten liegen:

log notify;
path certificate "/etc/racoon/ssl";
path pre_shared_key "/etc/racoon/psk.txt";

In der dritten Zeile landet optional der Pfad zu den Preshared Keys (PSK), die meist für den Testbetrieb ausreichen. Gelingt der Verbindungsaufbau, lassen sich die PSKs später durch die Zertifikate einer Public Key Infrastructure (PKI) ersetzen. Mit ihr verwaltet der Admin seine Zugangsberechtigungen und entzieht bei Bedarf einzelnen Usern die Zugriffsrechte. Der folgende »listen« -Block nennt die IP-Adressen und Portnummern, auf denen Racoon IKE-Verhandlungen entgegennimmt:

listen { isakmp 10.1.1.1 [500]; #IP of gentoo box isakmp_natt 10.1.1.1 [4500];
}

Wer NAT-Traversal [9] nutzt, findet dafür hier die Einträge für IP und Port. Fehlt die Zeile »isakmp [..]« , dann akzeptiert der Rechner bei allen Adressen auf Port 500 IKE-Pakete. Das Beispiel oben verwendet jedoch NAT-Traversal, deshalb ist die zweite Zeile notwendig. Pro Adresse, auf der er IPsec-Pakete entgegennehmen soll, muss hier eine Zeile für »isakamp« und eine für »isakmp_natt« stehen.

In den »remote« -Blöcken (Listing 1) gibt der Administrator die Konfigurationsdaten für einen Kommunikationspartner an, »anonymous« statt einer Netzwerkadresse bedeutet hier, dass diese Einstellung für beliebige Partner gilt, deren IP zunächst nicht bekannt ist. I-OS akzeptiert zwei Modi für den IKE-Austausch, daher sind beide im Parameter »exchange_mode main,aggressive« angegeben.

01 remote anonymous {
02 exchange_mode main,aggressive;
03 my_identifier fqdn "linuxvpn.example.com";
04 verify_identifier off;
05 certificate_type x509 "cert.pem" "key.pem";
06 ca_type x509 "ca.crt";
07 ike_frag on;
08 proposal_check claim;
09 passive on;
10 support_proxy on;
11 generate_policy on;
12 nat_traversal on;
13 dpd_delay 20;
14 proposal {
15 encryption_algorithm aes;
16 hash_algorithm sha1;
17 authentication_method xauth_psk_server;
18 # authentication_method xauth_rsa_server;
19 dh_group 2;
20 }
21 }

Der VPN-Server identifiziert sich zuerst mit dem eigenen Hostnamen. Bei Zertifikats-basierter Authentifizierung nennen die Parameter »certificate_type« und »ca_type« den Typ der Datei und Dateinamen, die IPsec wiederum im am Anfang angegebenen SSL-Verzeichnis sucht.

Mobile Clients

Der Parameter »ike_frag« gibt an, ob fragmentierte IKE-Pakete akzeptiert werden – er sollte bei mobilen Geräten angeschaltet sein. Aus dem gleichen Grund setzt »proposal_check claim« akzeptierte Schlüssellängen und Lebenszeiten der Session Keys auf das Maximum beziehungsweise Minimum. Der Eintrag »passive on« sorgt dafür, dass der Linux-Server nicht seinerseits versucht eine Verbindung zu initialisieren. Ohne IP-Adresse der Gegenstelle wäre das auch unmöglich. Zeile 10 sorgt dafür, dass die ID-Payloads im Phase 2 für den Austausch als Adressen der Endpunkte dienen.

Mit »generate_policy on« landen dynamisch erzeugte Einträge in der Security Policy Database, basierend auf den beim Verbindungsaufbau ausgehandelten Parametern. Bei Site-2-Site-VPNs sind diese Einträge normalerweise statisch und sorgen dafür, dass die gerouteten Datenpakete auch im VPN-Tunnel ankommen.

NAT-Traversal

Erst »nat_traversal on« sorgt dafür, dass sich auch Clients trotz NAT verbinden können. Den Delay für die Dead Peer Detection legt die nächste Zeile auf 20 Sekunden fest (»dpd_delay 20« ). Im folgenden »proposal« -Block finden sich die Verschlüsselungsparameter für die erste Phase des Verbindungsaufbaus. Der Kryptoalgorithmus ist AES, bei der Authentifizierung kommt SHA1, als Diffie-Hellman-Gruppe [10] die Variante »2« (Modp1024) für den DH-Schlüsselaustausch zum Einsatz.

Die Anweisung »authentication_method« beschreibt, wie sich die Gegenseite zu authentifizieren hat. Mit der Methode »xauth_psk_server« nutzt IPsec die PSK-Datei vom Anfang der Konfiguration. Die auskommentierte Zeile 18 »authentication method xauth_rsa_server« zeigt, wie das mit Zertifikaten funktioniert.

Phase 2

Der nächste Block (Listing 2) beschreibt die Parameter für die Verschlüsselung der Laufdaten (in Phase 2 von IKE). Pro Stunde handelt die Software einmal einen neuen Schlüssel aus, als Verschlüsselungsalgorithmen stehen AES und 3DES zur Verfügung, zur Authentisierung dienen wahlweise SHA1 oder MD5. Racoon verlangt den Kompressionsalgorithmus »compression_algorithm deflate« (Zeile 6), er erweist sich gerade bei langsamen Verbindungen über Mobilfunknetze als sehr hilfreich.

01 sainfo anonymous {
02 pfs_group 2;
03 lifetime time 1 hour;
04 encryption_algorithm aes, 3des;
05 authentication_algorithm hmac_sha1,hmac_md5;
06 compression_algorithm deflate;
07 }

Forcierte Client-Config

Der letzte Block (Listing 3) schließlich beschreibt die Client-Konfiguration, die der IPsec-Server übermittelt. Zwei-Faktor-Authentifizierung etwa gegen RSA-Tokens oder ähnliche Methoden [5] gehen meist mit einem zentralen Radius-Server einher. Die »auth_source pam« -Direktive authentisiert gegen die in PAM definierten Methoden des Linux-Systems, dort stehen auch Radius- oder LDAP-Anbindungen zur Verfügung. Die Parameter der LDAP- oder Radius-Konfiguration finden sich in der sehr empfehlenswerten Manualseite von »racoon.conf« .

01 mode_cfg {
02 auth_source pam;
03 pool_size 25;
04 network4 10.2.0.2;
05 netmask4 255.255.255.0;
06 dns4 10.1.1.1;
07 wins4 10.1.1.1;
08 default_domain "intern.example.com";
09 split_dns "intern.examplecom";
10 split_network include 10.1.0.0/16;
11 banner "/etc/racoon/motd";
12 pfs_group 2;
13 }

Der Parameter »pool_size« (Zeile 3) gibt an, wie viele Clients der Server aus diesem Adresspool gleichzeitig zu bedienen gewillt ist, hier 25. Das begrenzt gleichzeitig die maximale Anzahl verbundener Clients. »network4« spezifiziert die erste IP-Adresse des Pools, »netmask4« die Netzmaske, die der Client zugewiesen bekommt. In »dns4« und »wins4« finden sich DNS- oder WINS-Server.

In Zeile 8 steht »default_domain« für die Domain, die der Server an alle nicht vollständigen Hostnamen anhängt. Dies entspricht dem Parameter »domain« in der Datei »/etc/resolv.conf« . »split_dns “intern.examplecom”« erlaubt es, dem Client eine Liste von (internen) Domains zu übergeben, die dieser bei den in Zeile 6 spezifizierten DNS-Servern abfragen soll. Mit »split_network include« lassen sich lokale Netze durch den Tunnel routen, eine Ausnahmeliste (der Client routet dann alles außer den hier genannten IPs in den Tunnel) ließe sich hier mit »local_lan« eintragen.

Zeile 11 (»banner« ) ermöglicht eine optionale Nachricht (»/etc/racoon/motd« ), die der Client dem Anwender nach erfolgreichem Verbindungsaufbau einblendet. Abschließend muss der Admin auch hier eine »pfs_group« angeben.

Fehlersuche mit PSK

Neben den individuellen Benutzerdaten gehören zu den Zugangsdaten zu einem Cisco-VPN noch ein Gruppenname und ein Gruppenpasswort. Bei der Konfiguration mit Passwort (oder Pre Shared Secret) finden sich diese Daten in der Datei »psk.txt« . Die Kennung des Benutzers prüft IPsec gegen die Methode aus »auth_source« (Listing 3, Zeile 2). Für die Gruppe »testlan« und das Passwort »geheim« bedarf es des folgenden Eintrags in der »psk.txt« :

testlan geheim

Der Gruppenname landet dort, wo sonst die IP-Adresse der Gegenstelle steht. Auf dem Client trägt der Anwender dann »testlan« unter der Einstellung »Group Name« und »geheim« unter »Secret« im VPN-Konfigurationsdialog ein.

Bei der Fehlersuche rund um VPN-Verbindungen sind aussagekräftige Logmeldungen auf beiden Seiten unverzichtbar. Das I-OS-Device antwortet jedoch – wie alle gängigen Smartphones – nur mit Erfolg oder Misserfolg.

Doch von Apple gibt es unter [13] (für Windows und Mac OS) das iPhone Configuration Utility, das – neben der Möglichkeit, zentral Applikationen und Konfigurationsinformationen auf das iPhone zu spielen – auch eine Syslog-Konsole mitbringt, die die Racoon-Fehlermeldungen zeigt (Abbildung 3). Auch Zertifikate lassen sich mit dem Configuration Utility einspielen. Im Apple-Sprachgebrauch heißt die Kombination aus Zertifikat und Private Key jedoch »Profile« .

Abbildung 3: Apples iPhone Configurator liefert hilfreiche Details für den Verbindungsaufbau.

Kompliziert: Notifications

Wie in vielen Fällen steckt in den I-OS-Geräten mehr Open Source drin, als die Oberfläche und das Marketing vermuten lassen. Trotz Cisco-Banner ist es schon mit Linux-Bordmitteln möglich, einen VPN-Server zu betreiben, der den sicheren Zugriff auf das Unternehmensnetzwerk zulässt. Sicher ist das dann eben nur so weit, wie es die systembedingt unsicheren Endgeräte [14] erlauben. Aber bezahlen müssen Admin und Benutzer im Vergleich zu kommerziellen Angeboten mit einem Verlust an Komfort. So gelingt es in dieser Konfiguration mit einem Linux-Server nicht, Apples Notifications so zu nutzen, wie es kostenpflichtige Anbieter hinbekommen. Die Notifications benachrichtigen den Benutzer, wenn eine E-Mail-, Twitter-, Google+- oder andere IM-Nachricht eingeht, zum Beispiel mit einem leisen Piepston.

Ist das VPN inaktiv, funktionieren die darüber verbundenen Notification-Dienste natürlich nicht mehr. Doch so erfährt der Benutzer auch erst, nachdem er das VPN aufgebaut hat, ob neue Nachrichten da sind. Anderen Anbietern, zum Beispiel Check Point [15] gelingt dies trotz VPN vollkommen transparent, der Benutzer braucht das virtuelle Netz nicht aufzubauen, um Notifications über neue Nachrichten zu erhalten.