Wer mit seinem Smartphone über das unsichere Internet eine sichere Verbindung zum eigenen Heimnetz aufbauen möchte, der baut in wenigen Schritten einen VPN-Tunnel auf Basis von L2TP/IPSec dorthin auf.

“Wer nichts zu verbergen hat, der hat auch nichts zu befürchten” – so lautet das Credo, das nicht nur “Terrorbekämpfer” landauf, landab wie eine Hostie vor sich hertragen. Richtiger wäre allerdings: “Ich habe zwar nichts zu verbergen, doch ich fürchte, dass meine Privatsphäre im Internet ohne gezielte Vorsorge nicht respektiert wird”.

Wer zum Beispiel zuhause einen Video-Disk-Recorder (VDR, [1]) betreibt, und diesen auch von unterwegs via Smartphone bedienen will, der begibt sich schnell auf unsicheres Terrain. Das liegt daran, dass die Konfigurationsoberfläche Vdradmin [2] dazu über das Internet erreichbar sein muss und damit potenziellen Angreifern Tür und Tor öffnet: Der HTTP-Server des Recorders bietet nativ weder eine sichere Verbindung per SSL noch einen wirkungsvollen Passwortschutz beim Anmeldevorgang.

Hinzu kommt der Umstand, dass sich Smartphones über das öffentliche 3G-Datennetz des Mobilfunkanbieters oder über private WLANs – etwa im Internet-Café – ins Netz verbinden, wo Sie als Teilnehmer keinerlei Einfluss darauf haben, wer das Netz mit welchen Absichten noch benutzt. VPNs bieten hier eine wirkungsvolle Möglichkeit, den Datenverkehr zwischen Smartphone und dem heimischen Netz sicher zu gestalten.

Systemaufbau

Das vorgestellte Szenario geht davon aus, dass Sie Ihr Heimnetz über einen handelsüblichen xDSL-Router mit dem Internet verbinden. Weiterhin benötigen Sie einen Linux-Rechner, der als VPN-Server arbeitet und optional auch den Wunschdienst (etwa Vdradmin) anbietet (Abbildung 1).

Abbildung 1: Zwei Smartphones, eines (Client-A) in einem mobilen Netzwerk (A.0), das andere (Client-B) im WLAN (B.0) eines Internet-Cafés, kontaktieren die heimatliche Cloud via Internet (A.1/B.1) und bilden mit dem Server ein virtuelles privates Netzwerk über A respektive B.

Es spielt dabei kein Rolle, ob das lokale Netz per Ethernet oder WLAN kommuniziert. Aus Sicherheits- und Stabilitätsgründen sollten Sie jedoch der kabelgebundenen Variante den Vorzug geben. Zur permanenten Verfügbarkeit müssen sowohl Router als auch Server durchgehend aktiv bleiben. Darüber hinaus gilt es, die meist dynamische IP-Adresse über einen Dienst wie Dyndns [3] mit einem eindeutig adressierbaren Domainnamen erreichbar zu halten.

L2TP/IPSec

Erklärte Ziel dieses Artikels ist es, den Einsatz einer VPN-Lösung vorzustellen, welche die gängigen Android- und iOS-Smartphones von Haus aus mit der jeweiligen Firmware mitbringen. Deswegen fiel die Wahl auf L2TP/IPSec [4]. Das mobile System bleibt damit im Originalzustand, ein Jailbreak oder Rooten des Geräts kann unterbleiben.

IPSec steht für Internet Protocol Security und stellt in diesem Zusammenhang die Verschlüsselung der Verbindung zwischen Client und Server her. In kleinen, übersichtlichen Netzen – wie in diesem Fall – genügt es, die Authentifizierung über einen gemeinsamen, allen Clients bekannten Schlüssel zu realisieren, den man auch PSK (“Pre-shared Key”) nennt. Auch wenn das die Gefahr des Vertippens erhöht, sollten Sie dazu ein möglichst langes Passwort wählen, das sich nicht in Wörterbüchern findet und damit Brute-Force-Attacken widersteht. Ferner sollten Sie das Passwort stets nur über sichere Kanäle übermitteln.

