VPN mit Tinc

Aus ADMIN 02/2009

Zu groß, zu langsam, zu unflexibel. So waren die bestehenden VPN-Programme und Protokollstandards in den Augen von Guus Sliepen und Ivo Timmermans. Also entwickelten sie kurzerhand ihr eigenes Protokoll samt Referenzimplementierung, nannten das erste brauchbare Ergebnis Tinc und veröffentlichten es unter der GPL. Seitdem sind über 10 Jahre vergangen und noch immer treiben die beiden ihr Projekt mutig voran -- und haben dabei ein paar Schwachpunkte der Konkurrenz von vorn herein vermieden.

So legten die Entwickler die Konfigurationsdateien absichtlich sehr einfach an, was nicht nur eine schnelle Einrichtung ermöglicht, sondern auch Administrationsfehler minimiert. Gleichzeitig lässt sich ein mit Tinc aufgebautes VPN schnell erweitern: Jeder neu angestöpselten Knotenpunkt benötigt nur eine weitere Konfigurationsdatei. Anschließend ist noch nicht einmal ein Neustart der VPN-Software notwendig. Das eingebaute Routing sorgt dafür, dass die Informationen möglichst auf direktem Weg ihre Ziele erreichen. Tinc erlaubt so den raschen und flexiblen Aufbau von verschlüsselten, vermaschten Netzen (,,Mesh Networking``). Darüber hinaus lässt sich das VPN als Bridge missbrauchen, die mehrere Ethernet-Segmente zu einem einzelnen, großen zusammenfasst. Auf diese Weise lassen sich sogar Anwendungen über das Internet nutzen, die sonst nur in einem LAN funktionieren. Schließlich läuft Tinc auf allen aktuellen Betriebssystemen, einschließlich Windows XP. Das neue Vista steht allerdings noch nicht auf der Kompatibilitätsliste.

Erdarbeiten

Wer das Tinc-Paket von seiner Homepage lädt, findet darin einen kleinen Daemon, der vollständig im Userspace läuft und im Gegensatz zu mancher Konkurrenz keinerlei Anpassungen im Kernel verlangt. Nach seinem Start richtet er auf seinem Wirtscomputer eine neue, virtuelle Netzwerkschnittstelle ein. Alle darüber verschickten Informationen verschlüsselt er, komprimiert sie und sendet sie schließlich über eine herkömmliche Netzwerkverbindung zur Gegenstelle. Dort nimmt ein weiterer Tinc-Daemon die Datenpakete in Empfang, entpackt und entschlüsselt sie wieder, bevor sie über die dortige virtuelle Netzwerkschnittstelle ihre Zielanwendung erreichen. Tinc bohrt gewissermaßen einen von der Außenwelt abgeschirmten Tunnel durch das Internet, man spricht daher auch neudeutsch von Tunneling. Da sich die virtuellen Netzwerkschnittstellen, also die Tunneleingänge, nach außen ähnlich wie echte Netzwerkkarten verhalten, bleibt das gesamte Verfahren für alle Beteiligten vollkommen transparent. Man muss weder bestehende Programme anpassen, noch müssen beide Seiten irgendetwas über sich wissen. Darüber hinaus kann Tinc beliebige Ethernet-Frames durch seine Tunnel schicken und ist nicht, wie so mancher Konkurrent, auf IP-Pakete beschränkt. Tinc nimmt folglich nicht nur IPv6-Pakete ohne zu murren zur Weiterleitung entgegen, es kann seine Tunnel auch durch ein IPv6-Netz graben.

Bauwerkzeug

Die virtuellen Netzwerkkarten erstellt Tinc mit Hilfe des universellen Tun/Tap-Treibers, der Bestandteil aller halbwegs aktuellen Linux-Kernel ist. Ob ihn die eigene Distribution aktiviert, beziehungsweise einkompiliert hat, verrät ein kurzes »sudo modinfo tun« das den Aufenthaltsort des zugehörigen Moduls ausspuckt.

