Seit langem will ich mich mit dem Thema VPN beschäftigen. Allerdings hörte sich die Sache immer sehr mächtig an. Besonders, wenn frau/man anpeilt, einen eigenen Server zu implementieren. Zufällig stieß ich bei Kuketz in der Empfehlungsecke auf das hochgelobte WireGuard. Es sollte unglaublich simpel zu installieren sein. Drei Tage Arbeit und einen Techi-Tipp später war klar: also ich persönlich finde die Sache immer noch nicht ganz leicht. Aber wenn’s einmal läuft, dann läuft’s. Sogar der Energieverbrauch der App für das Smartphone ist in Ordnung. Wenn selbst das FP2 mit suboptimaler Akkulaufzeit damit klar kommt, ist das ein gutes Zeichen.
Interessant wird’s allerdings bei Kernel-Updates. Da hängt dann zumindest der Haussegen meines Servers doch wieder etwas schief…

WireGuard: „Server“ und „Client“-Installation

Alles fängt mit diesen Voraussetzungen an:
Ubuntu-Server 18.04 auf einem PC mit UEFI und natürlich der WireGuard-Page.

Schlecht ist sicher nicht, sich vorab darüber zu informieren, was VPN genau ist. Ich habe es während meiner Rumsucherei getan, weil ich ohne detaillierteres Verständnis einfach nicht vorwärts kam. Diejenigen, die etwas Geduld für Basisverständnis aufbringen, sind meist klar im Vorteil – hier ein Link.
Die Liste der Peer-Installationsanleitungen ist lang. Hier sind einige, die auf die ein oder andere Art hilfreich waren – sei es auch nur durch Mini-Hinweise:
_Linuxize
_Linux-Magazin
_Stavros.io
_Techrepublic
_IVPN
_Linode
_PC Welt
_Kürbis.org
Besonders verständlich waren für mich das immer hilfreiche Ubuntuuser-Wiki in Kombination mit Bitblokes.

„Required key not available“ – Lösung: UEFI Secure Boot deaktivieren

WireGuard hatte während der Installation verkündet, dass mein System mit UEFI Secure Boot laufe. Da Ubuntu kommerziell entwickelt wird, sind die Kernels signiert. WireGuard bringt jedoch seinen eigenen Kernel mit. Der ist unsigniert und wird extra installiert. UEFI weigert sich natürlich irgendwelche dahergelaufenen unsignierten Kernels zu akzeptieren. WireGuard reagierte anscheinend mit dem MOK. Meinem System half das leider gar nichts. Obwohl ich ein Passwort vergeben hatte, war die Installation nicht 100%ig geglückt.

Das Ergebnis war: „required key not available“Nach viel Online-Rumgesuche und -probiere griff ich zum Smartphone und zückte den Joker: den rettenden Techi-Tipp. Mir wurde erklärt, dass hier Brute Force am besten sei. Secure Boot musste händisch im BIOS ausgeschaltet werden. Also fuhr ich den Server runter und wieder hoch und drückte währenddessen „F2“. Anschließend suchte ich im BIOS „Secure Boot“, schaltete es aus, sicherte und ließ den Rechner weiter hoch laufen.

Vorhang auf: „sudo wg“

È voilà: Auf meine Anfrage: „sudo wg“ hin, regte sich endlich der VPN. Begeisterung – endlich sah das Ergebnis im Terminal so aus wie auf den Bildern der Anleitungen.
Nun ging’s an die Konfiguration. Eigentlich gibt es bei WireGuard kein Server-/Client-Verhältnis, sondern „Peers“. Der zentrale Peer heißt in der Konfiguration [Interface]. Auf welchem Gerät er sich befindet, ist völlig egal. Die Geräte-Performance sollte sicherlich stimmen, immerhin tauscht VPN kontinuierlich Daten aus. Der Client heißt bei WireGuard einfach [Peer].Wie auch immer, jetzt ging’s ans Key-Generieren. Linux fragte mich, ob ich denn wirklich der ganzen Welt meinen wichtigen hochgeheimen Private-Key mitteilen wollte. Natürlich nicht! Also lernte ich umask und 077 kennen und  tauchte tiefer in das Thema Rechte-Vergabe ein.