L2TP, das Layer 2 Tunneling Protocol, siedelt sich im OSI-Schichtenmodell oberhalb der IP- bzw IPSec-Schicht an. Es dient zum Transport der Datenpakete durch den IPSec-Tunnel. Es legt grundlegende Parameter des VPN-Netzwerks fest, etwa die IP-Adresse des VPN-Servers und den zur Verfügung stehenden IP-Adressraum sowie weitere Variablen, etwa die Erreichbarkeit des Domain-Name-Service.

Der PPPD (Point-to-Point Protocol Daemon) formt als letzte Instanz die Datenpakete und zeichnet in diesem Beispiel für die Punkt-zu-Punkt-Verbindung zwischen Client und Server verantwortlich. Er erledigt die Authentifizierung der Clients am Server anhand der Namen/Passwort-Paare sowie die finale Zuordnung der IP-Adressen. Darüber hinaus stellt er serverseitig die eigentliche Netzwerkschnittstelle dar, ähnlich eines Ethernet-Adapters. Abbildung 2 zeigt den serverseitigen Aufbau des VPN-Endpunkts.

Abbildung 2: Das serverseitige Ende des VPN-Tunnels und die Terminierung der einzelnen Schichten: IPSec, L2TP und PPP.

Serverkonfiguration

Zum Betrieb eines IPSec-Tunnels benötigen Sie die Pakete openswan, xl2tpd und ppp, die Sie in den Repositories aller gängigen Distributionen finden. Unter Ubuntu installieren Sie diese beispielsweise mit dem Aufruf

$ sudo aptget openswan xl2tpd ppp

Dabei stellt Openswan [5] die IPSec-Implementierung bereit und Xl2tpd [6] das L2TP-Gegenstück. Das Paket ppp ziehen die Paketmanager normalerweise automatisch als Abhängigkeit nach. Anschließend gilt es, Schicht für Schicht die einzelnen Teile zu konfigurieren.

IPSec beziehungsweise Openswan enthält drei Konfigurationsdateien. Die erste, /etc/ipsec.conf (Listing 1), dient zum eigentlich Setup von IPSec. Sie legt unter anderem fest, ob im lokalen Netz Network-Address-Translation (NAT) zum Einsatz kommt, welche Subnetze der Client nutzen darf, welche Verschlüsselung vorliegt und wie die IP-Adressen des VPN-Servers und des Routers im Netz lauten.

Ebenfalls regelt sie, wann eine Verbindung als tot (“dead peer”) gilt und was dann mit ihr geschieht. Dabei prüft der Server im Takt von dpddelay Sekunden die Verbindung geprüft und nach dpdtimeout Sekunden ohne Antwort die Verbindung als tot eingestuft. In unserem Fall ist ein Abbruch die einzig sinnvolle Art, mit einer toten Verbindung per dpdaction umzugehen.

version 2.0   # conforms to second version of ipsec.conf specification
config setup
  nat_traversal=yes
  virtual_private=%v4:10.0.0.0/8,%v4:172.16.0.0/12,%v4:192.168.0.0/16,%v4:!192.168.0.0/24
conn L2TP-PSK
  rekey=no
  authby=secret
  pfs=no
  keyingtries=3
  compress=no
  left=192.168.0.2
  leftnexthop=192.168.0.1
  leftprotoport=17/1701
  right=%any
  rightprotoport=17/%any
  rightsubnet=vhost:%priv,%no
  auto=add
  dpddelay=5
  dpdtimeout=30
  dpdaction=clear
include /etc/ipsec.d/examples/no_oe.conf

Die zweite Konfigurationsdatei, /etc/ipsec.d/examples/no_oe.conf (Listing 2) liegt in der Regel schon fertig vor. Sie wird nur in die ipsec.conf eingebunden, um gezielt die (in unserem Fall nicht genutzte) Funktion der opportunistischen Verschlüsselung zu deaktivieren. Die dritte Konfigurationsdatei im Bunde, /etc/ipsec.secrets (Listing 3), hält den PSK vor.

