WireGuard-Einrichtung unter Windows

Diese Anleitung beschreibt, wie Sie einen WireGuard-VPN-Tunnel zwischen zwei Windows-Rechnern einrichten: einem WireGuard-Server auf einem entfernten Windows-Host, zum Beispiel einem Windows-VPS, und einem WireGuard-Client auf Ihrem lokalen Windows-Computer. Sobald der Tunnel aktiv ist, tauschen die beiden Rechner Daten über eine verschlüsselte, private Verbindung aus, und Sie können optional den gesamten Datenverkehr des Clients über den Server leiten.

Die Grundkonfiguration stellt einen Tunnel zwischen Server und Client her. Um den gesamten Internetverkehr des Clients über den Server zu leiten, ist zusätzlich NAT auf dem Server erforderlich, siehe „NAT auf dem Server für Full Tunneling konfigurieren“.

Um die Schlüsselerzeugung einfach zu halten, werden in dieser Anleitung sowohl die Server- als auch die Client-Konfiguration in einer einzigen WireGuard-Anwendung erstellt und anschließend jeweils auf den Rechner übertragen, zu dem sie gehören. Die Server-Konfiguration läuft auf dem Server, die Client-Konfiguration auf dem Client. Server und Client sind immer getrennte Rechner. Für jeden weiteren Client wird dasselbe Verfahren verwendet.

Bevor Sie beginnen, installieren Sie auf dem Server und auf dem Client die aktuelle Version von WireGuard von der WireGuard-Installationsseite und stellen Sie sicher, dass Sie auf beiden Rechnern über Administratorrechte verfügen.

Das Setup in dieser Anleitung sieht wie folgt aus:

Server (öffentliche IP, lauscht auf UDP 51820)
Tunneladresse 10.0.0.1/24
        |
        |  verschlüsselter WireGuard-Tunnel
        |
Client
Tunneladresse 10.0.0.2/32

Server-Konfiguration erstellen

Starten Sie C:\Program Files\WireGuard\wireguard.exe, klicken Sie auf Add tunnel und wählen Sie Add empty tunnel. WireGuard erzeugt automatisch ein Schlüsselpaar. Der oben im Fenster angezeigte öffentliche Schlüssel ist der öffentliche Schlüssel des Servers. Sie benötigen ihn später bei der Konfiguration des Clients.

Geben Sie dem Tunnel einen Namen und füllen Sie den Abschnitt „Interface“ mit dem privaten Schlüssel des Servers, dem Port, auf dem WireGuard lauschen soll, und der internen Adresse, die der Server innerhalb des Tunnels verwendet.

[Interface]
PrivateKey = # privater Schlüssel des WireGuard-Servers
ListenPort = # Port, auf dem WireGuard lauscht
Address = # interne IP-Adresse des WireGuard-Servers, zum Beispiel 10.0.0.1/24

Verwenden Sie für das Tunnelnetz ein privates Subnetz und halten Sie Server und alle Clients im selben Adressbereich. Üblich sind 10.0.0.1/24 für den Server sowie 10.0.0.2/32, 10.0.0.3/32 usw. für die einzelnen Clients. Der Server verwendet das Präfix /24, damit er den gesamten Tunnelbereich als über die WireGuard-Schnittstelle erreichbar behandelt. Jeder Client verwendet /32, da ein Client eine einzelne Adresse und kein Subnetz darstellt. Ein Client mit /24 würde annehmen, dass der gesamte Bereich an seiner eigenen Schnittstelle liegt, und Datenverkehr für andere Tunneladressen nicht durch den Tunnel senden.

In der Server-Konfiguration wird das Kontrollkästchen Block untunneled traffic (kill-switch) nicht angezeigt. Diese Option erscheint nur in einer Client-Konfiguration, die den gesamten Datenverkehr durch den Tunnel leitet, siehe „Client-Konfiguration erstellen“.

Für eine zusätzliche Sicherheitsebene können Sie jedem Peer einen Pre-Shared Key hinzufügen. Erzeugen Sie ihn einmalig und fügen Sie dieselbe Zeile im zugehörigen Abschnitt [Peer] sowohl auf dem Server als auch auf dem Client ein:

PresharedKey = # Pre-Shared Key, identisch auf Server und Client

