Nur die Windows-Firewall als VPN-Notausschalter: Hält das?

Fragt man, ob die Windows-Firewall allein als Notausschalter fungieren kann, erhält man zwei selbstsichere und unvereinbare Antworten. Die eine sagt, die Regel nach Schnittstellentyp erledige die ganze Arbeit; die andere, ohne Skripte funktioniere es nicht. Beide beschreiben die Hälfte desselben Mechanismus. Die Firewall kann die Sperre ausdrücken, und ob das Ergebnis tatsächlich sicher geschlossen fehlschlägt, hängt von drei Dingen ab: wie Windows den Tunneladapter klassifiziert, ob die Endpunkt-Ausnahme überlebt und ob Namensauflösung und IPv6 abgedeckt sind. Vermasseln Sie eines davon, und die Maschine lässt entweder Daten durch oder verliert jede Verbindung.

Drei Bedingungen, in dieser Reihenfolge

Die erste Bedingung ist die Klassifizierung, und sie entscheidet, ob die gewünschte Regel überhaupt ausdrückbar ist. Windows-Firewallregeln lassen sich nach Schnittstellentyp einschränken: kabelgebunden, drahtlos oder Remotezugriff. Eine Richtlinie, die ausgehenden Verkehr auf den physischen Typen blockiert und den Tunnel zulässt, funktioniert nur, wenn Windows den Tunnel als Remotezugriff erkennt.

Die zweite Bedingung ist die Endpunkt-Ausnahme. Bevor ein Tunnel existiert, muss der Client den VPN-Server über den physischen Adapter erreichen, eine pauschale Sperre dieses Adapters verhindert also genau die Verbindung, die die Sperre überflüssig machen würde. Die Ausnahme muss den Server und seinen Port benennen, und das Paket muss über das physische Gateway hinausgehen statt in einen Tunnel, der noch nicht steht.

Die dritte ist die Abdeckung. Ein Regelsatz, der IPv4 blockiert und IPv6 vergisst, oder der dem lokalen Resolver die Endpunktabfrage erlaubt und damit jede andere Abfrage erlaubt, versagt offen genau in dem Fenster, für das es den Notausschalter gibt. Das ist eine Designlücke und kein Fehler der Firewall. Es ist auch die Lücke, die jeden Testlauf auf einem Schreibtisch übersteht.

Die Klassifizierung ist das erste Tor

Schauen Sie nach, was Windows über die Adapter denkt, bevor Sie auch nur eine Regel schreiben. Eine native Windows-VPN-Verbindung erscheint normalerweise als Remotezugriff. Ein Client eines Drittanbieters, der seinen eigenen virtuellen Adapter erzeugt, erscheint oft als kabelgebunden, was bedeutet, dass eine auf kabelgebundene Adapter begrenzte Sperre auch den Tunnel blockiert.

Get-NetConnectionProfile | Select-Object Name,InterfaceAlias,NetworkCategory
Get-NetAdapter | Select-Object Name,InterfaceDescription,Status,ifIndex
Get-NetFirewallProfile | Select-Object Name,Enabled,DefaultOutboundAction

Der dritte Befehl zeigt, ob bereits eine standardmäßige Ausgangssperre gilt, was die ganze Form des Entwurfs verändert. Ist die Vorgabe bereits Sperren, schreiben Sie Erlaubnisregeln statt Ausnahmen zu einer freizügigen Grundlage, und das ist eine viel leichter zu durchdenkende Haltung.

Meldet sich Ihr Tunneladapter als kabelgebunden, ist die Firewall allein nicht das richtige Werkzeug für ein Design mit sicherem Fehlschließen, und kein Regel-Tuning ändert das. Das ist der Fall, in dem die zweite Meinung in jedem Forenthread richtig ist.

Die Endpunkt-Ausnahme braucht eine Route und nicht nur eine Regel

Nehmen wir an, die Klassifizierung funktioniert. Die Ausnahme besteht aus zwei Teilen, und sie leben in verschiedenen Subsystemen. Die Firewallregel erlaubt den Verkehr; die Host-Route sorgt dafür, dass er über die richtige Schnittstelle hinausgeht, während der Tunnel unten ist.