conn block
  auto=ignore
conn private
  auto=ignore
conn private-or-clear
  auto=ignore
conn clear-or-private
  auto=ignore
conn clear
  auto=ignore
conn packetdefault
  auto=ignore

192.168.0.2 %any: PSK "VPN-Schlüssel"

Die Konfiguration von L2TP erfolgt in der Datei /etc/xl2tpd/xl2tpd.conf (Listing 4). Die globalen Einstellungen enthalten die IP-Adresse sowie den Port, an dem der Daemon Anfragen entgegennimmt. Die Sektion darunter legt fest, welcher IP-Adressbereich dem VPN zur Verfügung steht, sowie die Adresse des Servers selbst. Wichtig ist an dieser Stelle die genaue Definition der Authentifizierung. Da das Protokoll PAP Nutzerdaten im Klartext überträgt, wählen Sie stattdessen das sicherere CHAP.

[global]
listen-addr = 192.168.0.2
port = 1701
[lns default]
ip range = 192.168.128.2-192.168.128.3
local ip = 192.168.128.1
require chap = yes
refuse pap = yes
require authentication = yes
name = My-Cloud7-VPN-Server
ppp debug = yes
pppoptfile = /etc/ppp/options.l2tpd
length bit = yes

Als letzten Schritt gilt es, den PPP-Daemon über die beiden Dateien /etc/ppp/options.l2tpd (Listing 5) und /etc/ppp/chap-secrets (Listing 6) zu konfigurieren. In der ersten Datei genügt es, mindestens eine IP-Adresse eines Domain-Name-Servers einzutragen, die meist der des eigenen Routers entspricht. In der zweiten Datei erfolgt pro Zeile für jeden Client die finale Zuordnung der Benutzerdaten (Namen und Passwort) zur IP-Adresse im VPN. Diese Zuordnung ist zwar nicht zwingend notwendig, hat aber den Charme der Eindeutigkeit, sodass sich zum Beispiel in weiteren Ausbaustufen die Clients individuell behandeln lassen.

ipcp-accept-local
ipcp-accept-remote
noccp
ms-dns 192.168.0.1
ms-dns DNS_des_Providers
auth
crtscts
idle 1800
mtu 1410
mru 1410
nodefaultroute
debug
lock
proxyarp
connect-delay 10000

# clientname    server client-secret  IP addressesMobilerClient_A *      "Passwort_A"   192.168.128.2MobilerClient_B *      "Passwort_B"   192.168.128.3

Jetzt fehlt am VPN-Server nur noch die Weiterleitung der IP-Pakete zwischen der VPN-Schnittstelle und dem realen Ethernet-Adapter, mit dem der Rechner ans lokale Netzwerk angeschlossen ist. Folgender Befehl aktiviert das Forwarding im Kernel:

$ sudo echo 1 > /proc/sys/net/ipv4/ip_forward

