VPN-Daemon im Userspace: Tinc

Tinc ist ein VPN-Daemon, der ohne Kernelmodifikation ganze Netze tunnelt. Besonders bei größeren VPN- Installationen wird sich der Admin über die einfache Konfiguration freuen: Zusätzliche Knoten sind deutlich schneller integriert als bei Freeswan.

Für Tinc als Alternative zum allgegenwärtigen Freeswan sprechen einige Argumente: Es benötigt kein Kernel-Patch, das Programm arbeitet nur im Userspace. Es verwendet sehr einfache Konfigurationsdateien, die Administrationsfehler fast ausschließen. Tinc kann auch Nicht-IP-Verkehr über den Tunnel transportieren und schützen: Jedes Paket, das in einen Ethernet-Rahmen passt, lässt sich auch mit dieser Technik tunneln. Freeswan schützt dagegen nur IPv4-Pakete. Schließlich ist Tinc sehr klein und schont die Host-Ressourcen; die ausführbare Datei ist lediglich 80 KByte groß, auch der laufende Prozess belegt nur wenig Speicher.

Vor- und Nachteile

Tinc weist jedoch auch einige Nachteile auf. So verwendet es kein Standardprotokoll, daher sind interoperable Lösungen zwischen verschiedenen Betriebssystemen nicht immer möglich – seit Version 1.0 ist jedoch eine native Win32-Unterstützung enthalten. Die Verschlüsselung im Userspace ist langsamer als im Kernel, da die Daten öfter kopiert werden müssen. Außerdem hatte das Protokoll in der Vergangenheit einige Schwächen (siehe Kasten “Sicherheitslücken”), die sich durch ein Standardprotokoll hätten vermeiden lassen.

Sicherheitslücken

Im August 2000 wurde eine Sicherheitslücke in dem Schlüsselaustausch von Tinc entdeckt. Die Lücke war in allen Version bis einschließlich 1.0pre2 zu finden, sie ist aber inzwischen behoben. Für den Schlüsselaustausch ist nun die bewährte OpenSSL-Bibliothek zuständig, die Authentifizierung nutzt RSA-Schlüssel mit 1024 Bit Länge.

Jerome Etienne untersuchte das Tinc-Protokoll der Version 1.0pre4 und veröffentlichte am 29. Dezember 2001 seine Ergebnisse[3]. Er bemängelte das Fehlen einer Sequenznummer und einer Paketauthentifizierung. So gab es keinen Schutz vor Replay-Angriffen oder einer Modifikation der Pakete. Diese Lücken sind seit Version 1.0pre5 geschlossen. Tinc verfügt nun wie andere VPN-Protokolle (etwa IPsec) über eine Sequenznummer und einen Message Authentication Code (MAC), mit dessen Hilfe der Empfänger jede Modifikation der Pakete erkennt.

Zudem bemerkte Jerome, dass Tinc einen sehr kurzen (nur 16 Bit) zufälligen Initialisierungsvektor (IV) verwendete. Der IV ist im CBC-Modus erforderlich, er sollte möglichst lang und einzigartig sein. Da Tinc ihn zufällig bestimmte, konnte es die Einzigartigkeit nicht garantieren. Nun verwendet das Protokoll die Sequenznummer als IV. Diese ist 32 Bit lang und (eingeschränkt) einzigartig. Leider sind durch die Überarbeitungen des Protokolls Versionen vor 1.0pre8 nicht mehr kompatibel zu den aktuellen Versionen.

Damit bestätigt sich, dass nicht standardisierte Protokolle häufig Fehler in ihrem Design aufweisen. Diese können aber im Fall von Open-Source-Produkten schnell gefunden und behoben werden. Tinc ist ein positives Beispiel für diese These.

Installation

Tinc ist erst kürzlich in der stabilen Version 1.0 erschienen (unter der GPL). Sie ist kompatibel zu Tinc 1.0pre8, aber nicht zu älteren Versionen. Zum Übersetzen sind OpenSSL (0.9.7), ein aktuelles »gettext«-Paket (0.12) sowie die Zlib- und die LZO-Bibliothek erforderlich.

./configure
make
make install

Da die Installation besonders auf Red Hat Linux 9 problematisch ist, stellt der Autor unter[2] RPM-Pakete für diese Distribution zur Verfügung.

Tinc verwendet für die Kommunikation mit dem Linux-Kernel entweder den »ethertap«-Treiber (Linux 2.2) oder den universellen TUN/TAP-Treiber (Linux-Kernel ab 2.4, Abbildung 1). Ob der aktuelle Kernel diese Treiber enthält, ist schnell geklärt: »modinfo tun« sollte den Pfad zum Modul ausgeben. Zudem läuft Tinc auf FreeBSD, OpenBSD, NetBSD, Solaris und Mac OS X sowie Windows. Letzteres bedient sich des Cipe-Treibers, der unter Windows 2000 und XP funktioniert – für ältere Windows-Versionen ist eine Cygwin-Umgebung nötig.

