Mit WireGuard steht eine schlanke und zugleich moderne wie auch sehr performante VPN-Lösung bereit, die mittlerweile in immer mehr Routern und anderen Produkten und Plattformen Einzug hält.
Ursprünglich gab es nur einen Client (wie auch Server) für Linux, im Laufe der vergleichsweise jungen Geschichte kamen Implementierungen und Clients sowie Apps für weitere Betriebssysteme hinzu.
Seit einiger Zeit gibt es einen offiziellen WireGuard-Client für Windows, dieser bietet neben einer grafischen Oberfläche für das Erstellen, Importieren oder auch Exportieren von Tunneln zudem eine Steuerung via CLI an. In diesem Beitrag geht es um verschiedene Aspekte der Nutzung des Clients unter Windows und beschäftigt sich unter anderem mit unterschiedlichen Nutzungsszenarien.
Persönliche Vorab-Bemerkung: Im Laufe der folgenden Zeilen ziehe ich die meisten Vergleiche von WireGuard zu OpenVPN, da ich dieses seit vielen Jahren in unterschiedlichen Szenarien verwende. Mit IPsec habe ich, abgesehen von ganz wenigen FRITZ!Boxen, bereits seit sehr langer Zeit nichts mehr zu tun.
Nutzung der GUI wenn der Benutzer administrative Rechte hat
Der WireGuard-Client funktioniert am Besten, wenn der ausführende Benutzer administrative Rechte hat, denn die zugrundeliegenden ausführbaren Dateien müssen Dienste anlegen, starten, beenden und löschen dürfen, ebenso wie das Setzen von Routen. Abgesehen davon ist die grafische Oberfläche simple und funktional:
Nutzung der GUI wenn der Benutzer keine administrative Rechte hat (Non-Admin)
Der offizielle Weg als normaler Benutzer WireGuard unter Windows nutzen zu können besteht darin das man in der Registry zunächst eine Änderung vornimmt. Der nachfolgende Einzeiler mit erhöhten Rechten ausgeführt erledigt die Aufgabe am einfachsten:
reg add HKLM\Software\WireGuard /v LimitedOperatorUI /t REG_DWORD /d 1 /f
Zusätzlich muss der Benutzer Mitglied in der Gruppe “Netzwerkkonfigurations-Operatoren” sein.
Quelle: Registry Keys for Admins
Grundsätzlich muss allerdings immer vom Administrator-Desktop (runas und Co. reicht nicht aus!) die Konfiguration angelegt oder importiert werden, erst dann kann der Benutzer den oder die Tunnel starten oder stoppen.
Persönlicher Erfahrungswert: Auf drei verschiedenen Windows-Systemen hatte ich mit der Nutzung von WireGuard als Non-Admin keinen wirklichen Erfolg. Die GUI öffnete sich immer erst dann, wenn man zuvor als Administrator angemeldet war und dort zuerst die GUI gestartet hatte. Wirklich praktikabel war und ist das nicht, daher wurden weitere Wege gesucht, dazu weiter unten mehr.
Wer sich noch an frühere Zeiten mit dem OpenVPN-Client unter Windows erinnern kann, dürfte ein gewisses Déjà-vu erleben. In dessen Anfangstagen war lange Zeit eine Nutzung ohne administrative Rechte ebenfalls nicht (so einfach) möglich, dort “scheiterte” es allerdings meist nur am Setzen der Route.
Steuerung via CLI
Neben der grafischen Oberfläche kann man mittels der “wg.exe” und “wireguard.exe” in der Eingabeaufforderung oder mittels Skript(e) WireGuard-Tunnel anlegen, ändern, starten, stoppen und entfernen. Dies bietet einige Möglichkeiten und ermöglicht zudem die Integration in automatisierte Abläufe oder in Admin-Werkzeugen. Die “wg.exe” dient primär dem Erzeugen der notwendigen Schlüssel und zum einsehen und ändern einer bestehenden Verbindung:
C:\Program Files\WireGuard>wg --help Usage: wg <cmd> [<args>] Available subcommands: show: Shows the current configuration and device information showconf: Shows the current configuration of a given WireGuard interface, for use with `setconf' set: Change the current configuration, add peers, remove peers, or change peers setconf: Applies a configuration file to a WireGuard interface addconf: Appends a configuration file to a WireGuard interface syncconf: Synchronizes a configuration file to a WireGuard interface genkey: Generates a new private key and writes it to stdout genpsk: Generates a new preshared key and writes it to stdout pubkey: Reads a private key from stdin and writes a public key to stdout You may pass `--help' to any of these subcommands to view usage.
Die “wireguard.exe” hingegen ist für die Tunnel-Dienste verantwortlich:
C:\Program Files\WireGuard>wireguard.exe --help
Kurzum, ein
"C:\Program Files\WireGuard\wireguard.exe" /installtunnelservice <Konfigurationsdatei>
installiert einen neuen Dienst mit dem Namen “WireGuard Tunnel: <Name der Konfigurationsdatei OHNE .conf>” und startet diesen.
Allerdings sind auch hierbei die Berechtigungen zu beachten! Als Workaround(s) kann man die “wireguard.exe” über eine Aufgabe mit höheren Rechten ausführen lassen oder das Skript als Dienst anlegen und steuern. Wie dies grundsätzlich geht, ist in folgenden Beiträgen beschrieben:
Windows: Aufgaben durch andere Benutzer ausführen lassen
Windows: Ein Skript oder eine Anwendung als Dienst ausführen
Tests haben gezeigt, das der Weg über einen eigenen Dienst gut funktioniert, aber dann benötigt der Benutzer die Berechtigung Dienste starten und beenden zu dürfen. Mitunter einfacher erscheint die Nutzung einer Aufgabe, da diese vom einfachen Benutzer z.B. mittels
schtasks /run /tn "WireGuard"
ausgeführt werden kann.
Nachteil: Via Aufgabe oder als Dienst gestartet, werden der oder die Tunnel nicht in der GUI angezeigt. Da die GUI allerdings als normaler Benutzer meiner Erfahrung nach ohnehin nicht richtig funktioniert, kann und muss man dies an dieser Stelle vernachlässigen.
Ausblick: Ich arbeite an einem Skript und Tool, das nach dem Start des Tunnels signalisiert, das eine Verbindung besteht.
Ausführen von Befehlen und Skripten
WireGuard bietet die Möglichkeit, Befehle und Skripte bei verschiedenen Verbindungs-Stati auszuführen. Damit dies überhaupt möglich ist, muss man dies zunächst in einer Eingabeaufforderung mit erhöhten Rechten ermöglichen:
reg add HKLM\Software\WireGuard /v DangerousScriptExecution /t REG_DWORD /d 1 /f
Nun kann man in der Konfigurationsdatei im Abschnitt “[Interface]” angeben, das z.B. vor der nach dem Verbindungsaufbau etwas ausgeführt werden soll:
PreUp = <Befehl oder Skript> PostUp = <Befehl oder Skript>
Ein ganz großes ABER gibt es an dieser Stelle: Diese Befehle werden mit SYSTEM-Rechten ausgeführt, das ist zwar am Beispiel von Split Tunneling für den Punkt DNS hilfreich (dazu gleich mehr), allerdings unbrauchbar wenn z.B. ein Netzlaufwerk nach dem Verbindungsaufbau verbunden werden soll.
Soviel zum Client an sich. Nachfolgend verschiedene typische Roadwarrior-VPN-Szenarien und wie man diese speziell mit WireGuard unter Windows umsetzen kann.
Alles durch den Tunnel (DNS + Redirect-Gateway)
Um grundsätzlich jeden Datenverkehr umzuleiten, muss man lediglich zwei Zeilen in der Konfigurationsdatei auf dem WireGuard-Client anpassen:
Im Abschnitt “[Interface]”:
DNS = <IP-Adresse des DNS-Servers>
Im Abschnitt “[Peer]”:
AllowedIPs = 0.0.0.0/0
Auf der Gegenseite, gemeint ist der beim WireGuard-Server, muss die Firewall den Datenverkehr natürlich durchlassen und routen können. Am WireGuard-Server ist im Vergleich zum OpenVPN-Server diesbezüglich nichts spezielles zu konfigurieren.
Split Tunneling (Routing)
Beim Split Tunneling geht es darum, nur bestimmten Datenverkehr in den Tunnel zu leiten. Das bekannteste Beispiel ist der Zugriff auf das Firmennetzwerk, mehr aber auch nicht. Damit nun das oder die IP-Netz(e) der Gegenseite erreicht werden können, muss lediglich folgen Zeile angepasst werden:
Im Abschnitt “[Peer]”:
AllowedIPs = 192.168.175.0/24
Mehrere Netze können komma-getrennt angegeben werden:
AllowedIPs = 192.168.175.0/24, 192.168.2.0/24
Split Tunneling (DNS)
Das Thema “Split Tunneling” und DNS ist bei WireGuard leider recht kompliziert. Fügt man im “[Interface]”-Abschnitt der Konfigurationsdatei den DNS-Eintrag hinzu:
DNS = 192.168.175.1
werden alle DNS-Anfragen zu diesem Server umgeleitet! Versucht man nun beispielsweise mit
DNS = 192.168.175.1, domain.tld
ein verbindungsspezifische DNS-Suffix zu verwenden funktioniert es ebenfalls nicht. Das Suffix wird zwar gesetzt, aber offenbar greift es nicht. Abhilfe schafft die Funktion NRPT – Name Resolution Policy Table zu nutzen, die Microsoft mit DirectAccess eingeführt hat. Gefunden wurde dieser Lösungsansatz hier:
reox’s projects/ blog/ posts/ wireguard dns only for vpn
Kurzum, man aktiviert wie weiter oben beschrieben die Skript-Ausführung und fügt im Abschnitt “[Interface]” folgende Befehle hinzu:
PostUp = powershell -command "Add-DnsClientNrptRule -Namespace '<domain.tld>','.<domain.tld>' -NameServers '<IP-des-DNS-Servers>'"
PostDown = powershell -command "Get-DnsClientNrptRule | Where { $_.Namespace -match '.*\.domain\.tld' } | Remove-DnsClientNrptRule -force"
Diese müssen hinsichtlich “domain.tld” und IP des internen DNS-Servers angepasst werden. Vor dem Tunnelaufbau wird die konfigurierte DNS-Domäne und deren DNS-Server bekannt gemacht und nach dem Tunnelabbau werden die Daten wieder gelöscht.
In der PowerShell (mit erhöhten Rechten) kann man mit
Get-DnsClientNrptRule
während der Tunnel besteht prüfen, ob die Richtlinie konfiguriert ist.
Das funktioniert, aber wirkt nicht auf alle Befehle. nslookup kann einen FQDN so nicht auflösen. Ein Ping auf den FQDN wiederum soll dem Hörensagen nach funktionieren, in meinen Tests kam allerdings immer ein Fehler von der Transfer-Netz-Adresse des WireGuard-Server zurück. Alternativ kann man auf die PowerShell zurückgreifen:
Resolve-DnsName <FQDN, domain.tld oder IP>
Nur Host- bzw. Computernamen funktioniert nicht, hingegen klappen aufrufe von FQDNs und URLs im Explorer und Browser.
Weiteres
Neutral: Im Gegensatz zu OpenVPN kann man bei WireGuard keine Einstellungen vom Server zum Client übertragen (pushen), d.h. eine zentrale Verwaltung ist nicht möglich und man muss seine Konfigurationsdatei für die Clients entsprechend ordentlich planen und verteilen. Man arbeitet (imho) am besten mit einer Vorlage die nur noch personalisiert werden muss.
Der Speicherort einer in der GUI importierten oder manuell angelegten Konfiguration lautet:
C:\Program Files\WireGuard\Data\Configurations
Die dortigen Konfigurationsdateien sind verschlüsselt. Kopiert man dort eine unverschlüsselte Konfigurationsdatei hinein, wird diese ebenfalls verschlüsselt!
Mehrere gleichzeitige Tunnel sind möglich, nachdem man in der Registry zuvor “MultipleSimultaneousTunnels” (siehe Quellen) setzt.
Fazit
Wer viel mit unterschiedlichen VPN-Verbindungen arbeitet, wird die CLI und die damit einhergehenden Automatisierungsmöglichkeiten zu schätzen Wissen. Mit ihrer Hilfe konnte ich WireGuard beispielsweise in mRemoteNG integrieren oder eine einfache Einwahl für einen Kunden realisieren so das man auf Mausklick eine Verbindung aufbauen oder trennen.
Der WireGuard-Client unter Windows ist nicht schlecht, aber es gibt noch Luft nach oben.
Mehrere Tunnel gleichzeitig, ohne das wie bei OpenVPN mehreren tun- oder tap-Interfaces benötigt werden, sind möglich. Hier ist allerdings, wie bei jeder anderen VPN-Lösung auch, das Routing zu beachten. Gemeint ist, das auf beiden Seiten des Tunnels das IP-Netz eindeutig sein sollte.
Quellen
GitHub – WireGuard/wireguard-windows
rair.dev – WireGuard Windows – Multiple Simultaneous Tunnels
Schon immer Technik-Enthusiast, seit 2001 in der IT tätig und seit über 10 Jahren begeisterter Blogger. Mit meiner Firma IT-Service Weber kümmern wir uns um alle IT-Belange von gewerblichen Kunden und unterstützen zusätzlich sowohl Partner als auch Kollegen. Die Schwerpunkte liegen auf der Netzwerkinfrastruktur, den Betrieb von Servern und Diensten.