Damit die Änderung einen Neustart überlebt, gilt es in der Datei /etc/sysctl.conf die Zeile net.ipv4.ip_forward=1 hinzuzufügen oder das Hash-Zeichen (“#”) davor zu entfernen, um sie zu aktivieren.

Abschließend noch ein weiterer Hinweis in Sachen Sicherheit: Die beiden Dateien /etc/ipsec.secrets und /etc/ppp/chap-secrets, die den PSK beziehungsweise die Authentifizierungsdaten enthalten, dürfen nur für den Benutzer root les- und schreibbar sein. Gegebenenfalls ändern Sie die Dateirechte mit chown und chmod entsprechend.

Routing

Damit Geräte über das Internet den Server im heimischen Netz erreichen, gilt es sich mit den Einstellmöglichkeiten des xDSL-Routers vertraut zu machen. Die meisten Geräte dieser Art verfügen über eine webbasierte Konfigurationsoberfläche, die es relativ problemlos erlaubt, das notwendige Port-Forwarding einzurichten. Suchen Sie dazu im Menü Ihres Routers unter einem Punkt wie etwa erweiterte Einstellungen nach Begriffen wie NAT, Virtual Server oder auch Port Forwarding. In vielen Fällen bieten die Router bereits vorkonfigurierte Setups dafür, die Sie unter Begriffen wie L2TP IPsec VPN auswählen. Sollte das nicht der Fall sein, tragen Sie die weiterzuleitenden Ports per Hand ein – welche, das zeigt Listing 7.

Protokoll Quell-IP Port Ziel-IP     Port
UDP       all      4500 192.168.0.2 4500
UDP       all      500  192.168.0.2 4500
ESP       all      -    192.168.0.2 -

Was jetzt noch fehlt, ist vor allem die Erreichbarkeit des VPN-Clients aus der Cloud heraus: Der DSL-Router kennt von Haus aus nur die Route in das lokale Subnetz der Cloud, weiß aber nichts vom Subnetz des VPN, das bis jetzt nur der VPN-Server kennt. Entsprechend müssen Sie die Routing-Tabelle des Routers entsprechend ergänzen (Listing 8).

Ziel          Netzmaske     Gateway
192.168.128.1 255.255.255.0 192.168.0.2

Bietet Ihr Router diese Möglichkeit der Konfiguration nicht an, greifen Sie zum sogenannten IP-Masquerading: Dabei ersetzt das Kommando

$ sudo iptables -t nat -A POSTROUTING -s 192.168.128.0/24 -o eth0 -j MASQUERADE

im VPN-Server bei jedem Paket, das vom VPN kommt, die IP-Adresse durch jene des VPN-Servers im LAN. Auf diese Weise braucht der Router die Route zum VPN nicht explizit zu kennen: Er leitet einfach alle Pakete ins lokale Netz und erwischt dabei auf jeden Fall auch den VPN-Server, der dann die entsprechenden Pakete ins VPN zurückschleust.

Allerdings hat diese Vorgehensweise einen gravierenden Nachteil: Mit den eindeutig zugeordneten VPN-IP-Adressen kann man außerhalb des VPN-Servers nun so einfach nichts mehr anfangen.

Starten des VPN-Servers

Starten Sie vorbereitend zwei Terminals und verfolgen Sie im ersten Terminal mittels des Kommandos

$ sudo tail -f /var/log/syslog

die Systemmeldungen, welche das System beim Aktivieren des VPN-Servers dorthin schreibt. Im zweiten Terminal starten Sie den Server mit

$ sudo /etc/init.d/xl2tpd start

Erscheint im Systemprotokoll eine Meldung wie Unable to open /var/run/xl2tpd/l2tp-control for reading, was etwa bei Ubuntu 8.04.4 LTS der Fall ist, liegt die Ursache dafür sehr wahrscheinlich an einem fehlerhaften Startskript. Um es zu korrigieren, kopieren Sie den Inhalt aus Listing 9 in die Datei xl2tpd.diff in Ihrem Heimatverzeichnis und wechseln im Terminal ins Verzeichnis /etc/init.d, wo Sie folgenden Befehl ausführen:

$ sudo patch -p0 < ~/xl2tpd.diff

Beim nächsten Startversuch sollte dann die Meldung Listening on IP address 192.168.0.2, port 1701 im Systemlog erscheinen.

--- xl2tpd.old 2008-01-29 05:22:37.000000000 +0100
+++ xl2tpd   2011-09-11 16:30:59.000000000 +0200
@@ -27,6 +27,8 @@
 set -e
+mkdir -m 0755 -p /var/run/xl2tpd
+
 case "$1" in
  start)
    echo -n "Starting $DESC: "

Smartphones einrichten

In Android-Smartphones wie dem Samsung Galaxy S2 wechseln Sie in den Einstellungen zu Drahtlos und Netzwerke | VPN-Einstellungen | VPN hinzufügen. Aus dem erscheinenden Auswahldialog wählen Sie L2TP/IPsec PSK-VPN hinzufügen aus, worauf die Konfigurationsmaske für die entsprechende Verbindung erscheint. Füllen Sie diese wie in Abbildung 3 gezeigt aus.

Abbildung 3: VPN-Eingabemaske des Android-Smartphones Samsung Galaxy S2, im Beispiel der Mobile-Client-A.