Den Schlüssel können Sie mit dem Tool wg erzeugen, das mit WireGuard installiert wird:

"C:\Program Files\WireGuard\wg.exe" genpsk

Client-Konfiguration erstellen

Klicken Sie ein zweites Mal auf Add tunnel und wählen Sie Add empty tunnel, diesmal für den Client. Der für diesen Tunnel angezeigte öffentliche Schlüssel ist der öffentliche Schlüssel des Clients, den der Server benötigt, um den Client zu akzeptieren.

Füllen Sie die Client-Konfiguration aus:

[Interface]
PrivateKey = # privater Schlüssel des WireGuard-Clients
Address = # interne IP-Adresse des WireGuard-Clients, zum Beispiel 10.0.0.2/32
DNS = 1.1.1.1, 1.0.0.1
[Peer]
PublicKey = # öffentlicher Schlüssel des WireGuard-Servers
AllowedIPs = # 0.0.0.0/0 für Full Tunnel oder 10.0.0.0/24 für Split Tunnel
Endpoint = # öffentliche IP-Adresse und Port des WireGuard-Servers
PersistentKeepalive = 25

Der Endpoint muss die tatsächliche öffentliche IP-Adresse des Servers zusammen mit dem in ListenPort des Servers festgelegten Port sein, nicht die interne Tunneladresse. Hinweise zur Wahl des Werts für AllowedIPs finden Sie im Abschnitt „AllowedIPs verstehen“ weiter unten.

Die Zeilen DNS und PersistentKeepalive sind optional. DNS legt die DNS-Server fest, die bei aktivem Tunnel verwendet werden, und hilft, Probleme bei der Namensauflösung nach dem Verbindungsaufbau zu vermeiden. Sie können öffentliche Resolver wie 1.1.1.1, 1.0.0.1 oder 8.8.8.8, 8.8.4.4 oder den DNS-Server des VPN-Netzwerks selbst verwenden. PersistentKeepalive = 25 sendet alle 25 Sekunden ein kleines Paket und hilft, die Verbindung offen zu halten, wenn sich der Client hinter NAT befindet.

Wenn die Client-Konfiguration genau einen [Peer] enthält und dessen AllowedIPs den Wert 0.0.0.0/0 (oder ::/0) enthält, zeigt der Tunnel-Editor unterhalb des Konfigurationsfelds das Kontrollkästchen Block untunneled traffic (kill-switch) an. Bei einem Split Tunnel, zum Beispiel AllowedIPs = 10.0.0.0/24, erscheint das Kontrollkästchen gar nicht.

Der Kill-Switch ist standardmäßig aktiviert, sobald Sie 0.0.0.0/0 eingeben. Solange der Tunnel aktiv ist, lassen die Firewall-Regeln nur Datenverkehr durch den Tunnel, Loopback-Verkehr, DHCP und IPv6 Neighbor Discovery zu. Alles andere wird blockiert, einschließlich Geräten im lokalen Netzwerk wie Druckern und NAS. Ist die Zeile DNS gesetzt, sind DNS-Abfragen nur an die dort aufgeführten Server erlaubt.

Das Deaktivieren des Kontrollkästchens schaltet nicht nur eine Einstellung ab. Der Editor schreibt AllowedIPs um: 0.0.0.0/0 wird zu 0.0.0.0/1, 128.0.0.0/1 und ::/0 zu ::/1, 8000::/1. Der gesamte Internetverkehr läuft weiterhin durch den Tunnel, die blockierenden Firewall-Regeln werden jedoch nicht erstellt. Wenn Sie das Kontrollkästchen erneut aktivieren, wird 0.0.0.0/0 wiederhergestellt.

Kopieren Sie die Schlüssel und den Endpoint sehr sorgfältig. Ein falsch eingegebener Schlüssel oder ein falscher Endpoint ist die häufigste Ursache dafür, dass ein Tunnel keine Verbindung herstellt.

Client zum Server hinzufügen

Öffnen Sie die Server-Konfiguration erneut und fügen Sie einen Abschnitt [Peer] für den Client hinzu. Verwenden Sie dabei den öffentlichen Schlüssel des Clients aus dem vorherigen Schritt.

[Peer]
PublicKey = # öffentlicher Schlüssel des WireGuard-Clients
AllowedIPs = # interne IP-Adresse des Clients

