© Péter Gudella, 123RF

Wer ein Virtual Private Network einrichten möchte, kämpft oftmals mit einer nicht ganz simplen Konfiguration. Wireguard verspricht, dass der Tunnelbau auch einfacher und flinker gelingen kann.

VPNs (Virtual Private Networks) gelten als sichere Nummer, wenn es darum geht, das Home Office mit dem Firmennetz, Firmensitze mit der Zentrale oder Geschäftsreisende mit ihrer Kundendatenbank zu verbinden. Privatnutzer verwenden VPNs, um beispielsweise sicher über das Internet auf die heimische Wetterstation mit angeschlossenem Datenbankserver zuzugreifen.

Unter Linux gibt es mehrere Lösungen für Virtual Private Networks. Zu den populären Vertretern zählen Open VPN [1] und solche, die auf dem IPsec-Protokoll [2] aufbauen, wozu etwa Libre Swan [3], Open Swan [4] und Strong Swan [5]gehören. Seit etwas mehr als einem Jahr wird mit Wireguard [6] an einer dritten VPN-Lösung gefeilt, die der Artikel näher in Augenschein nimmt.

An Wireguard (Fast and Secure Kernelspace VPN) arbeitet seit 2015 der Sicherheits-Forscher und -Consultant Jason Donenfeld mit seiner Firma Edge Security. Er hat es unter der GPLv2 veröffentlicht. In freien Wildbahn treffen Admins Wireguard bislang noch eher selten an. Das dürfte vor allem daran liegen, dass das Projekt noch nicht im offiziellen Linux-Kernel steckt und aktuell nur für Linux und OS X verfügbar ist. Daneben fehlen Sicherheits-Audits und das Protokoll kann sich noch ändern.

Trotzdem haben es manche VPN-Provider wie Azirevpn [7] oder Mullvad [8] bereits in ihr Portfolio integriert. Entwickler Donenfeld zeigt sich zudem optimistisch, dass Wireguard in der ersten Hälfte des kommenden Jahres im Mainline-Kernel landen wird.

Schlüsselfrage

Wireguard arbeitet ausschließlich auf der Schicht 3 des OSI-Modells (IPv4, IPv6, IPv4-over-IPv6 und IPv6-over-IPv4). Es gilt als weniger kompliziert als der VPN-Platzhirsch IPsec und zeigt sich performanter als Open VPN. Die VPN-Software besteht aus weniger als 4000 Zeilen Quelltext und setzt auf starke Verschlüsselungsalgorithmen, wofür Donenfeld Trevor Perrins Noise Protocol Framework [9] ins Boot nimmt. Für den Schlüsselaustausch setzt das Wireguard-Protokoll auf Curve25519 (ECDHE) und für den Datentransport auf Chacha20-poly1305.

Wireguard unterstützt allerdings nur eine kryptografische Suite, die sich jedoch bei Problemen ohne Weiteres austauschen lässt. Anwender müssen ihre Verschlüsselungs-Suite also nicht mehr aus verschiedenen Chiffren selbst zusammenbasteln. Das reduziert die Komplexität und vermindert das Risiko von Sicherheitslücken. Wireguard arbeitet aus Sicht des Administrators zustandslos und bringt einen integrierten Schutz gegen Denial-of-Service-Attacken mit.

Installation und Inbetriebnahme

Die Repositories zahlreicher Distributionen bieten Wireguard bereits an, sodass Experimentierfreudige es leicht mit Hilfe der entsprechenden Paketverwaltung installieren. Auf der Webseite des Projekts finden sich diverse Installationsanleitungen [10]. Debianer brauchen lediglich das Unstable-Repository (Listing 1). Anwender, die stets den neuesten Code wünschen, übersetzen das Kernelmodul und die Wireguard-Tools einfach händisch. Eventuell sind in beiden Fällen noch die entsprechenden Kernelheader erforderlich.

01 # als root
02 echo "deb http://deb.debian.org/debian/ unstable main" > /etc/apt/sources.list.d/unstable-wireguard.list
03 printf 'Package: *\nPin: release a=unstable\n Pin-Priority: 150\n' > /etc/apt/preferences.d/limit-unstable
04 apt-get update
05 apt-get install wireguard-dkms wireguard-tools