Zum Start der VPN-Verbindung wechseln Sie in den Einstellungen in den Pfad Drahtlos und Netzwerke | VPN-Einstellungen und tippen auf den neu erstellten Eintrag, im Beispiel My-Cloud7. Zum Verbindungsaufbau geben Sie noch die Benutzerdaten ein (Abbildung 4). Das System merkt sich dabei zwar den eingegebenen Nutzernamen, nicht jedoch das Passwort, was aus sicherheitstechnischer Sicht durchaus Sinn ergibt.

Abbildung 4: Aufforderung zur Eingabe der Benutzerdaten beim Android-Smartphone zum Erstellen der VPN-Verbindung.

Sehr ähnlich sieht die Konfiguration eines iPhone4 unter dem Betriebssystem iOS 4.x aus. Im Menü erreichen Sie die Eingabemaske (Abbildung 5) über Einstellungen | VPN | VPN**hinzufügen und füllen diese aus. Aufgebaut wird die VPN-Verbindung, sobald Sie im Menü unter Einstellungen | VPN den Eintrag My-Cloud7 auswählen und den Schiebeschalter oben nach rechts schieben.

Abbildung 5: VPN-Eingabemaske des Apple iPhone 4 – hier der Mobile-Client-B.

Starten Sie nun mit einem Client den ersten Verbindungsaufbau, erscheinen im Erfolgsfall im Systemlog des Servers Meldungen, wie sie Listing 10 zeigt.

$ sudo tail -f /var/log/syslog
Sep 11 17:57:20 vpn-server xl2tpd[20752]: Connection established to 80.187.106.147, 49680. Local: 13158, Remote: 24616
Sep 11 17:57:20 vpn-server xl2tpd[20752]: start_pppd: I'm running:... Wiederholung von Teilen der L2TP-Konfiguration ...
Sep 11 17:57:20 vpn-server xl2tpd[20752]: Call established with 80.187.106.147, Local: 60116, Remote: 334, Serial: -2127911921
Sep 11 17:57:20 vpn-server pppd[21478]: pppd 2.4.4 started by root, uid 0
Sep 11 17:57:20 vpn-server pppd[21478]: using channel 4
Sep 11 17:57:20 vpn-server pppd[21478]: Using interface ppp0
Sep 11 17:57:20 vpn-server pppd[21478]: Connect: ppp0 <--> /dev/pts/1... Kette von sent/rcvd-Paketen zur Authentifizierung ...
Sep 11 17:57:20 vpn-server pppd[21478]: rcvd [CHAP Response id=0x33 <...>, name = "Mobile-Client-B"]
Sep 11 17:57:20 vpn-server pppd[21478]: sent [CHAP Success id=0x33 "Access granted"]... Kette von sent/rcvd-Paketen zum Aushandeln der Kommunikationsparameter ...
Sep 11 17:57:20 vpn-server pppd[21478]: local IP address 192.168.128.1
Sep 11 17:57:20 vpn-server pppd[21478]: remote IP address 192.168.128.3

Fazit

Haben Sie schon immer mit dem Gedanken gespielt, einen eigenen VDR-Heimserver aufzubauen? Etwa, um damit die erste Anwendung Ihrer eigenen Cloud zu realisieren, schnell mal das heutige Fußballspiel aufzuzeichnen und dann Ihren Freunden und Kollegen in der Kneipe damit zu imponieren? Vermutlich haben Sie diesen Gedanken aber schnell wieder verworfen, weil Sie keine Skript-Kiddies zu Gast auf Ihrem Rechner haben wollen und auch eventuell interessierten Behörden nicht gleich Ihre Aufzeichnungen ins Dossier diktieren möchten? Mit einem VPN kommunizieren Sie unbesorgt und sicher vor den Blicken Dritter mit Ihrem Heimnetz, als wären Sie selbst vor Ort. Das gilt nicht nur für Smartphones als Endgeräte, sondern für praktische alle internetfähigen Clients auf Basis von Linux, Android, iOS und sogar Windows.