New-NetFirewallRule -DisplayName "VPN endpoint allow" -Direction Outbound -Action Allow \
  -Protocol TCP -RemoteAddress 203.0.113.9 -RemotePort 443 -InterfaceType Wired,Wireless
New-NetRoute -DestinationPrefix 203.0.113.9/32 -InterfaceIndex 12 -NextHop 192.168.1.1
Get-NetRoute -DestinationPrefix 203.0.113.9/32

Ohne die Route hilft die Endpunkt-Ausnahme nur, solange eine Standardroute noch auf das physische Gateway zeigt. Sobald der Client seine eigene Standardroute installiert und dann stirbt, haben die erlaubten Pakete keinen vernünftigen Weg und die Verbindung lässt sich nicht wiederherstellen. Dieser Fehler sieht wie ein defekter Client aus und ist in Wahrheit eine fehlende Route.

Halten Sie die Ausnahme so eng, wie der Client es zulässt. Eine Adresse und ein Port sind überprüfbar; ein Bereich, der das gesamte Netz des Anbieters abdeckt, nicht. Die breitere Regel erlaubt auch alles andere, was beim selben Anbieter gehostet wird, und das ist meist mehr, als beabsichtigt war.

DNS und IPv6 sind die Stellen, an denen es offen versagt

Die Namensauflösung ist das klassische Leck. Ist der Endpunkt ein Hostname, muss der Client ihn auflösen, bevor der Tunnel existiert, was bedeutet, dass der physische Adapter einen Resolver erreichen darf. Dieselbe Erlaubnis lässt jede andere Abfrage hinaus, während der Tunnel unten ist, und eine Abfrage genügt, um zu verraten, was Sie besuchen wollten.

IPv6 ist das zweite. Für IPv4 geschriebene Regeln decken die andere Familie nicht ab, und viele Clients installieren nur IPv4-Routen. Eine Maschine mit nativem IPv6-Zugang kann daher weiter mit dem Internet sprechen, während die IPv4-Seite fest blockiert ist, und der Notausschalter meldet durchweg Erfolg.

Die dritte Zeile lohnt das Verstehen statt des Umgehens. Eine Firewall entscheidet über Pakete, nicht darüber, welche Schnittstelle eine Anwendung nutzen wollte, und ein Programm, das sich ausdrücklich bindet, lässt sich schwer bändigen. Das ist ein Argument für einen clientseitigen Notausschalter unterhalb der Anwendung, nicht für mehr Regeln.

Testen Sie durch Anhalten des Clients, nicht durch Ziehen des Kabels

Der einzig sinnvolle Test ist der, der den Fehler nachahmt, vor dem Sie sich schützen. Halten Sie den Dienst an, töten Sie den Prozess oder deaktivieren Sie den vom Client erzeugten Adapter, und versuchen Sie dann, das Internet und einen Namen zu erreichen:

Stop-Service -Name "YourVpnService" -Force
Test-NetConnection -ComputerName 1.1.1.1 -Port 443
Resolve-DnsName example.com
Test-NetConnection -ComputerName 2606:4700:4700::1111 -Port 443

Alle drei sollten fehlschlagen. Gelingt die erste, ist die Sperre nicht in Kraft; gelingt die zweite dort, wo die erste scheiterte, haben Sie ein DNS-Leck; gelingt die dritte, ist IPv6 nicht abgedeckt. Jedes Ergebnis zeigt auf genau eine der Lücken oben.

Wiederholen Sie den Test nach Ruhezustand und Aufwachen, denn das Firewallprofil kann sich ändern, wenn Windows ein Netzwerk als öffentlich oder privat einstuft, und profilgebundene Regeln folgen ihm. Ein Design, das auf dem Schreibtisch hält und im Zug versagt, ist ein einmal getestetes Design.

Machen das Klassifizierungstor oder die DNS-Anforderung den Nur-Firewall-Ansatz unbrauchbar, ist ein clientseitiger Notausschalter die ehrliche Antwort. Endet der Tunnel stattdessen auf einem Router, sollte der Router die Richtlinie besitzen, denn eine Regel dort deckt jedes Gerät dahinter ab und hängt nicht davon ab, wie Windows einen Adapter benennt.