© marchello74, 123RF

Wer seinen Netzwerkverkehr verschlüsselt über öffentliche Leitungen senden möchte, greift meist zu IPsec, chiffriert den Traffic mit SSL über Port 443 oder nutzt Open VPN. Die Bitparade nimmt vier dazu alternative Tunnelbauer unter die Lupe, die VPN über Peer-to-Peer-Verfahren versprechen.

Die P2P-basierten VPN-Lösungen der Bitparade dieses Monats unterscheiden sich in ihren Ansätzen deutlich. Sie reichen von Software, die dem klassischen Modell folgt, bis hin zu einem einfachen Peer-to-Peer-Modell. Setzt ein Admin beim ersten Ansatz zwei Netze auf, reiht sich der Rechner beim zweiten mit Hilfe einer ID ins Netzwerk ein, wobei das Routing automatisch erfolgt.

Einige der Projekte bieten zudem Clients für andere Betriebssysteme an, darunter solche für Mobilgeräte. Vier Kandidaten hat sich die Bitparade diesmal angeschaut. Die Tests fanden in einer virtualisierten Umgebung beim Arbeitgeber des Autors statt, mit passenden Gegenstellen im Internet.

Tinc [1] ist dabei das dienstälteste unter den getesteten Programmen. Freelan [2] ist hingegen ein noch recht junges Projekt, das Clients für Linux, Windows und OS X anbietet. An Ipop [3] entwickeln maßgeblich Studierende der University of Florida mit, es ähnelt Tinc. Lediglich Zero Tier [4] ist als einziger Kandidat als ein reines Peer-to-Peer-VPN implementiert.

Tinc

Das Tinc-Projekt [1] gibt es bereits seit 1998, die letzten Änderungen auf der Webseite stammen aus dem Jahre 2014. Tinc erlaubt den Aufbau eines vermaschten VPN. Was soviel bedeutet, dass jeder Knoten einen Weg zu jedem anderen findet (Abbildung 1). Die gegenseitige Authentisierung basiert auf RSA-Schlüsseln (2048 Bit).

Abbildung 1: Tinc baut ein vermaschtes VPN auf und tunnelt verschlüsselt UDP-Traffic.

Tinc definiert logische Netzwerke, die jeweils einen Namen besitzen, im Test lautete er zum Beispiel »LM« . Der Tinc-Daemon erwartet unter »/etc/tinc« einen Unterordner pro Netz, der den gleichen Namen tragen muss. Pro Ordner erwartet der Daemon eine Datei »tinc.conf« . Sie enthält im einfachsten Fall nur zwei Einträge: Den logischen Namen des Systems innerhalb dieses Netzwerks und das Device, das die Tunnel aufbaut.

Die Manpage von »tinc.conf« listet weitere Optionen auf, die etwa bestimmen, welches Interface der Dienst verwendet und ob der Host als Intermediate Node agieren soll oder nicht. Die einfachste Form der Datei sieht so aus:

Name = left
Device = /dev/net/tun

Im Ordner »/etc/tinc/LM« erwartet Tinc dann noch einen weiteren Unterordner »hosts« . In dem befindet sich für jeden beteiligten Host eine eigene Datei mit dem logischen Namen des Hosts.

Im Test kamen zwei Hosts zum Einsatz, die »left« und »right« hießen, den Inhalt von »left« zeigt Abbildung 2. Der Eintrag »Subnet« dort beschreibt das Netz, das der Teilnehmer zu sich routen möchte, bei »Address« handelt es sich um die offiziell erreichbare Adresse. Da der Test in einer geschlossenen Umgebung stattfand, ist das eine RFC-Adresse.

Abbildung 2: Jeder beteiligte Host erhält bei Tinc eine eigene Konfigurationsdatei.

Den Schlüssel lässt der Admin beim ersten Versuch einfach weg, da Tinc ihn später generiert und automatisch ergänzt. Beim ersten Einrichten trägt er auf dem Host »left« also nur die ersten beiden Zeilen ein. Danach ruft er

tincd -n LM -K

auf. Gibt er über die Option »-K« keine Schlüssellänge mit auf den Weg, verwendet Tinc 2048 Bit und trägt den Public Key dann automatisch in »/etc/tinc/LM/hosts/left« ein. Die Option »-n« gibt den Namen des Netzwerks an.

