Ich wollte auch einmal das neue Virtual Private Network WireGuard ausprobieren. Ein VPN ist für berufliche oder private Zwecke nützlich, etwa um auf selbst gehostete Serverdienste oder Dateien, die man nicht über das Internet freigeben möchte, von unterwegs aus zugreifen will.
Mein Anwendungsfall sieht konkret so aus, dass ich über mein Smartphone einen VPN-Tunnel zu meinem Heimserver herstellen können will. Selbst wenn ich mein Notebook außerhalb benutzen sollte, würde ich immer mein Smartphone als Hotspot für den Internetzugang benutzen. Das Handy führt man schließlich immer mit sich, daher ist das kein Nachteil. Entsprechend wird es auch nur eine Gegenstelle zu meinem Server für das VPN geben.
WireGuard ist als relativ neues VPN-Protokoll im Gespräch, unter anderem weil es schneller als andere VPN-Systeme ist, aber auch weil die Komplexität geringer ist. WireGuard soll nur etwa viertausend Codezeilen besitzen, während es bei OpenVPN mehrere hunderttausend sind. Weniger Komplexität sorgt für weniger Sicherheitsschwachstellen, weniger Fehler und mehr Geschwindigkeit. Gerade wenn man unterwegs nicht den besten Empfang hat, kann das Plus an Geschwindigkeit nützlich sein.
Je nachdem welchen Router man besitzt, ist die WireGuard-Unterstützung eventuell schon an Bord. Wenn euer Router keine Updates mehr bekommt müsst Ihr WireGuard gegebenenfalls selber auf eurem Server oder NAS installieren, besonders schwierig gestaltet sich die Installation unter Linux aber nicht.
Wenn man WireGuard selber installieren will, sollte man als Erstes vermutlich den standardmäßig von WireGuard verwendeten Port 51820 im Router freigeben. Denn sollte es dabei Probleme geben oder Ihr habt gar keinen Zugriff auf den Haus-Router, könnt Ihr euch das weitere Vorgehen direkt ersparen. Wichtig ist übrigens, dass WireGuard UDP und nicht TCP verwendet.
Ich werde keine vollständige Installationsanleitung zu WireGuard schreiben, da es schon diverse dazu gibt. Primär habe ich mich an der Anleitung von Serhat Teker orientiert, die für Ubuntu ausgelegt ist. Bei HowtoForge gibt es auch eine deutsche Anleitung für Ubuntu. Da WireGuard noch in Entwicklung ist und Unterstützung im Linux-Kernel benutzt, sollte die zugrundeliegende Linux-Distribution meines Erachtens nicht zu alt sein.
Man muss zwei Schlüsselpaare, jeweils bestehend aus einem Private und einem Public Key, erstellen – für den Server und für den Client. Das geschieht über den “wg genkey”-Befehl. Später bearbeitet man die Einstellungsdatei wg0.conf und trägt die Daten dort ein. Meine Datei vom Server sieht folgendermaßen aus:
[Interface]
Address = 10.0.0.1/24
SaveConfig = true
PostUp = iptables -A FORWARD -i %i -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
PostDown = iptables -D FORWARD -i %i -j ACCEPT; iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE
ListenPort = 51820
FwMark = 0xca6c
PrivateKey = $PRIVATE_SERVER_KEY
[Peer]
PublicKey = $PUBLIC_CLIENT_KEY
AllowedIPs = 10.0.0.2/32
Mit $ kennzeichne ich bei mir Variablen, diese Einträge müsst Ihr bei auch natürlich austauschen.
In der spartanischen WireGuard-Android-App auf dem Handy sieht das vom Aufbau her genauso aus, auch wenn man dort natürlich keine Textdatei bearbeitet. Der obere Abschnitt bezieht sich immer auf die Daten für das lokale Gerät, der untere Abschnitt dann auf die Gegenstelle.
Entsprechend bezieht sich der Abschnitt [Interface] der Datei wg0.conf vom Server auf die Daten des Servers, der Abschnitt [Peer] gibt die Daten des Smartphones an. Die IP-Adressen dort können beliebig vergeben werden und beziehen sich nicht auf bereits vorhandene IPs.
Übrigens ergänzt der WireGuard-Dienst im [Peer]-Abschnitt automatisch eine Endpoint-Zeile mit der öffentlichen IP-Adresse der Gegenstelle. Die öffentliche IP-Adresse im Internet wird meistens nicht fix sein, daher macht es keinen Sinn sie selber dort einzutragen. Wenn man die Datei nachträglich ändern möchte, sollte man jedenfalls den Dienst vorher stoppen und deaktivieren:
systemctl stop wg-quick@wg0
systemctl disable wg-quick@wg0
Wichtig ist außerdem, dass der Public Key des Clients dem Server bekannt gemacht werden muss:
wg set wg0 peer $PUBLIC_CLIENT_KEY allowed-ips 10.0.0.2
In der Android-App auf dem Smartphone werden die Daten der Gegenstelle, also vom Server, im unteren Abschnitt “Teilnehmer” eingetragen. Wichtig ist auch das Feld “Erlaubte IPs” nicht freizulassen, sondern dort 0.0.0.0/0 einzugeben. Damit funktioniert die Verbindung dann auch schon.
Falls Ihr übrigens bei aktiver VPN-Verbindung eure lokalen Serverdienste, aber keine Internetseiten mehr aufrufen könnt, solltet Ihr die DNS-Server-Einstellung überprüfen. Innerhalb des Haus-Netzes sollte das die IP vom Router sein. Ansonsten gibt es auch noch ein Log von WireGuard, das zur Fehlersuche kontrolliert werden kann.
Die Statistiken innerhalb der WireGuard-Android-App könnten sicher noch etwas ausgefeilter werden, im Grunde werden nur die gesendeten und empfangenen Datenmengen aufgelistet. Wenn der Handshake nicht funktioniert, bleibt es bei 0 KB auf der Empfangen-Seite.
Verlinken möchte ich abschließend noch die Seite von Digital Ocean mit mehr technischen Details zur Einrichtung von WireGuard unter Ubuntu.
Installation von Bitwarden
Neben WireGuard wollte ich auch noch einen richtigen Passwortmanager auf meinem Server installieren, dabei habe ich mich für Bitwarden entschieden. Als Installationsanleitung habe ich die von Linuxways.net benutzt. Als Erstes benötigt man Installation ID und Schlüssel für die Installation von Bitwarden, diese kann man über die Bitwarden-Seite im Internet anfordern.
Interessant ist, dass das Installationsskript von Bitwarden ganze elf Docker-Container aufsetzt, als Datenbank wird übrigens der Microsoft SQL Server benutzt. Wer auf Docker verzichten möchte, hat bei der Installation von Bitwarden also schlechte Karten.
Eigentlich ist die Installation von Bitwarden aber recht einfach, siehe Anleitung. Natürlich muss man auch den Reverse Proxy anpassen, wenn man die Mobile-Apps benutzen will. Bei Swag geht das recht einfach. Soweit ich gelesen habe wird SSL-Verschlüsselung bei Bitwarden vorausgesetzt, ich habe es bei mir ohne gar nicht erst probiert.
Ich habe bei meinen ersten Tests aber direkt ein paar Kritikpunkte an Bitwarden gefunden. Wenn man sich mit dem Master-Passwort einloggt, sieht man immer die Warnung dass man seine E-Mail-Adresse verifizieren muss, um alle Funktionen freizuschalten. Warum erscheint die Warnung, wenn man Bitwarden selber hostet und sich mit dem Master-Passwort einloggt?
Aber für die Benachrichtigungen macht es schon Sinn, als Erstes die Einrichtung des EMail-Accounts vorzunehmen. Aber da kam dann schon die nächste Frage, wo nimmt man eigentlich die SMTP-EMail-Einstellungen vor, damit das Versenden von EMails funktioniert? Er muss ja wissen welchen SMTP-Server er verwenden soll. Über die Oberfläche kann man diese Einstellungen jedenfalls nicht vornehmen.
Stattdessen nimmt man diese Einstellungen in der Datei global.override.env vor, den Pfad der Datei müsst Ihr ggf. mit locate suchen. Dort kann man die SMTP-Einstellungen wie Mailserver, Port und Passwort des EMail-Providers vornehmen. Falls man Änderungen dort vornimmt, fährt man übrigens am besten das ganze Bitwarden-Paket mit
bitwarden.sh stop
bitwarden.sh start
herunter bzw. startet es wieder neu.
Dann gab es bei mir das nächste Problem, das Versenden der Mail funktionierte zunächst nicht. Auf dem Webinterface erschien nur die Meldung dass es einen Fehler gab, aber keine Fehlermeldung die Rückschlüsse auf die Ursache geben würde. Ohne Hinweis gestaltete sich die Fehlersuche schwer.
Bitwarden benutzt ganze elf Docker-Container, was wohl mit ein Grund dafür ist dass es auf diese Weise ausgeliefert und eingerichtet wird. Es ohne Docker aufzusetzen würde sich wahrscheinlich ziemlich aufwendig gestalten. Jedenfalls hat natürlich jeder Docker eigene Logs, und die Fehlermeldungen beim Versenden der Mails konnte ich dann mit
>docker logs bitwarden-api
auslesen.
Diese Fehlermeldungen werden also im Bitwarden-Api-Docker protokolliert. Ich hatte mit meiner GMX-EMail-Adresse getestet, und de versendeten Mails wurden von GMX mit der Fehlermeldung
>Sender address is not allowed
abgewiesen.
Über den Fehler war ich an anderer Stelle schon einmal gestoßen; die EMails, die über GMX versendet werden sollen, müssen dieselbe Absenderadresse benutzen, mit der man sich auch bei GMX authentifiziert. Bezüglich Bitwarden muss man dann aber herausfinden, wie der Parameter dort heißt. Ich habe einen solcher Parameter in der Dokumentation in den Abschnitten “Included Variables” und “Optional Variables” vergeblich gesucht.
Der Parameter nennt sich
globalSettings__mail__smtp__From
Die Bezeichnung ist schon naheliegend, aber es kommt ja auf die genaue Syntax an. In der Einstellungsdatei ist ein solcher Parameter nicht per Default aufgelistet.
Jedenfalls konnte ich somit die Einrichtung abschließen und das Versenden von Benachrichtigungen funktioniert nun. Bitwarden macht auf mich funktional einen etwas spartanischen Eindruck, aber das kann ja auch ein Vorteil sein. Ein Anwendungslog auf der Webseite wäre vielleicht von Vorteil, wer möchte schon die Logs von elf Docker-Containern auf Terminalebene nach Fehlern durchsuchen.
Eventuell wäre für kleinere Setups auch ein Blick auf Vaultwarden von Vorteil gewesen, das ist ein Open Source-Fork von Bitwarden und wird auch auf kleineren Systemen wie dem Raspberry Pi unterstützt. Bei meinem Server kann ich immerhin nicht erkennen, dass Bitwarden nennenswert Performance nehmen würde. In den Tests hatte Bitwarden ganz gut abgeschnitten.
Von Vorteil ist natürlich, dass es Apps für Bitwarden für verschiedene Desktop- und Mobile-Betriebssysteme gibt, und auch Addons für mehrere Webbrowser sind verfügbar. Bitwarden ist für meine Zwecke sicher einsetzbar, ich würde aber wahrscheinlich schon dazu raten direkt über Backups nachzudenken. Es hat wahrscheinlich schon eine höhere Anwendungskomplexität im Vergleich zu anderen Managern und erst Recht im Vergleich zu einer einfachen KeePass-Containerdatei.
Ich tendiere dazu den ganzen LXC-Container über einen separaten Proxmox-Backupserver sichern zu lassen, aber soweit bin ich noch nicht. In der Bitwarden-Oberfläche gibt es eine “Tresor Exportieren”-Funktion, diese sollte man sicher öfter benutzen.
Einen Passwortmanager mit Einmal-Passwörtern zu benutzen ist in den heutigen Zeiten sicher von Vorteil. Eventuell kann man Bitwarden auch noch mit Authelia kombinieren, ich habe gesehen dass Swag für den Einsatz von Authelia bereits vorbereitet ist.