Tinc komprimiert den von ihm beförderten Netzwerkverkehr auf Wunsch per »zlib« oder »LZO«. Die eigentliche und obligatorische Verschlüsselung der Daten erledigt das bewährte OpenSSL. Alle drei genannten Softwarepakete sind somit Voraussetzung für eine erfolgreiche Inbetriebnahme. Unter Ubuntu Linux heißen die zugehörigen und noch zu installierenden Kandidaten »liblzo2-2«, »liblzo2-dev« und »libssl-dev«.

Damit fehlt nur noch der Tinc-Daemon, der in Quellcode-Form auf seiner Homepage wartet [1]. Wenn möglich, sollten Sie ausschließlich auf ihn zurückgreifen und ein eventuell fertig geschnürtes Angebot Ihres Paketmanagers ausschlagen. Diese bieten häufig -- wenn überhaupt -- nur veraltete Versionen, die unter Umständen noch Sicherheitslöcher enthalten. Die Übersetzung von Tinc erfolgt zudem genau so flott mit dem bekannten Dreisatz:

./configure --prefix=
make
sudo make install

Achten Sie dabei auf das angehängte »--prefix=«, da ansonsten gleich alle Konfigurationsdateien unter »/usr/local/etc/tinc« verschwinden müssen. Wenn Ihre Distribution auf »udev« verzichtet, müssen Sie unter Umständen noch eine Gerätedatei erstellen. Dazu prüfen Sie, ob »/dev/net/tun« existiert. Wenn nicht, legt sie der Befehl »sudo mknod -m 600 /dev/net/tun c 10 200« an.

Geländeerkundung

Wie bei vielen anderen VPNs, kommt man auch bei der Einrichtung von Tinc nicht drum herum, mit zahlreichen IP-Adressen zu jonglieren. Im Folgenden soll deshalb ein kleines Beispiel die Verwirrung in Grenzen halten: Die Kloob Reifenwerke GmbH möchte ihre Hauptverwaltung in Aachen mit einer kleinen Außenstelle in Bochum verbinden. Wie in Abbildung 1 zu sehen, existiert derzeit in Aachen ein Netzwerk, dessen Teilnehmer aus dem Bereich »192.168.1.x« eine IP-Adresse beziehen. Einer der Computer mit der IP-Adresse »192.168.1.111« ist über eine zweite Netzwerkkarte an das Internet angeschlossen und von dort aus unter der Adresse »100.1.2.3« zu erreichen. Analog hängen in Bochum alle Computer in einem eigenen Netz »192.168.2.x«. Dort erreicht man vom Internet aus den Rechner »50.1.2.3«, der im internen Netz unter der Adresse »192.168.2.222« erreichbar ist.

Abbildung 1: Die Ausgangssituation der Kloob Reifenwerke GmbH: Die hier in grün gezeichneten Computer hängen sowohl in einem internen Netz, als auch am Internet.

Abbildung 2: Tinc erstellt jeweils eine virtuelle Schnittstelle (tun0) und stöpselt diese über eine gesicherte Verbindung zusammen (rot).

Ein VPN soll nun diese verteilte Infrastruktur zusammenbringen (Abbildung 2). Hier zeigt sich ein weiterer Unterschied zu manch anderer VPN-Lösung: In Tinc definiert der Administrator keine Tunnel, sondern ausschließlich deren Endpunkte. Das spart Arbeit, denn schon bei vier Teilnehmern am VPN wären sonst sechs Tunnel zu graben. Im Beispiel platziert man einen der Endpunkte auf dem Rechner in Aachen, den anderen auf seinem Pendant in Bochum. Zunächst zum Computer in der Aachener Hauptzentrale.

Bohrbeginn

Tinc verlangt nach mehreren Konfigurationsdateien, die es allesamt im Verzeichnis »/etc/tinc« und dessen Unterordnern erwartet. Sofern es noch nicht existiert, legen Sie es genau wie alle folgenden Unterverzeichnisse und Dateien neu an. Sobald der Daemon startet, liest er seine eigenen Einstellungen aus der Datei »/etc/tinc/tinc.conf«. Ihre Inhalte, wie auch die der anderen Konfigurationsdateien, gehorchen dem Muster »Variable = Wert«; wobei die Variablennamen zwischen Groß- und Kleinschreibung unterscheiden. Für den Rechner in Aachen genügt bereits eine einfache »tinc.conf« mit den folgenden zwei Zeilen:

