Firebox-geolokationsafvisning: find VPN-indgangsfasen først

En person i et andet land kan ikke forbinde, og den første indskydelse er at kigge på reglen, der giver adgang til interne ressourcer. Den regel kører efter adgang, så den kan ikke være det, der afviser tunnelen. Den blokerende fase ligger et sted på indgangsvejen, og Firebox har mere end én indgangsvej afhængigt af VPN-tjenesten. Udfør kontrollerne i rækkefølge, og stop så snart en af dem forklarer afvisningen.

Kontrol 1: navngiv den indgående tjeneste

For Mobile VPN med SSL, Access Portal og BOVPN over TLS er den indgående indgang WatchGuard SSLVPN-politikken. Anvend den tilsigtede begrænsning der, på den faktisk konfigurerede tjeneste, i stedet for at udlede den af en brugeradgangsregel, der kører senere.

IPsec tager en anden vej. Den indbyggede IPSec-politik tillader ekstern IPsec-trafik til Firebox for de relevante branch- og mobile VPN-tjenester, og den har forrang over en manuelt oprettet IPSec-politik. Hvis din klient er IKEv2, er du på den anden vej, og SSLVPN-politikken er irrelevant.

At tage fejl her er den mest almindelige spildte eftermiddag på dette område: at redigere en politik, der aldrig ser pakken, og derefter konkludere, at begrænsningen ikke virker.

Kontrol 2: læs afvisningen, ikke teorien

Foretag ét kontrolleret tilladt forsøg, og korrelér fire ting: klientens offentlige kildeadresse, den indgangstjeneste den ramte, den politik der matchede, og enhver afvisningsårsag i loggen. WatchGuards fejlfindingsvejledning til IKEv2 bemærker, at geolokation og standardpakkehåndtering kan afvise trafik før den indbyggede politiks adgang, hvilket betyder, at den afvisning, du ser, kan navngive en fase, du ikke har overvejet.

Landeklassifikation følger den observerede netværkskilde. En roaming bruger, en NAT længere fremme eller en anden godkendt vej kan ændre, hvad Firebox ser, så bekræft adressen i stedet for brugerens beskrivelse af, hvor de er. Bed om den offentlige adresse, klienten ser, og sammenlign den med kilden i Firebox-loggen. Når de afviger, følger klassifikationen en vej, ingen har nævnt.

Kontrol 3: er den indbyggede politik stadig ejeren?

Hvis en manuel IPSec-politik ser ud til at blive ignoreret, så kontrollér, om den indbyggede stadig er aktiveret. En manuel regel, der overskygges af en indbygget regel med højere forrang, og en manuel regel, der er den eneste adgang, er forskellige konfigurationer med ens udseende i brugerfladen.

Beslut, hvilken der skal eje vejen. Er det den manuelle politik, skal den indbyggede deaktiveres for den trafik, og det er der, den næste kontrol begynder.

Kontrol 4: planlæg erstatningen, før du deaktiverer

Deaktivering af den indbyggede IPSec-politik fjerner dens adgang for de berørte VPN-tjenester. Det omfatter branch-tunneler, du måske ikke tænker på, mens du retter én mobil brugers forbindelse.

Planlæg den fuldstændige erstatning først: hvilke tjenester har brug for adgang, hvilke kildeområder får de, og hvordan du vil administrere boksen, hvis ændringen går galt. Hold en uafhængig administrations- og gendannelsesvej åben, for en fejl her kan fjerne den tunnel, du ville bruge til at rette den. Notér gendannelsestrinene i ændringsregistret, herunder hvordan du når boksen, hvis VPN-vejen er væk. Test derefter fornyelse, ikke kun den første forbindelse.

Aktiv forbindelse og senere genforhandling kan begge afhænge af adgang. En ændring, der virker for den session, du testede, og fejler ved næste nøgleudskiftning, er et klassisk resultat af at erstatte adgang uden at teste fornyelse.

Kontrol 5: hold identitet adskilt fra placering

Geolokation tilføjer kontekst til en indgangsbeslutning. Den fastslår ikke, hvem brugeren er, og bør ikke erstatte gateway-identitetskontroller, kontogodkendelse eller MFA.

Hvis forretningskravet kun er godkendte brugere fra godkendte steder, har du brug for begge kontroller. En placeringsregel, der tillader et helt land, er ikke en erstatning for autentificering, og en autentificeret bruger i et blokeret land er et politikspørgsmål, ikke en fejl.

Kontrol 6: skriv det ned, og verificér begge veje

Skriv tjenesten ned, indgangspolitikken, det tilsigtede placeringsområde, undtagelserne og gendannelsesejeren. Test derefter den mobile vej og mindst én stedvej efter ændringen, så begrænsningen bliver knyttet til den tjeneste, den er designet til at styre.

Til sidst, læs afvisningen, du startede med, igen. Hvis den er ændret fra en placeringsafvisning til en autentificerings- eller godkendelsesfejl, er indgangsproblemet løst, og et andet er nu synligt. WatchGuards vejledning om IKEv2-afvisninger er referencen for den faseinddeling, der er beskrevet ovenfor.