WireGuard-Einrichtung unter Windows
In dieser Anleitung wird erläutert, wie Sie einen WireGuard-VPN-Tunnel zwischen zwei Windows-Rechnern einrichten: einem WireGuard-Server, der auf einem entfernten Windows-Host läuft, beispielsweise einem Windows-VPS, und einem WireGuard-Client, der auf Ihrem lokalen Windows-Computer läuft. 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.
Um die Schlüsselgenerierung einfach zu halten, werden in dieser Anleitung sowohl die Server- als auch die Client-Konfiguration innerhalb einer einzigen WireGuard-Anwendung erstellt und anschließend die jeweilige Konfigurationsdatei auf dem Rechner bereitgestellt, zu dem sie gehört. Die Serverkonfiguration läuft auf dem Server und die Clientkonfiguration auf dem Client. Server und Client sind immer separate Rechner. Der gleiche Vorgang wird verwendet, um beliebig viele weitere Clients hinzuzufügen.
Bevor Sie beginnen, installieren Sie die neueste Version von WireGuard von der WireGuard-Installationsseite sowohl auf dem Server als auch auf dem Client und stellen Sie sicher, dass Sie auf jedem Rechner über Administratorrechte verfügen.
Die Einrichtung in dieser Anleitung sieht wie folgt aus:
Server (public IP, listening on UDP 51820) Tunnel address 10.0.0.1/24 | | encrypted WireGuard tunnel | Client Tunnel address 10.0.0.2/32
Erstellen der Serverkonfiguration
Führen Sie „C:\Program Files\WireGuard\wireguard.exe“ aus, klicken Sie auf „Tunnel hinzufügen“ und wählen Sie „Leeren Tunnel hinzufügen“. WireGuard generiert 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.

Gib dem Tunnel einen Namen und trage im Abschnitt „Schnittstelle“ den privaten Schlüssel des Servers, den Port, auf dem WireGuard empfangsbereit ist, sowie die interne Adresse ein, die der Server innerhalb des Tunnels verwenden wird.
[Interface] PrivateKey = # private key of the WireGuard server ListenPort = # port that WireGuard will listen on Address = # internal IP address of the WireGuard server, for example 10.0.0.1/24

Verwenden Sie für das Tunnelnetzwerk ein privates Subnetz und halten Sie den Server und alle Clients im selben Adressbereich. Eine gängige Wahl ist 10.0.0.1/24 für den Server und 10.0.0.2/32, 10.0.0.3/32 usw. für jeden Client. Der Server verwendet ein /24-Präfix, sodass er den gesamten Tunnelbereich als über die WireGuard-Schnittstelle erreichbar betrachtet. Jeder Client verwendet /32, da ein Client eine einzelne Adresse und kein Subnetz darstellt. Ein auf /24 eingestellter Client würde annehmen, dass sich der gesamte Bereich auf seiner eigenen Schnittstelle befindet, und würde keinen Datenverkehr für andere Tunneladressen durch den Tunnel senden.
Im Tunnel-Editor können Sie unterhalb des Konfigurationsfelds optional die Option „Ungetunnelten Datenverkehr blockieren (Kill-Switch)“ aktivieren, die jeglichen Datenverkehr blockiert, der den Tunnel verlassen würde, sowie einen vorab vereinbarten Schlüssel festlegen, der eine zusätzliche Sicherheitsebene bietet. Beide Optionen sind optional. Im Abschnitt „AllowedIPs verstehen“ erfahren Sie, wann der Kill-Switch nützlich ist und was er blockiert.

