Firebox-geolokiga rifuzo: unue trovu la VPN-eniran stadion

Iu en alia lando ne povas konektiĝi, kaj la unua instinkto estas rigardi la regulon, kiu donas aliron al internaj rimedoj. Tiu regulo funkcias post akcepto, do ĝi ne povas esti tio, kio forĵetas la tunelon. La blokanta stadio troviĝas ie en la enira vojo, kaj la Firebox havas pli ol unu eniran vojon depende de la VPN-servo. Faru la kontrolojn laŭorde kaj haltu tuj kiam unu el ili klarigas la rifuzon.

Kontrolo 1: nomu la envenantan servon

Por Mobile VPN kun SSL, Access Portal kaj BOVPN super TLS, la envenanta eniro estas la politiko WatchGuard SSLVPN. Apliku la celatan limigon tie, sur la efektive agordita servo, anstataŭ deduki ĝin el regulo de uzanta aliro, kiu funkcias poste.

IPsec prenas alian vojon. La enkonstruita IPSec-politiko permesas eksteran IPsec-trafikon al la Firebox por la koncernaj branch kaj poŝtelefonaj VPN-servoj, kaj ĝi havas prioritaton super permane kreita IPSec-politiko. Se via kliento estas IKEv2, vi estas sur tiu dua vojo, kaj la SSLVPN-politiko estas sensignifa.

Erari ĉi tie estas la plej ofta perdata posttagmezo en ĉi tiu kampo: redakti politikon, kiu neniam vidas la paketon, kaj poste konkludi, ke la limigo ne funkcias.

Kontrolo 2: legu la rifuzon, ne la teorion

Faru unu kontrolitan permesitan provon kaj kunligu kvar aferojn: la publikan fontadreson de la kliento, la eniran servon, kiun ĝi trafis, la politikon, kiu kongruis, kaj ajnan rifuzan kialon en la protokolo. La gvidilo de WatchGuard pri solvado de IKEv2-problemoj notas, ke geolokigo kaj defaŭlta paketa traktado povas rifuzi trafikon antaŭ la akcepto de la enkonstruita politiko, kio signifas, ke la rifuzo, kiun vi vidas, povas nomi stadion, kiun vi ne konsideris.

Landa klasifiko sekvas la observitan retan fonton. Vojaĝanta uzanto, NAT supre aŭ alia aprobita vojo povas ŝanĝi tion, kion la Firebox vidas, do konfirmu la adreson anstataŭ la priskribon de la uzanto pri kie li estas. Petu la publikan adreson, kiun la kliento vidas, kaj komparu ĝin kun la fonto en la Firebox-protokolo. Kiam ili diferencas, la klasifiko sekvas vojon, kiun neniu menciis.

Kontrolo 3: ĉu la enkonstruita politiko ankoraŭ estas la posedanto?

Se permana IPSec-politiko ŝajnas esti ignorata, kontrolu ĉu la enkonstruita ankoraŭ estas ŝaltita. Permanenta regulo ombrata de enkonstruita regulo de pli alta prioritato kaj permana regulo, kiu estas la sola akcepto, estas malsamaj agordoj kun simile aspektanta interfaco.

Decidu, kiun vi intencas posedi la vojon. Se temas pri la permana politiko, la enkonstruita devas esti malŝaltita por tiu trafiko, kaj tie komenciĝas la sekva kontrolo.

Kontrolo 4: planu la anstataŭigon antaŭ malŝalto

Malŝalti la enkonstruitan IPSec-politikon forigas ĝian akcepton por la tuŝitaj VPN-servoj. Tio inkluzivas branch-tunelojn, pri kiuj vi eble ne pensas dum vi riparas la konekton de unu poŝtelefona uzanto.

Unue planu la kompletan anstataŭigon: kiuj servoj bezonas akcepton, kiujn fontajn gamojn ili ricevas, kaj kiel vi administros la aparaton se la ŝanĝo malsukcesos. Tenu sendependan administran kaj restarigan vojon malferma, ĉar eraro ĉi tie povas forigi la tunelon, kiun vi uzus por ripari ĝin. Notu la restarigajn paŝojn en la ŝanĝprotokolo, inkluzive kiel atingi la aparaton se la VPN-vojo malaperis. Poste testu la renovigon, ne nur la unuan konekton.

Aktiva konektebleco kaj posta reintertraktado povas ambaŭ dependi de akcepto. Ŝanĝo, kiu funkcias por la testita seanco kaj malsukcesas ĉe la sekva ŝlosilŝanĝo, estas klasika rezulto de anstataŭigi akcepton sen testi la renovigon.

Kontrolo 5: tenu identecon aparte de la loko

Geolokigo aldonas kuntekston al enira decido. Ĝi ne establas, kiu estas la uzanto, kaj ĝi ne anstataŭu la identeckontrolojn de la enirejo, la kontan rajtigon aŭ MFA.

Se la komerca postulo estas nur aprobitaj uzantoj el aprobitaj lokoj, vi bezonas ambaŭ kontrolojn. Loka regulo, kiu akceptas tutan landon, ne anstataŭas aŭtentikigon, kaj aŭtentikigita uzanto en blokita lando estas politika demando, ne cimo.

Kontrolo 6: skribu ĝin kaj kontrolu ambaŭ vojojn

Skribu la servon, la eniran politikon, la celatan lokan gamon, la esceptojn kaj la restarigan posedanton. Poste testu la poŝtelefonan vojon kaj almenaŭ unu ejan vojon post la ŝanĝo, por ke la limigo restu ligita al la servo, por kiu ĝi estis desegnita.

Fine, relegu la rifuzon, kun kiu vi komencis. Se ĝi ŝanĝiĝis de loka rifuzo al aŭtentikiga aŭ rajtiga malsukceso, la enira problemo estas solvita kaj alia nun videblas. WatchGuard-gvidilo pri IKEv2-rifuzoj estas la referenco por la stadia ordo priskribita supre.