Erwähnenswert ist auch die Datei »/etc/tinc/LM/tinc-up« . Es handelt sich um ein ausführbares Shellskript mit dem Auftrag, das Tunnelinterface zu aktivieren und ihm eine IP-Adresse zu verpassen. Im Test sah dieses Skript für den Host »left« wie folgt aus:

#! /bin/bash
ifconfig $INTERFACE 192.168.22.1 netmask  255.255.255.0

Dem aufmerksamen Betrachter fällt sicher auf, dass die IP-Adresse in einem Netz liegt, dessen Netzmaske mehr Hosts umfasst als das Subnet in Abbildung 1. Das sorgt dafür, dass der Host dank der vom Kernel gesetzten Route alle anderen Teilnehmer über das Tunnelinterface erreicht. Die speziellere Route auf dem LAN-Interface soll bewirken, dass die Hosts im LAN erreichbar bleiben.

Der Administrator fügt dann den passenden Public Key ein und verteilt die Hostdatei »left« an alle Beteiligten. Das geschieht in einem Any-to-any-Verfahren, das recht aufwändig geraten kann. Die Datei darf neben den genannten noch weitere Parameter enthalten, beispielsweise spezifische Verschlüsselungsalgorithmen oder alternative Ports.

Bevor er Tinc startet, muss der Admin sicherstellen, dass Linux das »tun« -Modul geladen hat. Tinc erledigt dies nicht automatisch, es wird jedoch für ein funktionierendes VPN gebraucht. Nach dem Start des Daemon bei allen Beteiligten routet Tinc die Pakete dann wie erwartet über den Tunnel.

Die Software funktionierte im Test gut, lief stabil und erfüllte auch die Anforderung an das Full Mesh. Der Ansatz bringt jedoch auch Einschränkungen mit. So entsteht Aufwand dabei, alle Hostdateien an alle Beteiligten zu verteilen. Ändert sich bei einem Host die Konfiguration, muss Tinc die Datei neu versenden. Das funktioniert bei fünf Hosts gut, bei 100 wird es unübersichtlich.

Außerdem muss jeder Teilnehmer von außen erreichbar sein. Das setzt Zugriff auf eine Firewall voraus, um den eingehenden Port durchzuschalten. Alternativ kann Tinc auf einem per Internet erreichbaren Host laufen. Da trifft es sich gut, dass es Tinc nicht nur für Linux, sondern auch für die meisten BSD-Derivate (darunter OS X) sowie als Build für Open WRT gibt. Von Windows unterstützt es die Versionen 2000 (!) bis 7.

Freelan

Freelan [2] gibt es noch nicht so lange wie Tinc, laut Github startete die Entwicklung im Jahr 2011, sie ist weitgehend eine One-Man-Show. Freelan erlaubt sowohl ein klassisches Site-to-Site- als auch ein Peer-to-Peer-VPN oder eine Mischung aus beiden Formen und ist wie Tinc aufgebaut (Abbildung 1).

Die Software steht auf der Webseite [2] für Windows (XP bis 8), OS X (10.7 bis 10.9) und Linux bereit. Für das freie Betriebssystem gibt es fertige Debian-Pakete (die das Linux-Magazin im Test verwendete) und den Quellcode, um ihn selbst zu übersetzen. Letzteres stellte sich im Test zumindest auf der standardmäßig genutzten Gentoo-Test-VM als nicht ganz trivial heraus.

Im Unterschied zu Tinc authentisieren sich die Hosts untereinander mit Hilfe von X.509-Zertifikaten. Im einfachsten Fall benötigt jeder Host ein eigenes Zertifikat mit Private Key sowie das Zertifikat der CA, die die Zertifikate der Teilnehmer unterschrieben hat, um die anderen zu autorisieren.

Eine sehr einfache Konfiguration zweier Hosts sieht wie in Abbildung 3 aus (eine Quelle für Zertifikate vorausgesetzt). Dies ist die Konfiguration vom Host Alice unter »/etc/freelan/LM-Test.conf« . Die Tunnelinterfaces nutzen Adressen aus dem Netz »10.10.1.0/24« . Alice hat die Hostadresse »1« und muss Bobs Rechner über den angegebenen Hostnamen und Port erreichen. Über die »contact« -Anweisung versucht der Alice-Rechner aktiv, eine Verbindung aufzubauen.

Abbildung 3: Die Konfiguration für Alice enthält unter anderem die IP-Adresse und Links auf die X.509-Zertifikate.

