Cipe ist eine robuste und recht einfach zu benutzende VPN-Technik. Da es IP-Pakete in UDP verpackt, überwindet das Crypto-IP-Encapsulation-Protokoll spielend NAT- und Socks-Geräte.

Cipe, die Crypto IP Encapsulation[1], überträgt IP-Pakete verschlüsselt in UDP-Paketen. Über die UDP-Ports lassen sich mehrere Endpunkte auf einem Host leichter unterscheiden als bei IP-in-IP-Tunneln, es sind keine zusätzlichen Verbindungs-IDs nötig. Aus Sicht der Firewalls, Socks-Proxies und NAT-Geräte (Network Address Translation) handelt es sich um ein gewöhnliches UDP-Protokoll, Cipe kann damit komplett auf der bestehenden IP-Infrastruktur aufsetzen.

Linux und Windows

Die Cipe-Implementierung (GPL-lizenziert) ist für Linux und Windows verfügbar[2]. Für die Linux-Variante ist ein Kernelmodul nötig, das die meisten Distributionen bereits mitliefern. Das Modul ist für das Senden und Empfangen der IP-Pakete zuständig, es legt dazu ein Netzwerk-Device »cipcb*« an (siehe Abbildung 1). Der Name des Interface enthält nach dem Text »cip« ein Kürzel für die Protokollversion (»c« steht für Version 3) und den Verschlüsselungsalgorithmus (im Beispiel »b« für Blowfish); der Algorithmus wird bereits beim Übersetzen des Moduls festgelegt.

Die Cipe-Interfaces verhalten sich wie normale Netzwerkdevices, sie tauchen unter anderem als Hostrouten in der Routingtabelle auf. Damit ist es auch möglich, zusätzliche Routen über dieses Interface mit Hilfe von »/etc/cipe/ip-up« einzutragen oder Firewall-Regeln darauf anzuwenden.

Das Netzwerk-Analysewerkzeug Ethereal eignet sich gut, um den verschlüsselten UDP-Traffic zu beobachten. Abbildung 2 zeigt einen Ping mit Antwort; die beiden Rechner stehen an verschiedenen Enden des VPN-Tunnels. Auf das »cipcb0«-Interface angewendet, würde das Tool die Pakete im Klartext anzeigen.

Im Userspace läuft der Hintergrunddienst »ciped«. Dieser Daemon ist mit »pppd« vergleichbar: Er öffnet und schließt das Netzwerkinterface und beachtet dabei die aktuelle Konfiguration.

Flottes VPN

Verschlüsselungsrouter auf Basis von Cipe sind sehr leistungsfähig mit gemessenen Datentransferraten, die nur zwei bis drei Prozent unter denen des unverschlüsselten Verkehrs liegen. Tunnellösungen mit komplexeren Protokollen wie MPPE/PPTP oder PPP über SSH büßen dagegen 15 bis 20 Prozent ein.

UDP als Transportprotokoll vermeidet subtile Interaktionen, die durch mehrere übereinander gestapelte TCP-Layer entstehen. Wenn zwei Flusssteuerungen und Fehlerkorrekturen den Datenstrom bearbeiten, wird das Gesamtergebnis nicht besser[3]. Cipe-Tunnel sind darüber hinaus sehr robust. Sie können durchaus mehrere Wochen durchgehend laufen, wenn sich die IP-Daten der Verbindungsendpunkte nicht ändern.

Tunnel-Grabung

Die meisten Linux-Distribution haben Cipe bereits in ihrem Lieferumfang, sie legen üblicherweise ein Startskript sowie das Konfigurationsverzeichnis »/etc/ cipe/« an. Das Kernelmodul »cipcb« wird entweder gleich automatisch mit dem Start des Cipe-Daemon geladen oder manuell per »insmod cipcb«.

