Samo požarni zid Windows kot zasilni izklop VPN: zdrži?

Vprašajte, ali lahko požarni zid Windows sam služi kot zasilni izklop, in dobili boste dva samozavestna in nezdružljiva odgovora. Eden pravi, da pravilo po vrsti vmesnika opravi vse delo; drugi, da brez skriptov ne deluje. Oba opisujeta polovico istega mehanizma. Požarni zid lahko izrazi blokado, ali pa se rezultat res zaključi zaprto, je odvisno od treh stvari: kako Windows razvrsti tunelski adapter, ali preživi izjema za končno točko in ali sta pokrita razreševanje imen in IPv6. Zmotite se pri kateri koli in stroj bodisi pušča bodisi izgubi vso povezljivost.

Trije pogoji, v tem vrstnem redu

Prvi pogoj je klasifikacija in ta odloča, ali je želeno pravilo sploh izrazljivo. Pravila požarnega zidu Windows je mogoče omejiti po vrsti vmesnika: žični, brezžični ali oddaljeni dostop. Politika, ki blokira odhodni promet na fizičnih vrstah in dovoljuje tunel, deluje le, če Windows tunel prepozna kot oddaljeni dostop.

Drugi pogoj je izjema za končno točko. Preden obstaja kakršen koli tunel, mora odjemalec doseči strežnik VPN prek fizičnega adapterja, zato celotna blokada tega adapterja prepreči prav tisto povezavo, ki bi blokado naredila nepotrebno. Izjema mora navesti strežnik in njegova vrata, paket pa mora oditi skozi fizični prehod in ne v še ne dvignjen tunel.

Tretja je pokritost. Nabor pravil, ki blokira IPv4 in pozabi na IPv6, ali ki lokalnemu razreševalniku dovoli iskanje končne točke in s tem dovoli vsako drugo iskanje, odpove odprto točno v oknu, za katero izklop obstaja. To je vrzel v zasnovi, ne napaka v požarnem zidu. To je tudi vrzel, ki preživi vsak preizkus na mizi.

Klasifikacija so prva vrata

Poglejte, kaj si Windows misli o adapterjih, preden napišete eno samo pravilo. Vgrajena povezava VPN v Windows se običajno pojavi kot oddaljeni dostop. Odjemalec tretje strani, ki ustvari svoj navidezni adapter, se pogosto pojavi kot žični, kar pomeni, da blokada, omejena na žične adapterje, blokira tudi tunel.

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

Tretji ukaz pove, ali že velja privzeta blokada odhodnega prometa, kar spremeni celotno obliko zasnove. Če je privzeto že blokiranje, pišete pravila dovoljenja, ne izjem od permisivne osnove, in to je veliko lažje stališče za razmislek.

Če se vaš tunelski adapter javlja kot žični, sam požarni zid ni pravo orodje za zasnovo z zaprtim neuspehom in nobeno uglaševanje pravil tega ne spremeni. To je primer, ko ima drugo mnenje v vsaki forumski niti prav.

Izjema za končno točko potrebuje poleg pravila še pot

Predpostavimo, da klasifikacija deluje. Izjema je sestavljena iz dveh delov in ta živita v različnih podsistemih. Pravilo požarnega zidu dovoli promet; gostiteljska pot poskrbi, da odide skozi pravi vmesnik, medtem ko je tunel spuščen.

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

Brez poti izjema pomaga le, dokler privzeta pot še kaže na fizični prehod. Ko odjemalec namesti svojo privzeto pot in nato umre, dovoljeni paketi nimajo kam smiselno iti in povezave ni mogoče znova vzpostaviti. Ta odpoved je videti kot pokvarjen odjemalec in je v resnici manjkajoča pot.

Držite izjemo tako ozko, kot dovoljuje odjemalec. En naslov in ena vrata sta pregledna; obseg, ki pokriva celotno omrežje ponudnika, ni. To širše pravilo dovoljuje tudi vse drugo, gostovano pri istem ponudniku, kar je običajno več, kot ste nameravali.

DNS in IPv6 sta mesti, kjer odpove odprto

Razreševanje imen je klasično uhajanje. Če je končna točka ime gostitelja, ga mora odjemalec razrešiti, preden tunel obstaja, kar pomeni, da je treba fizičnemu adapterju dovoliti doseči razreševalnik. Isto dovoljenje spusti vsako drugo poizvedbo, medtem ko je tunel spuščen, in ena poizvedba zadostuje, da razkrije, kaj ste nameravali obiskati.

IPv6 je drugi. Pravila, napisana za IPv4, ne pokrivajo druge družine in veliko odjemalcev namesti le poti IPv4. Stroj z vgrajeno povezljivostjo IPv6 lahko zato še naprej govori z internetom, medtem ko je stran IPv4 trdno blokirana, izklop pa ves čas poroča o uspehu.

Tretja vrstica je vredna razumevanja, ne obhoda. Požarni zid odloča o paketih, ne o tem, kateri vmesnik je zahtevala aplikacija, in program, ki se izrecno veže, je lahko težko obvladljiv. To je argument za izklop na strani odjemalca, ki deluje pod aplikacijo, ne za več pravil.

Preizkusite z ustavitvijo odjemalca, ne z izvlekom kabla

Edini smiselni preizkus je tisti, ki posnema odpoved, pred katero se ščitite. Ustavite storitev, ubijte proces ali onemogočite adapter, ki ga je ustvaril odjemalec, nato poskusite doseči internet in ime:

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

Vsi trije bi morali odpovedati. Če prvi uspe, blokada ne velja; če drugi uspe tam, kjer je prvi odpovedal, imate uhajanje DNS; če uspe tretji, IPv6 ni pokrit. Vsak izid kaže točno na eno od zgornjih vrzeli.

Preizkus ponovite po spanju in prebujanju, ker se profil požarnega zidu lahko spremeni, ko Windows odloči, da je omrežje javno ali zasebno, in pravila, omejena na profil, mu sledijo. Zasnova, ki zdrži na mizi in odpove na vlaku, je zasnova, preizkušena enkrat.

Če vrata klasifikacije ali zahteva DNS naredijo pristop samo s požarnim zidom neizvedljiv, je izklop na strani odjemalca pošten odgovor. Če se tunel namesto tega konča na usmerjevalniku, naj politika pripada usmerjevalniku, ker eno pravilo tam pokriva vsako napravo za njim in ni odvisno od tega, kako Windows poimenuje adapter.