Denegación por xeolocalización do Firebox: atope primeiro a etapa de entrada VPN
A regra que bloquea un cliente VPN adoita ser a política de entrada, non a regra de acceso de usuario. Seis comprobacións que atopan a etapa real antes de cambiar nada.
Alguén noutro país non pode conectarse, e o primeiro instinto é mirar a regra que concede acceso aos recursos internos. Esa regra execútase despois da admisión, así que non pode ser o que rexeita o túnel. A etapa que bloquea está nalgún punto da ruta de entrada, e o Firebox ten máis dunha ruta de entrada segundo o servizo VPN. Faga as comprobacións en orde e detéñase en canto unha delas explique a denegación.
Comprobación 1: nomee o servizo entrante
Para Mobile VPN con SSL, Access Portal e BOVPN sobre TLS, a entrada entrante é a política WatchGuard SSLVPN. Aplique alí a restrición prevista, sobre o servizo realmente configurado, en lugar de deducila dunha regra de acceso de usuario que se executa máis tarde.
IPsec segue outra ruta. A política IPSec integrada permite o tráfico IPsec externo cara ao Firebox para os servizos de sucursal e VPN móbil aplicables, e ten precedencia sobre unha política IPSec creada manualmente. Se o seu cliente é IKEv2, está nesa segunda ruta, e a política SSLVPN é irrelevante.
Equivocarse aquí é a tarde máis habitualmente perdida neste ámbito: editar unha política que nunca ve o paquete e logo concluír que a restrición non funciona.
Comprobación 2: lea a denegación, non a teoría
Faga un intento permitido e controlado e correlacione catro cousas: o enderezo de orixe pública do cliente, o servizo de entrada ao que chegou, a política que coincidiu e calquera motivo de denegación no rexistro. A guía de resolución de problemas de IKEv2 de WatchGuard sinala que a xeolocalización e o tratamento predeterminado de paquetes poden denegar tráfico antes da admisión da política integrada, o que significa que a denegación que ve pode nomear unha etapa que non considerara.
A clasificación do país segue a orixe de rede observada. Un usuario en itinerancia, un NAT anterior ou unha ruta aprobada distinta poden cambiar o que ve o Firebox, así que confirme o enderezo e non a descrición do usuario sobre onde está. Pida o enderezo público que ve o cliente e compáreo coa orixe do rexistro do Firebox. Cando difiren, a clasificación segue unha ruta que ninguén mencionou.
Comprobación 3: a política integrada segue sendo a propietaria?
Se unha política IPSec manual parece ignorada, comprobe se a integrada segue activada. Unha regra manual tapada por unha regra integrada de maior prioridade e unha regra manual que é a única admisión son configuracións distintas cunha interface de aspecto idéntico.
Decida cal debe posuír a ruta. Se é a política manual, a integrada debe desactivarse para ese tráfico, e aí comeza a seguinte comprobación.
Comprobación 4: planifique a substitución antes de desactivar
Desactivar a política IPSec integrada elimina a súa admisión para os servizos VPN afectados. Iso inclúe túneles de sucursal nos que quizais non pense mentres arranxa a conexión dun usuario móbil.
Planifique primeiro a substitución completa: que servizos necesitan admisión, que ámbitos de orixe reciben e como xestionará o equipo se o cambio sae mal. Mantéñase aberta unha ruta de xestión e recuperación independente, porque un erro aquí pode eliminar o túnel que usaría para arranxalo. Anote os pasos de recuperación no rexistro de cambios, incluído como chegar ao equipo se a ruta VPN desapareceu. Despois probe a renovación, non só a primeira conexión.
A conectividade activa e a renegociación posterior poden depender ambas da admisión. Un cambio que funciona para a sesión probada e falla no seguinte cambio de clave é un resultado clásico de substituír a admisión sen probar a renovación.
Comprobación 5: manteña a identidade separada da localización
A xeolocalización engade contexto a unha decisión de entrada. Non establece quen é o usuario e non debe substituír as comprobacións de identidade da pasarela, a autorización da conta nin o MFA.
Se o requisito de negocio é só usuarios aprobados desde lugares aprobados, necesita ambos os controis. Unha regra de localización que admite un país enteiro non substitúe a autenticación, e un usuario autenticado nun país bloqueado é unha cuestión de política, non un erro.
Comprobación 6: anóteo e verifique ambas as rutas
Anote o servizo, a política de entrada, o ámbito de localización previsto, as excepcións e o responsable da recuperación. Despois probe a ruta móbil e polo menos unha ruta de sitio tras o cambio, para que a restrición siga ligada ao servizo para o que se deseñou.
Por último, relea a denegación coa que empezou. Se pasou dunha denegación por localización a un fallo de autenticación ou autorización, o problema de entrada está resolto e agora vese outro. Guía de WatchGuard sobre denegacións de IKEv2 é a referencia para a orde de etapas descrita arriba.