Open Source im professionellen Einsatz
Linux-Magazin 08/2015
© marchello74, 123RF

© marchello74, 123RF

Peer-to-Peer-basierte VPN-Alternativen

Tunnelblick

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.

1377

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.

Diesen Artikel als PDF kaufen

Express-Kauf als PDF

Umfang: 5 Heftseiten

Preis € 0,99
(inkl. 19% MwSt.)

Linux-Magazin kaufen

Einzelne Ausgabe
 
Abonnements
 
TABLET & SMARTPHONE APPS
Bald erhältlich
Get it on Google Play

Deutschland

Ähnliche Artikel

  • Einfache Verbindung

    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.

  • Version 1.0.0 von Zero Tier One verbessert Nat- und Multicast-Support und unterstützt Raspbi und Co.

    Mit Zero Tier One lassen sich unabhängig von Anbietern wie EC2, Vultr, Azure oder Digital Ocean globale Virtual Private Networks (VPN) aufbauen, die auf P2P-Basis laufen. Jetzt haben die Anbieter Version 1.0.0 veröffentlicht.

  • Tooltipps

    Die Programme Drukkar 1.11, Tinc 1.0.23,  Ftwin 0.8.8, Log Analyzer 3.6.5, Mail­drop 2.7.0 und Binwalk 1.2.2 im monatlichen Software-Überblick.

  • Zero-Tier-Projekt testet Netzwerk-Container

    Das Zero-Tier-Projekt experimentiert mit Netzwerk-Containern. Sie sollen als Usermode-Lösung die mehrfachen Kontext-Switches zwischen Kernel und Usermode verhindern und es ermöglichen, ein vollständiges virtuelles Netzwerkgerät in einen Container zu packen.

  • Zerotiers VLAN erreicht Version 1.1.0

    Zerotier bietet ein virtuelles P2P-Ethernet-Netzwerk an, nun ist Version 1.1.0 erschienen. Die unterstützt Circuit-Testing, Multicast-freie IPv6-Netzwerke dank NDP-Emulation und Clustering.

comments powered by Disqus

Stellenmarkt

Artikelserien und interessante Workshops aus dem Magazin können Sie hier als Bundle erwerben.