Métodos de monitoramento de VPN

Por que você precisa de verificação de datapath IPsec?

O estado da interface de túnel seguro (st0) no modo ponto a ponto para VPNs baseadas em rota normalmente é baseado no estado do túnel VPN. Após o dispositivo estabelecer a associação de segurança IPsec, o Junos OS adiciona rotas associadas à interface st0 à tabela de encaminhamento. Se sua rede tiver um firewall de trânsito entre os endpoints do túnel VPN, o firewall pode bloquear o tráfego de dados IPsec que usa rotas ativas na interface st0. Como resultado, você pode encontrar perda de tráfego.

Para evitar essa perda de tráfego, você deve habilitar a verificação do datapath IPsec. Quando você habilita este recurso, o dispositivo Junos OS não traz a interface st0 até que ele verifique o datapath. Você pode configurar a verificação de datapath com as seguintes opções:

• Você pode configurar com a declaração [set security ipsec vpn vpn-name vpn-monitor verify-path] para túneis VPN baseados em rota e de site para site.

• Se houver um dispositivo NAT na frente do endpoint do túnel peer, o firewall traduz o endereço IP do endpoint do túnel peer para o endereço IP do dispositivo NAT. Para que a solicitação do ICMP do monitor VPN chegue ao endpoint do túnel de peer, você precisa especificar explicitamente o endereço IP original não traduzido do endpoint do túnel de peer atrás do dispositivo NAT. Você pode configurar isso com a declaração de [set security ipsec vpn vpn-name vpn-monitor verify-path destination-ip] configuração.

• A partir do Junos OS Release 15.1X49-D120, você pode configurar o tamanho do pacote que é usado para verificar um datapath IPsec antes que a interface st0 seja criada. Use a declaração de [set security ipsec vpn vpn-name vpn-monitor verify-path packet-size] configuração. O tamanho do pacote configurável varia de 64 a 1350 bytes; o padrão é de 64 bytes.

Considere os seguintes pontos ao usar a verificação do datapath IPsec:

• A interface de origem e os endereços IP de destino que você configura para a operação de monitoramento de VPN não têm efeito na verificação do datapath IPsec. A fonte para as solicitações de ICMP na verificação de datapath IPsec é o endpoint local do túnel.

• Quando você habilita a verificação do datapath IPsec, o Junos OS ativa automaticamente o monitoramento de VPN somente após o acionamento da interface st0. Recomendamos que você configure a opção no nível de hierarquia quando habilitar a[edit security ipsec vpn vpn-name] verificação do datapath IPsec.vpn-monitor optimized 

• Se um failover de cluster de chassi ocorrer durante a verificação do datapath IPsec, o novo nó ativo inicia a verificação novamente. O Junos OS não ativa a interface st0 até que a verificação seja bem sucedida.

• Para rekeys da associação de segurança IPsec, o Junos OS não realiza a verificação do datapath IPsec, porque o estado da interface st0 não muda para rekeys.

• O Junos OS não oferece suporte à verificação de datapath IPsec em interfaces st0 em um modo ponto a multiponto que são usados com AutoVPN, Auto Discovery VPN (ADVPN) e vários seletores de tráfego.

• O monitoramento de VPN e a verificação de datapath IPsec não oferecem suporte a endereços IPv6. Portanto, você não pode usar a verificação de datapath IPsec com túneis IPv6.

Como funciona a verificação do datapath IPsec?

Quando você configura a verificação do datapath IPsec, ocorrem os seguintes eventos :

1. Após o dispositivo estabelecer o túnel VPN, ele envia uma solicitação de ICMP ao endpoint do túnel de peer para verificar o datapath IPsec. O endpoint do túnel de peer deve ser alcançado por solicitações de ICMP do monitor VPN e deve ser capaz de responder à solicitação do ICMP. Enquanto a verificação do datapath está em andamento, o show security ipsec security-association detailVPN Monitoring campo na saída de comando exibe a letra V.

2. O Junos OS ativa a interface st0 apenas quando recebe uma resposta do peer. A show interface st0.x saída de comando mostra o status da interface st0 durante e após a verificação do datapath: Link-Layer-Down antes que a verificação termine e Up após a verificação terminar com sucesso.