Erstellen der Client-Konfiguration
Klicken Sie auf „Tunnel hinzufügen“ und wählen Sie ein zweites Mal „Leeren Tunnel hinzufügen“, 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.
Geben Sie die Client-Konfiguration ein:
[Interface] PrivateKey = # private key of the WireGuard client Address = # internal IP address of the WireGuard client, for example 10.0.0.2/32 DNS = 1.1.1.1, 1.0.0.1 [Peer] PublicKey = # public key of the WireGuard server AllowedIPs = # 0.0.0.0/0 for a full tunnel, or 10.0.0.0/24 for a split tunnel Endpoint = # public IP address and port of the WireGuard server PersistentKeepalive = 25
Der Endpunkt muss die tatsächliche öffentliche IP-Adresse des Servers zusammen mit dem im ListenPort des Servers festgelegten Port sein, nicht die interne Tunneladresse. Hilfe bei der Auswahl 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 verwendet werden, solange der Tunnel aktiv ist, wodurch Probleme bei der Namensauflösung nach dem Verbindungsaufbau verhindert werden. 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 dabei, die Verbindung aufrechtzuerhalten, wenn sich der Client hinter einem NAT befindet.
Kopieren Sie die Schlüssel und den Endpunkt sehr sorgfältig. Ein falsch eingegebener Schlüssel oder ein falscher Endpunkt ist der häufigste Grund dafür, dass der Tunnel keine Verbindung herstellen kann.

Hinzufügen des Clients zum Server
Öffnen Sie die Serverkonfiguration erneut und fügen Sie einen [Peer] -Abschnitt für den Client hinzu, wobei Sie den öffentlichen Schlüssel des Clients aus dem vorherigen Schritt verwenden.
[Peer] PublicKey = # public key of the WireGuard client AllowedIPs = # internal IP address of the client
In der Serverkonfiguration hat „AllowedIPs“ zwei Funktionen. Es teilt dem Server mit, welche Tunneladresse zu diesem Client gehört, und dient gleichzeitig als Routing-Liste: Jedes Paket, das an diese Adressbereiche adressiert ist, wird verschlüsselt und an diesen Peer gesendet. Bei einem einzelnen Client ist dies dessen Tunneladresse, zum Beispiel 10.0.0.2/32. Soll der Client auch ein lokales Netzwerk über den Tunnel erreichbar machen, fügen Sie dieses Subnetz ebenfalls hier hinzu, zum Beispiel 10.0.0.2/32, 192.168.1.0/24. Wiederholen Sie diesen Schritt für jeden weiteren Client.

Konfiguration der Windows-Firewall auf dem Server
Der Server muss eingehenden WireGuard-Datenverkehr auf seinem UDP-Port akzeptieren. Öffnen Sie die „Windows Defender-Firewall mit erweiterter Sicherheit“, wählen Sie „Eingehende Regeln“ aus 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, listen Sie die Ports durch Kommas getrennt auf, 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, reicht in der Regel das Profil „Öffentlich“ aus; andernfalls lassen Sie die Profile „Domäne“, „Privat“ und „Öffentlich“ ausgewählt. Klicken Sie auf „Weiter“, geben Sie der Regel einen eindeutigen Namen wie beispielsweise „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 empfängt. Stellen Sie bei einem VPS außerdem sicher, dass Ihr Hosting-Anbieter eingehenden UDP-Datenverkehr auf diesem Port auf Netzwerkebene zulässt, nicht nur in der Windows-Firewall.
Exportieren und Bereitstellen der Konfigurationen
Wenn beide Konfigurationen fertig sind, klicken Sie auf „Alle Tunnel als ZIP exportieren“, wählen Sie einen Speicherort aus und speichern Sie die Datei.

Öffne das Archiv, um die Konfigurationsdateien für alle Tunnel zu finden. Lege die Serverkonfiguration auf dem Server ab und weise jedem Client seine eigene Konfigurationsdatei zu. Wenn der Rechner viele Tunnel enthält, kannst du auch einen einzelnen Tunnel über dessen 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 dem jeweiligen Host erstellen, ist ein Export nicht erforderlich, und Sie können die Konfigurationsdatei manuell kopieren.
Wählen Sie auf dem Server die Serverkonfiguration aus und klicken Sie auf „Aktivieren“.

