Kill switch i Windows utan extra programvara: profiler eller rutter?
Brandväggsprofiler följer nätverkets kategori, rutter följer adaptern. Jämför båda och testa sedan krascherfallet med tunneln borta och ikonen som ljuger.
Klienten dör mitt i en nedladdning och ikonen i aktivitetsfältet försvinner. Överföringen fortsätter över hemanslutningen. Det är just den sekvensen som är anledningen till att en kill switch finns, och Windows kan närma sig en utan en andra produkt.
Två metoder är värda att känna till. De misslyckas på olika ställen, och ingen av dem är ett fullständigt svar.
Metod ett: tillåt programmet på bara en profil
Windows-brandväggen begränsar regler till profilerna Domain, Private och Public. Knepet är att ge tunneladaptern den ena kategorin och den fysiska adaptern den andra. Sedan skriver du en utgående regel som tillåter det skyddade programmet på tunnelprofilen och blockerar det överallt annars. Brandväggen läser kategorin, inte adapterns namn.
Ställ först in VPN-anslutningen på Private och det fysiska nätet på Public. Lägg sedan till en blockeringsregel för programmet som gäller för de profiler du inte vill ha. Bekräfta därefter tilldelningen med Get-NetConnectionProfile, eftersom det är den tilldelningen regeln följer.
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
Svagheten är strukturell. En profilregel följer kategorin, så när Windows omklassificerar ett hotellnät kan blockeringen sluta gälla. Ingenting i regellistan ändras när det händer.
Metod två: ta bort den fysiska standardrutten
Rutmetoden är grövre och mycket lättare att granska. Notera den fysiska gatewayen, låt VPN installera sin egen standardrutt med lägre metrik och ta sedan bort den fysiska standardrutten. Ingenting annat kan då bära trafik.
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"
När klienten dör försvinner VPN-rutten tillsammans med sin adapter. Maskinen går offline i stället för att läcka, och det är precis vad en kill switch ska åstadkomma.
Två detaljer avgör om det håller en vecka. DHCP sätter tillbaka gatewayen varje gång länken fladdrar. En fysisk adapter med statisk adress undviker den överraskningen. Själva VPN-serverns adress måste också förbli nåbar. Utan den värdrutten kan klienten aldrig ansluta igen efter det avbrott som utlöste blockeringen.
Metod tre: ingen gateway, en bestående värdrutt
Det tredje alternativet börjar med att rensa gatewayen från adapterinställningarna. Sedan ersätter en enda bestående rutt till VPN-slutpunkten den. Maskinen kan då tala med servern och med ingenting annat förrän tunneln kommer upp.
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
Att återställa gatewayen återställer vanligt internet, vilket gör detta till en ren på- och avbrytare. Den beror inte på ett skript som övervakar gränssnittshändelser. Den bryr sig inte heller om hur nätet kategoriseras.
Priset är total isolering medan tunneln är nere. Uppdateringar stannar, och det gör även själva nedladdningen som satte igång övningen. På en arbetslaptop är det ofta rätt, medan det på en personlig maskin är ett beslut som måste tas medvetet.
Varför globikon inte bevisar något
Windows rapporterar nåbarhet genom en sondering mot en Microsoft-slutpunkt. Den sonderingen säger ingenting om din tunnel. En ansluten tunnel kan sitta bakom en glob som rapporterar att inget internet finns, och en död kan visa en frisk anslutning.
Testa genom att döda klientprocessen och försök sedan nå en offentlig adress via nummer. Ett namnuppslag kan besvaras från cachen, så varken ikonen eller ett DNS-svar är bevis.
Vad som ska antecknas efter ett verkligt avbrott
Kör testet som en sekvens i stället för en enda kontroll. Döda processen i stället för att koppla från och prova sedan en numerisk adress i båda familjerna. Återställ klienten efteråt och bekräfta att den fortfarande når sin egen server via rutten du behöll.
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"
Upprepa sekvensen efter sömn, efter ett Wi-Fi-byte och efter byte från kabel till trådlöst. Det är vid dessa övergångar både profilmetoden och DHCP-beteendet misslyckas. En regel som håller på ett skrivbord håller inte nödvändigtvis på ett hotell.
Skriv ångrasteget bredvid varje regel och rutt. Microsoft dokumenterar skapandet av utgående regler i sin referens för Windows-brandväggsregler, och det är en bättre källa än en genomgång med bara skärmbilder.