In der Server-Konfiguration hat AllowedIPs zwei Aufgaben. Es teilt dem Server mit, welche Tunneladresse zu diesem Client gehört, und dient als Routing-Liste: Jedes an diese Bereiche adressierte Paket wird verschlüsselt und an diesen Peer gesendet. Bei einem einzelnen Client ist das seine Tunneladresse, zum Beispiel 10.0.0.2/32. Soll der Client zusätzlich ein lokales Netzwerk über den Tunnel erreichbar machen, fügen Sie auch dieses Subnetz hinzu, zum Beispiel 10.0.0.2/32, 192.168.1.0/24. Wiederholen Sie diesen Schritt für jeden weiteren Client.

Windows-Firewall auf dem Server konfigurieren

Der Server muss eingehenden WireGuard-Verkehr auf seinem UDP-Port akzeptieren. Öffnen Sie Windows Defender Firewall mit erweiterter Sicherheit, wählen Sie Eingehende Regeln und klicken Sie auf Neue Regel. Wählen Sie Port und klicken Sie auf Weiter. Wählen Sie UDP, geben Sie den WireGuard-Port ein, zum Beispiel 51820, und klicken Sie auf Weiter. Wenn Sie mehr als einen Port verwenden, trennen Sie die Ports durch Kommas, zum Beispiel 51820, 51821. Wählen Sie Verbindung zulassen und klicken Sie auf Weiter. Wählen Sie die Profile aus, für die die Regel gelten soll. Wenn der Server in einem Rechenzentrum gehostet wird, genügt in der Regel das Profil „Öffentlich“, andernfalls lassen Sie die Profile „Domäne“, „Privat“ und „Öffentlich“ ausgewählt. Klicken Sie auf Weiter, vergeben Sie einen aussagekräftigen Namen wie WireGuard UDP 51820 und klicken Sie auf Fertig stellen.

Diese eingehende Regel wird nur auf dem Server benötigt, da der Server die Seite ist, die eingehende Verbindungen entgegennimmt. Stellen Sie bei einem VPS außerdem sicher, dass Ihr Hosting-Anbieter eingehenden UDP-Verkehr auf diesem Port auch auf Netzwerkebene erlaubt, nicht nur in der Windows-Firewall.

Konfigurationen exportieren und bereitstellen

Wenn beide Konfigurationen fertig sind, klicken Sie auf Export all tunnels to zip, wählen Sie einen Speicherort und speichern Sie.

Öffnen Sie das Archiv, um die Konfigurationsdateien aller Tunnel zu finden. Legen Sie die Server-Konfiguration auf dem Server ab und geben Sie jedem Client seine eigene Konfigurationsdatei. Enthält der Rechner viele Tunnel, können Sie einen einzelnen Tunnel auch über sein Kontextmenü exportieren. Der Export in eine ZIP-Datei ist praktisch, wenn beide Tunnel auf demselben Rechner erstellt wurden, wie in dieser Anleitung. Wenn Sie jede Konfiguration direkt auf ihrem eigenen Host erstellen, ist ein Export nicht erforderlich, und Sie können die Konfigurationsdatei manuell kopieren.

Wählen Sie auf dem Server die Server-Konfiguration aus und klicken Sie auf Activate.

Klicken Sie auf dem Client auf Add Tunnel, wählen Sie die Client-Konfigurationsdatei aus und öffnen Sie sie.

Klicken Sie anschließend auf Activate.

Der erste Client ist nun konfiguriert. Weitere Clients fügen Sie auf dieselbe Weise hinzu: Erstellen Sie für jeden Client einen neuen leeren Tunnel und fügen Sie der Server-Konfiguration einen passenden Abschnitt [Peer] mit dem öffentlichen Schlüssel und der Tunneladresse dieses Clients hinzu, wie unter „Client zum Server hinzufügen“ beschrieben.

Verbindung überprüfen

Nach dem Aktivieren des Tunnels zeigt Windows den WireGuard-Adapter im Netzwerk- und Freigabecenter möglicherweise als „Kein Netzwerkzugriff“ oder „Kein Internetzugriff“ an. Das ist erwartetes Verhalten, da Windows VPN-Tunneladapter nicht als normale Internetverbindungen behandelt, und es hat keine Auswirkungen auf den Tunnel. Windows ermittelt diesen Status mit seiner Konnektivitätsprüfung, die bestimmte Microsoft-URLs abfragt. Die Warnung kann daher auch erscheinen, wenn diese Abfragen blockiert oder von Ihrem DNS nicht aufgelöst werden, selbst wenn der Tunnel funktioniert.

