Doar firewallul Windows ca întrerupător de urgență VPN: rezistă?

Întrebați dacă firewallul Windows poate singur să acționeze ca întrerupător de urgență și veți primi două răspunsuri încrezătoare și incompatibile. Unul spune că regula după tipul interfeței face toată treaba; celălalt că nu funcționează fără scripturi. Ambele descriu jumătatea aceluiași mecanism. Firewallul poate exprima blocarea, iar dacă rezultatul chiar eșuează închis depinde de trei lucruri: cum clasifică Windows adaptorul tunelului, dacă excepția punctului final supraviețuiește și dacă rezolvarea numelor și IPv6 sunt acoperite. Greșiți oricare și mașina fie scurse, fie pierde toată conectivitatea.

Trei condiții, în această ordine

Prima condiție este clasificarea, iar ea decide dacă regula dorită este măcar exprimabilă. Regulile firewallului Windows pot fi limitate după tipul interfeței: cu fir, fără fir sau acces la distanță. O politică ce blochează traficul de ieșire pe tipurile fizice și permite tunelul funcționează doar dacă Windows recunoaște tunelul ca acces la distanță.

A doua condiție este excepția punctului final. Înainte de a exista vreun tunel, clientul trebuie să ajungă la serverul VPN prin adaptorul fizic, așa că o blocare totală pe acel adaptor împiedică exact conexiunea care ar face blocarea inutilă. Excepția trebuie să numească serverul și portul lui, iar pachetul trebuie să iasă prin poarta fizică, nu într-un tunel încă ne ridicat.

A treia este acoperirea. Un set de reguli care blochează IPv4 și uită IPv6, sau care permite resolverului local căutarea punctului final și astfel permite orice altă căutare, eșuează deschis exact în fereastra pentru care există întrerupătorul. Este o lacună de proiectare, nu un defect al firewallului. Este și lacuna care supraviețuiește fiecărui test pe un birou.

Clasificarea este prima poartă

Uitați-vă ce crede Windows despre adaptoare înainte de a scrie o singură regulă. O conexiune VPN nativă Windows apare de obicei ca acces la distanță. Un client terț care își creează propriul adaptor virtual apare adesea ca fiind cu fir, ceea ce înseamnă că o blocare limitată la adaptoare cu fir blochează și tunelul.

Get-NetConnectionProfile | Select-Object Name,InterfaceAlias,NetworkCategory
Get-NetAdapter | Select-Object Name,InterfaceDescription,Status,ifIndex
Get-NetFirewallProfile | Select-Object Name,Enabled,DefaultOutboundAction

A treia comandă vă spune dacă este deja în vigoare o blocare implicită a traficului de ieșire, ceea ce schimbă toată forma proiectării. Dacă implicitul este deja blocare, scrieți reguli de permisiune, nu excepții de la o bază permisivă, iar aceasta este o poziție mult mai ușor de argumentat.

Dacă adaptorul tunelului se raportează ca fiind cu fir, doar firewallul nu este instrumentul potrivit pentru o proiectare cu eșec închis, iar nicio ajustare a regulilor nu schimbă asta. Acesta este cazul în care a doua părere din fiecare fir de forum este corectă.

Excepția punctului final are nevoie de o rută, nu doar de o regulă

Să presupunem că clasificarea funcționează. Excepția are două părți, iar ele trăiesc în subsisteme diferite. Regula firewallului permite traficul; ruta gazdei îl face să iasă prin interfața corectă cât timp tunelul este coborât.

New-NetFirewallRule -DisplayName "VPN endpoint allow" -Direction Outbound -Action Allow \
  -Protocol TCP -RemoteAddress 203.0.113.9 -RemotePort 443 -InterfaceType Wired,Wireless
New-NetRoute -DestinationPrefix 203.0.113.9/32 -InterfaceIndex 12 -NextHop 192.168.1.1
Get-NetRoute -DestinationPrefix 203.0.113.9/32

Fără rută, excepția ajută doar cât timp o rută implicită mai indică poarta fizică. Când clientul instalează propria rută implicită și apoi moare, pachetele permise nu au unde să meargă în mod sensibil și conexiunea nu poate fi restabilită. Acea eșec arată ca un client stricat și în realitate este o rută lipsă.

Țineți excepția cât de îngustă permite clientul. O adresă și un port sunt verificabile; un interval care acoperă toată rețeaua furnizorului nu este. Regula mai largă permite și orice altceva găzduit la același furnizor, ceea ce de obicei este mai mult decât ați intenționat.

DNS și IPv6 sunt locurile unde eșuează deschis

Rezolvarea numelor este scurgerea clasică. Dacă punctul final este un nume de gazdă, clientul trebuie să îl rezolve înainte de a exista tunelul, ceea ce înseamnă că adaptorului fizic trebuie să i se permită să ajungă la un resolver. Aceeași permisiune lasă să iasă orice altă căutare cât timp tunelul este coborât, iar o singură căutare este suficientă pentru a dezvălui ce urma să vizitați.

IPv6 este al doilea. Regulile scrise pentru IPv4 nu acoperă cealaltă familie, iar mulți clienți instalează doar rute IPv4. O mașină cu conectivitate IPv6 nativă poate deci continua să vorbească cu internetul în timp ce partea IPv4 este blocată ferm, iar întrerupătorul raportează succes tot timpul.

Al treilea rând merită înțeles în loc de ocolit. Un firewall decide despre pachete, nu despre ce interfață a cerut o aplicație să folosească, iar un program care se leagă explicit poate fi greu de ținut sub control. Acesta este un argument pentru un întrerupător pe partea clientului care lucrează sub aplicație, nu pentru mai multe reguli.

Testați oprind clientul, nu trăgând cablul

Singurul test semnificativ este cel care imită eșecul de care vă protejați. Opriți serviciul, ucideți procesul sau dezactivați adaptorul creat de client, apoi încercați să ajungeți la internet și la un nume:

Stop-Service -Name "YourVpnService" -Force
Test-NetConnection -ComputerName 1.1.1.1 -Port 443
Resolve-DnsName example.com
Test-NetConnection -ComputerName 2606:4700:4700::1111 -Port 443

Toate trei ar trebui să eșueze. Dacă primul reușește, blocarea nu este în vigoare; dacă al doilea reușește unde primul a eșuat, aveți o scurgere DNS; dacă al treilea reușește, IPv6 nu este acoperit. Fiecare rezultat indică exact una dintre lacunele de mai sus.

Repetați testul după suspendare și reluare, pentru că profilul firewallului se poate schimba când Windows decide că o rețea este publică sau privată, iar regulile limitate la un profil îl urmează. O proiectare care rezistă pe un birou și eșuează în tren este o proiectare testată o dată.

Dacă poarta de clasificare sau cerința DNS fac abordarea doar-cu-firewall neviabilă, un întrerupător pe partea clientului este răspunsul onest. Dacă tunelul se termină pe un router, politica ar trebui să aparțină routerului, pentru că o regulă acolo acoperă fiecare dispozitiv din spatele lui și nu depinde de modul în care Windows numește un adaptor.