Name = aachen
Device = /dev/net/tun

Zunächst bekommt der Endpunkt, um den sich der Daemon kümmert, einen »Name«. In diesem Fall soll er einfach »aachen« heißen. »Device« bezeichnet den Gerätenamen der virtuellen Netzwerkkarte, die der Daemon anbieten soll.

Die Grundkonfiguration von »tinc.conf« wird ergänzt durch das Unterverzeichnis »/etc/tinc/hosts«, das für jeden Endpunkt des VPN eine eigene Konfigurationsdatei enthält. Diese wiederum trägt den Namen des jeweiligen Endpunktes und enthält dessen wichtigsten Eckdaten, darunter wie er überhaupt über das Internet zu erreichen ist. Im Beispiel gibt es derzeit nur den Endpunkt »aachen«, folglich benötigt man im Verzeichnis »/etc/tinc/hosts« eine neue Datei mit dem gleichen Namen und folgendem Inhalt:

Adress = 100.1.2.3
Subnet = 192.168.1.0/24

Dieser Server ist vom Internet aus (also für andere Tinc-Daemons) unter der Adresse 100.1.2.3 zu erreichen und hängt im Subnetz 192.168.1.0/24. Anstelle der IP-Adresse 100.1.2.3 kann auch einen eventueller vorhandener Domainname, wie etwa »aachen.reifenwerke.de« verwendet werden. Das ist besonders mit einem Dienst wie DynDNS praktisch. Das »Subnet« bezeichnet das Netzwerk, das über den Rechner 192.168.1.111 ins Internet gelangt und das VPN später nutzen darf. Wenn mehrere Adressbereiche existieren, erstellt der Admin einfach mehrere »Subnet«-Einträge.

Schlüsseldienst

Nachdem die Grundkonfiguration für den ersten Knoten steht, fehlen nur noch ein öffentlicher und ein privater Schlüssel, die Tinc später zur Authentifizierung der übertragenen Pakete heranzieht. Dazu genügt schon das einfache Kommando »sudo tincd -K«. Die vorgeschlagenen Speicherorte übernimmt man einfach mit der Eingabetaste. Damit wandert dann der öffentliche Schlüssel als Anhängsel in die Host-Datei »aachen« und der private Teil in die »/etc/tinc/rsa_key.priv«.

Hoch und runter

Mit den bisherigen Einstellungen erstellt Tinc gleich eine virtuelle Netzwerkschnittstelle, die alles, was man in sie hineinsteckt, an den Daemon schickt. Dieser empfängt, verschlüsselt und verpackt die Daten, bevor er sie über die reale Netzwerkkarte (also über die mit der Adresse »100.1.2.3«) Richtung Ziel versendet. Allerdings besitzt die virtuelle Netzwerkkarte noch keine IP-Adresse. Diese vergibt unter Linux für gewöhnlich das Kommandozeilenwerkzeug »ifconfig«. Man müsste also nach jedem (Neu-)Start von Tinc zum einen den Namen der neuen Schnittstelle ausfindig machen und dann auch noch »ifconfig« manuell aufrufen. Um das Leben des Administrators zu erleichtern, bietet Tinc die Skripte »tinc-up« und »tinc-down« an. Ersteres aktiviert der Daemon direkt nach seinem Start, letzteres wenn er wieder herunterfährt. Beide Skripte liegen neben »tinc.conf« im Unterverzeichnis »/etc/tinc/«. Um der virtuellen Netzwerkkarte des Aachener Computers eine IP-Adresse zuzuweisen, genügt eine »tinc-up« mit folgendem Inhalt:

#!/bin/sh
ifconfig $INTERFACE 192.168.1.119 netmask 255.255.255.0

Die Variable »$INTERFACE« stellt der Daemon bereit. Sie enthält den Namen der virtuellen Netzwerkschnittstelle. Die Netzmaske ist übrigens die Maske des gesamten VPN-Netzwerks, nicht nur des eigenen Subnetzes. Abschließend darf man nicht vergessen, das Skript noch ausführbar zu machen.