Um zu bestätigen, dass der Tunnel funktioniert, prüfen Sie seinen Status im WireGuard-Client. Ein aktiver Tunnel zeigt den Status Active zusammen mit Datenübertragungszählern. Steigen die Zähler, überträgt der Tunnel Datenverkehr.

Auf dem Server können Sie außerdem prüfen, ob WireGuard bei aktivem Tunnel auf seinem UDP-Port lauscht:

netstat -ano | findstr 51820

In PowerShell lautet das Äquivalent:

Get-NetUDPEndpoint -LocalPort 51820

Ersetzen Sie 51820 durch Ihren WireGuard-Port. Wird nichts zurückgegeben, ist der Tunnel nicht aktiv oder der Port weicht von dem in der Server-Konfiguration festgelegten ab.

Öffnen Sie anschließend die Eingabeaufforderung und senden Sie einen Ping an die interne Tunneladresse des Servers:

ping 10.0.0.1

Ersetzen Sie 10.0.0.1 durch die tatsächlich festgelegte interne IP des Servers. Antwortet der Server, läuft der Datenverkehr durch den Tunnel. Bleibt die Antwort aus, prüfen Sie zuerst den Handshake: Die Windows-Firewall unter Windows Server blockiert eingehende Pings standardmäßig, daher bedeutet eine fehlende Antwort nicht immer, dass der Tunnel ausgefallen ist.

Verwendet der Client AllowedIPs = 0.0.0.0/0, können Sie zusätzlich bestätigen, dass der Datenverkehr durch den Tunnel geleitet wird:

tracert 8.8.8.8

Der erste Hop sollte die interne IP-Adresse des WireGuard-Servers sein.

WireGuard-Handshake prüfen

Der Handshake ist der aussagekräftigste Indikator bei der Diagnose einer WireGuard-Verbindung. Öffnen Sie in der WireGuard-Anwendung den Tunnel und beobachten Sie das Feld Latest handshake. Bei einem funktionierenden Tunnel erscheint der Handshake wenige Sekunden nach der Aktivierung und wird bei Datenübertragung regelmäßig aktualisiert. Ist der Tunnel inaktiv, kann zwischen Handshakes einige Zeit vergehen, eine kurze Pause ist also normal. Bleibt das Feld leer, können sich die Peers nicht erreichen. Das deutet meist auf einen falschen Endpoint, einen geschlossenen UDP-Port oder nicht übereinstimmende Schlüssel hin.

Den Handshake können Sie auch über die Befehlszeile mit dem Tool wg prüfen, das mit WireGuard installiert wird:

wg show

Die Ausgabe listet jeden Peer mit dem Zeitpunkt des letzten Handshakes und den Übertragungszählern auf.

AllowedIPs verstehen

Der Wert AllowedIPs in der Client-Konfiguration bestimmt, welcher Datenverkehr durch den Tunnel gesendet wird. Kurz gesagt: Auf dem Client legt AllowedIPs fest, welche Pakete in den Tunnel gesendet werden, auf dem Server dagegen, welche Pakete von einem bestimmten Client akzeptiert werden und wohin sie geroutet werden.

Der Wert 0.0.0.0/0 leitet den gesamten Datenverkehr durch den Tunnel, einschließlich des normalen Surfens im Internet. Verwenden Sie ihn, wenn Sie vollständigen Schutz des Datenverkehrs wünschen. Damit dieser Datenverkehr das Internet erreicht, muss der Server ihn übersetzen. Siehe „NAT auf dem Server für Full Tunneling konfigurieren“ weiter unten.

Ein Wert wie 10.0.0.0/24 leitet nur den Datenverkehr des internen Netzwerks durch den Tunnel, während der normale Internetverkehr die gewöhnliche Verbindung nutzt. Verwenden Sie ihn, wenn Sie nur auf bestimmte Ressourcen im entfernten Netzwerk zugreifen müssen.

Sie können mehrere Subnetze durch Kommas getrennt angeben, zum Beispiel 10.0.0.0/24, 192.168.1.0/24.

