SSH auf die öffentliche IP des WireGuard-Servers scheitert unter Windows

Eine Route und eine Firewall-Regel sind zwei getrennte Entscheidungen. Unter Windows aktiviert ein Peer mit /0 restriktive Regeln, und der eigene Transport des Tunnels ist die Ausnahme.

Tunnel, die hochkommen, während SSH auf die öffentliche Adresse des Servers nicht mehr funktioniert, sehen aus wie ein Server, der die Verbindung ablehnt. Unter Windows ist die wahrscheinlichere Ursache lokal: Ein AllowedIPs für einen Volltunnel mit /0 aktiviert restriktive Firewall-Regeln, die den eigenen Transport des Tunnels und sehr wenig sonst erlauben. Verschlüsselte Pakete, die diese Adresse erreichen, sagen nichts darüber aus, ob eine separate TCP-Verbindung an dieselbe Adresse hinausgehen darf.

Trenne die öffentliche Adresse des Endpunkts von seiner inneren Tunneladresse, bevor du die Peer-Liste anfasst. Fast jeder Versuch, das durch Bearbeiten von AllowedIPs zu reparieren, macht die Richtlinie schwächer statt die Route korrekt.

Routing-Erlaubnis und Firewall-Erlaubnis sind verschieden

Eine Route entscheidet, wohin ein Paket gesendet würde, und eine Firewall-Regel entscheidet, ob es überhaupt gesendet werden darf. Eine Route für die öffentliche IP des Endpunkts erzeugt daher einen Pfad, den der Filter weiterhin blockieren kann, und genau diese Verwechslung erzeugt das Symptom. Unter Windows ist der Filter Teil der Implementierung und kein Zusatz, daher ändert ihn kein Routeneintrag. Auch anderswo sind die beiden Entscheidungen getrennt, auch wenn die Standardwerte abweichen.

Deshalb kann ein traceroute zum Endpunkt gelingen, während ein SSH-Versuch scheitert. Ersteres trägt der Dienst, dem die Ausnahme gehört, Letzteres nicht.

Was /0 unter Windows bewirkt

Bei einem einzigen Peer, dessen erlaubte Adressen den gesamten IPv4-Raum abdecken, wendet WireGuard for Windows eine restriktive Firewall-Haltung an, die Verkehr blockiert, der sonst außerhalb des Tunnels hinausgehen würde. Der eigene Transport des Tunneldienstes ist erlaubt, weil die VPN sonst nicht funktionieren könnte. Eine andere Anwendung an dieselbe öffentliche Adresse erhält keine solche Erlaubnis, da die Ausnahme zum Transport und nicht zur Adresse gehört. Windows-Netzwerkhinweise beschreiben dieses Verhalten und die zugehörige Steuerung im Editor.

Diese Regeln sind der Mechanismus hinter dem Begriff Kill-Switch. Sie werden durch die Form der Konfiguration aktiviert und nicht durch ein Kästchen mit dieser Bezeichnung.

Ausnahmen verändern das Schutzmodell

/0 durch zwei halbe Standardpräfixe zu ersetzen ist der dokumentierte Weg, breites Routing ohne die restriktive Semantik zu behalten, und es ist ein anderes Schutzmodell statt einer kürzeren Schreibweise. Die Endpunktadresse von den erlaubten Präfixen abzuziehen ist der andere übliche Workaround, der die Liste verlängert und ebenfalls ändert, welche Regeln greifen. Keines von beidem ist eine lokale Änderung mit lokaler Wirkung. Jede verschiebt die Grenze für jeden Datenfluss auf dem Rechner, nicht nur für die Verbindung, die repariert wurde.

Wo direktes öffentliches SSH wirklich nötig ist, muss der Profilinhaber sowohl die äußere Route als auch ihre Firewall-Erlaubnis entwerfen und entscheiden, was mit unbezogenem Verkehr geschieht, wenn der Tunnel abbricht. IPv4 und IPv6 getrennt zu prüfen gehört dazu, da die Regeln je Familie ausgedrückt werden. Ein breiter Bypass, der eine einzelne Verwaltungssitzung retten soll, legt meist mehr offen als diese Sitzung.

Teste den gewählten Verwaltungsweg

Entscheide zuerst, ob Verwaltung innerhalb oder außerhalb des Tunnels laufen soll, und teste dann diese Wahl statt beides gleichzeitig. Die folgenden Befehle prüfen die Adressen des Clients, den Peer-Zustand und eine Verbindung zu jedem Ziel. Führe sie vom Windows-Client aus, während der Tunnel steht.

ipconfig | findstr /i "WireGuard IPv4"
wg show
ssh -v [email protected]
Test-NetConnection 203.0.113.9 -Port 22

Ein erfolgreiches SSH auf die innere Adresse beweist, dass der Tunnel Verwaltungsverkehr trägt und die Firewall des Servers ihn aus dem Peer-Bereich annimmt. Ein Fehlschlag bei beiden Zielen ist ein serverseitiges oder Schlüsselproblem und kein Windows-Routingproblem. Wenn die innere Adresse funktioniert und die äußere nicht, die lokale Firewall-Haltung tut genau das, wofür sie entworfen wurde. Lies die drei Ergebnisse in dieser Reihenfolge, bevor du ein Profil bearbeitest.

Notiere den Verwaltungsweg, die verwendete Adresse und das Verhalten bei ausgefallenem Tunnel. Diese Notiz ist es, die die nächste Person davon abhält, den Bypass zu erweitern, um fünf Minuten zu sparen.

Ähnliche Artikel