Ist die Installation geglückt und hat der Kernel das frisch übersetzte Kernelmodul geladen, legt der Admin mit den »iproute2«-Werkzeugen ein virtuelles Wireguard-Interface an und bestückt es mit einer IP-Adresse. Im nächsten Schritt erzeugt das Wireguard-Kommandozeilenwerkzeug die für die Authentifizierung nötigen Schlüssel und bindet den privaten an die Netzwerkschnittstelle.

Bei den Schlüsseln handelt es sich um die schon erwähnten Curve25519-Keys. Sie sind 32 Byte lang, allerdings als Base64 kodiert und entsprechend größer. Hat der Admin das Interface mit »ip link set wg0 up« aktiviert, macht er den Rechner mit seinen zum VPN gehörigen Peers bekannt. Beispielhaft für zwei Server (»grasovka« und »zubrowka«) zeigt Listing 2 das Verfahren.

01 # Als root
02 # Auf grasovka, mit wg für Wireguard
03 wg genkey > wgprivate_grasovka.key
04 chmod 700 wgprivate_grasovka.key
05 # Public Key anzeigen
06 wg pubkey < wgprivate_grasovka.key
07
08 ip link add dev wg0 type Wireguard
09 ip address add dev wg0 192.168.222.1/24 dev wg0
10 wg set wg0 private-key ./wgprivate_grasovka.key
11 ip link set wg0 up
12 # Peer definieren
13 wg set wg0 peer fAoJ02w4ravlkLbcaiIl8bbQ6svlAZXJ3mUO3XR4u0g= allowed-ips 192.168.222.2/32 endpoint 188.xxx.xx.xx:36448 persistent-keepalive 25
14 # IP-Forwarding aktivieren
15 sysctl -w net.ipv4.ip_forward=1
16 iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
17
18 # auf Zubrowka
19 wg genkey > wgprivate_zubrowka.key
20 chmod 700 wgprivate_zubrowka.key
21 wg pubkey < wgprivate_zubrowka.key
22
23 ip link add dev wg0 type Wireguard
24 ip address add dev wg0 192.168.222.2/24 dev wg0
25 wg set wg0 private-key ./wgprivate_zubrowka.key
26 ip link set wg0 up
27 wg set wg0 peer OUFbJXQMARaZQVfaIzpIfMcfib/uZduyxePr8WAnSWE= allowed-ips 192.168.222.1/32,192.168.10.0/24 endpoint 91.7.52.20:46602

Zu jedem Peer gehören dessen öffentlicher Schlüssel, den Wireguard über »wg pubkey < Private.key« vom privaten Schlüssel ableitet und ausgibt, sowie eine Reihe von IP-Adressen. Beide kommen für das Kryptokey-Routing zum Einsatz. Will ein Client eine Verbindung über das Wireguard-Interface aufbauen, identifiziert ihn die Zielschnittstelle anhand seines öffentlichen Schlüssels und prüft, ob die zugehörige IP-Adresse in der Kryptokey-Routingtabelle auffindbar ist. Ist dies nicht der Fall, verwirft Wireguard die Pakete. Anderenfalls handeln beide Seiten Sessionkeys aus, die jeweils für zwei Minuten gültig sind, und der Datenaustausch kann beginnen.

Peersönlich

Mittels »wg« holen sich Anwender Informationen auf den Schirm. Sie erfahren etwa, wie ein Interface konfiguriert ist und wie viel Traffic Peers ausgetauscht haben (Abbildung 1). Die Informationsflut lässt sich mit »wg show Interface [Attributes]« auch auf bestimmte Schnittstellen und Attribute beschränken, was die Sache bei mehreren Wireguard-Tunneln übersichtlicher gestaltet.

Abbildung 1: Wer »wg« ohne weitere Optionen aufruft, sieht, wie es um die Tunnel steht. Die Attribute lassen sich bei Bedarf filtern und farblich anpassen.

Der Peer-Eintrag für den Host Grasovka enthält die zusätzliche Option »persistent-keepalive 25«. Bei dem Server handelt es sich um ein VPN-Gateway, das hinter einem Router hängt und den Zugriff auf das heimische Netzwerk erlaubt. So lassen sich aus der Ferne Drucker ansteuern oder die abgeschotteten Smarthome-Geräte bedienen. Das setzt aktiviertes IP-Forwarding voraus.