Zugriff auf das lokale Netzwerk bei aktivem Tunnel

Bei einem Split Tunnel, zum Beispiel AllowedIPs = 10.0.0.0/24, funktioniert das lokale Netzwerk wie gewohnt, und es muss nichts geändert werden. Die folgenden Schritte gelten für einen Full Tunnel.

Die einfachste Möglichkeit ist, das Kontrollkästchen Block untunneled traffic (kill-switch) im Tunnel-Editor des Clients zu deaktivieren. Der Editor ersetzt 0.0.0.0/0 durch 0.0.0.0/1, 128.0.0.0/1. Für Ihr lokales Subnetz, zum Beispiel 192.168.1.0/24, existiert über den physischen Adapter eine spezifischere Route, sodass Windows LAN-Verkehr direkt in das lokale Netzwerk sendet, während der Internetverkehr weiterhin durch den Tunnel läuft. Der Nachteil: Nichts blockiert den Datenverkehr, wenn der Tunnel ausfällt.

Wenn Sie sicherstellen möchten, dass LAN-Verkehr niemals in den Tunnel gelangt, schließen Sie den lokalen Bereich ausdrücklich aus AllowedIPs aus. Der folgende Wert deckt zum Beispiel jede IPv4-Adresse außer 192.168.0.0/16 ab:

AllowedIPs = 0.0.0.0/1, 128.0.0.0/2, 192.0.0.0/9, 192.128.0.0/11, 192.160.0.0/13, 192.169.0.0/16, 192.170.0.0/15, 192.172.0.0/14, 192.176.0.0/12, 192.192.0.0/10, 193.0.0.0/8, 194.0.0.0/7, 196.0.0.0/6, 200.0.0.0/5, 208.0.0.0/4, 224.0.0.0/3

Verwendet Ihr lokales Netzwerk einen anderen Bereich, etwa 10.x.x.x oder 172.16.x.x, berechnen Sie die Liste für diesen Bereich mit einem AllowedIPs-Rechner und stellen Sie sicher, dass das Tunnel-Subnetz weiterhin enthalten ist. Da dieser Wert keine /0-Route enthält, ist der Kill-Switch hiermit nicht verfügbar.

Info Verwenden Sie für den Tunnel und das lokale Netzwerk nicht dasselbe Subnetz. Wenn Ihr Heimnetzwerk 10.0.0.0/24 ist, wählen Sie einen anderen Tunnelbereich, zum Beispiel 10.8.0.0/24.

Um ein Netzwerk hinter dem Server zu erreichen, zum Beispiel ein Büro-LAN 192.168.10.0/24, benötigt der Server keinen zusätzlichen Eintrag, da er bereits eine Route zu seinem eigenen LAN besitzt. Fügen Sie es auf dem Client im Abschnitt [Peer] zu AllowedIPs hinzu, zum Beispiel AllowedIPs = 10.0.0.0/24, 192.168.10.0/24. Der Server muss diesen Datenverkehr außerdem weiterleiten und übersetzen, siehe „NAT auf dem Server für Full Tunneling konfigurieren“. Geräte in diesem LAN antworten an die LAN-Adresse des Servers, daher ist NAT auf dem Server der einfachste Weg, damit die Antworten durch den Tunnel zurückgelangen.

NAT auf dem Server für Full Tunneling konfigurieren

Wenn Clients AllowedIPs = 0.0.0.0/0 verwenden und ihr Datenverkehr tatsächlich über den Server ins Internet gelangen soll, muss der Server die internen WireGuard-Adressen in seine eigene externe Adresse übersetzen. Unter Windows geschieht dies mit dem Befehl New-NetNat und nicht mit den PostUp- und PostDown-Skripten, die unter Linux verwendet werden.

Öffnen Sie PowerShell als Administrator auf dem Server und führen Sie Folgendes aus, wobei Sie das dem Server zugewiesene Tunnel-Subnetz verwenden:

New-NetNat -Name WireGuardNAT -InternalIPInterfaceAddressPrefix 10.0.0.0/24

Ersetzen Sie 10.0.0.0/24 durch Ihr Tunnel-Subnetz und stellen Sie sicher, dass das Präfix jede zugewiesene Client-Adresse abdeckt. Ein Client außerhalb dieses Bereichs, zum Beispiel 10.0.1.2, würde von dieser Regel nicht erfasst. Die aktiven Regeln können Sie jederzeit prüfen:

