Zavrnitev geolokacije v Fireboxu: najprej poiščite fazo vstopa VPN
Pravilo, ki blokira odjemalca VPN, je pogosto vstopni politik, ne pravilo dostopa uporabnika. Šest preverjanj, ki najdejo dejansko fazo, preden karkoli spremenite.
Nekdo v drugi državi se ne more povezati, in prvi instinkt je pogledati pravilo, ki daje dostop do notranjih virov. To pravilo se izvede po sprejemu, zato ne more biti tisto, kar zavrača tunel. Faza, ki blokira, je nekje na vstopni poti, in Firebox ima več kot eno vstopno pot glede na storitev VPN. Izvedite preverjanja po vrsti in se ustavite takoj, ko eno od njih pojasni zavrnitev.
Preverjanje 1: poimenujte dohodno storitev
Za Mobile VPN s SSL, Access Portal in BOVPN prek TLS je dohodni vstop politik WatchGuard SSLVPN. Predvideno omejitev uporabite tam, na dejansko konfigurirani storitvi, namesto da bi jo izpeljali iz pravila dostopa uporabnika, ki se izvede pozneje.
IPsec gre po drugi poti. Vgrajeni politik IPSec dovoljuje zunanji promet IPsec do Fireboxa za ustrezne storitve podružnice in mobilnega VPN ter ima prednost pred ročno ustvarjenim politikom IPSec. Če je vaš odjemalec IKEv2, ste na tej drugi poti, in politik SSLVPN ni pomemben.
Zmota tukaj je najpogosteje zapravljeno popoldne na tem področju: urejati politik, ki paketa nikoli ne vidi, in nato sklepati, da omejitev ne deluje.
Preverjanje 2: berite zavrnitev, ne teorije
Naredite en nadzorovan dovoljen poskus in povežite štiri stvari: javni naslov vira odjemalca, vstopno storitev, ki jo je dosegel, politik, ki se je ujemal, in vsak razlog zavrnitve v dnevniku. Vodnik WatchGuard za odpravljanje težav IKEv2 navaja, da lahko geolokacija in privzeto ravnanje s paketi zavrneta promet še pred sprejemom vgrajenega politika, kar pomeni, da lahko zavrnitev, ki jo vidite, navaja fazo, ki je niste upoštevali.
Razvrstitev države sledi opazovanemu omrežnemu viru. Gostujoči uporabnik, nadrejeni NAT ali druga odobrena pot lahko spremenijo, kar Firebox vidi, zato potrdite naslov in ne uporabnikovega opisa, kje je. Zahtevajte javni naslov, ki ga vidi odjemalec, in ga primerjajte z virom v dnevniku Fireboxa. Ko se razlikujeta, razvrstitev sledi poti, ki je nihče ni omenil.
Preverjanje 3: je vgrajeni politik še lastnik?
Če se zdi, da je ročni politik IPSec prezrt, preverite, ali je vgrajeni še omogočen. Ročno pravilo, ki ga zasenči vgrajeno pravilo z višjo prioriteto, in ročno pravilo, ki je edini sprejem, sta različni konfiguraciji s podobno vidnim vmesnikom.
Odločite, kateri naj ima pot. Če je to ročni politik, je treba vgrajenega za ta promet onemogočiti, in tam se začne naslednje preverjanje.
Preverjanje 4: načrtujte zamenjavo pred onemogočanjem
Onemogočanje vgrajenega politika IPSec odstrani njegov sprejem za prizadete storitve VPN. To vključuje tunele podružnic, na katere morda ne pomislite, medtem ko popravljate povezavo enega mobilnega uporabnika.
Najprej načrtujte popolno zamenjavo: katere storitve potrebujejo sprejem, kakšne obsege virov dobijo in kako boste upravljali napravo, če gre sprememba narobe. Ohranite odprto neodvisno pot upravljanja in obnovitve, ker lahko napaka tukaj odstrani tunel, ki bi ga uporabili za popravek. Zapišite korake obnovitve v dnevnik sprememb, vključno s tem, kako doseči napravo, če je pot VPN izginila. Nato preizkusite obnovitev, ne le prve povezave.
Dejavna povezljivost in poznejše ponovno pogajanje sta lahko odvisna od sprejema. Sprememba, ki deluje za preizkušeno sejo in ne uspe pri naslednji menjavi ključa, je klasičen izid zamenjave sprejema brez preizkusa obnovitve.
Preverjanje 5: ohranite identiteto ločeno od lokacije
Geolokacija doda kontekst odločitvi o vstopu. Ne ugotavlja, kdo je uporabnik, in ne sme nadomestiti preverjanj identitete prehoda, avtorizacije računa ali MFA.
Če je poslovna zahteva le odobreni uporabniki z odobrenih mest, potrebujete oba nadzora. Pravilo lokacije, ki sprejme celo državo, ne nadomesti avtentikacije, in avtenticiran uporabnik v blokirani državi je vprašanje politike, ne napaka.
Preverjanje 6: zabeležite in preverite obe poti
Zapišite storitev, vstopni politik, predvideni obseg lokacije, izjeme in odgovornega za obnovitev. Nato po spremembi preizkusite mobilno pot in vsaj eno pot do lokacije, da omejitev ostane vezana na storitev, za katero je bila zasnovana.
Na koncu znova preberite zavrnitev, s katero ste začeli. Če se je spremenila iz zavrnitve zaradi lokacije v napako avtentikacije ali avtorizacije, je vstopna težava rešena in zdaj je vidna druga. Vodnik WatchGuard o zavrnitvah IKEv2 je referenca za zgoraj opisani vrstni red faz.