Für jeden Cipe-Tunnel ist eine eigene Konfigurationsdatei erforderlich. SuSE beispielsweise installiert eine Vorlage als »/etc/cipe/option«. Wer mehr als einen Tunnel braucht, ergänzt dazu am besten diesen Namen mit einem Punkt und einem symbolischen Namen für die VPN-Verbindung, zum Beispiel »/etc/cipe/option.example-vpn«. Ein einzelnes, gemeinsames Init-Skript kann dann alle Konfigurationen einlesen, die mit »option.*« beginnen.

Für das Beispiel-VPN in Abbildung 3 sind die Konfigurationsdateien aus den Listings 1 und 2 zuständig. Das interne Interface des VPN-Routers im linken Subnetz hat die Adresse 192.168.2.254. In der Konfiguration der linken Seite ist diese Adresse als »ipaddr« angegeben, auf der rechten Seite als »ptpaddr«. Ähnliches gilt für 192.168.4.254, die interne Adresse des rechten Routers, nur sind hier die Seiten vertauscht. Vom Internet aus sind die beiden Endpunkte als 202.38.21.24 (links) und 62.137.15.134 (rechts) zu erreichen: Diese Adressen sind, zusammen mit der Portnummer, als »me« (gleiche Seite) und »peer« (Gegenüber) eingetragen.

Das Beispiel geht davon aus, dass beide Seiten statische IP-Adressen verwenden (hier 62.137.15.134 und 202.38.21.24). In diesem Fall können beide Tunnelendpunkte das VPN selbst starten. Privatanwender mit einer Dial-up-Leitung erhalten allerdings in den meisten Fällen dynamischen Adressen. Hat die Gegenstelle eine statische IP, dann muss diese nur auf eingehende Verbindungen warten und daraus die IP-Adresse des Heimrechners ermitteln.

Um den Verbindungsaufbau der statischen Seite zu blockieren, sollte der Admin dort die »peer«-Adresse auf »localhost« und Discard-Port »9« setzen. Die Anzahl der erlaubten Fehlversuche legt er mit dem Wert »-1« auf unendlich fest, somit bricht »ciped« seine eigenen Versuche nicht ab und wartet weiter auf eingehende VPN-Wünsche.

me      134.34.80.5:11153
peer    127.0.0.1:9
maxerr  -1

Die Seite mit der dynamischen IP-Adresse erhält folgende Einstellungen:

me      0.0.0.0:10000
peer    134.34.80.5:11153
dynip

Nur dieser Rechner kann die Verbindung initiieren. Haben beide Seiten eine dynamische Adresse, muss der VPN-Admin auf DNS-Namen ausweichen, die über Dienste wie Dyndns ständig auf die aktuelle IP verweisen. Dennoch können Probleme auftreten, wenn beide Seiten ihre IP ändern.

Abbildung 1: Das Cipe-Kernelmodul erzeugt ein neues Netzwerk-Device »cipcb0«. Die Linux-Standardkommandos »ifconfig« und »ip« fördern die aktuellen Daten dieses Device zu Tage.

Abbildung 2: Der Rechner mit der IP-Adresse 132.230.9.124 kommuniziert mit 217.82.244.83. Dass es sich dabei um Pings und die Antworten darauf handelt, kann Ethereal dank Cipe-VPN nicht entdecken.

Schlüsseltausch

Cipe 1.5 kann erstmals ein Public-Key-Verfahren für die Authentifizierung und zum Ermitteln des Session-Keys benutzen: »pkcipe« arbeitet mit einem RSA-Schlüsselpaar, das der Admin mit Hilfe der OpenSSL-Tools erzeugen muss. Innerhalb der VPN-Verbindung benutzt PKCipe dann einen Diffie-Hellmann-Key-Exchange, um den Sitzungsschlüssel zu bestimmen.

Einfacher und weniger fehleranfällig ist es, in den Konfigurationen einen gemeinsamen geheimen Schlüssel mit 128 Bit Länge zu verwenden. Generieren lässt er sich mit einem Kommando der folgenden Art:

echo "this is my keyphrase"|md5sum

Das Ergebnis muss der künftige VPN-Admin an beide Tunnelenden kopieren. Diesen Schlüssel benutzt Cipe dann zur Authentifizierung sowie als Basis für die Sitzungsschlüssel. Letztere werden vom Protokoll aus Sicherheitsgründen regelmäßig erneuert.