Get-NetNat

Um die NAT-Regel später zu entfernen, führen Sie aus:

Remove-NetNat -Name WireGuardNAT

Wenn Clients sich verbinden und der Handshake erfolgreich ist, ihr Internetverkehr aber dennoch nicht über den Server läuft, aktivieren Sie IP-Weiterleitung auf den am Routing beteiligten Schnittstellen und testen Sie erneut. Die genaue Form hängt von der Windows-Version ab, zum Beispiel:

Set-NetIPInterface -InterfaceAlias "Ethernet" -Forwarding Enabled

Wenden Sie dies auf die externe Schnittstelle an, die den Internetverkehr trägt, sowie auf die WireGuard-Schnittstelle, und verwenden Sie dabei deren tatsächliche Namen aus Get-NetIPInterface.

Fehlerbehebung

Der Tunnel ist aktiv, aber es besteht keine Verbindung zum Server. Prüfen Sie, ob der WireGuard-UDP-Port, zum Beispiel 51820, in der Firewall des Servers geöffnet ist. Vergewissern Sie sich, dass die öffentlichen Schlüssel zwischen Server- und Client-Konfiguration korrekt kopiert wurden. Stellen Sie sicher, dass der Endpoint in der Client-Konfiguration auf die tatsächliche öffentliche IP-Adresse des Servers verweist und nicht auf die interne Tunneladresse.

DNS funktioniert nach dem Verbinden nicht. Fügen Sie dem Abschnitt „Interface“ des Clients einen DNS-Server hinzu:

[Interface]
PrivateKey = ...
Address = ...
DNS = 1.1.1.1, 1.0.0.1

Die Paketzähler steigen nicht. Der Tunnel überträgt keine Daten. Prüfen Sie, ob AllowedIPs auf beiden Seiten korrekt gesetzt ist, ob die internen WireGuard-Adressen nicht mit dem bestehenden lokalen Netzwerk kollidieren und ob der ListenPort nicht bereits von einer anderen Anwendung verwendet wird.

Das Kill-Switch-Kontrollkästchen lässt sich nicht deaktivieren. Der Editor schreibt AllowedIPs nur um, wenn er die gesamte Konfiguration lesen kann. Prüfen Sie, ob der Abschnitt [Peer] einen gültigen, vom Server kopierten öffentlichen Schlüssel enthält und ob jede Einstellung in einer eigenen Zeile steht, und versuchen Sie es dann erneut.

Sie benötigen mehr Details zur Diagnose eines Problems. Öffnen Sie den Tunnel in der WireGuard-Anwendung und sehen Sie sich die Registerkarte Log an, die Handshakes, Fehler und Verbindungsereignisse in Echtzeit aufzeichnet. Von dort können Sie das Protokoll exportieren, wenn Sie es weitergeben müssen.

WireGuard nach einem Server-Neustart automatisch starten

Damit der Tunnel über Neustarts hinweg weiterläuft, installieren Sie ihn als Windows-Dienst. Ein als Dienst installierter Tunnel startet nach einem Neustart automatisch. Öffnen Sie die Eingabeaufforderung oder PowerShell als Administrator und führen Sie den folgenden Befehl aus, wobei Sie den Pfad zu Ihrer Server-Konfigurationsdatei verwenden:

wireguard /installtunnelservice "C:\Program Files\WireGuard\wg_server.conf"

Führen Sie diesen Befehl nur einmal aus, nicht bei jedem Start. Das Aktivieren des Tunnels in der WireGuard-Anwendung installiert normalerweise denselben Dienst, sodass in vielen Fällen einmaliges Aktivieren genügt. Um den Dienst später zu entfernen, verwenden Sie den Tunnelnamen, also den Namen der Konfigurationsdatei ohne die Endung .conf.

wireguard /uninstalltunnelservice wg_server

Um den Dienst neu zu starten, zum Beispiel nach dem Bearbeiten der Konfiguration, führen Sie den Deinstallationsbefehl und anschließend erneut den Installationsbefehl aus.

Starten Sie den Server neu und prüfen Sie, ob der Tunnel von selbst startet.