Abbildung 1: Im Linux-Kernel 2.4 muss unter »Network device support« der »Universal TUN/TAP device driver support« aktiviert sein. Üblicherweise ist er als Modul ausgewählt.

Tunnel graben

Im Gegensatz zu anderen VPN-Implementierungen muss der Admin bei Tinc keine Tunnel, sondern lediglich deren Endpunkte definieren. Das erleichtert die Konfiguration ungemein, da er sonst bei vier Endpunkten bereits sechs Tunnel definieren müsste. Tinc unterscheidet auch nicht zwischen Client und Server: Jeder Tinc-Daemon ist gleichzeitig Client und Server.

Die Konfigurationsdatei »/etc/tinc/tinc.conf« ist in Listing 1 zu sehen, sie bildet die Basis für das VPN aus Abbildung 2. Zusätzlich muss der Administrator für jeden angegebenen Namen (Berlin, Paris und London) eine Datei im Verzeichnis »/etc/tinc/hosts/« erzeugen. In »/etc/tinc/hosts/Berlin« muss er beispielsweise folgende zwei Zeilen einfügen:

Listing 1: Tunnel-Endpunkte

Name = Berlin
ConnectTo = London
ConnectTo = Paris
Device = /dev/net/tun
PrivateKeyFile = /etc/tinc/rsa_key.priv

Abbildung 2: Tinc erlaubt es dem Administrator, VPNs mit vielen Endpunkten sehr einfach aufzubauen und zu konfigurieren. Er muss für jeden zusätzlichen Knoten nur zwei Konfigurationsdateien anpassen.

Address = berlin.spenneberg.org
Subnet = 192.168.2.0/24

Der »Address«-Eintrag gibt den DNS-Namen oder die IP-Adresse des Rechners Berlin an. Das »Subnet« definiert das Netzwerk, das sich hinter diesem Endpunkt befindet und über das VPN kommuniziert.

Für die gegenseitige Authentifizierung der Endpunkte erzeugt der VPN-Admin noch ein RSA-Schlüsselpaar: »tincd -K« speichert den privaten Kex in »/etc/tinc/rsa_key.priv«, den öffentlichen hängt das Tool an die entsprechende Datei im Verzeichnis »/etc/tinc/hosts/« an.

Sobald Tinc seinen Partner authentifiziert hat, erzeugt es ein neues Netzwerk-Device, über das die VPN-Kommunikation stattfindet. Die Konfiguration dieser Karte liegt in der Datei »/etc/tinc/ tinc-up«. Sie enthält folgende Zeile:

ifconfig $INTERFACE 192.168.0.1 netmask 
255.255.0.0

Wichtig ist die Wahl der Netzmaske. Sie muss alle Netzwerke, die über das VPN kommunizieren, zusammenfassen – sozusagen ein Supernetting.

Hat der Administrator alle Rechner konfiguriert, alle Schlüssel erzeugt und die »/etc/tinc/hosts/*«-Dateien untereinander ausgetauscht, kann er »tincd« auf den Rechnern starten. Die Reihenfolge ist dabei unproblematisch.

Blick hinter die Kulissen

Jeder Tinc-Tunnel besteht aus zwei Verbindungen, beide nutzen den Port 665 (TCP und UDP). Die Entwickler haben diesen Port sogar bei der IANA registriert, folgender Eintrag in »/etc/services« ist damit zulässig:

tinc    665/tcp TINC
tinc    665/udp TINC

Tinc verwendet das UDP-Protokoll, um die verschlüsselten Pakete auszutauschen. Es benutzt den Blowfish-Algorithmus (konfigurierbar) mit 128 Bit Schlüssellänge im CBC-Modus (Cipher Block Chaining). Zusätzlich verwendet Tinc eine 32 Bit lange Sequenznummer und einen 4 Byte langen Message Authentication Code (MAC, die Länge ist konfigurierbar). Diesen MAC berechnet es per SHA-1-Algorithmus aus dem Paket. Die Sequenznummer und der MAC stellen sicher, dass das Protokoll gegen Replay-Angriffe gewappnet ist.

Bevor Tinc die Pakete jetzt verschlüsseln kann, muss es seinen Partner noch authentifizieren und die symmetrischen Sitzungsschlüssel generieren. Über die TCP-Verbindung tauscht es diese Metadaten aus. Aus diesem Grund heißt die Verbindung in der Tinc-Dokumentation auch Metaverbindung.

Fazit

Tinc ist eine ausgereifte Anwendung, mit der sich sehr einfach und schnell auch komplizierte VPN-Szenarien implementieren lassen. Die Interoperabilität ist zwar noch nicht mit allen Betriebssystemen gewährleistet, neben Linux ist Tinc aber auch für viele BSD-Varianten verfügbar sowie für Solaris, Mac OS X und Windows. (fjl)