Die Seite des Servers Zubrowka benötigt zusätzlich die IP-Adressen im Peer-Eintrag, damit Wireguard die Route anlegt. Im obigen Fall in Listing 2 betrifft dies das gesamte Netz »192.168.10.0/24«. Die Angabe der Endpunkte ist optional. Ohne Endpunkt fügt Wireguard automatisch die externe IP und den UDP-Port des Peers hinzu, der sich erfolgreich authentifiziert.

Der Datentransfer zwischen zwei Wireguard-Peers funktioniert so: Ein Peer schickt ein Paket im Klartext an die Wireguard-Schnittstelle. Die prüft, ob es für die Ziel-IP einen Public Key gibt. Falls nicht, löscht sie das Paket und gibt ein ICMP-Type3-Paket (“No route to host”) und ein »-ENOKEY« (kein Schlüssel gefunden) zurück. Andernfalls verschlüsselt Wireguard das Paket per Chacha20-poly1305 mit einem symmetrischen Schlüssel und einem Nachrichtenzähler (zum Schutz gegen Replay-Angriffe), bestückt es mit einem Header und überträgt es via UDP an die Zieladresse.

Die Gegenseite lauscht am vorgegebenen UDP-Port und identifiziert bei empfangenen Paketen anhand des Headers den sendenden Peer. Sie prüft, ob der Nachrichtenzähler gültig ist, und versucht die gesicherte Sitzung zu authentifizieren und zu entschlüsseln. Schlägt das fehl, löscht sie die Pakete. Ist alles in Ordnung, aktualisiert sie den Endpunkt und UDP-Port der Gegenseite und entschlüsselt das Paket. Dann untersucht sie, ob es sich um ein IP-Paket handelt und die Quell-IP in der Kryptokey-Routingtabelle auftaucht. Trifft beides zu, schiebt sie das Klartextpaket in die Empfangsqueue der »wg«-Schnittstelle. Fällt die Prüfung negativ aus, verwirft sie es.

Funktioniert der Pakettransfer innerhalb des VPN zufriedenstellend, möchte der gewöhnliche Nutzer das Setup vielleicht, in der Regel sogar ganz bestimmt, festzurren. Die Wireguard-Einstellungen einzelner Hosts gießt er in diesem Fall fix in Konfigurationsdateien.

Mit dem Befehl »wg showconf« gibt Wireguard die aktuelle Konfiguration im richtigen Format aus (Abbildung 2). So lässt sich mit Hilfe einer Pipe eine gültige Konfigurationsdatei erzeugen, zum Beispiel »/etc/wireguard/wg0.conf«, die der Admin später mit »wg setconf wg0 /etc/wireguard/wg0.conf« einlesen kann.

Abbildung 2: »wg showconf« gießt bestehende Tunnel in eine Konfigurationsdatei. Die lässt sich bei Bedarf schnell wieder herstellen.

Betriebsbereit

Unter den Wireguard-Tools befindet sich auch das Bash-Skript »/usr/bin/wg-quick«. Das macht es möglich, Wireguard-Schnittstellen einfach in Betrieb zu nehmen beziehungsweise abzuschalten. Existiert für die gewünschte Wireguard-Schnittstelle eine Konfigurationsdatei, legt das Kommando »wg up Interface« das virtuelle Netzwerkinterface an, ordnet ihm eine IP-Adresse zu und setzt weitere IP-Adressen sowie gegebenenfalls auch Routen und DNS-Einträge. Darüber hinaus führt es zusätzliche »pre«- und »post-up«-Skripte aus.

Nach der Konfigurationsdatei sucht »wg-quick« standardmäßig in dem Verzeichnis »/etc/wireguard/interface.conf«. Der Befehl »wg down wg0« macht indes genau das, was nun bestimmt viele bereits vermuten, nämlich ein Wireguard-Interface abräumen. Eine Beispiel-Konfigurationsdatei zeigt Listing 3.

