Firebox geolokációs elutasítás: először a VPN-belépési szakaszt találja meg

Valaki egy másik országban nem tud csatlakozni, és az első ösztön az, hogy megnézzük azt a szabályt, amely hozzáférést ad a belső erőforrásokhoz. Az a szabály a beengedés után fut, tehát nem az lehet az, ami elutasítja az alagutat. A blokkoló szakasz valahol a belépési útvonalon van, és a Fireboxnak a VPN-szolgáltatástól függően több belépési útvonala is lehet. Végezze el a vizsgálatokat sorrendben, és álljon meg, amint valamelyik megmagyarázza az elutasítást.

1. vizsgálat: nevezze meg a bejövő szolgáltatást

SSL-lel működő Mobile VPN, Access Portal és TLS feletti BOVPN esetén a bejövő belépés a WatchGuard SSLVPN-szabályzat. A szándékolt korlátozást ott alkalmazza, a ténylegesen beállított szolgáltatáson, ahelyett hogy egy később futó felhasználói hozzáférési szabályból következtetné ki.

Az IPsec más útvonalat követ. A beépített IPSec-szabályzat engedélyezi a külső IPsec-forgalmat a Firebox felé az érintett fióktelep- és mobil VPN-szolgáltatásokhoz, és elsőbbséget élvez a kézzel létrehozott IPSec-szabályzattal szemben. Ha az ügyfele IKEv2, akkor ezen a második útvonalon van, és az SSLVPN-szabályzat irreleváns.

Ezt elrontani a leggyakoribb elvesztegetett délután ezen a területen: olyan szabályzatot szerkeszteni, amely soha nem látja a csomagot, majd arra jutni, hogy a korlátozás nem működik.

2. vizsgálat: az elutasítást olvassa, ne az elméletet

Végezzen egy ellenőrzött engedélyezett kísérletet, és kapcsoljon össze négy dolgot: az ügyfél nyilvános forráscímét, az elért belépési szolgáltatást, az egyező szabályzatot és a naplóban szereplő elutasítási okot. A WatchGuard IKEv2-hibaelhárítási útmutatója megjegyzi, hogy a geolokáció és az alapértelmezett csomagkezelés a forgalmat a beépített szabályzat beengedése előtt is elutasíthatja, ami azt jelenti, hogy a látott elutasítás olyan szakaszt nevezhet meg, amelyet nem vett figyelembe.

Az országbesorolás a megfigyelt hálózati forrást követi. Egy barangoló felhasználó, egy felsőbb NAT vagy egy másik jóváhagyott útvonal megváltoztathatja, mit lát a Firebox, ezért a címet igazolja, ne a felhasználó leírását arról, hol van. Kérje el a nyilvános címet, amelyet az ügyfél lát, és hasonlítsa össze a Firebox naplójában szereplő forrással. Ha eltérnek, a besorolás olyan útvonalat követ, amelyet senki nem említett.

3. vizsgálat: a beépített szabályzat-e még a tulajdonos?

Ha úgy tűnik, hogy a kézi IPSec-szabályzatot figyelmen kívül hagyják, ellenőrizze, hogy a beépített még engedélyezve van-e. A magasabb prioritású beépített szabály által árnyékolt kézi szabály és az egyetlen beengedést jelentő kézi szabály különböző konfigurációk hasonló megjelenésű felülettel.

Döntse el, melyik birtokolja az útvonalat. Ha a kézi szabályzat, akkor a beépítettet ki kell kapcsolni arra a forgalomra, és ott kezdődik a következő vizsgálat.

4. vizsgálat: a csere megtervezése a kikapcsolás előtt

A beépített IPSec-szabályzat kikapcsolása eltávolítja annak beengedését az érintett VPN-szolgáltatásokhoz. Ebbe beletartoznak olyan fióktelep-alagutak, amelyekre talán nem gondol, miközben egy mobil felhasználó kapcsolatát javítja.

Először tervezze meg a teljes cserét: mely szolgáltatásoknak kell beengedés, milyen forrástartományokat kapnak, és hogyan fogja kezelni az eszközt, ha a változtatás rosszul sül el. Tartson nyitva egy független kezelési és helyreállítási útvonalat, mert egy hiba itt eltávolíthatja azt az alagutat, amelyet a javításhoz használna. Jegyezze fel a helyreállítási lépéseket a változásjegyzőkönyvben, beleértve azt is, hogyan érhető el az eszköz, ha a VPN-útvonal eltűnt. Utána tesztelje a megújítást, ne csak az első kapcsolatot.

Az aktív kapcsolódás és a későbbi újratárgyalás is függhet a beengedéstől. Az a változtatás, amely a tesztelt munkamenetben működik, de a következő kulcscserénél meghiúsul, a beengedés megújítás tesztelése nélküli cseréjének klasszikus eredménye.

5. vizsgálat: tartsa külön az identitást a helytől

A geolokáció kontextust ad a belépési döntéshez. Nem állapítja meg, ki a felhasználó, és nem helyettesítheti az átjáró identitásellenőrzéseit, a fiókengedélyezést vagy az MFA-t.

Ha az üzleti követelmény csak jóváhagyott helyekről érkező jóváhagyott felhasználó, mindkét kontrollra szüksége van. Az egész országot beengedő helyszabály nem helyettesíti a hitelesítést, és egy blokkolt országban lévő hitelesített felhasználó szabályzatkérdés, nem hiba.

6. vizsgálat: rögzítse és ellenőrizze mindkét útvonalat

Írja le a szolgáltatást, a belépési szabályzatot, a tervezett helytartományt, a kivételeket és a helyreállítás felelősét. Utána tesztelje a változtatás után a mobil útvonalat és legalább egy telephelyi útvonalat, hogy a korlátozás ahhoz a szolgáltatáshoz kapcsolódjon, amelynek szánták.

Végül olvassa újra az elutasítást, amellyel kezdte. Ha az helyszín szerinti elutasításból hitelesítési vagy engedélyezési hibává változott, a belépési probléma megoldódott, és most egy másik látható. A fent leírt szakaszsorrendhez a WatchGuard útmutató az IKEv2 elutasításaihoz nyújt referenciát.