Само защитната стена на Windows като превключвател за спиране на VPN: издържа ли?
Правилата по тип интерфейс могат да блокират физическите адаптери, но тунелът на трета страна често изглежда като кабелен. Проверете класификацията, маршрута до крайната точка, после DNS.
Попитайте дали защитната стена на Windows може сама да служи като превключвател за спиране и ще получите два уверени и несъвместими отговора. Единият казва, че правилото по тип интерфейс върши цялата работа; другият — че без скриптове не работи. И двата описват половината от един и същ механизъм. Защитната стена може да изрази блокирането, а дали резултатът наистина се затваря безопасно зависи от три неща: как Windows класифицира тунелния адаптер, дали изключението за крайната точка оцелява и дали разрешаването на имена и IPv6 са покрити. Сбъркайте което и да е от тях и машината или изтича, или губи всякаква връзка.
Три условия, в този ред
Първото условие е класификацията и то решава дали желаното правило изобщо може да бъде изразено. Правилата на защитната стена на Windows могат да се ограничат по тип интерфейс: кабелен, безжичен или отдалечен достъп. Политика, която блокира изходящия трафик по физическите типове и разрешава тунела, работи само ако Windows разпознава тунела като отдалечен достъп.
Второто условие е изключението за крайната точка. Преди да съществува какъвто и да е тунел, клиентът трябва да достигне VPN сървъра през физическия адаптер, затова пълно блокиране на този адаптер предотвратява точно връзката, която би направила блокирането ненужно. Изключението трябва да посочва сървъра и неговия порт, а пакетът трябва да излиза през физическия шлюз, а не в тунел, който още не е вдигнат.
Третото е покритието. Набор от правила, който блокира IPv4 и забравя IPv6, или разрешава на локалния резолвер да търси крайната точка и с това разрешава всяко друго търсене, се проваля отворено точно в прозореца, за който съществува превключвателят. Това е пропуск в дизайна, а не дефект в защитната стена. Това е и пропускът, който оцелява при всеки тестов пробег на бюро.
Класификацията е първата порта
Проверете какво мисли Windows за адаптерите, преди да напишете дори едно правило. Вградената VPN връзка в Windows обикновено се показва като отдалечен достъп. Клиент на трета страна, който създава свой виртуален адаптер, често се показва като кабелен, което значи, че блокиране, ограничено до кабелни адаптери, блокира и тунела.
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 страната е здраво блокирана, а превключвателят през цялото време отчита успех.
| Gap | What leaks | Control |
|---|---|---|
| Resolver permitted for endpoint lookup | Every name queried while down | Pin the endpoint as an address, or block non-tunnel DNS |
| Rules only for IPv4 | Full IPv6 connectivity | Add the same rules for the other family |
| Application bound to physical interface | Its own traffic | Firewall cannot fix this; change the binding |
Третият ред заслужава разбиране, а не заобикаляне. Защитната стена решава за пакети, а не за това кой интерфейс е поискала да използва дадена програма, и програма, която се свързва изрично, може да е трудна за овладяване. Това е аргумент за превключвател от страна на клиента, който работи под програмата, а не за още правила.
Тествайте, като спрете клиента, а не като издърпате кабела
Единственият смислен тест е този, който имитира отказа, от който се пазите. Спрете услугата, убийте процеса или деактивирайте адаптера, създаден от клиента, после се опитайте да достигнете интернет и име:
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 нарича адаптера.