01 [Interface]
02 Address = 192.168.222.1/24
03 SaveConfig = true
04 PostUp = sysctl -w net.ipv4.ip_forward=1 && iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
05 PreDown = iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE && sysctl -w net.ipv4.ip_forward=0
06 ListenPort = 46602
07 PrivateKey = YMO3RHNWE1zroMaidnLEsg+lMpsbu+TAhTFQd/yPjHo=
08
09 [Peer]
10 PublicKey = fAoJ02w4ravlkLbcaiIl8bbQ6svlAZXJ3mUO3XR4u0g=
11 AllowedIPs = 192.168.222.2/32
12 Endpoint = 188.xxx.xx.xx:36448
13 PersistentKeepalive = 25
14
15 [Peer]
16 PublicKey = IhtXHhqeAJujdNTqAgWI/gfOxu/aq2aKI2fcReWfXEY=
17 AllowedIPs = 192.168.222.3/32
18 Endpoint = 192.168.10.9:44449

Der Eintrag »SaveConfig = true« sorgt dafür, die aktuelle Konfiguration zu speichern, sobald das Interface stirbt. Läuft alles und will der Admin das Wireguard-Interface künftig beim Booten automatisch erzeugen lassen, genügt es (zumindest unter Debian und Ubuntu), im Block mit dem entsprechenden physischen Interface die Zeile »post-up wg-quick up wg0« zu ergänzen.

Wireguard gegen Open VPN

Verglichen mit Open VPN möchte Wireguard in vielen Bereichen punkten. Dazu zählen – neben der fixen kryptografischen Suite – der kompakte Code des Kernelmoduls und höhere Übertragungsgeschwindigkeiten. Die bestätigten sich auch in einem kurzen Test. Dessen Resultate listet Tabelle 1 auf, die Messungen zeigen die Abbildungen 3 und 4. Als Testumgebung diente ein Netzwerk mit einem Raspberry Pi 2 als VPN-Gateway sowie einem EEE-PC 901, einem Open-VPN-Point-to-Point-Setup mit Tun-Dev und symmetrischen Schlüsseln.

Abbildung 3: Weniger ist besser: Auch beim Pingtest hat Wireguard leicht die Nase vorn.

Abbildung 4: Weniger ist besser: Wireguard kopierte Daten im Test deutlich schneller als Open VPN.

Mit nur knapp 4000 Zeilen Quelltext prüft und ändert ein Admin den Wireguard-Code deutlich einfacher, als es Open VPN ermöglicht, dessen Quelltext laut [11] 292182 Codezeilen umfasst.

Auch Ersteinrichtung und Inbetriebnahme gehen mit Wireguard deutlich flotter von der Hand und machen gefühlt mehr Freude als mit Open VPN. Schon die schnell erzeugten Schlüsselpaare sind verglichen mit der bei Open VPN nötigen Public-Key-Infrastruktur ein Traum. Hinzu kommen die ziemlich hohe Verschwiegenheit von Wireguard, der integrierte Schutz gegen DoS-Angriffe und die optionale Möglichkeit, PSK-Keys zu verwenden. Letztere hat Donenfeld implementiert, um möglichen Fortschritten im Quantencomputing zu begegnen und weiterhin die verschlüsselte Kommunikation sicherzustellen.

Gegen Wireguard spricht, dass es sich um ein noch relativ junges Protokoll mit nur einem Entwickler handelt. Zur Zeit unterstützt es außer Linux und OS X keine weiteren Betriebssysteme, weshalb sich das Tunnelprotokoll noch nicht für heterogene Netze und mobile Geräte eignet. So lange Wireguard nicht im Mainline-Kernel steckt, dürften Admins wenig Lust zeigen, das Modul mit jedem neuen Kernel zu aktualisieren. Auch das ausstehende Audit ist im professionellen Umfeld ein echtes Hindernis.

Fazit

Wireguard präsentiert sich als vielversprechende VPN-Alternative, die im privaten homogenen Netz bereits viel Spaß macht und überzeugt. Es lohnt sich, die Technologie im Auge zu behalten und – wenn möglich – die Entwicklung und den Einsatz aktiv mit voranzutreiben. Das Konzept ist ebenso spannend wie der Umstand, dass die VPN-Lösung demnächst im Kernel landen könnte.

Verglichen mit anderen VPNs sind Wireguard-Tunnel kinderleicht und schnell einzurichten. Das klare Konzept und die wenigen Konfigurationsmöglichkeiten bieten kaum Raum für fehlerhaft eingerichtete VPNs, und die Pakete sind im Netz flink unterwegs. Zu guter Letzt sei noch auf die umfassende Dokumentation und das Whitepaper [12] verwiesen, die Funktionsweise und Implementierung recht detailliert beschreiben.