Neuere Windows-Versionen ersetzen PPTP durch L2TP. Das Layer 2 Tunneling Protocol bietet aber selbst keine Sicherheitsfunktionen, daher kommt es zusammen mit IPsec zum Einsatz.

Um eine IPsec-Verbindung zwischen Freeswan und einem Windows-PC herzustellen, hat der Benutzer die Wahl zwischen einigen kommerziellen Produkten[1] und dem in Windows 2000 und XP bereits enthaltenen Client. Ohne erheblichen Zusatzaufwand[2] eignet der sich aber nur zum Tunneln von L2TP. Das Layer 2 Tunneling Protocol ist in RFC 2661 spezifiziert. Als Weiterentwicklung löst es die beiden nicht standardisierten Vorläufer PPTP (siehe Artikel in dieser Themen-Strecke) und Ciscos Layer 2 Forwarding (L2F) ab. Zu Letzterem ist L2TP abwärtskompatibel.

L2TP: Unten UDP, oben PPP

L2TP tunnelt eine PPP-Verbindung durch paketvermittelte Netzwerke, in IP-Netzen sendet es seine Pakete über UDP. Es bietet Funktionen, die IPsec nicht kennt oder die sich nur in nicht standardisierter Form nachrüsten lassen. Zum Beispiel transportiert es neben IP auch andere Protokolle, etwa IPX für den Zugriff auf ältere Netware-Server. Zudem kann es den Client vom Server aus konfigurieren, beispielsweise die IP-Adressen für das virtuelle Interface und die Adressen der Nameserver übermitteln.

Doch L2TP bietet keine nennenswerten Sicherheitsfunktionen, im Internet ist es nur zusammen mit IPsec sinnvoll einzusetzen. In der Folge sind recht viele Protokolle übereinander gestapelt, siehe Abbildung 1. Mit dem zusätzlichen Tunneln von PPP erreicht Windows, dass die Einwahl in ein VPN genauso funktioniert wie die Einwahl ins Internet, auch für den Benutzer sieht es identisch aus. Der Verbindungsaufbau läuft in vier Schritten ab:

• Der PC wählt sich ins Internet ein
• Er baut dann eine IPsec-Verbindung zum Freeswan-Server auf, beide müssen gültige Zertifikate vorlegen
• Über die IPsec-geschützte Verbindung startet der Client einen L2TP-Tunnel
• Im L2TP-Tunnel baut er eine PPP-Verbindung auf, der Benutzer muss ein Passwort angeben

Der L2TP-Tunnelanfang heißt LAC (L2TP Access Concentrator), der Ausgang nennt sich LNS (L2TP Network Server). Der Eingang ist meist direkt im Client-Rechner in Software realisiert. Sein Name verrät aber, dass er auch als externes Gerät implementiert sein kann – zum Beispiel auf einem Network Access Server beim Provider (Abbildung 2). Dort würde er die PPP-Verbindungen der Clients in ihre jeweiligen Zielnetze weiterleiten.

Die IPsec-Schicht

Das VPN-Gateway benötigt einige Freeswan-Features, die im Standardumfang nicht enthalten sind: X.509-Zertifikate, Port Selectors und Delete/Notification. Am einfachsten ist es daher, das umfassende Super-Freeswan[3] zu installieren. Vorsicht: Einige der darin enthaltenen Patches sollten bei der Kernel-Konfiguration deaktiviert bleiben, besonders Single-DES-Unterstützung und der Aggressive Mode sind aus Sicherheitsgründen abzulehnen.

Listing 1 zeigt eine minimale Beispielkonfiguration. Sie berücksichtigt, dass der Windows-Client die Perfect Forward Secrecy ablehnt (Zeile 15) und die IPsec-Verbindung auf bestimmte Protokoll/Port-Werte festlegt. Das Authentifizieren erfolgt Zertifikat-basiert (siehe Freeswan-Artikel in dieser Strecke).

Die Schlüsselinformationen müssen, damit Windows sie später einlesen kann, im PKCS#12-Format (Public Key Cryptography Standards) abgelegt sein. Ein OpenSSL-Kommando fügt die nötigen Bestandteile zusammen: Client-Schlüssel, Client-Zertifikat und das CA-Zertifikat schreibt es in die Datei »VPN-Client.p12« und schützt sie mit einem Passwort:

openssl pkcs12 -export 
  -password pass:Sehrgeheim 
  -chain -name "VPN-Client" 
  -inkey  "VPN-Client.key" 
  -in     "VPN-Client.cert.pem" 
  -CAfile "cacert.pem" 
  -out    "VPN-Client.p12"

