Само Windows заштитни зид као VPN прекидач: издржава ли?

Питајте да ли Windows заштитни зид може сам да служи као прекидач за нужду и добићете два самоуверена и неспојива одговора. Један каже да правило по типу интерфејса обавља цео посао; други да не ради без скрипти. Оба описују половину истог механизма. Зид може да изрази блокирање, а да ли резултат заиста не успева затворено зависи од три ствари: како Windows класификује тунелски адаптер, да ли опстаје изузетак за крајњу тачку и да ли су покривени резолуција имена и IPv6. Погрешите у било чему од тога и машина или цури или губи сву везу.

Три услова, овим редом

Први услов је класификација и она одлучује да ли је жељено правило уопште изразиво. Правила Windows заштитног зида могу се ограничити по типу интерфејса: жичани, бежични или удаљени приступ. Политика која блокира одлазни саобраћај на физичким типовима и дозвољава тунел ради само ако Windows препознаје тунел као удаљени приступ.

Други услов је изузетак за крајњу тачку. Пре него што постоји било какав тунел, клијент мора да стигне до VPN сервера преко физичког адаптера, па потпуна блокада тог адаптера спречава управо ону везу која би блокирање учинила непотребним. Изузетак мора да именује сервер и његов порт, а пакет мора да изађе кроз физички пролаз, а не у још недигнути тунел.

Треће је покривеност. Скуп правила који блокира IPv4 и заборавља IPv6, или дозвољава локалном резолверу да тражи крајњу тачку и тиме дозвољава сваки други упит, отворено не успева тачно у оном прозору због којег прекидач постоји. То је празнина у дизајну, не дефект у зиду. То је и празнина која преживљава свако тестирање за столом.

Класификација је прва капија

Погледајте шта Windows мисли о адаптерима пре него што напишете и једно правило. Уграђена Windows VPN веза обично се појављује као удаљени приступ. Клијент треће стране који ствара сопствени виртуелни адаптер често се појављује као жичан, што значи да блокирање ограничено на жичане адаптере блокира и тунел.

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

Трећа команда вам каже да ли је подразумевано блокирање одлазног саобраћаја већ на снази, што мења цео облик дизајна. Ако је подразумевано већ блокирање, пишете правила дозволе, а не изузетке од дозвољиве основе, и то је много лакши став за размишљање.

Ако се ваш тунелски адаптер пријављује као жичан, само зид није прави алат за дизајн са затвореним неуспехом и никакво подешавање правила то не мења. То је случај у којем је друго мишљење у свакој форумској теми тачно.

Изузетак за крајњу тачку тражи и руту, не само правило

Претпоставимо да класификација ради. Изузетак су два дела и они живе у различитим подсистемима. Правило зида дозвољава саобраћај; рута домаћина га изводи кроз прави интерфејс док је тунел спуштен.

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

Без руте изузетак помаже само док подразумевана рута још показује на физички пролаз. Када клијент инсталира сопствену подразумевану руту и затим се угаси, дозвољени пакети немају куд разумно да оду и веза не може поново да се успостави. Тај неуспех изгледа као покварен клијент, а у ствари је рута која недостаје.

Држите изузетак тесан колико клијент дозвољава. Једна адреса и један порт су прегледни; опсег који покрива целу мрежу добављача није. То шире правило дозвољава и све друго хостовано код истог добављача, што је обично више него што сте намеравали.

DNS и IPv6 су места где отворено не успева

Резолуција имена је класично цурење. Ако је крајња тачка име домаћина, клијент мора да га резолује пре него што тунел постоји, што значи да физичком адаптеру мора да се дозволи приступ резолверу. Исто дозвољење пушта сваки други упит док је тунел спуштен, а један упит је довољан да открије шта сте намеравали да посетите.

IPv6 је други. Правила написана за IPv4 не покривају другу фамилију, а многи клијенти инсталирају само IPv4 руте. Зато машина са уграђеном IPv6 везом може да настави да разговара са интернетом док је страна IPv4 чврсто блокирана, а прекидач све време пријављује успех.

Трећи ред вреди разумети уместо заобићи. Зид одлучује о пакетима, не о томе који је интерфејс апликација затражила, и програм који се изричито везује може бити тешко обуздати. То је аргумент за прекидач на клијентској страни који ради испод апликације, не за више правила.

Тестирајте заустављањем клијента, не чупањем кабла

Једини смислен тест је онај који опонаша неуспех од којег се штитите. Зауставите услугу, убијте процес или онемогућите адаптер који је клијент створио, па покушајте да стигнете до интернета и до имена:

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

Сва три треба да не успеју. Ако први успе, блокирање није на снази; ако други успе тамо где је први не успео, имате цурење DNS; ако трећи успе, IPv6 није покривен. Сваки резултат показује тачно на једну од празнина горе.

Поновите тест после сна и буђења, јер се профил зида може променити када Windows одлучи да је мрежа јавна или приватна, а правила ограничена на профил га следе. Дизајн који издржава за столом и не успева у возу је дизајн тестиран једном.

Ако капија класификације или захтев DNS учине приступ само са зидом неупотребљивим, прекидач на клијентској страни је честит одговор. Ако тунел уместо тога завршава на рутеру, политика треба да припада рутеру, јер једно правило тамо покрива сваки уређај иза њега и не зависи од тога како Windows именује адаптер.