IPV4, IPv6 und die DNS-Server des Peers

Nach der Key-Vergabe näherte sich nun die Sache mit IPv4 und IPv6. Es wurde wieder vielschichtig. Wo sollten die herkommen? Da IPs etwas sind, das in einschlägigen Posts öfter verschleiert wird, hatte ich vermutet, dass die Anleitungen nicht die korrekten IPs angeben. Stattdessen, so dachte ich, sind wohl Adressen aus dem eigenen LAN-Netz gefragt. Tja, das war eine Fehlannahme.
Doch bevor sich das Problem in ganzer Schönheit zeigte, spielte ich ganz harmlos den Android-Client auf das Smartphone. Dafür kontaktierte ich F-Droid. Zu der Client-Konfiguration war das Netz recht wortkarg. Bitblokes war aber auch hier sehr hilfreich. Zu dem empfohlenen dnsforge DNS-Server packte ich noch den von digitalcourage und sicherte meine Konfiguration. So weit, so simpel. Tja, was soll ich sagen?
Der Server blieb stumm; der Client arbeitslos. Was war passiert?

Selbst“gebrautes“ Subnetz für WireGuard

Um es kurz zu machen: WireGuard braucht ein eigenes Subnetz – im Rückblick erklärlich. Immerhin soll der VPN ja möglichst störungsfrei autark Daten durchleiten. Hat er kein eigenes Subnetz, sondern wird z.B. irgendwie „Teil“ des LAN-Netzes, wird dieses kompromittiert, that´s not good. Aber vor allem: VPN funktioniert nicht richtig. Der Test mit einem Mail-Client zeigte, dass die Mails nicht weitergeleitet wurden. Ein bisschen Verständnis für IP und Subnetze half da weiter. Also auf in die exotische Welt der  homebrewed IP Adressen.

Das letzte Nadelöhr: der Port

Zum Thema Port war vorgesorgt. Vor einiger Zeit hatte ich auf Wikipedia dazu rum gelesen. Dieses „Ding“ läuft eine:r im Zusammenhang mit Rechnern immer wieder über den Weg. Naja, und da diese Software ja Daten über unterschiedlichste Distanzen hin- und herschicken soll, muss sie über das lokale Netz hinaus senden können. Wikipedia bietet eine Liste zum Thema Ports. Eigentlich geht fast jeder. Einige – besonders 80 und 443 – scheinen allerdings ungünstig zu sein. Für die Anleitungsschreibenden etabliert sich 51820 immer mehr als Standard. Den verwendet WireGuard auf seiner offiziellen Seite.

Welche:r hätte das gedacht: Die Kommunikation via WireGuard klappt!

…und sonst so?

Hier noch ein paar weiterführende Tipps:
_Heise

bezügl. Verbindung von Clients untereinander:
_EDVPfau

bezügl. fehlgeschlagenem Kernel-Update bei allgemeinem System-Update (Secure Boot disabled)
_reddit: DKMS rekonfigurieren

Ach so, falls euch die Sache mit dem eigenen „Interface“ zu blöd ist oder nicht eure Zwecke erfüllt: Es geht auch via VPN-Anbieter. Mullvad scheint aktuell ok zu sein, wenn frau/man 5€ monatlich locker machen möchte. Leider ist es wie üblich: nimmt frau/man es ganz genau, ist natürlich mal wieder nichts richtig sicher. Tja, Kuketz macht’s eine:r nicht leicht.

…und noch was

Ähnlich wie das Internet erzeugt VPN Datenverkehr zwischen dem Host und dem Peer. Das kostet Strom und erhöht folglich weiter unseren Bedarf. Damit wir nicht noch mehr AKW-Ruinen wie Rheinsberg verwalten müssen: immer schön Augenmaß bei der Nutzung bewahren.

 

Lizenzen: Fotos + Text: CC BY-SA