Kill-Switch unter Windows ohne Zusatzsoftware: Profile oder Routen?

Firewall-Profile folgen der Kategorie eines Netzes, Routen folgen dem Adapter. Vergleichen Sie beides und prüfen Sie dann den Absturzfall, wenn der Tunnel weg ist und das Symbol lügt.

Der Client stirbt mitten im Download und das Taskleisten-Symbol verschwindet. Die Übertragung läuft über die Heimverbindung weiter. Genau diese Abfolge ist der Grund, warum es einen Kill-Switch gibt, und Windows kann einen ohne ein zweites Produkt annähern.

Zwei Verfahren lohnt es zu kennen. Sie scheitern an unterschiedlichen Stellen, und keines ist eine vollständige Antwort.

Verfahren eins: das Programm nur in einem Profil erlauben

Die Windows-Firewall beschränkt Regeln auf die Profile Domain, Private und Public. Der Trick besteht darin, dem Tunneladapter eine Kategorie und dem physischen Adapter eine andere zu geben. Dann schreiben Sie eine Ausgangsregel, die das geschützte Programm im Tunnelprofil erlaubt und es überall sonst blockiert. Die Firewall liest die Kategorie, nicht den Adapternamen.

Setzen Sie zuerst die VPN-Verbindung auf Private und das physische Netz auf Public. Fügen Sie dann eine Sperrregel für das Programm hinzu, die für die unerwünschten Profile gilt. Bestätigen Sie die Zuordnung danach mit Get-NetConnectionProfile, denn genau dieser Zuordnung folgt die Regel.

Get-NetConnectionProfile | Select-Object Name, InterfaceAlias, NetworkCategory

New-NetFirewallRule -DisplayName 'Block browser off VPN' -Direction Outbound `
  -Program 'C:\Program Files\Mozilla Firefox\firefox.exe' -Action Block -Profile Public

New-NetFirewallRule -DisplayName 'Allow browser on VPN' -Direction Outbound `
  -Program 'C:\Program Files\Mozilla Firefox\firefox.exe' -Action Allow -Profile Private

Die Schwäche ist strukturell. Eine Profilregel folgt der Kategorie, wenn Windows also ein Hotelnetz neu einstuft, kann die Sperre aufhören zu greifen. In der Regelliste ändert sich dabei nichts.

Verfahren zwei: die physische Standardroute entfernen

Der Routenansatz ist gröber und deutlich leichter zu prüfen. Notieren Sie das physische Gateway, lassen Sie das VPN seine eigene Standardroute mit niedrigerer Metrik setzen und löschen Sie dann die physische Standardroute. Danach kann nichts anderes mehr Verkehr tragen.

route print -4
route delete 0.0.0.0 mask 0.0.0.0 192.168.50.1
route print -4 | findstr /c:"0.0.0.0"

Wenn der Client stirbt, verschwindet die VPN-Route mit ihrem Adapter. Die Maschine geht offline statt zu leaken, und genau das soll ein Kill-Switch erzeugen.

Zwei Details entscheiden, ob das eine Woche übersteht. DHCP setzt das Gateway zurück, sobald die Verbindung flattert. Ein physischer Adapter mit statischer Adresse vermeidet diese Überraschung. Auch die Adresse des VPN-Servers selbst muss erreichbar bleiben. Ohne diesen Hostpfad kann der Client sich nach dem Ausfall, der die Sperre ausgelöst hat, nie wieder verbinden.

Verfahren drei: kein Gateway, eine dauerhafte Hostroute

Die dritte Möglichkeit beginnt damit, das Gateway aus den Adaptereinstellungen zu entfernen. Danach ersetzt eine einzige dauerhafte Route zum VPN-Endpunkt es. Die Maschine kann dann mit dem Server und mit nichts anderem sprechen, bis der Tunnel hochkommt.

route -p add 198.51.100.44 mask 255.255.255.255 192.168.50.1 metric 1
route print -4 | findstr 198.51.100.44

Das Gateway wiederherzustellen stellt normales Internet wieder her, was dies zu einem sauberen Ein- und Ausschalter macht. Es hängt nicht von einem Skript ab, das Schnittstellenereignisse beobachtet. Es ist auch egal, wie das Netz eingestuft wird.

Der Preis ist völlige Isolation, solange der Tunnel steht. Updates hören auf, und damit auch genau der Download, der die Übung ausgelöst hat. Auf einem Arbeitslaptop ist das oft richtig, auf einem privaten Rechner ist es eine bewusst zu treffende Entscheidung.

Warum das Globussymbol nichts beweist

Windows meldet Erreichbarkeit über eine Sonde gegen einen Microsoft-Endpunkt. Diese Sonde sagt nichts über Ihren Tunnel. Ein verbundener Tunnel kann hinter einem Globus sitzen, der kein Internet meldet, und ein toter kann eine gesunde Verbindung anzeigen.

Testen Sie, indem Sie den Clientprozess beenden, und versuchen Sie dann, eine öffentliche Adresse über die Nummer zu erreichen. Eine Namensabfrage kann aus dem Cache beantwortet werden, also ist weder das Symbol noch eine DNS-Antwort ein Beweis.

Was nach einem echten Ausfall zu protokollieren ist

Führen Sie den Test als Abfolge und nicht als einzelne Prüfung aus. Beenden Sie den Prozess, statt die Verbindung zu trennen, und versuchen Sie dann eine numerische Adresse in beiden Familien. Stellen Sie den Client danach wieder her und bestätigen Sie, dass er seinen eigenen Server über die behaltene Route noch erreicht.

taskkill /IM openvpn-gui.exe /F
ping -4 198.51.100.44
ping -6 2606:4700:4700::1111
route print -4 | findstr /c:"0.0.0.0"

Wiederholen Sie die Abfolge nach dem Ruhezustand, nach einem Wi-Fi-Wechsel und nach dem Wechsel von Kabel auf Funk. Bei diesen Übergängen scheitern sowohl die Profilmethode als auch das DHCP-Verhalten. Eine Regel, die am Schreibtisch hält, hält nicht unbedingt im Hotel.

Schreiben Sie den Rückgängig-Schritt neben jede Regel und Route. Microsoft dokumentiert das Anlegen von Ausgangsregeln in seiner Referenz zu Windows-Firewall-Regeln, und das ist eine bessere Quelle als ein Durchgang nur mit Bildschirmfotos.

Ähnliche Artikel