Firebox-geolokasjonsavvisning: finn VPN-inngangstrinnet først

Noen i et annet land får ikke koblet til, og den første innskytelsen er å se på regelen som gir tilgang til interne ressurser. Den regelen kjører etter innslipp, så den kan ikke være det som avviser tunnelen. Det blokkerende trinnet ligger et sted på inngangsveien, og Firebox har mer enn én inngangsvei avhengig av VPN-tjenesten. Gå gjennom kontrollene i rekkefølge og stopp så snart en av dem forklarer avvisningen.

Kontroll 1: navngi den innkommende tjenesten

For Mobile VPN med SSL, Access Portal og BOVPN over TLS er den innkommende inngangen WatchGuard SSLVPN-policyen. Bruk den tiltenkte begrensningen der, på den faktisk konfigurerte tjenesten, i stedet for å utlede den fra en brukertilgangsregel som kjører senere.

IPsec tar en annen vei. Den innebygde IPSec-policyen tillater ekstern IPsec-trafikk til Firebox for de aktuelle branch- og mobile VPN-tjenestene, og den har forrang foran en manuelt opprettet IPSec-policy. Hvis klienten din er IKEv2, er du på den andre veien, og SSLVPN-policyen er irrelevant.

Å gjøre dette feil er den vanligste bortkastede ettermiddagen på dette området: å redigere en policy som aldri ser pakken, og deretter konkludere med at begrensningen ikke virker.

Kontroll 2: les avvisningen, ikke teorien

Gjør ett kontrollert tillatt forsøk og korreler fire ting: klientens offentlige kildeadresse, inngangstjenesten den traff, policyen som samsvarte, og en eventuell avvisningsårsak i loggen. WatchGuards feilsøkingsveiledning for IKEv2 bemerker at geolokasjon og standard pakkehåndtering kan avvise trafikk før den innebygde policyens innslipp, noe som betyr at avvisningen du ser kan navngi et trinn du ikke har vurdert.

Landsklassifisering følger den observerte nettverkskilden. En roaming bruker, en NAT lenger opp eller en annen godkjent vei kan endre det Firebox ser, så bekreft adressen i stedet for brukerens beskrivelse av hvor de er. Be om den offentlige adressen klienten ser, og sammenlign den med kilden i Firebox-loggen. Når de er forskjellige, følger klassifiseringen en vei ingen nevnte.

Kontroll 3: er den innebygde policyen fortsatt eieren?

Hvis en manuell IPSec-policy ser ut til å bli ignorert, sjekk om den innebygde fortsatt er aktivert. En manuell regel som overskygges av en innebygd regel med høyere prioritet, og en manuell regel som er den eneste innslippen, er forskjellige konfigurasjoner med likt utseende i grensesnittet.

Bestem hvilken som skal eie veien. Er det den manuelle policyen, må den innebygde deaktiveres for den trafikken, og det er der neste kontroll begynner.

Kontroll 4: planlegg erstatningen før du deaktiverer

Deaktivering av den innebygde IPSec-policyen fjerner innslippet for de berørte VPN-tjenestene. Det inkluderer branch-tunneler du kanskje ikke tenker på mens du fikser tilkoblingen til én mobil bruker.

Planlegg den fullstendige erstatningen først: hvilke tjenester som trenger innslipp, hvilke kildeområder de får, og hvordan du vil administrere boksen hvis endringen går galt. Hold en uavhengig administrasjons- og gjenopprettingsvei åpen, fordi en feil her kan fjerne tunnelen du ville brukt til å rette den. Noter gjenopprettingstrinnene i endringsloggen, inkludert hvordan du når boksen hvis VPN-veien er borte. Test deretter fornyelse, ikke bare den første tilkoblingen.

Aktiv tilkobling og senere reforhandling kan begge avhenge av innslipp. En endring som virker for økten du testet og feiler ved neste nøkkelbytte, er et klassisk resultat av å erstatte innslipp uten å teste fornyelse.

Kontroll 5: hold identitet atskilt fra plassering

Geolokasjon legger til kontekst til en inngangsbeslutning. Den fastslår ikke hvem brukeren er, og den bør ikke erstatte gateway-identitetskontroller, kontogodkjenning eller MFA.

Hvis forretningskravet bare er godkjente brukere fra godkjente steder, trenger du begge kontrollene. En plasseringsregel som slipper inn et helt land er ikke en erstatning for autentisering, og en autentisert bruker i et blokkert land er et policyspørsmål, ikke en feil.

Kontroll 6: skriv det ned og verifiser begge veier

Skriv ned tjenesten, inngangspolicyen, det tiltenkte plasseringsområdet, unntakene og gjenopprettingseieren. Test deretter mobilveien og minst én nettstedsvei etter endringen, slik at begrensningen forblir knyttet til tjenesten den var ment å kontrollere.

Til slutt, les avvisningen du startet med på nytt. Hvis den har endret seg fra en plasseringsavvisning til en autentiserings- eller autorisasjonsfeil, er inngangsproblemet løst og et annet er nå synlig. WatchGuards veiledning om IKEv2-avvisninger er referansen for trinnrekkefølgen beskrevet ovenfor.