Open Source im professionellen Einsatz

© reykamensky, 123RF.com

I-OS-VPN mit Linux-Servern

Geschützte Äpfel

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.

Listing 1

Remote-Block aus racoon.conf

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.

Diesen Artikel als PDF kaufen

Express-Kauf als PDF

Umfang: 4 Heftseiten

Preis € 0,99
(inkl. 19% MwSt.)

Als digitales Abo

Als PDF im Abo bestellen

comments powered by Disqus

Ausgabe 07/2013

Preis € 6,40

Insecurity Bulletin

Insecurity Bulletin

Im Insecurity Bulletin widmet sich Mark Vogelsberger aktuellen Sicherheitslücken sowie Hintergründen und Security-Grundlagen. mehr...

Linux-Magazin auf Facebook