3. Se o peer não enviar uma resposta ICMP, o dispositivo envia outra solicitação de ICMP no intervalo configurado do monitor VPN até atingir o valor limite do monitor VPN configurado. Observe que o intervalo padrão do monitor VPN é de 10 segundos e o valor limite padrão do monitor VPN é de 10 vezes. Se a verificação não for bem sucedida, a entrada de log do KMD_VPN_DOWN_ALARM_USER sistema indica o motivo como um erro de caminho de verificação de monitoramento de VPN. O dispositivo registra um erro em eventos de túnel na show security ipsec security-association detail saída de comando. O show security ipsec tunnel-events-statistics comando exibe o número de vezes que o erro ocorreu. Você pode configurar o intervalo do monitor vpn e o valor de limite do monitor VPN usando a opçãovpn-monitor-options de configuração no nível [edit security ipsec] de hierarquia. 

4. Se o peer não enviar uma resposta ICMP mesmo depois de atingir o valor limite do monitor VPN, on Junos OS derruba o túnel VPN e derruba o túnel VPN.

Como funciona o DPD?

Durante a criação de túneis IPsec, os pares de VPN negociam para decidir se usam ou não o método de detecção de peer (DPD). Se os pares concordarem em usar o método DPD, quando não há tráfego ativo, o protocolo DPD envia mensagens periódicas para o peer e aguarda uma resposta. Se o peer não responder às mensagens, o protocolo DPD assume que o peer não está mais disponível. O comportamento do DPD é o mesmo para protocolos IKEv1 e IKEv2. Os timers DPD estão ativos assim que o IKE estabelece a Associação de Segurança da Fase 1 (SA).

Um firewall da Série SRX usa o protocolo DPD para detectar a vida em uma conexão VPN IPsec.

Figura 1: Troca de mensagens no protocolo DPD

Figura 1 mostra a troca de mensagens DPD entre os pares IKE em um túnel VPN IPsec. Os eventos a seguir ocorrem quando o dispositivo de firewall executa DPD:

1. O SRX-A de firewall aguarda até o intervalo de DPD especificado para verificar se ele recebeu algum tráfego do peer, SRX-B.

2. Se o SRX-A não receber nenhum tráfego do SRX-B durante o intervalo de DPD especificado, ele envia uma carga de notificação IKE Phase 1 criptografada — uma mensagem R-U-THERE — para o SRX-B.

3. O SRX-A aguarda o reconhecimento de DPD — uma mensagem R-U-THERE-ACK — do SRX-B.

   1. Se o SRX-A receber uma mensagem R-U-THERE-ACK do SRX-B durante este intervalo, ele considera o peer vivo. Em seguida, o SRX-A reinicia seu contador de mensagens R-U-THERE para esse túnel e inicia um novo intervalo.

   2. Se o SRX-A não receber uma mensagem R-U-THERE-ACK durante o intervalo, ele considera o peer, SRX-B, desativado. O SRX-A então remove a associação de segurança da Fase 1 e todas as associações de segurança da Fase 2 para esse peer.

Parâmetros de DPD configuráveis

Aqui está uma lista de parâmetros de DPD que você precisará configurar:

• Modo — Com base na atividade de tráfego, você pode configurar o DPD em um dos seguintes modos:

  • Otimizado — No modo otimizado , quando o dispositivo de iniciação envia pacotes de saída para o peer, se não houver tráfego IKE ou IPsec de entrada do peer dentro do intervalo configurado, o dispositivo de iniciação aciona mensagens R-U-THERE. O DPD opera neste modo padrão a menos que você configure outro modo.

  • Sondar túnel ocioso — No modo de túnel ocioso da sonda , o dispositivo aciona mensagens R-U-THERE se não houver tráfego IKE ou IPsec de entrada ou saída em um intervalo configurado. O dispositivo envia mensagens R-U-THERE periodicamente para o peer até que haja atividade de tráfego. Esse modo ajuda na detecção antecipada de um peer que está desativado, garantindo a disponibilidade do túnel durante o fluxo de tráfego ativo.



    Nota:

    Nesse cenário, quando você configura o modo de túnel ocioso da sonda, o dispositivo aciona mensagens R-U-THERE se um túnel ficar ocioso, independentemente do tráfego em outro túnel para a mesma associação de segurança IKE.

  • Sempre enviar — No modo de sempre enviar , o dispositivo envia mensagens R-U-THERE em um intervalo configurado, independentemente da atividade de tráfego entre os pares. Recomendamos que você use o modo de túnel ocioso de sondagem em vez de sempre enviar o modo.

• Intervalo — Use o parâmetro de intervalo para especificar a quantidade de tempo (em segundos) que o dispositivo espera pelo tráfego de seus pares antes de enviar uma mensagem R-U-THERE. O intervalo padrão é de 10 segundos. Começando pelo Junos OS Release 15.1X49-D130, reduzimos o intervalo de parâmetros de intervalo permitido no qual as mensagens R-U-THERE são enviadas ao dispositivo peer de 10 segundos a 60 segundos para 2 segundos a 60 segundos. Recomendamos que você defina o parâmetro limite mínimo para 3, quando o parâmetro de intervalo de DPD for definido para menos de 10 segundos.