Über die Konfigurationsdatei »/etc/freelan/LM-Test.conf« ist es zudem möglich, gleich mehrere Netze nebeneinander zu betreiben. Welche Konfigurationen er aktiviert, steuert der Admin über Einträge in »/etc/default/freelan« . Hier legt er auch fest, ob Freelan eingehende Verbindungen überhaupt annimmt, schließt Netzbereiche von der Kontaktaufnahme aus und regelt über ein einstellbares Skript, welche eingehenden Zertifikate Freelan akzeptiert. In der Konfiguration mit gegenseitiger Kontaktaufnahme ist der Tunnel im Handumdrehen aufgebaut und die Adressen sind im Netz »10.10.1.0/24« erreichbar.

Zusätzlich gibt es noch einen Servermodus. In ihm erhält ein zentraler Webserver die Parameter eines Netzwerks. Das ermöglicht es den Teilnehmern, die anderen Teilnehmer kennenzulernen. Leider verrät die Dokumentation nicht, wie der Admin den Servermodus einrichtet. Die mitgelieferte Beispielkonfiguration zeigt lediglich auf, wie er sich mit dem Masterserver verbindet. Da der Dienst auch ohne diesen Modus arbeitet, kann der Anwender sein VPN in Betrieb nehmen.

Weil die Software Zertifikate statt Schlüsselpaare einsetzt, wie es Tinc tut, lassen sich die Teilnehmer etwas weniger aufwändig verwalten. Wie bei Tinc muss der Admin aber den Teilnehmern alle öffentlich erreichbaren IP-Adressen und Hostnamen bekanntmachen. Das heißt auch: Zwei Teilnehmer, die hinter NAT-Devices sitzen, über die sie keine Kontrolle haben, finden nicht zueinander.

Allerdings muss das Netz nicht voll vermascht sein, damit Alice auch noch mit Felix über das VPN kommunizieren kann. Per Default ist der »relay_mode« aktiv, sodass es lediglich eine Kette von Kontakten zwischen Alice und Felix geben muss, was jedoch für die Latenz nicht gerade förderlich ist.

Ipop

Das Ipop-Projekt [3] wurde 2006 an der Universität von Florida gestartet. Es geht einen etwas anderen Weg als die ersten beiden Kandidaten. Statt die Clients direkt zu verbinden, tritt Jabber [5] als Vermittler auf. Die eigentlich für Multimedia-Inhalte gedachte Erweiterung Jingle [6] handelt dann die Nutzdaten-Verbindungen aus (Abbildung 4). Ipop bietet zwei VPN-Varianten an: Social VPN soll einzelne Clients miteinander verbinden, Group VPN eher Server miteinander in Kontakt setzeb.

Abbildung 4: Ipop wählt einen anderen Weg als Tinc und Freelan, indem es einen Jabber-Server voraussetzt und Stun sowie Turn unterstützt.

Befinden sich zwei Teilnehmer jeweils hinter einer NAT-Verbindung, nutzen sie einen Stun- oder Turn-Server ([7], [8]) als Verbindungspunkt im Internet. Die Software steht unter [3] und auf Github [9] zum Download für alle gängigen Linux-Distributionen bereit. Außerdem gibt es eine Version für Windows, Android und Open WRT.

Das Linux Magazin hat sich speziell die Group-VPN-Variante angeschaut. Im ersten Test nahmen zwei nebeneinanderliegende VMs Kontakt auf, später kommunizierten zwei VPNs hinter NAT-Gateways, um auch dies zu testen.

Zum Betrieb von Ipop ist ein Jabber-Server notwendig, auf dem sich alle Teilnehmer einen Account teilen. In der Dokumentation auf der Webseite [3] findet sich eine Beschreibung, wie der Admin für diesen Zweck Open Fire einsetzen kann. Ipop funktioniert aber auch mit öffentlichen Servern wie etwa http://talk.google.com, der im Test zum Einsatz kam.

Nach dem Download des Tar-Archivs legt der Admin im ersten Schritt eine Konfigurationsdatei mit dem Namen »config.json« an (Abbildung 5). Die ersten drei Parameter beschreiben den Zugang zum XMPP-Server. Die beiden IP-Parameter stehen für die IP-Adresse des Knotens im VPN sowie für die Netzmaske, die übrigen sind lediglich für das Logging zuständig. Nun startet der Admin nacheinander zwei Prozesse:

Abbildung 5: Ipop verlangt eine Konfigurationsdatei im Json-Format, die den Zugang zum XMPP-Server ermöglicht.

ipop-tincan-x86_64 1> out.log 2> err.log &

und

