Kill switch en Windows sen plia programaro: profiloj aŭ itineroj?

Fajroŝirmilaj profiloj sekvas la kategorion de reto, itineroj sekvas la adaptilon. Komparu ambaŭ, poste testu la kraŝan kazon kun la tunelo for kaj la piktogramo mensoganta.

La kliento mortas meze de elŝuto kaj la piktogramo malaperas el la sistemopleto. La transigo daŭras tra la hejma konekto. Ĝuste tiu sinsekvo estas la kialo, ke ekzistas kill switch, kaj Windows povas proksimigi unu sen dua produkto.

Indas koni du metodojn. Ili malsukcesas en malsamaj lokoj, kaj neniu el ili estas kompleta respondo.

Metodo unu: permesi la programon nur en unu profilo

La fajroŝirmilo de Windows limigas regulojn al la profiloj Domain, Private kaj Public. La artifiko estas doni al la tunela adaptilo unu kategorion kaj al la fizika adaptilo alian. Poste vi skribas eliran regulon, kiu permesas la protektitan programon en la tunela profilo kaj blokas ĝin ĉie alie. La fajroŝirmilo legas la kategorion, ne la nomon de la adaptilo.

Unue agordu la VPN-konekton al Private kaj la fizikan reton al Public. Poste aldonu blokan regulon por la programo, kiu validas por la profiloj, kiujn vi ne volas. Poste konfirmu la atribuon per Get-NetConnectionProfile, ĉar la regulo sekvas ĝuste tiun atribuon.

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

La malforteco estas struktura. Profila regulo sekvas la kategorion, do kiam Windows reklasifikas hotelan reton, la blokado povas ĉesi validi. Nenio en la regula listo ŝanĝiĝas kiam tio okazas.

Metodo du: forigi la fizikan defaŭltan itinero

La itinera aliro estas pli kruda kaj multe pli facila por kontroli. Notu la fizikan enirejon, lasu la VPN instali sian propran defaŭltan itinero kun pli malalta metriko, poste forigu la fizikan defaŭltan. Nenio alia povas tiam porti trafikon.

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"

Kiam la kliento mortas, la VPN-itinero foriras kun sia adaptilo. La maŝino iras eksterrete anstataŭ liki, kaj tion kill switch devus produkti.

Du detaloj decidas ĉu ĝi postvivos semajnon. DHCP remetas la enirejon ĉiufoje, kiam la ligilo flagras. Fizika adaptilo kun statika adreso evitas tiun surprizon. La adreso de la VPN-servilo mem ankaŭ devas resti atingebla. Sen tiu gastiga itinero la kliento neniam povas rekonekti post la falo, kiu ekigis la blokadon.

Metodo tri: neniu enirejo, unu daŭra gastiga itinero

La tria opcio komenciĝas per forigo de la enirejo el la agordoj de la adaptilo. Poste unu sola daŭra itinero al la VPN-finpunkto anstataŭas ĝin. La maŝino tiam povas paroli kun la servilo kaj kun nenio alia, ĝis la tunelo leviĝos.

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

Restarigo de la enirejo restarigas ordinaran interreton, kio faras ĝin pura ŝaltilo por en kaj el. Ĝi ne dependas de skripto, kiu observas interfaĉajn eventojn. Ĝi ankaŭ ne zorgas, kiel la reto estas kategoriigita.

La kosto estas plena izoliteco dum la tunelo estas mallevita. Ĝisdatigoj haltas, kaj same la elŝuto mem, kiu kaŭzis la ekzercon. Por labortekkomputilo tio ofte estas ĝuste, dum sur persona maŝino ĝi estas decido farota konscie.

Kial la tergloba piktogramo pruvas nenion

Windows raportas atingeblon per sondado al finpunkto de Microsoft. Tiu sondado diras nenion pri via tunelo. Konektita tunelo povas sidi malantaŭ terglobo, kiu raportas neniun interreton, kaj mortinta povas montri sanan konekton.

Testu per mortigo de la klienta procezo kaj poste provu atingi publikan adreson per nombro. Noma serĉo povas esti respondita el kaŝmemoro, do nek la piktogramo nek DNS-respondo estas pruvo.

Kion registri post reala falo

Plenumu la teston kiel sinsekvon, ne kiel unu kontrolon. Mortigu la procezon anstataŭ malkonekti, poste provu numeran adreson en ambaŭ familioj. Poste restarigu la klienton kaj konfirmu, ke ĝi ankoraŭ atingas sian propran servilon tra la itinero, kiun vi konservis.

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"

Ripetu la sinsekvon post dormo, post ŝanĝo de Wi-Fi kaj post transiro de kablo al sendrata. Ĝuste ĉe tiuj transiroj malsukcesas kaj la profila metodo kaj la konduto de DHCP. Regulo, kiu tenas sur skribotablo, ne nepre tenas en hotelo.

Skribu la malfaran paŝon apud ĉiu regulo kaj itinero. Microsoft dokumentas la kreadon de eliraj reguloj en sia referenco pri reguloj de la fajroŝirmilo de Windows, kaj tio estas pli bona fonto ol gvidilo nur el ekrankopioj.

Rilataj artikoloj