kleiner VPN-Vergleich

Da ich mittlerweile eine kleine Heerschar an Servern betreibe die auch in verschiedenen Rechenzentren stehen, wurde es an der Zeit diese mittels VPN zu verbinden, schon nur um die mögliche Angriffsfläche nach außen zu verkleinern. Zudem werden einige Dienste nur intern benötigt (z.B. Monitoring, DNS-Master, MariaDB, …) und müssen daher nicht „offen“ im Internet erreichbar sein (auch wenn natürlich etliche Firewall-Regeln das meiste abhalten).

Wenn man ein VPN einrichten will stellt sich natürlich erst mal die Frage welche Features man erwartet. Für mich war wichtig, dass das VPN hochverfügbar ist, da es später ein zentraler Bestandteil werden soll. Daher sollte ein Single Point of Failure (SPOF) unbedingt vermieden werden. Zudem sollte es natürlich sicher sein, eine gute Performance bieten, einfach zu konfigurieren sein und keinen allzu großen Overhead verursachen. Da dies nun feststand war es an der Zeit sich die verschiedenen Software-Lösungen anzuschauen. Es gibt eine Unzahl an VPN-Lösungen, daher habe ich folgende 4 Näher verglichen:

openVPN

Der Klassiker unter den VPN-Lösungen. openVPN ist für fast jeden ein Begriff und existiert quasi für jede erdenkliche Plattform. Der große Nachteil für mich war jedoch das ein HA-Cluster nicht leicht aufzusetzen ist und einiges an Konfiguration benötigt. Daher schied es für mich persönlich aus.

SoftEther

Diese Lösung glänzt vor allem durch eine einfache Konfiguration dank GUI-Umgebung. Zudem wird eine Vielzahl an Protokollen unterstützt, sodass quasi jeder erdenkliche Client einfach angebunden werden kann. Aber auch hier ist das konfigurieren eines HA-Clusters nicht einfach, zudem ist eine GUI zur Konfiguration in Server-Umgebungen nicht gerade ideal. Diese Lösung behalte ich aber im Hinterkopf, falls ich später mal Client-Geräte ins VPN einbinden will 😉

Wireguard

Dies ist eine recht neue Software die gerade etwas Aufmerksamkeit bekommen hat, da sie wohl in absehbarer Zeit fester Bestandteil des Linux-Kernels wird. Der große Vorteil ist das die Codebasis sehr klein und damit überschaubar ist und sicherheitsrelevante Aspekte wurden formal bewiesen. Somit dürfte diese Lösung in punkto Sicherheit vorne mitspielen. Aber auch hier ist das Setup eines HA-Clusters nicht so einfach zu mache, auf der ToDo Liste des Projektes steht aber unter dem Punkt „Mesh Networking Tools“ ein interessanter Ansatz, der unsere letzte Lösung bereits voll unterstützt. Aktuell erfüllt Wireguard meine Anforderungen nicht, aber in Zukunft könnte sich dies definitiv ändern. Also auch auf dem Schirm behalten.

tinc

Die Website dieses Projekts wirkt etwas altbacken, das Projekt selbst ist es aber nicht. Letztlich war dies mein Gewinner und ich selbst nutze diese Software für mein VPN. Ausschlaggebend war die Fähigkeit, automatisch ein Mesh-Netzwerk bilden zu können. Bei einem klassischen VPN mit zentralem Server läuft sämtlicher Traffic über eben jenen Server. Verbinden sich nun zwei Clients A und B und wollten Daten austauschen, so läuft sämtlicher Traffic über den VPN-Server. Nicht so bei tinc, hier wird ein Mesh-Netzwerk gebildet. So können A und B direkt Daten austauschen, ohne über den zentralen VPN-Server zu gehen. Somit wäre ein Ausfall eben jenes Servers auch nicht tragisch und würde zu keinem Totalausfall des VPN-Netzes führen. Zudem verursacht tinc keinen großen Overhead, ist klein und einfach zu konfigurieren, dadurch das sich ein Mesh bildet benötigt man auch keinen zentralen „dicken“ Server der sämtlichen Traffic durchleitet, passt also alles 😎

Konkret habe ich es wie folgt umgesetzt: Einige Hauptserver verbinden sich untereinander und bilden das „Kern-Mesh“, den Einstiegspunkt für das VPN. Alle anderen Server verbinden sich nun mit diesem Kern-Mesh. Sollte ein Server dieses Kern-Mesh down gehen, führt dies nicht zu einem Ausfall des VPN, da die anderen Server noch online sind und sich Clients mit diesen verbinden können. Somit habe ich eine große Anzahl an Einstiegspunkten für das VPN und da sich automatisch ein Mesh bildet, ist keine weitere Konfiguration notwendig um ein HA-Cluster zu bilden. Erst wenn alle Server des Kern-Mesh down gehen können sich keine neuen Clients verbinden, aber dann habe ich ganz andere Probleme in der Infrastruktur… 😉

Vielleicht wird es später dazu noch eine detaillierte Anleitung zur Konfiguration geben, aber im Grunde ist das Internet bereits voll damit und die Einrichtung ist definitiv kein Hexenwerk und im Vergleich zu anderen Lösungen super simpel.

Fazit

tinc ist in meinen Augen aktuell die beste Lösung, um ein VPN-Netzwerk zwischen Servern aufzubauen, das hochverfügbar ist und gut skaliert. Die Konfiguration ist einfach und das sich automatisch bildende Mesh erledigt den Rest. In meiner Umgebung gab es bisher auch noch nie Probleme, egal ob Server plötzlich verschwinden, neu dazukommen oder instabil laufen. Bisher hat Tinc alles gemeistert. Nur auf Clients jenseits Linux/Debian habe ich tinc bisher noch nicht getestet.

Natürlich gibt es noch mehr VPN-Lösungen die möglicherweise bessere zu eurem Use-Case passen, daher hier noch ein paar Namen von Projekten die definitiv interessant sein können:

• vpnc
  Alternative zu Cisco VPN-Client, kann z.B. zum Verbinden zum Uni-VPN genutzt werden. Aktuelleres Repo?
• fastd
  sehr beliebt bei Freifunk, jedoch schlechte Performance auf CPU-schwachen Geräten (z.B. TL-WR841ND)
• L2TP/Tunneldigger
  wird von einigen Freifunk Communities als Ersatz für fastd genutzt, da wesentlich schneller auf CPU-schwachen Geräten, aber keine (!) Verschlüsselung. L2TP läuft im Kernel-Space statt User-Space, was viele Kontext-Switches erspart. Tunneldigger sorgt dafür, dass die Verbindung auch durch alle möglichen NAT-Konstruktionen möglich ist.
• StrongSwan/LibreSwan
  IPSec zum Verbinden mehrere Server