gvpn_controller.py -c config.json &> log.txt &

Zuvor muss er per Hand das »tun« -Modul in den Kernel laden – wie bei den anderen Kandidaten auch. Beide Aufrufe führt er als »root« oder mit »sudo« aus.

Nun braucht man ein wenig Geduld, um sich mit dem Jabber-Server zu verbinden. Befinden sich dann Teilnehmer im VPN mit der gleichen User-ID, aber auf unterschiedlichen Branches, schaltet Ipop den Tunnel ein und die IP-Adressen der Partner sind erreichbar.

Die Einträge der Logdateien sind leider erst aussagekräftig, wenn der Admin die Logstufe auf Debug setzt. Allerdings kann er die Serverprozesse von Ipop nach dem aktuellen Status fragen: Über das Kommando

echo -e '\x02\x01{"m":"get_state"}' |  netcat -q 1 -u 127.0.0.1 5800

erhält er eine Statusanzeige, die unter anderem die gefundenen Partner anzeigt. Befinden sich die Teilnehmer hinter NAT-Gateways, kann er wie für Sprachverbindungen einen Stun- beziehungsweise einen Turn-Server in die Konfiguration aufnehmen.

Dazu muss er die Datei »config.json« entweder um die Zeile

"stun": ["Stun-Server-im-Internet"]

erweitern, um einen Stun-Server aufzusetzen, oder um die Zeile

"turn": [{"server":  "Stun-Server:Port", "user": "Benutzername", "pass": "Passwort"}]

für einen Turn-Server. Leser mit Json-Erfahrung erkennen schnell, dass sich auch mehrere Turn-Server angeben lassen.

Die Möglichkeit, einen Stun- oder Turn-Server zu verwenden, um NAT zu überbrücken, ist für Anwender zwar sehr praktisch. Für Sicherheitsverantwortliche in Firmen, in denen die Security Policy jeglichen Traffic von innen nach außen erlaubt, ist sie aber ein Albtraum. Leider ist diese Policy in vielen Firmen verbreitet. Kommt ein Stun- oder Turn-Server zum Einsatz, so müssen die Pakete allerdings mehrfach durch das Internet, was natürlich die Performance nicht gerade steigert.

Zero Tier

Der letzte Kandidat im Test ist Zero Tier. Erster Code des Projekts auf Github stammt von Mitte 2013. Als Kombination aus Software und Dienst erzeugt Zero Tier ein Overlay-Netzwerk, das die Webseite aber eher mit einem WLAN vergleicht. Peer-to-Peer-Verbindungen leiten die Daten, ähnlich wie bei Skype oder Bittorrent, weiter. Ein virtuelles Netz erhält je eine ID zur Identifikation, und es gibt öffentliche und private Netze (Abbildung 6).

Abbildung 6: Zero Tier setzt auf reine Peer-to-Peer-Verbindungen und unterscheidet öffentliche und private Netzwerke.

Die Software steht unter [4] zum Download bereit, das Projekt bietet sie für Linux, OS X und Windows 7 an. Für Linux gibt es Deb- und RPM-Pakete und ein generisches Installer-Paket für Intels 32- und 64-Bit-Architekturen sowie für den Raspberry Pi. Im Test kam der Installer auf einem Gentoo-Linux zum Einsatz, der Sourcecode wartet in einem Github-Repository [10].

Wie bei den anderen Paketen auch sollte der Admin zunächst das »tun« -Modul laden. Danach startet das installierte Initskript den Dienst. Damit meldet sich Zero Tier im P2P-Netzwerk an. Der Admin verwaltet die Zero-Tier-Verbindungen mit dem Programm »zerotier-cli« , für Windows und OS X gibt es sogar eine grafische Oberfläche.

Über »zerotier-cli listpeers« erhält er eine Liste der verbundenen Knoten und prüft damit, ob der Rechner den Weg in das Zero-Tier-Netz gefunden hat. Der Output sieht etwa aus wie in Listing 1. Daneben existiert noch das Subkommando »status« , das aber nur die Version, die eigene Node-ID und den »Online« – oder »Offline« -Status zurückgibt.