Klicken Sie auf dem Client auf „Tunnel hinzufügen“, wählen Sie die Client-Konfigurationsdatei aus und öffnen Sie sie.

Klicken Sie anschließend auf „Aktivieren“.

Der erste Client ist nun konfiguriert. Fügen Sie weitere Clients auf dieselbe Weise hinzu: Erstellen Sie für jeden Client einen neuen leeren Tunnel und fügen Sie der Serverkonfiguration einen entsprechenden [Peer] -Abschnitt mit dem öffentlichen Schlüssel und der Tunneladresse dieses Clients hinzu, wie unter „Hinzufügen des Clients zum Server“ beschrieben.
Wenn Sie WireGuard auf einem Remote-Server über eine RDP-Sitzung konfigurieren, lesen Sie den Abschnitt „AllowedIPs verstehen“, bevor Sie einen Tunnel aktivieren, der den gesamten Datenverkehr weiterleitet. Eine Konfiguration mit AllowedIPs = 0.0.0.0/0 kann den eigenen Datenverkehr des Servers in den Tunnel umleiten und Ihre RDP-Verbindung unterbrechen.
Überprüfen der Verbindung
Nachdem Sie den Tunnel aktiviert haben, zeigt Windows den WireGuard-Adapter im Netzwerk- und Freigabecenter möglicherweise als „Kein Netzwerkzugriff“ oder „Kein Internetzugang“ an. Dies ist ein erwartetes Verhalten, da Windows VPN-Tunneladapter nicht als Standard-Internetverbindungen behandelt, und es hat keine Auswirkungen auf den Tunnel. Windows ermittelt diesen Status anhand seiner Verbindungsprüfung, bei der bestimmte Microsoft-URLs abgefragt werden. Daher kann die Warnung auch erscheinen, wenn diese Abfragen blockiert oder von Ihrem DNS nicht aufgelöst werden – selbst wenn der Tunnel funktioniert.
Um zu überprüfen, ob der Tunnel funktioniert, sehen Sie sich dessen Status im WireGuard-Client an. Ein aktiver Tunnel zeigt den Status „Aktiv“ zusammen mit Zählern für die Datenübertragung an. Wenn sich die Zähler erhöhen, leitet der Tunnel Datenverkehr weiter.
Auf dem Server können Sie außerdem überprüfen, ob WireGuard während der Tunnelaktivität auf seinem UDP-Port lauscht:
netstat -ano | findstr 51820
In PowerShell lautet der entsprechende Befehl:
Get-NetUDPEndpoint -LocalPort 51820
Ersetzen Sie 51820 durch Ihren WireGuard-Port. Wenn keine Antwort zurückgegeben wird, ist der Tunnel nicht aktiv oder der Port weicht von dem in der Serverkonfiguration festgelegten ab.
Öffnen Sie anschließend die Eingabeaufforderung und pingen Sie die interne Tunneladresse des Servers an:
ping 10.0.0.1
Ersetze 10.0.0.1 durch die tatsächliche interne IP-Adresse, die du für den Server festgelegt hast. Antworten bestätigen, dass der Tunnel funktioniert.
Wenn der Client „AllowedIPs = 0.0.0.0/0“ verwendet, können Sie außerdem überprüfen, ob der Datenverkehr durch den Tunnel geleitet wird:
tracert 8.8.8.8
Der erste Hop sollte die interne IP-Adresse des WireGuard-Servers sein.
Überprüfen des WireGuard-Handshakes
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 innerhalb von Sekunden nach der Aktivierung und wird dann während der Datenübertragung regelmäßig aktualisiert. Befindet sich der Tunnel im Ruhezustand, kann zwischen den Handshakes etwas Zeit vergehen, sodass eine kurze Pause normal ist. Bleibt das Feld leer, können die Peers einander nicht erreichen, was in der Regel auf einen falschen Endpunkt, einen geschlossenen UDP-Port oder nicht übereinstimmende Schlüssel hindeutet.
Sie können den Handshake auch über die Befehlszeile mit dem im Lieferumfang von WireGuard enthaltenen Tool „wg“ überprüfen:
wg show
Die Ausgabe listet jeden Peer zusammen mit seiner letzten Handshake-Zeit und seinen Übertragungszählern auf.
AllowedIPs verstehen
Der Wert „AllowedIPs“ in der Client-Konfiguration legt fest, welcher Datenverkehr durch den Tunnel geleitet wird. Kurz gesagt: Auf dem Client bestimmt „AllowedIPs“, welche Pakete in den Tunnel gesendet werden, während es auf dem Server festlegt, welche Pakete von einem bestimmten Client akzeptiert und wohin sie weitergeleitet werden.
Ein Wert von 0.0.0.0/0 leitet den gesamten Datenverkehr durch den Tunnel, einschließlich des normalen Surfens im Internet. Verwenden Sie diesen Wert, wenn Sie einen vollständigen Schutz des Datenverkehrs wünschen. Damit dieser Datenverkehr das Internet erreichen kann, muss der Server ihn übersetzen. Siehe „NAT auf dem Server für vollständiges Tunneling konfigurieren“ weiter unten.
Ein Wert wie 10.0.0.0/24 leitet nur den internen Netzwerkverkehr durch den Tunnel, während der normale Internetverkehr weiterhin über die normale Verbindung läuft. Verwenden Sie diese Einstellung, wenn Sie nur bestimmte Ressourcen im Remote-Netzwerk erreichen müssen.
Sie können mehrere Subnetze durch Kommas getrennt auflisten, zum Beispiel 10.0.0.0/24, 192.168.1.0/24.
Die Option „Untunnelten Datenverkehr blockieren (Kill-Switch)“ im Tunnel-Editor entfaltet ihre volle Wirkung bei „AllowedIPs = 0.0.0.0/0“. Sie blockiert alles, was außerhalb des Tunnels übertragen würde, wodurch auch das lokale Netzwerk blockiert wird. Wenn Sie Zugriff auf Drucker oder andere LAN-Geräte benötigen, lassen Sie den Kill-Switch deaktiviert.
Die Einstellung „AllowedIPs = 0.0.0.0/0“ leitet jede Verbindung durch den Tunnel. Wenn Sie dies auf einem Remote-Server anwenden, den Sie über RDP verwalten, kann die RDP-Sitzung in dem Moment abbrechen, in dem der Tunnel aktiv wird, da der Datenverkehr des Servers umgeleitet wird. Leiten Sie auf einem über RDP erreichbaren Server nur die Subnetze weiter, die Sie benötigen, und testen Sie zunächst mit einem engen „AllowedIPs“-Wert, bevor Sie auf 0.0.0.0/0 umstellen.
Konfiguration von NAT auf dem Server für vollständiges Tunneling
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 erfolgt dies mit dem Befehl „New-NetNat“, nicht mit den unter Linux verwendeten Skripten „PostUp“ und „PostDown“.
Öffnen Sie PowerShell als Administrator auf dem Server und führen Sie folgenden Befehl 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 alle von Ihnen zugewiesenen Client-Adressen abdeckt. Ein Client außerhalb dieses Bereichs, zum Beispiel 10.0.1.2, würde von dieser Regel nicht erfasst werden. Sie können die aktiven Regeln jederzeit einsehen:
Get-NetNat
Um die NAT-Regel später zu entfernen, führen Sie folgenden Befehl aus:
Remove-NetNat -Name WireGuardNAT
Wenn Clients eine Verbindung herstellen und der Handshake erfolgreich ist, ihr Internetverkehr jedoch immer noch nicht über den Server geleitet wird, aktivieren Sie die IP-Weiterleitung auf den am Routing beteiligten Schnittstellen und führen Sie einen erneuten Test durch. Die genaue Syntax hängt von der Windows-Version ab, zum Beispiel:
Set-NetIPInterface -InterfaceAlias "Ethernet" -Forwarding Enabled
Wenden Sie dies auf die externe Schnittstelle, über die der Internetverkehr läuft, und auf die WireGuard-Schnittstelle an, wobei Sie deren tatsächliche Namen aus „Get-NetIPInterface“ verwenden.
„New-NetNat“ erfordert Windows 10, Windows 11 oder Windows Server 2016 und höher; auf einigen Systemen muss zudem die Hyper-V-Funktion aktiviert sein, auch wenn Sie Hyper-V ansonsten nicht nutzen. Bei einigen VPS-Tarifen kann Hyper-V nicht aktiviert werden, wodurch diese Methode nicht möglich ist. Ob „New-NetNat“ allein ausreicht oder zusätzlich die IP-Weiterleitung aktiviert werden muss, kann von der Windows-Version abhängen. Überprüfen Sie dies daher auf Ihrem Server, wenn das vollständige Tunneling nicht funktioniert.
Fehlerbehebung
Der Tunnel ist aktiv, aber es besteht keine Verbindung zum Server. Überprüfen Sie, ob der WireGuard-UDP-Port, zum Beispiel 51820, in der Firewall des Servers offen ist. Vergewissern Sie sich, dass die öffentlichen Schlüssel korrekt zwischen den Server- und Client-Konfigurationen kopiert wurden. Stellen Sie sicher, dass der Endpunkt in der Client-Konfiguration auf die tatsächliche öffentliche IP-Adresse des Servers verweist und nicht auf die interne Tunneladresse.
DNS funktioniert nach dem Verbindungsaufbau nicht. Fügen Sie im Abschnitt „Client-Schnittstelle“ einen DNS-Server hinzu:
[Interface] PrivateKey = ... Address = ... DNS = 1.1.1.1, 1.0.0.1
Die Paketzähler steigen nicht an. Der Tunnel leitet keine Daten weiter. Überprüfen Sie, ob „AllowedIPs“ auf beiden Seiten korrekt eingestellt 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.
Zur Diagnose eines Problems benötigen Sie weitere Details. Öffnen Sie den Tunnel in der WireGuard-Anwendung und sehen Sie sich die Registerkarte „Log“ an, auf der Handshakes, Fehler und Verbindungsereignisse in Echtzeit protokolliert werden. Von dort aus können Sie das Protokoll exportieren, falls Sie es weitergeben müssen.
WireGuard nach einem Server-Neustart automatisch starten
Um den Tunnel auch nach einem Neustart am Laufen zu halten, installieren Sie ihn als Windows-Dienst. Wenn ein Tunnel als Dienst installiert ist, startet er nach einem Neustart automatisch. Öffnen Sie die Eingabeaufforderung oder PowerShell als Administrator und führen Sie den folgenden Befehl unter Verwendung des Pfads zu Ihrer Serverkonfigurationsdatei aus:
wireguard /installtunnelservice "C:\Program Files\WireGuard\wg_server.conf"
Führen Sie diesen Befehl nur einmal aus, nicht bei jedem Systemstart. Durch das Aktivieren des Tunnels über die WireGuard-Anwendung wird normalerweise derselbe Dienst installiert, sodass in vielen Fällen eine einmalige Aktivierung ausreicht. Um den Dienst später zu entfernen, verwenden Sie den Tunnelnamen, d. h. den Namen der Konfigurationsdatei ohne die Erweiterung .conf.
wireguard /uninstalltunnelservice wg_server
Um den Dienst neu zu starten, beispielsweise nach einer Bearbeitung der Konfiguration, führen Sie den Deinstallationsbefehl gefolgt vom Installationsbefehl erneut aus.
Da der Tunnel als Dienst läuft, ist keine separate Aufgabe im Taskplaner erforderlich.
Starten Sie den Server neu und vergewissern Sie sich, dass der Tunnel automatisch startet.