• Limiar — Use o parâmetro limiar para especificar o número máximo de vezes que o dispositivo envia a mensagem R-U-THERE sem receber uma resposta do peer antes que ele considere o peer para baixo. O número padrão de transmissões é de cinco, com uma faixa permissível de 1 a 5 retries.

Observe as seguintes considerações antes de configurar o DPD:

• Depois de adicionar a configuração de DPD a um gateway existente com túneis ativos, o dispositivo começa a ativar mensagens R-U-THERE sem limpar as associações de segurança de Fase 1 ou Fase 2.

• Ao excluir a configuração de DPD de um gateway existente com túneis ativos, o dispositivo para de acionar mensagens R-U-THERE para os túneis. Mas isso não afeta a associaçãode segurança IKE e IPsec.

• Quando você modifica parâmetros de configuração de DPD, como os valores de modo, intervalo ou limiar, o IKE atualiza a operação de DPD sem limpar as associaçõesde segurança fase 1 ou Fase 2.

• Se você configurar o gateway IKE com monitoramento de DPD e VPN sem especificar a opção de estabelecer túneis imediatamente, a IKE não inicia a negociação da Fase 1. Ao configurar o DPD, você também deve configurar a opção establish-tunnels immediately no nível [edit services ipsec-vpn] de hierarquia para derrubar a interface st0 quando não houver nenhuma associaçãode segurança de fase 1 e fase 2 disponível. Veja túneis de criação.

• Se você configurar o gateway IKE com vários endereços IP peer e DPD, mas não estabelecer a Fase 1 SA com o primeiro endereço IP peer, o IKE tenta estabelecer com o próximo endereço IP peer. O DPD só está ativo após o IKE estabelecer a associação de segurança da Fase 1. Veja a detecção inigualável.

• Se você configurar o gateway IKE com vários endereços IP peer e DPD, mas a conexão falhar com o endereço IP do peer atual, o IKE libera as associaçõesde segurança de Fase 1 e Fase 2 e o DPD faz um failover para o próximo endereço IP peer. Veja gateway (Security IKE).

• Mais de uma Fase 1 ou AA fase 2 podem existir com os mesmos pares por causa de negociações simultâneas. Neste caso, a DPD envia mensagens R-U-THERE para todas as associaçõesde segurança da Fase 1. Se o gateway não receber respostas DPD pelo número configurado de vezes consecutivas, ele limpará a associação de segurança da Fase 1 e a associação de segurança de Fase 2 associada (apenas para IKEv2).

Se o peer IKE estiver vivo, isso significa que a VPN subjacente está ativa?

Como funciona o monitoramento do túnel VPN?

O monitoramento de VPN usa solicitações de eco (ou pings) do Protocolo de Mensagem de Controle de Internet (ICMP) e dados de assinatura, como iD de túnel, no pacote ICMP para determinar se o túnel VPN está funcionando.

Ao ativar o monitoramento de VPN, o dispositivo envia solicitações de eco do ICMP pelo túnel VPN para o gateway peer ou para um destino especificado na outra extremidade do túnel. O dispositivo envia as solicitações por padrão em intervalos de 10 segundos por até 10 vezes consecutivas. Se o dispositivo não receber nenhuma resposta após 10 pings consecutivos, ele considera a VPN baixa e libera a associação de segurança IPsec.

Use os seguintes modos de operação para monitorar túneis VPN:

• Modo de envio sempre — Neste modo, o dispositivo envia um pacote de monitoramento vpn assim que cada intervalo configurado, independentemente do tráfego no túnel. Depois de habilitar o monitoramento de VPN, o Junos OS usa o modo sempre enviado como o modo padrão se você não especificar um.

• Modo otimizado — Neste modo, o dispositivo envia um pacote de monitoramento vpn uma vez que cada intervalo configurado somente se houver tráfego de saída e sem tráfego de entrada pelo túnel durante o intervalo. Se houver tráfego de entrada pelo túnel VPN, o dispositivo considera o túnel ativo e impede o envio de pings para o peer. Você pode usar o modo otimizado para economizar recursos no dispositivo, pois neste modo o dispositivo envia pings apenas quando precisa para determinar a vida dos pares. O envio de pings também pode ativar links de backup caros que de outra forma não seriam usados.

  O dispositivo opera no modo de envio sempre padrão se você não configurar o modo otimizado explicitamente.