Samotný firewall Windows jako nouzový vypínač VPN: obstojí?

Zeptejte se, zda může firewall Windows sám fungovat jako nouzový vypínač, a dostanete dvě sebevědomé a neslučitelné odpovědi. Jedna říká, že pravidlo podle typu rozhraní udělá celou práci; druhá, že bez skriptů nefunguje. Obě popisují polovinu téhož mechanismu. Firewall umí blok vyjádřit, a zda výsledek skutečně selže do zavřeného stavu, závisí na třech věcech: jak Windows klasifikuje tunelový adaptér, zda přežije výjimka pro koncový bod a zda jsou pokryty překlad jmen a IPv6. Spletete-li jedinou z nich, stroj buď prosákne, nebo ztratí veškeré spojení.

Tři podmínky, v tomto pořadí

První podmínkou je klasifikace a ta rozhoduje, zda lze požadované pravidlo vůbec vyjádřit. Pravidla firewallu Windows lze omezit podle typu rozhraní: kabelové, bezdrátové nebo vzdálený přístup. Zásada, která blokuje odchozí provoz na fyzických typech a povoluje tunel, funguje jen tehdy, když Windows tunel uzná jako vzdálený přístup.

Druhou podmínkou je výjimka pro koncový bod. Než tunel existuje, musí se klient dostat na server VPN přes fyzický adaptér, takže plošná blokáda tohoto adaptéru znemožní právě to spojení, které by blokádu učinilo zbytečnou. Výjimka musí jmenovat server a jeho port a paket musí odejít fyzickou bránou, nikoli do tunelu, který ještě není nahoře.

Třetí je pokrytí. Sada pravidel, která blokuje IPv4 a zapomene na IPv6, nebo povolí místnímu resolveru dotaz na koncový bod a tím povolí každý jiný dotaz, selhává otevřeně přesně v okně, kvůli kterému vypínač existuje. To je mezera v návrhu, ne chyba firewallu. Je to také mezera, která přežije každý test na stole.

Klasifikace je první branou

Podívejte se, co si Windows o adaptérech myslí, než napíšete jediné pravidlo. Nativní připojení VPN ve Windows se obvykle hlásí jako vzdálený přístup. Klient třetí strany, který si vytváří vlastní virtuální adaptér, se často hlásí jako kabelový, což znamená, že blokáda omezená na kabelové adaptéry zablokuje i tunel.

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

Třetí příkaz vám řekne, zda už platí výchozí blokování odchozího provozu, což mění celý tvar návrhu. Pokud je výchozí už blokování, píšete povolovací pravidla, nikoli výjimky z permisivní základny, a to je mnohem snažší pozice k uvažování.

Pokud se váš tunelový adaptér hlásí jako kabelový, samotný firewall není správný nástroj pro návrh se zavřeným selháním a žádné ladění pravidel to nezmění. To je případ, kdy je druhý názor v každém vlákně fóra správný.

Výjimka pro koncový bod potřebuje kromě pravidla i trasu

Předpokládejme, že klasifikace funguje. Výjimka má dvě části a ty žijí v různých subsystémech. Pravidlo firewallu provoz povolí; trasa hostitele ho donutí odejít správným rozhraním, dokud 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áhá výjimka jen tehdy, dokud výchozí trasa ještě míří na fyzickou bránu. Jakmile klient nainstaluje vlastní výchozí trasu a pak zhasne, povolené pakety nemají kam rozumně jít a spojení nelze obnovit. Taková porucha vypadá jako rozbitý klient a ve skutečnosti je to chybějící trasa.

Držte výjimku tak úzkou, jak klient dovolí. Jedna adresa a jeden port se dají zkontrolovat; rozsah pokrývající celou síť poskytovatele ne. To širší pravidlo povolí i cokoli jiného hostovaného u stejného poskytovatele, což je obvykle víc, než jste zamýšleli.

DNS a IPv6 jsou místa, kde to selhává otevřeně

Překlad jmen je klasický únik. Je-li koncovým bodem jméno hostitele, musí ho klient přeložit dřív, než tunel existuje, což znamená, že fyzickému adaptéru musí být dovoleno dosáhnout resolveru. Stejné oprávnění pustí každý jiný dotaz, dokud je tunel dole, a jeden dotaz stačí k prozrazení toho, co jste se chystali navštívit.

IPv6 je druhé. Pravidla psaná pro IPv4 nepokrývají druhou rodinu a mnoho klientů instaluje jen trasy IPv4. Stroj s nativní konektivitou IPv6 tak může dál mluvit s internetem, zatímco strana IPv4 je pevně zablokovaná, a vypínač celou dobu hlásí úspěch.

Třetí řádek stojí za pochopení, ne za obcházení. Firewall rozhoduje o paketech, ne o tom, které rozhraní si aplikace vyžádala, a program, který se výslovně váže, se někdy těžko drží na uzdě. To je argument pro vypínač na straně klienta, který pracuje pod aplikací, ne pro další pravidla.

Testujte zastavením klienta, ne vytažením kabelu

Jediný smysluplný test je ten, který napodobuje poruchu, před níž se chráníte. Zastavte službu, zabijte proces nebo zakažte adaptér, který klient vytvořil, a pak zkuste dosáhnout internetu a jména:

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šechny tři by měly selhat. Pokud první uspěje, blokáda neplatí; pokud druhé uspěje tam, kde první selhalo, máte únik DNS; pokud uspěje třetí, IPv6 není pokryto. Každý výsledek ukazuje přesně na jednu z mezer výše.

Test zopakujte po spánku a probuzení, protože profil firewallu se může změnit, když Windows rozhodne, že síť je veřejná nebo soukromá, a pravidla vázaná na profil ho následují. Návrh, který drží na stole a selže ve vlaku, je návrh otestovaný jednou.

Pokud brána klasifikace nebo požadavek DNS činí přístup jen s firewallem neproveditelným, vypínač na straně klienta je poctivá odpověď. Pokud tunel končí na routeru, politika by měla patřit routeru, protože jedno pravidlo tam pokrývá každé zařízení za ním a nezávisí na tom, jak Windows adaptér pojmenuje.