Pelkkä Windowsin palomuuri VPN:n hätäkatkaisimena: pitääkö?

Kysy, voiko Windowsin palomuuri yksin toimia hätäkatkaisimena, niin saat kaksi varmaa ja yhteensopimatonta vastausta. Toinen sanoo, että liitäntätyyppisääntö tekee koko työn; toinen, ettei se toimi ilman skriptejä. Molemmat kuvaavat saman mekanismin puolikasta. Palomuuri voi ilmaista eston, ja se, epäonnistuuko tulos todella suljetusti, riippuu kolmesta asiasta: miten Windows luokittelee tunnelisovittimen, säilyykö päätepisteen poikkeus ja kattavatko nimien ratkaisu ja IPv6. Erehdy yhdessäkään niistä, niin kone joko vuotaa tai menettää kaiken yhteyden.

Kolme ehtoa, tässä järjestyksessä

Ensimmäinen ehto on luokittelu, ja se ratkaisee, onko haluamasi sääntö edes ilmaistavissa. Windowsin palomuurisääntöjä voi rajata liitäntätyypin mukaan: langallinen, langaton tai etäkäyttö. Käytäntö, joka estää lähtevän liikenteen fyysisillä tyypeillä ja sallii tunnelin, toimii vain, jos Windows tunnistaa tunnelin etäkäytöksi.

Toinen ehto on päätepisteen poikkeus. Ennen kuin tunnelia on olemassa, asiakkaan on päästävä VPN-palvelimeen fyysisen sovittimen kautta, joten kyseisen sovittimen yleinen esto estää juuri sen yhteyden, joka tekisi estosta tarpeettoman. Poikkeuksen on nimettävä palvelin ja sen portti, ja paketin on poistuttava fyysisen yhdyskäytävän kautta eikä vielä pystyttämättömään tunneliin.

Kolmas on kattavuus. Sääntöjoukko, joka estää IPv4:n ja unohtaa IPv6:n, tai sallii paikallisen ratkaisijan päätepistehaun ja siten kaikki muut haut, epäonnistuu avoimesti juuri siinä ikkunassa, jota varten hätäkatkaisin on olemassa. Se on suunnittelun aukko, ei palomuurin vika. Se on myös aukko, joka kestää jokaisen työpöytätestin.

Luokittelu on ensimmäinen portti

Katso, mitä Windows ajattelee sovittimista ennen kuin kirjoitat yhtäkään sääntöä. Windowsin oma VPN-yhteys näkyy yleensä etäkäyttönä. Kolmannen osapuolen asiakas, joka luo oman virtuaalisen sovittimensa, näkyy usein langallisena, mikä tarkoittaa, että langallisiin sovittimiin rajattu esto estää myös tunnelin.

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

Kolmas komento kertoo, onko oletusarvoinen lähtevän liikenteen esto jo voimassa, mikä muuttaa koko suunnittelun muodon. Jos oletus on jo esto, kirjoitat sallivia sääntöjä etkä poikkeuksia sallivaan perustaan, ja se on paljon helpompi kanta ajatella.

Jos tunnelisovittimesi ilmoittautuu langalliseksi, pelkkä palomuuri ei ole oikea työkalu suljetun epäonnistumisen suunnitteluun, eikä mikään sääntöjen viritys muuta sitä. Tämä on tapaus, jossa jokaisen foorumiketjun toinen mielipide on oikeassa.

Päätepisteen poikkeus tarvitsee säännön lisäksi reitin

Oletetaan, että luokittelu toimii. Poikkeus on kaksi osaa, ja ne elävät eri alijärjestelmissä. Palomuurisääntö sallii liikenteen; isäntäreitti saa sen lähtemään oikeasta liitännästä, kun tunneli on alhaalla.

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

Ilman reittiä poikkeus auttaa vain niin kauan kuin oletusreitti osoittaa vielä fyysiseen yhdyskäytävään. Kun asiakas asentaa oman oletusreittinsä ja kuolee sitten, sallituilla paketeilla ei ole järkevää paikkaa mennä eikä yhteyttä voi palauttaa. Se vika näyttää rikkinäiseltä asiakkaalta ja on oikeasti puuttuva reitti.

Pidä poikkeus niin kapeana kuin asiakas sallii. Yksi osoite ja yksi portti ovat tarkistettavissa; alue, joka kattaa palveluntarjoajan koko verkon, ei ole. Laajempi sääntö sallii myös kaiken muun samalla palveluntarjoajalla isännöidyn, mikä on yleensä enemmän kuin tarkoitit.

DNS ja IPv6 ovat paikat, joissa se epäonnistuu avoimesti

Nimien ratkaisu on klassinen vuoto. Jos päätepiste on isäntänimi, asiakkaan on ratkaistava se ennen tunnelin olemassaoloa, mikä tarkoittaa, että fyysiselle sovittimelle on sallittava pääsy ratkaisijaan. Sama lupa päästää kaikki muut haut ulos tunnelin ollessa alhaalla, ja yksi haku riittää paljastamaan, mitä olit aikeissa käydä katsomassa.

IPv6 on toinen. IPv4:lle kirjoitetut säännöt eivät kata toista perhettä, ja monet asiakkaat asentavat vain IPv4-reittejä. Niinpä kone, jolla on natiivi IPv6-yhteys, voi jatkaa internetiin puhumista, kun IPv4-puoli on tiukasti estetty, ja hätäkatkaisin ilmoittaa onnistumisesta koko ajan.

Kolmas rivi kannattaa ymmärtää eikä kiertää. Palomuuri päättää paketeista, ei siitä, mitä liitäntää sovellus pyysi käyttämään, ja ohjelmaa, joka sitoutuu nimenomaisesti, voi olla vaikea pitää kurissa. Se on argumentti asiakaspuolen hätäkatkaisimen puolesta, joka toimii sovelluksen alapuolella, ei lisäsääntöjen puolesta.

Testaa pysäyttämällä asiakas, älä kiskomalla johtoa

Ainoa mielekäs testi on se, joka jäljittelee vikaa, jolta suojaudut. Pysäytä palvelu, tapa prosessi tai poista käytöstä asiakkaan luoma sovitin ja yritä sitten päästä internetiin ja nimeen:

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

Kaikkien kolmen pitäisi epäonnistua. Jos ensimmäinen onnistuu, esto ei ole voimassa; jos toinen onnistuu siellä, missä ensimmäinen epäonnistui, sinulla on DNS-vuoto; jos kolmas onnistuu, IPv6 ei ole katettu. Jokainen tulos osoittaa täsmälleen yhteen yllä olevista aukoista.

Toista testi lepotilan ja herätyksen jälkeen, koska palomuuriprofiili voi vaihtua, kun Windows päättää, että verkko on julkinen tai yksityinen, ja profiiliin rajatut säännöt seuraavat sitä. Suunnittelu, joka kestää työpöydällä ja epäonnistuu junassa, on suunnittelu, joka testattiin kerran.

Jos luokitteluportti tai DNS-vaatimus tekee pelkän palomuurin lähestymistavasta toimimattoman, asiakaspuolen hätäkatkaisin on rehellinen vastaus. Jos tunneli sen sijaan päättyy reitittimeen, käytännön pitäisi kuulua reitittimelle, koska yksi sääntö siellä kattaa jokaisen sen takana olevan laitteen eikä riipu siitä, miten Windows sovittimen nimeää.