Windows-kill switch sonder ekstra sagteware: profiele of roetes?

Firewall-profiele volg die kategorie van ’n netwerk, roetes volg die adapter. Vergelyk albei en toets dan die ongelukgeval wanneer die tonnel weg is en die ikoon lieg.

Die kliënt sterf midde-in ’n aflaai en die taakbalk-ikoon verdwyn. Die oordrag hou aan oor die tuisverbinding. Daardie volgorde is die rede waarom ’n kill switch bestaan, en Windows kan een benader sonder ’n tweede produk.

Twee metodes is die moeite werd om te ken. Hulle faal op verskillende plekke, en nie een daarvan is ’n volledige antwoord nie.

Metode een: laat die program slegs op een profiel toe

Windows Firewall beperk reëls tot die profiele Domain, Private en Public. Die truuk is om die tonnel-adapter een kategorie te gee en die fisiese adapter ’n ander. Jy skryf dan ’n uitgaande reël wat die beskermde program op die tonnel-profiel toelaat en dit oral elders blokkeer. Die firewall lees die kategorie, nie die adapternaam nie.

Stel die VPN-verbinding eerste op Private en die fisiese netwerk op Public. Voeg dan ’n blokreël by vir die program wat op die profiele geld wat jy nie wil hê nie. Bevestig daarna die toewysing met Get-NetConnectionProfile, want dit is die toewysing wat die reël volg.

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 swakheid is struktureel. ’n profielreël volg die kategorie, so wanneer Windows ’n hotelnetwerk herklassifiseer, kan die blokkade ophou geld. Niks in die reëls verander wanneer dit gebeur nie.

Metode twee: verwyder die fisiese standaardroete

Die roetebenadering is botter en baie makliker om te oudit. Let op die fisiese gateway, laat die VPN sy eie standaard met ’n laer metriek installeer en verwyder dan die fisiese standaard. Niks anders kan daarna verkeer dra nie.

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"

Wanneer die kliënt sterf, vertrek die VPN-roete saam met sy adapter. Die masjien gaan vanlyn in plaas daarvan om te lek, en dit is presies wat ’n kill switch veronderstel is om te lewer.

Twee besonderhede bepaal of dit ’n week oorleef. DHCP sit die gateway terug wanneer die skakel fladder. ’n Fisiese adapter met ’n statiese adres vermy daardie verrassing. Die VPN-bediener se eie adres moet ook bereikbaar bly. Sonder daardie gasheerroete kan die kliënt nooit weer verbind ná die onderbreking wat die blokkade veroorsaak het nie.

Metode drie: geen gateway, een blywende gasheerroete

Die derde opsie begin deur die gateway uit die adapter-instellings te verwyder. ’n Enkele blywende roete na die VPN-eindpunt vervang dit dan. Die masjien kan dan met die bediener praat en met niks anders totdat die tonnel opkom.

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

Die herstel van die gateway herstel gewone internet, wat dit ’n skoon aan-en-af-skakelaar maak. Dit hang nie af van ’n script wat koppelvlak-gebeurtenisse dophou nie. Dit maak ook nie saak hoe die netwerk gekategoriseer word nie.

Die koste is totale isolasie terwyl die tonnel af is. Opdaterings stop, en so ook die betrokke aflaai wat die oefening veroorsaak het. Vir ’n werkskootrekenaar is dit dikwels korrek, terwyl dit op ’n persoonlike masjien ’n besluit is om doelbewus te neem.

Waarom die aardbol-ikoon niks bewys nie

Windows rapporteer bereikbaarheid deur ’n toets teen ’n Microsoft-eindpunt. Daardie toets sê niks oor jou tonnel nie. ’n Gekoppelde tonnel kan agter ’n aardbol sit wat geen internet aandui, en ’n dooie een kan ’n gesonde verbinding wys.

Toets deur die kliëntproses te dood en dan ’n publieke adres per nommer te probeer bereik. ’n Naamsoektog kan uit die kas beantwoord word, so nóg die ikoon nóg ’n DNS-antwoord is bewyse.

Wat om na ’n werklike onderbreking te noteer

Voer die toets as ’n reeks uit eerder as ’n enkele kontrole. Dood die proses in plaas daarvan om te ontkoppel en probeer dan ’n numeriese adres op albei families. Herstel daarna die kliënt en bevestig dat dit steeds sy eie bediener kan bereik deur die roete wat jy behou het.

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"

Herhaal die reeks ná slaap, ná ’n Wi-Fi-verandering en ná ’n oorskakeling van kabel na draadloos. Daardie oorgange is waar die profielmetode en die DHCP-gedrag albei faal. ’n Reël wat op ’n lessenaar hou, hou nie noodwendig in ’n hotel nie.

Skryf die onttrekkingsstap langs elke reël en roete. Microsoft dokumenteer die skep van uitgaande reëls in sy verwysing vir Windows Firewall-reëls, en dit is ’n beter bron as ’n blote skermkiekie-rondleiding.

Verwante artikels