IPsec sobre uma WAN privada: limites de política no SRX a verificar

Uma WAN privada pode transportar os pacotes externos de um túnel IPsec, pelo que os endereços do par não têm de ser endereços públicos de internet. O que muda é o caminho que esses pacotes externos percorrem e as permissões na interface que os recebe. Num SRX, o caminho de controlo externo, a ligação da interface de túnel e a política de tráfego reencaminhado são três objetos separados. Diagnosticar um enquanto os outros dois estão errados é a razão habitual para um túnel ficar em baixo.

Registe primeiro o caminho IKE externo

Anote quatro valores antes de tocar na política: o endereço do par, a interface local que recebe IKE, o contexto de encaminhamento que chega ao par e a rota que seleciona essa interface. Os pacotes IKE são endereçados ao próprio SRX, pelo que precisam de permissão host-inbound na zona de receção, não de uma política de tráfego reencaminhado. Um endereço WAN privado não elimina esse requisito, porque o pacote continua a terminar no equipamento.

Verifique o estado instalado com show security ike sa e a configuração com show configuration security ike. A primeira indica se a fase 1 existe; a segunda indica o que o equipamento pensa que deveria fazer.

Ligue a interface de túnel à política correta

Uma VPN baseada em rotas liga uma interface de túnel a um objeto VPN, e os prefixos protegidos são encaminhados para essa interface. Registe qual interface, qual rota e qual política permitem as aplicações entre as zonas relevantes. Uma zona chamada trust é um contentor de políticas, e o nome não prova que os pacotes de controlo ou de dados necessários estejam permitidos.

Leia as ligações reais em vez de um diagrama antigo: show configuration security ipsec vpn para a definição de ligação à interface e show configuration security policies para as regras que referenciam a zona do túnel.

Se a rota protegida apontar para outro lugar, o túnel pode estar ativo enquanto o tráfego nunca entra nele. É um problema de encaminhamento disfarçado de IPsec.

Mantenha a rota do par no underlay

A rota para o par externo tem de ser resolvida através do underlay, não de forma recursiva através do túnel que estabelece. Se a rota do par apontar para a interface de túnel, os pacotes IKE perseguem o seu próprio túnel e a fase 1 nunca fica concluída. O caminho de resposta para o tráfego protegido precisa da sua própria rota e política corretas, e é normalmente a metade em falta quando uma direção funciona. Leia a entrada da tabela de rotas para o endereço do par e confirme que a interface de saída é a interface WAN.

Verifique-o com show route 198.51.100.10, substituindo o endereço real do par, e confirme que o salto seguinte não é uma interface de túnel.

Verifique controlo e serviço por ordem

Avance de baixo para cima: estado da fase 1, estado da fase 2 e depois um fluxo real de aplicação. show security ipsec sa lista as associações de segurança, e show security flow session destination-prefix 10.60.0.0/16 mostra se estão a ser criadas sessões reencaminhadas para a rede protegida.

Uma relação de controlo saudável e um caminho de dados funcional são dois resultados diferentes, e passar a fase 2 não diz nada sobre se a política permite a aplicação. Teste um fluxo permitido e outro que a política deveria rejeitar, para que a diferença seja visível.

Registe em conjunto a rota do par, a permissão host-inbound, a ligação do túnel, a rota interna e a política da aplicação. Esses cinco registos mostram que camada é responsável por uma falha futura sem depender da etiqueta de uma porta.