Recusa de geolocalização do Firebox: encontre primeiro o estágio de entrada VPN

Alguém noutro país não consegue ligar-se, e o primeiro instinto é olhar para a regra que concede acesso aos recursos internos. Essa regra é executada depois da admissão, por isso não pode ser o que rejeita o túnel. O estágio que bloqueia está algures no caminho de entrada, e o Firebox tem mais de um caminho de entrada conforme o serviço VPN. Faça as verificações por ordem e pare assim que uma delas explicar a recusa.

Verificação 1: nomeie o serviço de entrada

Para Mobile VPN com SSL, Access Portal e BOVPN sobre TLS, a entrada de entrada é a política WatchGuard SSLVPN. Aplique aí a restrição pretendida, no serviço realmente configurado, em vez de a deduzir de uma regra de acesso de utilizador que corre mais tarde.

O IPsec segue outro caminho. A política IPSec integrada permite o tráfego IPsec externo para o Firebox nos serviços de filial e VPN móvel aplicáveis, e tem precedência sobre uma política IPSec criada manualmente. Se o seu cliente for IKEv2, está nesse segundo caminho, e a política SSLVPN é irrelevante.

Errar isto é a tarde mais frequentemente desperdiçada nesta área: editar uma política que nunca vê o pacote e depois concluir que a restrição não funciona.

Verificação 2: leia a recusa, não a teoria

Faça uma tentativa permitida e controlada e correlacione quatro coisas: o endereço de origem público do cliente, o serviço de entrada alcançado, a política que coincidiu e qualquer motivo de recusa no registo. O guia de resolução de problemas de IKEv2 da WatchGuard observa que a geolocalização e o tratamento predefinido de pacotes podem recusar tráfego antes da admissão da política integrada, o que significa que a recusa que vê pode nomear um estágio que não considerou.

A classificação do país segue a origem de rede observada. Um utilizador em roaming, um NAT a montante ou um caminho aprovado diferente podem alterar o que o Firebox vê, por isso confirme o endereço e não a descrição do utilizador sobre onde está. Peça o endereço público que o cliente vê e compare-o com a origem no registo do Firebox. Quando diferem, a classificação segue um caminho que ninguém mencionou.

Verificação 3: a política integrada ainda é a proprietária?

Se uma política IPSec manual parecer ignorada, verifique se a integrada ainda está ativa. Uma regra manual tapada por uma regra integrada de maior prioridade e uma regra manual que é a única admissão são configurações diferentes com uma interface de aspeto idêntico.

Decida qual deve possuir o caminho. Se for a política manual, a integrada tem de ser desativada para esse tráfego, e é aí que começa a verificação seguinte.

Verificação 4: planeie a substituição antes de desativar

Desativar a política IPSec integrada remove a sua admissão para os serviços VPN afetados. Isso inclui túneis de filial em que talvez não pense enquanto corrige a ligação de um utilizador móvel.

Planeie primeiro a substituição completa: que serviços precisam de admissão, que âmbitos de origem recebem e como vai gerir o equipamento se a alteração correr mal. Mantenha aberto um caminho de gestão e recuperação independente, porque um erro aqui pode remover o túnel que usaria para o corrigir. Anote os passos de recuperação no registo de alterações, incluindo como chegar ao equipamento se o caminho VPN desapareceu. Depois teste a renovação, não apenas a primeira ligação.

A conectividade ativa e a renegociação posterior podem ambas depender da admissão. Uma alteração que funciona para a sessão testada e falha na troca de chave seguinte é um resultado clássico de substituir a admissão sem testar a renovação.

Verificação 5: mantenha a identidade separada da localização

A geolocalização acrescenta contexto a uma decisão de entrada. Não estabelece quem é o utilizador e não deve substituir as verificações de identidade da gateway, a autorização da conta ou o MFA.

Se o requisito de negócio for apenas utilizadores aprovados de locais aprovados, precisa dos dois controlos. Uma regra de localização que admite um país inteiro não substitui a autenticação, e um utilizador autenticado num país bloqueado é uma questão de política, não um erro.

Verificação 6: registe-o e verifique os dois caminhos

Anote o serviço, a política de entrada, o âmbito de localização pretendido, as exceções e o responsável pela recuperação. Depois teste o caminho móvel e pelo menos um caminho de site após a alteração, para que a restrição continue ligada ao serviço para o qual foi concebida.

Por fim, releia a recusa com que começou. Se passou de uma recusa de localização para uma falha de autenticação ou autorização, o problema de entrada está resolvido e agora vê-se outro. Guia da WatchGuard sobre recusas de IKEv2 é a referência para a ordem de estágios descrita acima.