Abbildung 1: Bei L2TP über IPsec sammeln sich viele Protokolle an. Die Internet-Einwahl mit PPP ist die Basis für eine IP-Kommunikation inklusive IPsec. Auf UDP-Port 1701 arbeitet dann der L2TP-Tunnel, der eine PPP-Verbindung zum VPN-Gateway herstellt und darüber wieder IP anbietet.

Der L2TP-Daemon

Google findet mindestens drei Open-Source-Implementierungen von L2TP für Linux, von denen zur Zeit aber nur »l2tpd«[4] in aktiver Entwicklung ist. Um ihn stabil zur Zusammenarbeit mit Windows zu bewegen, muss die aktuelle Version 0.69 noch gepatcht werden. Jacco de Leeuw stellt eine hervorragende Dokumentation und fertige gepatchte RPMs zur Verfügung[5].

Nach der Installation enthält »/etc/l2tpd/l2tpd.conf« eine Minimalkonfiguration (siehe Listing 2) für einen LNS, in der nur noch die IP-Adressen angepasst werden müssen. Die »ip range« gibt einen Pool von Adressen an, aus dem der »l2tpd« den Clients dynamisch Adressen zuweist.

Der »l2tpd« reicht nun die entgegengenommenen PPP-Verbindungen an den »pppd« weiter, der beim Start die Konfigurationsdatei »/etc/ppp/options.l2tpd« einliest. Dort sollten die IP-Adressen von DNS- und eventuell WINS-Servern, die der VPN-Client benutzen soll, angegeben werden.

Als Authentifizierungsverfahren kommt mit dieser Konfiguration – wie unter Windows üblich – CHAP zum Einsatz. Benutzernamen und Passwörter stehen in der »/etc/ppp/chap-secrets«, die IP-Adresse ist in diesem File optional. Ist sie angegeben, weist der »pppd« sie dem Client anstelle der vom »l2tpd« vorgeschlagenen Pool-Adresse zu.

Der »l2tpd«-Server bindet sich an den UDP-Port 1701. Dieser Port ist unbedingt zu schützen: Ein Paketfilter sollte bereits vor dem VPN-Gateway installiert sein. Zusätzlich empfiehlt sich eine lokale Netfilter-Regel, die den Zugriff auf den Port nur Paketen gestattet, die von einem IPsec-Interface kommen. Nur sie wurden von Freeswan authentifiziert:

iptables -I INPUT -p udp --dport 1701 
  ! -i ipsec+ -j DROP

Abbildung 2: Ein LAC (L2TP Access Concentrator) kann als eigenständiges Gerät beim Netzwerkprovider stehen. Er leitet dann die PPP-Verbindungen durch das Backbone weiter zu verschiedenen L2TP-Network- Servern (LNS). Diese senden die Daten in die jeweiligen Zielnetze.

Die Windows-Software

Das Betriebssystem muss auf dem aktuellen Stand sein. Erfolgreich getestet hat der Autor Windows 2000 mit Service Pack 4 und Windows XP ohne Service- Paket, beide mit allen verfügbaren Sicherheitsupdates.

Als Erstes muss der Windows-Administrator (normalen Benutzern fehlen die Rechte) die vorbereiteten Zertifikate in den Zertifikatspeicher des Computers (nicht des Benutzers) einlesen. Der komplizierteste Teil dabei ist das Zusammenklicken einer Managementkonsole:

• Managementkonsole starten: »Start | Ausführen | mmc«
• Snap-In hinzufügen: »Datei | Snap-In hinzufügen/entfernen«
• Darauf achten, dass die Zertifikatkonsole für den Computer und nicht die Benutzer gilt: »Hinzufügen | Zertifikate | Computerkonto | Lokaler Computer | Fertig stellen«

Das neue Snap-In kann das PKCS#12-Paket einlesen (siehe Abbildung 3):

• Rechtsklick auf »Konsolenstamm | Zertifikate (Lokaler Computer) | Eigene Zertifikate«
• Im Kontextmenü »Alle Tasks | Importieren« und dann die »*.p12«-Datei auswählen E
• Aufpassen, dass Windows die Zertifikate auch am richtigen Ort speichert: »Zertifikatspeicher automatisch auswählen«.

Das Client-Zertifikat landet im Bereich »Eigene Zertifikate«, das CA-Zertifikat dagegen in »Vertrauenswürdige Stammzertifikate«.

