Csak a Windows tűzfal VPN-halálkapcsolóként: kibírja?

Kérdezze meg, működhet-e a Windows tűzfala önmagában vészleállítóként, és két magabiztos, egymással összeegyeztethetetlen választ kap. Az egyik szerint az interfésztípus-szabály mindent megold; a másik szerint szkriptek nélkül nem működik. Mindkettő ugyanazon mechanizmus felét írja le. A tűzfal ki tudja fejezni a blokkolást, és hogy az eredmény valóban zártan hibázik-e, három dolgon múlik: hogyan osztályozza a Windows az alagútadaptert, túléli-e a végpont kivétele, és le van-e fedve a névfeloldás és az IPv6. Ha bármelyiket elrontja, a gép vagy szivárog, vagy elveszíti a teljes kapcsolatot.

Három feltétel, ebben a sorrendben

Az első feltétel az osztályozás, és ez dönti el, hogy a kívánt szabály egyáltalán kifejezhető-e. A Windows tűzfalszabályai interfésztípus szerint korlátozhatók: vezetékes, vezeték nélküli vagy távoli hozzáférés. Az a házirend, amely a fizikai típusokon blokkolja a kimenő forgalmat, miközben engedélyezi az alagutat, csak akkor működik, ha a Windows az alagutat távoli hozzáférésként ismeri fel.

A második feltétel a végpont kivétele. Mielőtt bármilyen alagút létezik, az ügyfélnek a fizikai adapteren keresztül el kell érnie a VPN-kiszolgálót, ezért az adapterre vonatkozó teljes blokkolás éppen azt a kapcsolatot akadályozza meg, amely a blokkolást feleslegessé tenné. A kivételnek meg kell neveznie a kiszolgálót és portját, a csomagnak pedig a fizikai átjárón keresztül kell kijutnia, nem egy még fel nem állt alagútba.

A harmadik a lefedettség. Az a szabálykészlet, amely blokkolja az IPv4-et és megfeledkezik az IPv6-ról, vagy engedélyezi a helyi feloldónak a végpont lekérdezését és ezzel minden más lekérdezést is engedélyez, nyíltan hibázik éppen abban az ablakban, amelyre a vészleállító létezik. Ez tervezési hiányosság, nem a tűzfal hibája. Ez az a rés is, amely minden asztali próbát túlél.

Az osztályozás az első kapu

Nézze meg, mit gondol a Windows az adapterekről, mielőtt egyetlen szabályt írna. A natív Windows VPN-kapcsolat általában távoli hozzáférésként jelenik meg. A saját virtuális adaptert létrehozó harmadik féltől származó kliens gyakran vezetékesként jelenik meg, ami azt jelenti, hogy a vezetékes adapterekre korlátozott blokkolás az alagutat is blokkolja.

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

A harmadik parancs megmondja, érvényben van-e már egy alapértelmezett kimenő blokkolás, ami az egész tervezés formáját megváltoztatja. Ha az alapértelmezés már blokkolás, engedélyező szabályokat ír, nem kivételeket egy megengedő bázishoz, és ez sokkal könnyebben átgondolható álláspont.

Ha az alagútadapter vezetékesként jelentkezik, a csak tűzfal nem megfelelő eszköz a zárt hibázású tervezéshez, és semmilyen szabályhangolás nem változtat ezen. Ez az az eset, amikor minden fórumtéma második véleménye igaz.

A végpont kivételéhez a szabály mellett útvonal is kell

Tegyük fel, hogy az osztályozás működik. A kivétel két darabból áll, és különböző alrendszerekben élnek. A tűzfalszabály engedélyezi a forgalmat; a gazdaútvonal pedig kivezeti a megfelelő interfészen, amíg az alagút le van kapcsolva.

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

Útvonal nélkül a kivétel csak addig segít, amíg egy alapértelmezett útvonal még a fizikai átjáróra mutat. Amint az ügyfél telepíti a saját alapértelmezett útvonalát, majd leáll, az engedélyezett csomagoknak nincs értelmes hova menniük, és a kapcsolat nem állítható helyre. Ez a hiba törött ügyfélnek látszik, valójában hiányzó útvonal.

Tartsa a kivételt olyan szűken, amilyen szűken az ügyfél engedi. Egy cím és egy port áttekinthető; a szolgáltató teljes hálózatát lefedő tartomány nem. A szélesebb szabály mindent engedélyez, ami ugyanannál a szolgáltatónál található, ami általában több a szándékolt mértéknél.

A DNS és az IPv6 az, ahol nyíltan hibázik

A névfeloldás a klasszikus szivárgás. Ha a végpont gazdagépnév, az ügyfélnek fel kell oldania, mielőtt az alagút létezik, ami azt jelenti, hogy a fizikai adapternek engedélyezni kell a feloldó elérését. Ugyanez az engedély minden más lekérdezést kienged, amíg az alagút le van kapcsolva, és egyetlen lekérdezés elég ahhoz, hogy felfedje, mit készült meglátogatni.

Az IPv6 a második. Az IPv4-hez írt szabályok nem fedik le a másik családot, és sok ügyfél csak IPv4-útvonalakat telepít. Így egy natív IPv6-kapcsolattal rendelkező gép tovább beszélhet az internettel, miközben az IPv4-oldal szilárdan blokkolt, és a vészleállító végig sikert jelent.

A harmadik sor megértést érdemel, nem megkerülést. A tűzfal a csomagokról dönt, nem arról, hogy egy alkalmazás melyik interfészt kérte, és egy kifejezetten kötődő programot nehéz lehet kordában tartani. Ez érv a kliensoldali vészleállító mellett, amely az alkalmazás alatt működik, nem a több szabály mellett.

A kliens leállításával teszteljen, ne a kábel kihúzásával

Az egyetlen értelmes teszt az, amely utánozza a hibát, amely ellen védekezik. Állítsa le a szolgáltatást, ölje meg a folyamatot, vagy tiltsa le a kliens által létrehozott adaptert, majd próbáljon elérni az internetet és egy nevet:

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

Mindháromnak hibáznia kell. Ha az első sikerül, a blokkolás nincs érvényben; ha a második ott sikerül, ahol az első hibázott, DNS-szivárgása van; ha a harmadik sikerül, az IPv6 nincs lefedve. Minden eredmény pontosan a fenti rések egyikére mutat.

Ismételje meg a tesztet alvás és ébredés után, mert a tűzfalprofil megváltozhat, amikor a Windows eldönti, hogy egy hálózat nyilvános vagy privát, és a profilhoz kötött szabályok követik. Az a tervezés, amely az asztalon kibírja és a vonaton hibázik, egyszer tesztelt tervezés.

Ha az osztályozási kapu vagy a DNS-követelmény a csak tűzfal megközelítést használhatatlanná teszi, a kliensoldali vészleállító az őszinte válasz. Ha az alagút inkább egy routeren végződik, a házirend a routeré kell legyen, mert ott egy szabály minden mögötte lévő eszközt lefed, és nem függ attól, hogyan nevezi el a Windows az adaptert.