Als IP-Adresse wurde für die virtuelle Schnittstelle einfach die noch freie »192.168.1.119« gewählt, unter der im Anschluss der Standort Bochum den Aachener Rechner erreicht. Damit muss aber insbesondere der Administrator noch eine weitere IP-Adresse pflegen. Aus diesem Grund empfehlen die Tinc-Entwickler einen kleinen Trick anzuwenden und der virtuellen Schnittstelle die Adresse der realen Netzwerkkarte zu verpassen. Das klappt allerdings nur, wenn sich die Netzmasken unterscheiden. Die neue »tinc-up« sieht damit in Aachen wie folgt aus:

#!/bin/sh
ifconfig $INTERFACE 192.168.1.111 netmask 255.255.0.0

Tunnelende

Damit wäre die Konfiguration in Aachen erst einmal fertig. Als nächstes kommt der Rechner in Bochum an die Reihe. Seine Dateien sehen fast genau so aus. Zunächst ist wieder die »tinc.conf« nötig:

Name = bochum
Device = /dev/net/tun

Der Endpunkt heißt in diesem Fall »bochum« und nutzt auch hier wieder das Tun-Device. Dazu gehört eine weitere Datei »bochum« ins Unterverzeichnis »/tinc/hosts« mit dem Inhalt:

Adress = 50.1.2.3
Subnet = 192.168.2.0/24

Die zugehörige »tinc-up« sieht ebenfalls vertraut aus:

#!/bin/sh
ifconfig $INTERFACE 192.168.2.222 netmask 255.255.0.0

Und auch hier erzeugt »sudo tincd -K« abschließend ein passendes Schlüsselpaar.

Partnervermittlung

Damit stehen die Endpunkte auf beiden Rechnern, der Admin muss sie dem Gegenüber nur noch bekannt geben. Dazu kopiert er im ersten Schritt die Host-Datei »aachen« in das Verzeichnis »/etc/tinc/hosts« des Bochumer Computers und umgekehrt dessen »bochum«-Datei in den Ordner »/etc/tinc/hosts« des Aachener Rechners. Die Dateien darf er erst zu diesem Zeitpunkt tauschen, da erst jetzt in beiden der jeweilige, öffentliche Schlüssel steckt.

Werden anschließend die beiden Tinc-Daemons gestartet, warten Sie auf Verbindungsversuche eines bekannten Kollegen. Es gibt somit keine klare Trennung in Client und Server, wie es bei anderen VPNs der Fall ist. Um eine Verbindung herzustellen, ergänzen Sie in der »tinc.conf« die Zeile:

ConnectTo = Endpunkt-Name

Möchten Sie beispielsweise, dass sich der Bochumer Rechner mit dem in Aachen verbindet, ergänzen Sie in der Bochumer »/etc/tinc/tinc.conf« die Zeile

ConnectTo = aachen

Sollte ein Gegenüber nicht erreichbar sein, versucht es Tinc immer wieder erneut.

Startet man nun einen Tinc Daemon per »sudo tincd« laufen sämtliche Meldungen in die Syslog-Datei. Wer eine separate Log-Datei wünscht, hängt noch den Parameter »--logfile=dateiname« an. Der Befehl »sudo tincd -k« beendet den Daemon wieder.

Brandschutz

Sobald auf jedem beteiligten Rechner ein »tincd« läuft, erreichen die Bochumer den Aachener Rechner unter der IP-Adresse »192.168.1.111«. Umgekehrt finden die Aachener ihre Kollegen unter der Adresse »192.168.2.222«. Das alles klappt freilich nur, wenn keine Firewall die Kommunikation stört. So reden die Tinc-Daemons standardmäßig auf Port 655 miteinander, den die Entwickler übrigens sogar bei der IANA hochoffiziell für sich reserviert haben. Darüber hinaus packt Tinc alle zu übertragenden Daten in UDP-Datagramme, und tauscht weitere Informationen per TCP aus. Die Firewall muss diese Pakete folglich nicht nur rein-, sondern auch rauslassen.