Die realen Adressen der beiden Tunnelendpunkte und die virtuellen Tunneladressen müssen sich in jedem Fall unterscheiden. Zusätzlich definierte Routen und Firewall-Regeln sollte man sicherheitshalber nur in das »ip-up«-Skript von Cipe eintragen und mittels »ip-down« auch wieder löschen.

01 # option.example-vpn left side
02 
03 # The peer's IP address
04 ptpaddr 192.168.4.254
05 
06 # Our Cipe device's IP address
07 ipaddr  192.168.2.254
08 
09 # My UDP address. Note: if you set port 0 here,
10 # the system will pick one and tell it to you via
11 # the ip-up script. Same holds for IP 0.0.0.0.
12 me      202.38.21.24:10001
13 
14 # ...and the UDP address we connect to.
15 # Of course no wildcards here.
16 peer    62.137.15.134:10000
17 
18 # The static key. Keep this file secret!
19 # The key is 128 bits in hexadecimal notation.
20 key     0219e5bfcae114c9203e2e26f048e21d

01 # option.example-vpn right side
02 
03 # The peer's IP address
04 ptpaddr 192.168.2.254
05 
06 # Our Cipe device's IP address
07 ipaddr  192.168.4.254
08 
09 # My UDP address. Note: if you set port 0 here,
10 # the system will pick one and tell it to you via
11 # the ip-up script. Same holds for IP 0.0.0.0.
12 me      62.137.15.134:10000
13 
14 # ...and the UDP address we connect to.
15 # Of course no wildcards here.
16 peer    202.38.21.24:10001
17 
18 # The static key. Keep this file secret!
19 # The key is 128 bits in hexadecimal notation.
20 key     0219e5bfcae114c9203e2e26f048e21d

Fazit

Cipe ist ein robustes und effizientes Verschlüsselungssystem für VPN-Verbindungen. Weniger komplex als IPsec und dazu auch inkompatibel, ist diese Alternative einfacher einzurichten – und sie arbeitet effizienter. Die Einfachheit endet jedoch bei virtuellen Netzen mit vielen Teilnehmern, die untereinander direkt kommunizieren wollen. Cipe ist für die stärker verbreiteten Punkt-zu-Punkt-Verbindungen ausgelegt.

Das VPN-Protokoll eignet sich gleichermaßen für Roadwarrior- und IP-Tunnel-Szenarien, es kann einzelne Rechner oder ganze Netze verbinden. Für jeden Tunnel ist nur ein eigenes Interface einzurichten. Damit sind Verbindungen von einzelnen Mitarbeitern oder ganzen Außenstellen an eine Zentrale einfach realisierbar, jedoch nicht kompatibel zu anderen Sicherheitsprodukten.

Sehr praktisch ist es, dass Cipe auf UDP aufsetzt: So gelingt auch ein Transport über Masquerading- oder NAT-Gateways hinweg. Da der Admin die Ports für jede Verbindungsrichtung festlegen kann, lassen sich Firewall-Regeln einfach danach ausrichten. Mit einem Linux- und einem Windows-Client ist die Unterstützung für die beiden Mainstream-Desktop- beziehungsweise -Serversysteme für kleinere und mittlere Unternehmen und Organisationen abgedeckt.

Ein Problem hat Cipe mit Freeswan und dem Cisco-IPsec-Client für Linux gemeinsam: Es verwendet ein Kernelmodul, das dem Standardkernel nicht beiliegt! Mit jedem Kernelupdate muss der Admin also zusätzlich ein aktuelles Cipe-Modul übersetzen. (fjl)

Abbildung 3: Die beiden Subnetze 192.168.2.0/24 und 192.168.4.0/24 sind mit einem Cipe-VPN sicher über das Internet verbunden. Von außen sind die beiden VPN-Router unter ihren öffentlichen Adressen 202.38.21.24 und 62.137.15.134 zu erreichen.