01 conn %default
02    keyingtries=0
03    disablearrivalcheck=no
04    authby=rsasig
05    leftrsasigkey=%cert
06    left=%any
07    leftprotoport=17/1701
08    rightrsasigkey=%cert
09    rightcert="/etc/ipsec.d/private/VPN-Gateway.pem"
10    rightid="/C=DE/L=D-37075 Goettingen/O=Tux/CN=VPN-Gateway"
11    right=193.175.27.131
12    rightnexthop=%defaultroute
13    rightprotoport=17/0
14    auto=add
15    pfs=no
16 
17 conn w2k-client
18    leftid="/C=DE/L=D-37075 Goettingen/O=Tux/CN=VPN-Client"

01 [global]
02 ; listen-addr = 192.168.1.98
03 
04 [lns default]
05 ; Aus diesem Bereich erhalten die Clients Adressen,
06 ; es sei denn chap-secrets schreibt andere vor.
07 ip range = 192.168.2.1-192.168.2.50
08 ; Adresse des Tunnelendpunkts auf dem LNS
09 local ip = 192.168.2.254
10 require chap = yes
11 refuse pap = yes
12 require authentication = yes
13 name = VPNGATE
14 ppp debug = yes
15 pppoptfile = /etc/ppp/options.l2tpd
16 length bit = yes

VPN-Verbindung unter Windows konfigurieren

Der weitere Weg ist unterschiedlich für Windows XP beziehungsweise 2000. Bei XP lässt sich die VPN-Verbindung wie folgt konfigurieren:

• »Start | Programme | Zubehör | Kommunikation | Assistent für neue Verbindungen«
• Im Assistenten »Verbindung mit dem Netzwerk am Arbeitsplatz herstellen« und dann »VPN-Verbindung« auswählen
• Name für die Verbindung eingeben
• Internetverbindung auswählen, die automatisch gewählt werden soll
• Hostname des VPN-Servers (oder dessen IP-Adresse) eingeben
• Nur »eigene Verwendung« zulassen
• »Fertig stellen«

Bei Windows 2000 tragen einige Optionen andere Namen, auch der Ablauf weicht in einigen Details von XP ab:

• »Start | Einstellungen | Netzwerk- und DFÜ-Verbindungen | Neue Verbindung erstellen«
• Im Assistenten (Abbildung 4) »Verbindung mit einem privaten Netzwerk über das Internet herstellen«
• Internetverbindung auswählen, die automatisch gewählt werden soll
• Hostname des VPN-Servers (oder dessen IP-Adresse) eingeben
• Die Option »Nur selbst verwenden« auswählen
• Name der Verbindung eingeben
• »Fertig stellen«

Unter »Netzwerkverbindungen« erscheint nun ein neues Icon, das die VPN-Verbindung herstellt.

Bei Windows 2000 ist es eventuell erforderlich, die Verschlüsselung innerhalb der PPP-Schicht abzuschalten (in den Optionen unter »Sicherheit | Datenverschlüsselung ist erforderlich«, siehe Abbildung 5). Sie ist unnötig, da die Daten bereits von IPsec verschlüsselt sind. Zudem ist der PPP-Daemon von Linux häufig ohne Unterstützung für PPP-Verschlüsselung kompiliert.

Abbildung 3: In der Managementkonsole liest der Administrator die PKCS#12-Datei ein. Sie enthält alle Schlüsseldaten für die VPN-Einwahl: Client-Key, Client-Zertifikat und das Zertifikat der CA (Certification Authority).

Abbildung 4: Der Netzwerkverbindungs-Assistent von Windows 2000 bietet eine VPN-Verbindung zur Auswahl, aus Sicht des Benutzers funktioniert sie wie eine Internet-Einwahl. Es handelt sich um die Kombination aus L2TP und IPsec.

Abbildung 5: Mit der Option »Datenverschlüsselung ist erforderlich« verlangt Windows 2000 eine Verschlüsselung innerhalb des PPP-Protokolls. Sie ist aber wegen IPsec unnötig und funktioniert mit den meisten Linux-Servern auch nicht.

Kein NAT-Traversal

Befindet sich der Client hinter einem NAT-Router (Network Address Translation), muss IPsec NAT-Traversal durchführen. Es kapselt die Daten dazu ein weiteres Mal in UDP. Microsoft bietet für Windows 2000 einen Hotfix an, der NAT-T nachliefert, jedoch kennt das NAT-T-Patch für Freeswan den von Windows verwendeten Identification Type nicht. Es ist aber zu erwarten, dass Freeswan das Verfahren bald unterstützt. Den entsprechenden Hotfix für Windows XP hat Microsoft wieder von den Update-Servern entfernt, da er zu Verbindungsproblemen führen soll. Zurzeit beherrscht der XP-Client NAT-T nicht. (fjl)