Sollten im Betrieb Probleme auftreten, helfen vielleicht die etwas ausführlicheren Meldungen des Daemons, die ein höheres Debug-Level aktiviert:

tincd --debug=5

Die 5 ist hier schon das höchste Level, das sämtlichen Netzverkehr mitschneidet. Zur Fehlersuche sollte ein Level von 2 ausreichen, der alle Status- und Fehlermeldungen der Skripte und des Tinc Daemons aufzeichnet.

Kryptisch

Unter der Haube bietet ein Tinc Daemon wenig spektakuläres: Sobald die Daten über die virtuelle Schnittstelle eingehen, erhalten sie zunächst eine 32-Bit lange Sequenznummer und werden anschließend standardmäßig per Blowfish-Algorithmus im Cipher Block Chaining (CBC) Modus verschlüsselt. Das Ergebnis erhält noch via SHA-1-Verfahren einen standardmäßig 4 Byte langen Message Authentication Code (MAC). Zusammen mit der Sequenznummer soll sie sogenannten Replay-Angriffen den Garaus machen. Das entstandene Datenpäckchen legt Tinc in ein UDP-Datagramm und schickt es Richtung Ziel. Parallel dazu bauen die Daemons eine TCP-Verbindung auf, über die sie unter anderem Schlüssel und weitere Metadaten austauschen. Aus diesem Grund spricht die Tinc-Dokumentation auch von einer Meta-Verbindung. Der Verschlüsselungsalgorithmus und der Message Authentification Algorithmus können in den Konfigurationsdateien frei gewählt werden, die Länge des MAC ist ebenfalls anpassbar. Die Länge des Schlüssels für den eigentlichen Verschlüsselungsvorgang ist immer auf die von OpenSSL vorgegebene Standardlänge festgelegt.

myvpn   10.0.0.0

/etc/tinc/tinc.conf
Name = celle
Device = /dev/tap0

/etc/tinc/hosts/celle
Adress = 80.1.2.3
Subnet = 192.168.3.0/24

/etc/tinc/tinc-up
#!/bin/sh
ifconfig $INTERFACE 192.168.3.133 netmask 255.255.0.0

Schlagwetter

Tincs Vorteil ist gleichzeitig auch sein größter Nachteil: Das proprietäre Protokoll ist kleiner, schlanker und schneller als andere Standardprotokolle. Im Gegenzug bleibt man zumindest derzeit auf die Referenzimplementierung festgelegt. Darüber hinaus fiel das Protokoll in der Vergangenheit immer mal wieder durch Sicherheitsmängel auf -- hier rächt sich vermutlich die gegenüber der Konkurrenz kleinere Nutzerbasis. Dass die Entwickler dennoch fdiese Themen sehr ernst nehmen und im Fall der Fälle schnell reagieren, zeigt der extra eingerichtete Bereich Security Issues auf der Tinc-Homepage. Zusätzliche Informationen liefert die Dokumentation in einem eigenen Abschnitt, und wer immer noch misstrauisch ist, wirft einen Blick in das Protokoll [2].

Nichtsdestotrotz mussten in der Vergangenheit immer mal wieder Änderungen am Protokoll vorgenommen werden. Nicht nur aus diesem Grund ist dringend davon abzuraten, auf den VPN-Knoten Daemons mit unterschiedlichen Versionsnummern einzusetzen. Am besten ist es, möglichst alle Tinc-Installationen immer auf dem aktuellen Stand zu halten und vor einem Update die News-Sektion auf der Homepage [1] genau zu studieren.

Für die Zukunft haben die Erfinder von Tinc noch einiges mit der kleinen Software vor. So soll beispielsweise die Konfiguration noch einfacher werden. Wohin die Reise gehen soll, verrät die Seite unter [3]. (ofr)

Infos

[1] Tinc-Homepage: [http://www.tinc-vpn.org]

[2] Arbeitsweise des Protokolls: [http://www.tinc-vpn.org/documentation/tinc_5.html#SEC56]

[3] Tinc-Roadmap: [http://www.tinc-vpn.org/goals]