Fireboxi geolokatsioonikeeld: leidke esmalt VPN-i sisenemisetapp

Keegi teises riigis ei saa ühendust luua ja esimene instinkt on vaadata reeglit, mis annab juurdepääsu sisemistele ressurssidele. See reegel töötab pärast lubamist, seega ei saa see olla see, mis tunnelit tagasi lükkab. Blokeeriv etapp asub kuskil sisenemistee peal ja Fireboxil on sõltuvalt VPN-teenusest rohkem kui üks sisenemistee. Tehke kontrolle järjest ja lõpetage kohe, kui üks neist keeldumise ära seletab.

Kontroll 1: nimetage sissetulev teenus

Mobile VPN-i puhul SSL-iga, Access Portal ja BOVPN üle TLS-i on sissetulev sisenemine WatchGuard SSLVPN-i reegel. Rakendage kavandatud piirang seal, tegelikult konfigureeritud teenusel, selle asemel et tuletada seda kasutaja juurdepääsureeglist, mis töötab hiljem.

IPsec läheb teist teed. Sisseehitatud IPSec-reegel lubab välist IPsec-liiklust Fireboxile asjakohaste haru- ja mobiilse VPN-i teenuste jaoks ning sellel on eesõigus käsitsi loodud IPSec-reegli ees. Kui teie klient on IKEv2, olete sellel teisel teel ja SSLVPN-i reegel ei ole asjakohane.

Siin eksimine on selle valdkonna kõige sagedasem raisatud pärastlõuna: reegli muutmine, mis ei näe paketti kunagi, ja seejärel järeldus, et piirang ei tööta.

Kontroll 2: lugege keeldumist, mitte teooriat

Tehke üks kontrollitud lubatud katse ja korreleerige nelja asja: kliendi avalik lähteaadress, tabatud sisenemisteenus, sobiv reegel ja mis tahes keeldumise põhjus logis. WatchGuardi IKEv2 tõrkeotsingu juhend märgib, et geolokatsioon ja pakettide vaikekäsitlemine võivad liikluse tagasi lükata enne sisseehitatud reegli lubamist, mis tähendab, et nähtav keeldumine võib nimetada etappi, mida te ei kaalunud.

Riigi klassifikatsioon järgib vaadeldud võrgu allikat. Rändkasutaja, ülemvoolu NAT või muu kinnitatud tee võivad muuta seda, mida Firebox näeb, seega kinnitage aadress, mitte kasutaja kirjeldust selle kohta, kus ta on. Küsige avalikku aadressi, mida klient näeb, ja võrrelge seda Fireboxi logi allikaga. Kui need erinevad, järgib klassifikatsioon teed, mida keegi ei maininud.

Kontroll 3: kas sisseehitatud reegel on veel omanik?

Kui käsitsi IPSec-reegel näib olevat eiratud, kontrollige, kas sisseehitatud on veel lubatud. Käsitsi reegel, mille varjutab kõrgema prioriteediga sisseehitatud reegel, ja käsitsi reegel, mis on ainus lubamine, on erinevad konfiguratsioonid sarnase välimusega liideses.

Otsustage, milline neist peaks teed omama. Kui see on käsitsi reegel, tuleb sisseehitatud selle liikluse jaoks keelata ja sealt algab järgmine kontroll.

Kontroll 4: planeerige asendus enne keelamist

Sisseehitatud IPSec-reegli keelamine eemaldab selle lubamise mõjutatud VPN-teenustele. See hõlmab harutunneleid, mille peale te ühe mobiilse kasutaja ühenduse parandamise ajal võib-olla ei mõtle.

Planeerige esmalt täielik asendus: millised teenused vajavad lubamist, millised lähtealad need saavad ja kuidas te seadet haldad, kui muudatus läheb valesti. Hoidke sõltumatu haldus- ja taastetee avatud, sest viga siin võib eemaldada tunneli, mida te selle parandamiseks kasutaksite. Kirjutage taastamisammud muudatuse kirjesse, sealhulgas see, kuidas seadmeni jõuda, kui VPN-i tee on kadunud. Seejärel testige uuendamist, mitte ainult esimest ühendust.

Aktiivne ühenduvus ja hilisem uuesti läbirääkimine võivad mõlemad sõltuda lubamisest. Muudatus, mis töötab testitud seansil ja ebaõnnestub järgmisel võtmevahetusel, on klassikaline tulemus lubamise asendamisest ilma uuendamist testimata.

Kontroll 5: hoidke identiteet asukohast eraldi

Geolokatsioon lisab sisenemisotsusele konteksti. See ei tuvasta, kes kasutaja on, ja see ei tohiks asendada lüüsi identiteedikontrolle, konto autoriseerimist ega MFA-d.

Kui ärialane nõue on ainult kinnitatud kasutajad kinnitatud kohtadest, on teil vaja mõlemat kontrolli. Asukohareegel, mis lubab tervet riiki, ei asenda autentimist, ja autenditud kasutaja blokeeritud riigis on reegli küsimus, mitte viga.

Kontroll 6: kirjutage see üles ja kontrollige mõlemat teed

Kirjutage üles teenus, sisenemise reegel, kavandatud asukohavahemik, erandid ja taastamise eest vastutaja. Seejärel testige pärast muudatust mobiilset teed ja vähemalt üht saidi teed, et piirang jääks seotuks teenusega, mille jaoks see loodi.

Lõpuks lugege uuesti keeldumist, millega alustasite. Kui see on muutunud asukohapõhisest keeldumisest autentimis- või autoriseerimistõrkeks, on sisenemisprobleem lahendatud ja nähtav on nüüd teine. Ülalkirjeldatud etappide järjekorra viide on WatchGuardi juhend IKEv2 keeldumiste kohta.