200 listpeers <ztaddr> <paths> <latency> <version> <role>
200 listpeers 7e19876aba udp;198.199.97.220/9993;3208;3035;3208;fixed,tcp_out;198.199.97.220/443;-1;-1;-1;fixed 173 1.0.1 SUPERNODE
200 listpeers 8841408a2e udp;107.191.46.210/9993;3208;3194;3208;fixed,tcp_out;107.191.46.210/443;-1;-1;-1;fixed 14 1.0.1 SUPERNODE
200 listpeers 8acf059fe3 udp;162.243.77.111/9993;3208;3114;3208;fixed,tcp_out;162.243.77.111/443;-1;-1;-1;fixed 94 1.0.1 SUPERNODE
200 listpeers 9d219039f3 udp;128.199.197.217/9993;3208;2928;3208;fixed,tcp_out;128.199.197.217/443;-1;-1;-1;fixed 280 1.0.1 SUPERNODE

Zum ersten Ausprobieren des Dienstes eignet sich das Earth-Netz [11] mit der ID »8056c2e21c000001« . Diesem tritt der Admin über »zerotier-cli join 8056c2e21c000001« bei. Das Unterkommando »listnetworks« zeigt die verbundenen Netzwerke und den Verbindungsstatus an, ein »ifconfig -a« verweist für das erste Netz auf das Interface »zt0« .

Im Test konfigurierte der Daemon keine IP-Adresse für das Interface. In der Datei »/var/lib/zerotier/networks.d/ 8056c2e21c000001.conf« findet sich allerdings eine Konfiguration des Netzes, darunter auch die vom Netz zugewiesene IP-Adresse.

Anwender sollten in den öffentlichen Netzen mit denselben Vorsichtsmaßnahmen wie in einem öffentlichen WLAN vorgehen. Das bedeutet: Firewallregeln und den Verkehr über Zero Tier verschlüsseln. Ein »tcpdump« auf das Interface »zt0« lieferte umgehend Broadcast-Pakete anderer Teilnehmer zurück. Gegenüber dem Rest des Internets sind die Zero-Tier-Tunnel jedoch verschlüsselt.

Will er ein privates Netz erzeugen, benötigt der Anwender zunächst einen Account unter [12]. Hier erzeugt er, wie es Abbildung 7 demonstriert, ein Netz und feinjustiert die Parameter. Private Netze sind für bis zu zehn Teilnehmer kostenlos, für größere Netze verlangt Zero Tier 4 US-Dollar pro Monat. Damit nicht einfach jeder einem privaten Netz beitreten kann, trägt der Admin die Node-IDs (aus »zerotier-cli info« ) manuell ein oder bestätigt sie nach einem Verbindungsversuch.

Abbildung 7: Eine grafische Admin-Oberfläche hält Zero Tier nur für Windows und OS X bereit.

Zero Tier ist darauf angelegt, einfach zu funktionieren. Der Teilnehmer sieht zwar, mit wem der Client kommuniziert, kann dies aber nicht steuern. Die technische und die Security-FAQ [4] geben eine gute Übersicht, wie das Netzwerk funktioniert und welche Algorithmen es einsetzt. Für Anwender, die Firewalls überbrücken möchten, bietet Zero Tier eine einfach verwendbare Lösung. Sicherheitsverantwortlichen, die getunnelte Verbindungen ablehnen, bereitet sie eher Kopfschmerzen. Auf welche Seite sich das Zero-Tier-Projekt dabei schlägt, zeigt ein Zitat auf der Startseite (Abbildung 8).

Abbildung 8: Zero Tier will Menschen in Organisationen und Firmen eine einfache Zusammenarbeit ermöglichen, auch wenn sie dafür womöglich die Security-Richtlinien der IT-Abteilungen umgehen.

Fazit

Die vorgestellten Programme unterscheiden sich ziemlich in ihrem Können. Tinc und Freelan funktionieren nur, wenn der VPN-Anwender auch den eingehenden Internetverkehr kontrolliert, bei Ipop und Zero Tier spielt dies keine Rolle. Allen gemeinsam ist, dass sie es erlauben, Verkehr vor den Augen des Internets abzuschirmen und direkte Verbindungen in Form von Overlay-Netzen und Tunneln zu erzeugen.

Tinc und Freelan müssen sich den Vergleich mit etablierten Lösungen wie Open VPN gefallen lassen, wobei sich gerade Tinc durch die aufwändige Schlüsselverteilung für größere Netze als unpraktisch erweist. Bei Ipop kostete die Dauer des Verbindungsaufbaus Nerven, was aber womöglich an der Ungeduld des Testers liegt. In Sicherheitsabteilungen von Firmen sorgen die Lösungen wohl eher für graue Haare, da sie es Anwendern ziemlich einfach machen, installierte Schutzmechanismen auszuhöhlen.