Kill switch în Windows fără software suplimentar: profiluri sau rute?

Profilurile paravanului urmează categoria rețelei, rutele urmează adaptorul. Comparați ambele, apoi testați cazul căderii cu tunelul dispărut și pictograma care minte.

Clientul moare la mijlocul descărcării și pictograma din tavă dispare. Transferul continuă prin conexiunea de acasă. Exact această succesiune este motivul pentru care există un kill switch, iar Windows poate apropia unul fără un al doilea produs.

Două metode merită cunoscute. Ele eșuează în locuri diferite, și niciuna nu este un răspuns complet.

Metoda întâi: permiteți programul doar pe un singur profil

Paravanul Windows limitează regulile la profilurile Domain, Private și Public. Trucul este să dați adaptorului tunelului o categorie, iar adaptorului fizic alta. Apoi scrieți o regulă de ieșire care permite programul protejat pe profilul tunelului și îl blochează în toate celelalte locuri. Paravanul citește categoria, nu numele adaptorului.

Mai întâi setați conexiunea VPN pe Private și rețeaua fizică pe Public. Apoi adăugați o regulă de blocare pentru program care se aplică profilurilor nedorite. După aceea confirmați alocarea cu Get-NetConnectionProfile, pentru că regula urmează exact acea alocare.

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

Slăbiciunea este structurală. O regulă de profil urmează categoria, așa că atunci când Windows reclasifică o rețea de hotel blocarea poate înceta să se aplice. Nimic din lista de reguli nu se schimbă când se întâmplă asta.

Metoda a doua: eliminați ruta implicită fizică

Abordarea prin rute este mai brutală și mult mai ușor de auditat. Notați gateway-ul fizic, lăsați VPN-ul să instaleze propria rută implicită cu o metrică mai mică, apoi ștergeți ruta implicită fizică. Nimic altceva nu mai poate transporta trafic.

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"

Când clientul moare, ruta VPN pleacă împreună cu adaptorul ei. Mașina trece offline în loc să scurgă, și exact asta trebuie să producă un kill switch.

Două detalii decid dacă rezistă o săptămână. DHCP pune gateway-ul la loc de fiecare dată când legătura tremură. Un adaptor fizic cu adresă statică evită acea surpriză. Adresa serverului VPN în sine trebuie și ea să rămână accesibilă. Fără acea rută către gazdă clientul nu se va putea reconecta niciodată după căderea care a declanșat blocarea.

Metoda a treia: fără gateway, o rută persistentă către gazdă

A treia opțiune începe prin curățarea gateway-ului din setările adaptorului. Apoi o singură rută persistentă către punctul final al VPN-ului îl înlocuiește. Mașina poate apoi vorbi cu serverul și cu nimic altceva până când tunelul urcă.

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

Restaurarea gateway-ului readuce internetul obișnuit, ceea ce face din asta un întrerupător curat de pornire și oprire. Nu depinde de un script care urmărește evenimentele interfeței. Nici nu-i pasă cum este categorizată rețeaua.

Prețul este izolarea totală cât timp tunelul este jos. Actualizările se opresc, și la fel descărcarea care a declanșat exercițiul. Pe un laptop de serviciu acest lucru este adesea corect, în timp ce pe o mașină personală este o decizie de luat deliberat.

De ce pictograma globului nu dovedește nimic

Windows raportează accesibilitatea printr-o sondă către un punct final Microsoft. Sonda aceea nu spune nimic despre tunelul dumneavoastră. Un tunel conectat poate sta în spatele unui glob care raportează că nu există internet, iar unul mort poate arăta o conexiune sănătoasă.

Testați omorând procesul clientului și apoi încercați să atingeți o adresă publică după număr. O interogare de nume poate fi răspunsă din cache, așa că nici pictograma, nici un răspuns DNS nu sunt dovezi.

Ce trebuie consemnat după o cădere reală

Rulați testul ca o succesiune, nu ca o singură verificare. Omoară procesul în loc să deconectați, apoi încercați o adresă numerică în ambele familii. Restabiliți clientul după aceea și confirmați că ajunge în continuare la propriul server prin ruta pe care ați păstrat-o.

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"

Repetați succesiunea după repaus, după o schimbare de Wi-Fi și după trecerea de la cablu la wireless. Exact la aceste tranziții eșuează și metoda profilului, și comportamentul DHCP. O regulă care rezistă pe un birou nu rezistă neapărat într-un hotel.

Scrieți pasul de anulare lângă fiecare regulă și rută. Microsoft documentează crearea regulilor de ieșire în referința sa pentru regulile paravanului Windows, și aceasta este o sursă mai bună decât un tutorial doar cu capturi de ecran.

Articole similare