Firebox-geolokasjonsavvising: finn VPN-inngangstrinnet først

Nokon i eit anna land får ikkje kopla til, og den første innskota er å sjå på regelen som gjev tilgang til interne ressursar. Den regelen køyrer etter innslepp, så han kan ikkje vere det som avviser tunnelen. Det blokkerande trinnet ligg ein stad på inngangsvegen, og Firebox har meir enn éin inngangsveg avhengig av VPN-tenesta. Gå gjennom kontrollane i rekkjefølgje og stopp så snart ein av dei forklarer avvisinga.

Kontroll 1: nemn den innkomande tenesta

For Mobile VPN med SSL, Access Portal og BOVPN over TLS er den innkomande inngangen WatchGuard SSLVPN-policyen. Bruk den tiltenkte avgrensinga der, på den faktisk konfigurerte tenesta, i staden for å utleie henne frå ein brukartilgangsregel som køyrer seinare.

IPsec tek ein annan veg. Den innebygde IPSec-policyen lèt ekstern IPsec-trafikk til Firebox for dei aktuelle branch- og mobile VPN-tenestene, og han har framom ein manuelt oppretta IPSec-policy. Viss klienten din er IKEv2, er du på den andre vegen, og SSLVPN-policyen er irrelevant.

Å gjere dette feil er den vanlegaste bortkasta ettermiddagen på dette området: å redigere ein policy som aldri ser pakken, og deretter konkludere med at avgrensinga ikkje verkar.

Kontroll 2: les avvisinga, ikkje teorien

Gjer eitt kontrollert tillaten forsøk og korreler fire ting: den offentlege kjeldeadressa til klienten, inngangstenesta han trefte, policyen som samsvarte, og ein eventuell avvisingsårsak i loggen. Feilsøkingsrettleiinga til WatchGuard for IKEv2 nemner at geolokasjon og standard pakkehandtering kan avvise trafikk før innsleppet til den innebygde policyen, noko som tyder på at avvisinga du ser kan nemne eit trinn du ikkje har vurdert.

Landsklassifisering følgjer den observerte nettverkskjelda. Ein roaming brukar, ein NAT lenger oppe eller ein annan godkjend veg kan endre det Firebox ser, så stadfest adressa og ikkje skildringa til brukaren av kvar han er. Be om den offentlege adressa klienten ser, og samanlikn henne med kjelda i Firebox-loggen. Når dei er ulike, følgjer klassifiseringa ein veg ingen nemnde.

Kontroll 3: er den innebygde policyen framleis eigaren?

Viss ein manuell IPSec-policy ser ut til å bli ignorert, sjekk om den innebygde framleis er slått på. Ein manuell regel som blir overskugga av ein innebygd regel med høgare prioritet, og ein manuell regel som er det einaste innsleppet, er ulike konfigurasjonar med likt utsjånad i grensesnittet.

Avgjer kva for ein som skal eige vegen. Er det den manuelle policyen, må den innebygde slåast av for den trafikken, og det er der neste kontroll byrjar.

Kontroll 4: planlegg erstatninga før du slår av

Avslåing av den innebygde IPSec-policyen fjernar innsleppet for dei råka VPN-tenestene. Det omfattar branch-tunnelar du kanskje ikkje tenkjer på medan du rettar tilkoplinga til éin mobil brukar.

Planlegg den fullstendige erstatninga først: kva tenester som treng innslepp, kva kjeldeområde dei får, og korleis du vil styre boksen om endringa går gale. Hald ein uavhengig styrings- og gjenopprettingsveg open, fordi ein feil her kan fjerne tunnelen du ville brukt til å rette han. Noter gjenopprettingstrinna i endringsloggen, inkludert korleis du når boksen om VPN-vegen er borte. Test deretter fornying, ikkje berre den første tilkoplinga.

Aktiv tilkopling og seinare reforhandling kan båe avhenge av innslepp. Ei endring som verkar for økta du testa og feilar ved neste nøkkelbyte, er eit klassisk resultat av å erstatte innslepp utan å teste fornying.

Kontroll 5: hald identitet skild frå plassering

Geolokasjon legg til kontekst til ei inngangsavgjerd. Han fastslår ikkje kven brukaren er, og han bør ikkje erstatte gateway-identitetskontrollar, kontogodkjenning eller MFA.

Viss forretningskravet berre er godkjende brukarar frå godkjende stader, treng du båe kontrollane. Ein plasseringsregel som slepp inn eit heilt land er ikkje ei erstatning for autentisering, og ein autentisert brukar i eit blokkert land er eit policyspørsmål, ikkje ein feil.

Kontroll 6: skriv det ned og verifiser båe vegar

Skriv ned tenesta, inngangspolicyen, det tiltenkte plasseringsområdet, unntaka og gjenopprettingseigaren. Test deretter mobilvegen og minst éin nettstadsveg etter endringa, slik at avgrensinga blir verande knytt til tenesta ho var meint å kontrollere.

Til slutt, les avvisinga du starta med på nytt. Viss ho har endra seg frå ei plasseringsavvising til ein autentiserings- eller autorisasjonsfeil, er inngangsproblemet løyst og eit anna er no synleg. WatchGuard-rettleiing om IKEv2-avvisingar er referansen for trinnrekkjefølgja skild ovanfor.