Handshake ja, Internet nein: Was auf Windows 11 zuerst zu prüfen ist

Frische Handshakes stehen auf Windows 11 oft neben Browsern, die nichts öffnen. Der Handshake belegt nur, dass der UDP-Austausch mit dem Peer abgeschlossen wurde. Er sagt nichts über die Route, die Windows eingerichtet hat, den Resolver, den es nutzt, oder ob der Ausgang überhaupt etwas weiterleitet.

Vier Bedingungen entscheiden, welche dieser Schichten versagt hat. Sie der Reihe nach abzuarbeiten dauert Minuten, während das Neuschreiben von Schlüsseln länger dauert und nichts ändert.

Erst die Schicht bestimmen, dann die Schlüssel anfassen

Arbeite drei Ziele in dieser Reihenfolge ab. Beginne mit einer tunnelinternen Adresse, dann eine öffentliche IP als Zahl, und schließe mit einem Hostnamen ab. Wo die Kette bricht, benennt die Schicht. Ein Fehler beim ersten Schritt ist Routing, beim zweiten ist es Weiterleitung oder NAT, beim dritten die Namensauflösung.

Diese Reihenfolge ist die ganze Methode. Sie verhindert, dass ein DNS-Fehler als kaputter Tunnel diagnostiziert wird, der häufigste Fehlgriff hier.

wg show
Find-NetRoute -RemoteIPAddress 1.1.1.1
Resolve-DnsName example.com -Server 1.1.1.1

Wenn die Handshake-Zeit leer ist

Wenn die Handshake-Zeit leer ist, kam der verschlüsselte Austausch nie zustande. Der Fehler liegt damit früher als das Routing. Prüfe zuerst Endpunktadresse und Port, dann ob das Netz UDP filtert. Ein Hoster, der WireGuard-Verkehr verwirft, erzeugt genau das, und ebenso ein Client, der einen Endpunkt aus einem alten Profil übernommen hat.

Bytes, die hinausgehen, ohne dass welche ankommen, sind ein anderer Fall. Das deutet auf NAT oder eine Firewall, die Verkehr an die falsche Stelle zurückgibt.

Wenn die Route gegen den physischen Adapter verliert

Für einen Full Tunnel muss der Peer-Abschnitt die Ziele abdecken, die du erwartest. Windows behält manchmal die Standardroute des physischen Adapters, selbst wenn ein Catch-all konfiguriert ist. Teilt man das Catch-all in 0.0.0.0/1 plus 128.0.0.0/1, entstehen zwei spezifischere Präfixe, die die Suche gewinnen. Die Aufteilung ist ein dokumentierter Workaround, keine Vorliebe.

Bestätige das mit route print oder einer Abfrage für eine öffentliche Adresse. Die gewählte Schnittstelle sollte der Tunneladapter sein. Wenn der physische weiterhin gewinnt, korrigiere die Peer-Bereiche, bevor du den Server anfasst.

Wenn Adressen funktionieren und Namen scheitern

WireGuard transportiert IP-Pakete und hat keine Meinung zu DNS. Setze eine Zeile DNS = in den Interface-Abschnitt oder stelle den Adapter über Windows ein. Ohne sie gelingt ein Ping auf eine Adresse, während jeder Hostname scheitert, und Nutzer melden das als kein Internet.

Prüfe, welche Server Windows nach dem Verbinden tatsächlich nutzt. Ein zurückgebliebener Resolver am physischen Adapter erklärt einen Teilausfall, bei dem einige Namen auflösen und andere nicht. Räume ihn auf, statt einen zweiten obendrauf zu setzen.

Wenn der Windows-Rechner der Ausgang ist

Internet Connection Sharing schreibt die Adressierung um, sobald es aktiviert ist, was den freigegebenen Adapter in einen anderen Bereich verschieben kann. Ein Client, der weiter auf die ursprüngliche Adresse zeigt, funktioniert dann nicht mehr. Die Registry-Werte ScopeAddress und StandaloneDHCPAddress steuern diesen Bereich, und die Einstellung kann nach einem Neustart zurückspringen.

Zwei weitere Windows-spezifische Konflikte lohnen einen Blick. Der Dienst Routing und RAS kann den Tunnel stören. Ein Installer für die falsche Architektur scheitert mit einer Meldung, die die Architektur nie erwähnt.

Behebe die Schicht, die der Test benannt hat, und wiederhole dann dieselben drei Ziele. Eine Änderung, die den Hostnamen-Test repariert, aber die Tunneladresse kaputt macht, wurde auf der falschen Schicht angewandt.