Samotný firewall Windows ako núdzový vypínač VPN: obstojí?

Spýtajte sa, či môže firewall Windows sám fungovať ako núdzový vypínač, a dostanete dve sebavedomé a nezlučiteľné odpovede. Jedna hovorí, že pravidlo podľa typu rozhrania urobí celú prácu; druhá, že bez skriptov to nefunguje. Obe opisujú polovicu toho istého mechanizmu. Firewall dokáže vyjadriť blokovanie, a či výsledok skutočne zlyhá do zatvoreného stavu, závisí od troch vecí: ako Windows klasifikuje tunelový adaptér, či prežije výnimka pre koncový bod a či sú pokryté preklad mien a IPv6. Pomýlite sa v ktorejkoľvek a stroj buď presiakne, alebo stratí všetko spojenie.

Tri podmienky, v tomto poradí

Prvou podmienkou je klasifikácia a tá rozhoduje, či sa požadované pravidlo vôbec dá vyjadriť. Pravidlá firewallu Windows možno obmedziť podľa typu rozhrania: káblové, bezdrôtové alebo vzdialený prístup. Zásada, ktorá blokuje odchádzajúcu prevádzku na fyzických typoch a povoľuje tunel, funguje len vtedy, keď Windows rozpozná tunel ako vzdialený prístup.

Druhou podmienkou je výnimka pre koncový bod. Než existuje tunel, klient sa musí dostať na server VPN cez fyzický adaptér, takže plošné zablokovanie tohto adaptéra znemožní práve to spojenie, ktoré by blokovanie urobilo zbytočným. Výnimka musí uviesť server a jeho port a paket musí odísť cez fyzickú bránu, nie do ešte nevzpriameného tunela.

Tretia je pokrytie. Sada pravidiel, ktorá blokuje IPv4 a zabúda na IPv6, alebo povoľuje miestnemu resolveru hľadať koncový bod a tým povoľuje každý iný dopyt, zlyháva otvorene presne v okne, pre ktoré vypínač existuje. To je medzera v návrhu, nie chyba firewallu. Je to aj medzera, ktorá prežije každý test na stole.

Klasifikácia je prvá brána

Pozrite sa, čo si Windows myslí o adaptéroch, skôr než napíšete čo i len jedno pravidlo. Natívne pripojenie VPN vo Windows sa zvyčajne javí ako vzdialený prístup. Klient tretej strany, ktorý si vytvára vlastný virtuálny adaptér, sa často javí ako káblový, čo znamená, že blokovanie obmedzené na káblové adaptéry zablokuje aj tunel.

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

Tretí príkaz vám povie, či už platí predvolené blokovanie odchádzajúcej prevádzky, čo mení celý tvar návrhu. Ak je predvolené už blokovanie, píšete povoľovacie pravidlá, nie výnimky z permisívnej základne, a to je oveľa ľahšia pozícia na uvažovanie.

Ak sa váš tunelový adaptér hlási ako káblový, samotný firewall nie je správny nástroj pre návrh so zatvoreným zlyhaním a žiadne ladenie pravidiel to nezmení. To je prípad, keď je druhý názor v každom vlákne fóra správny.

Výnimka pre koncový bod potrebuje okrem pravidla aj trasu

Predpokladajme, že klasifikácia funguje. Výnimka pozostáva z dvoch častí a tie žijú v rôznych podsystémoch. Pravidlo firewallu povoľuje prevádzku; trasa hostiteľa ju prinúti odísť správnym rozhraním, kým je tunel dole.

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

Bez trasy pomáha výnimka len dovtedy, kým predvolená trasa ešte ukazuje na fyzickú bránu. Keď klient nainštaluje vlastnú predvolenú trasu a potom zhasne, povolené pakety nemajú kam rozumne ísť a spojenie sa nedá obnoviť. Takáto porucha vyzerá ako pokazený klient a v skutočnosti je to chýbajúca trasa.

Držte výnimku takú úzku, ako klient dovolí. Jedna adresa a jeden port sa dajú skontrolovať; rozsah pokrývajúci celú sieť poskytovateľa nie. To širšie pravidlo povoľuje aj všetko ostatné hosťované u toho istého poskytovateľa, čo je zvyčajne viac, než ste zamýšľali.

DNS a IPv6 sú miesta, kde to zlyháva otvorene

Preklad mien je klasický únik. Ak je koncovým bodom názov hostiteľa, klient ho musí preložiť pred vznikom tunela, čo znamená, že fyzickému adaptéru treba povoliť dosiahnuť resolver. To isté povolenie pustí každý iný dopyt von, kým je tunel dole, a jeden dopyt stačí na prezradenie toho, čo ste sa chystali navštíviť.

IPv6 je druhé. Pravidlá písané pre IPv4 nepokrývajú druhú rodinu a mnohí klienti inštalujú len trasy IPv4. Stroj s natívnou konektivitou IPv6 tak môže ďalej hovoriť s internetom, kým strana IPv4 je pevne zablokovaná, a vypínač celý čas hlási úspech.

Tretí riadok stojí za pochopenie, nie za obchádzanie. Firewall rozhoduje o paketoch, nie o tom, ktoré rozhranie si aplikácia vyžiadala, a program, ktorý sa výslovne viaže, sa niekedy ťažko drží na uzde. To je argument za vypínač na strane klienta, ktorý pracuje pod aplikáciou, nie za ďalšie pravidlá.

Testujte zastavením klienta, nie vytiahnutím kábla

Jediný zmysluplný test je ten, ktorý napodobňuje poruchu, pred ktorou sa chránite. Zastavte službu, zabite proces alebo zakažte adaptér, ktorý klient vytvoril, a potom skúste dosiahnuť internet a meno:

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

Všetky tri by mali zlyhať. Ak prvý uspeje, blokovanie neplatí; ak druhý uspeje tam, kde prvý zlyhal, máte únik DNS; ak uspeje tretí, IPv6 nie je pokryté. Každý výsledok ukazuje presne na jednu z medzier vyššie.

Test zopakujte po spánku a prebudení, pretože profil firewallu sa môže zmeniť, keď Windows rozhodne, že sieť je verejná alebo súkromná, a pravidlá viazané na profil ho nasledujú. Návrh, ktorý drží na stole a zlyhá vo vlaku, je návrh otestovaný raz.

Ak brána klasifikácie alebo požiadavka DNS robia prístup len s firewallom neuskutočniteľným, vypínač na strane klienta je čestná odpoveď. Ak tunel namiesto toho končí na routeri, politika by mala patriť routeru, pretože jedno pravidlo tam pokrýva každé zariadenie za ním a nezávisí od toho, ako Windows adaptér pomenuje.