Miért nem ping-szabály csak az alagútra a VPN-állapothoz kötött tűzfal-kapu

Képzeljen el egy tűzfalszabályt, amely bekapcsolja az ICMP echo-t a kiszolgáló nyilvános címére, valahányszor egy megnevezett VPN-profil csatlakoztatva van. Úgy olvassuk, hogy „ping csak az alagúton keresztül”, és ez az olvasat olyan módon hibás, amely számít. A szabály nem korlátozza, ki érheti el a gazdagépet; azt változtatja meg, mire válaszol a nyilvános interfész, miközben egy másik kapcsolat véletlenül él. Ez két különböző szabályzat, és az egyik csendesen tágítja a kitettséget.

A szabály, amelyet azt hiszi, hogy megírt

A szándékolt követelmény általában szűk: a megfigyelő rendszernek, vagy az egyetlen VPN-en lévő rendszergazdának meg kell tudnia erősíteni, hogy a kiszolgáló él. Mondatként leírva úgy hangzik, mint az alagút hozzáférés-ellenőrzése. Tűzfalobjektumként leírva feltétellé válik a nyilvános profilon, mert az echo-kérés oda érkezik.

Amint a feltétel kapcsolatállapot lesz forrási cím helyett, az engedélyezett feladók halmaza már nem a VPN-partnerek halmaza. Bárki, aki eléri a nyilvános címet, küldhet echo-kérést, amíg a kapu nyitva van. Az alagút nem vált úttá; az alagút kapcsolóvá vált.

Az ötlet hirdetői általában nem hazudnak a kívánt hatásról. Olyan ellenőrzésre volt szükségük, amely csak akkor válaszol, ha a kapcsolat egészséges, és a kapcsolat egészségét a VPN-en keresztül volt a legkönnyebb megfigyelni. A hiba az, hogy egy elérhetőségi jelet hozzáférési döntésként kezelünk, majd automatizáljuk.

Mit irányít a kapu valójában

Ez a kialakítás két független dolgot olvaszt össze, és szétválasztásuk a javítás nagy része. Az első a hatókör: melyik helyi cím, mely távoli címek, melyik protokoll és melyik ICMP-típus. A második a feltétel: hogy a szabályobjektum ebben a pillanatban engedélyezett-e. A hatókört a tűzfal csomagonként értékeli; a feltételt egy szkript írja a házirend-tárba, és a kettő teljesen különböző órákon egyeztethető össze.

Ha a követelmény valóban csak VPN-partnerek, a hatókör minden kapcsolatállapot-logika nélkül megválaszolja: kösse a szabályt az alagút interfészéhez vagy az alagút címtartományához, korlátozza a távoli címeket az ügyfélkészletre, és adja meg az echo típusát az „ICMP” helyett. Ez a szabály akkor is helyes marad, ha nincs VPN, és egy nem kapcsolódó profil nem tudja kinyitni.

Ha a követelmény valóban nyilvános kapu, mondja ezt ki a házirend szövegében, mert az elfogadási feltételek megváltoznak. A nyilvános kapunak meg kell neveznie a pontos profilt, meg kell határoznia, mit jelent a csatlakoztatva, és ki kell jelentenie, hogy a nyilvános feladók tervezés szerint a hatókörben vannak. A zavar nagy része abban a pillanatban eltűnik, amikor valakit rákényszerítenek, hogy leírja ezt a mondatot.

Építse fel az objektumot egyszer, aztán kapcsolgassa

Készítsen előre egyetlen szabályt stabil identitással, letiltva, és engedje, hogy a vezérlő csak az engedélyezettségi állapotát változtassa. A szabályok megjelenített név szerinti létrehozása minden futáskor az az út, amelyen a házirend-tár öt majdnem azonos objektummal és megbízható eltávolítási mód nélkül végzi.

New-NetFirewallRule -Name "VpnGateEchoV4" -DisplayName "Public echo gated on VPN state" -Direction Inbound -Action Allow -Protocol ICMPv4 -IcmpType 8 -LocalAddress 203.0.113.10 -RemoteAddress Any -Enabled False
Set-NetFirewallRule -Name "VpnGateEchoV4" -Enabled True

A név a tartós azonosító; a megjelenített név olyan dokumentáció, amelyet egy ember szerkeszthet. Egyeztessen a -Name alapján, és a szkript abbahagyja a másolatok termelését. Ugyanaz a parancsforma lefedi az IPv6-os esetet a -Protocol ICMPv6 -IcmpType 128 segítségével, de az külön szabály, mert az echo-típus számai eltérnek a két család között.

Tartsa a címcsaládot és az ICMP-típust kifejezetten egy második okból is: a -Protocol ICMPv4 típus nélkül minden ICMPv4-üzenetet engedélyez, amelyet a profil megenged, beleértve azokat is, amelyeket soha nem kívánt elfogadni. A 8-as típus megnevezése az echo-kérésre szűkíti a szabályt, és az elérhetőség-ellenőrzés csak ezt küldi.

Ahol az automatizálás ellentmond a szándéknak

Az ügyfélprofil néhány percenkénti lekérdezése nem hozhat azonnali határt. A kapcsolat megszakadása és a következő lekérdezés között a szabály még válaszol a nyilvános címen; a kapcsolat felépülése és a következő lekérdezés között nem. Ezt a késleltetést elismerni őszinte, azt állítani, hogy a kialakítás szigorú invariánst kényszerít, nem az.

Maga az állapotellenőrzés is tartalmaz hatókörcsapdát. A Get-VpnConnection a gépen beállított ügyfélprofilokat jelenti, alapértelmezés szerint az aktuális felhasználóhoz és minden felhasználóhoz a -AllUserConnection kapcsolóval. Nem jelenti azokat a távoli felhasználókat, akik éppen egy RRAS-kiszolgálóhoz tárcsáztak be; az egy másik megfigyelés másik parancsrésszel. A rosszra épített kapu semmihez sincs csatlakoztatva.

Ezután fedje le azokat az állapotokat, amelyeket senki nem szkriptel: indítás már engedélyezett szabállyal egy korábbi futásból, a vezérlő összeomlása nyitott kapu mellett, és törölt profil, miközben a szabálya él. Mindegyikhez meghatározott alapérték kell, és a nyilvános engedély biztonságos alapértéke a letiltás. Ha a követelmény valóban nem tűri a lekérdezési ablakot, az állapothoz kötött szabály rossz eszköz, és a kényszerítés az alagúthoz tartozik, nem a nyilvános interfészhez.

Végül tesztelje a nyilvános kérést kétszer, egyszer a kiválasztott kapcsolat élő, egyszer pedig bontott állapotában, olyan gazdagépről, amely nincs a VPN-en. Az alagúton belülről sikeres ping semmit nem bizonyít erről a szabályzatról, és éppen ezt a mérést hagyják ki a legtöbb telepítésnél.