Visão Geral
A conectividade é fundamental para o acesso à WAN via nuvem Cato para redes por trás de um IPsec. A falta de conectividade de um site IPsec pode interromper funções empresariais. Este manual busca guiar a solução de problemas neste cenário.
Sintomas
A falha na conectividade do IPsec pode ser determinada das seguintes maneiras. Um administrador pode notar os seguintes sintomas:
-
Site IPsec está desconectado no CMA
- Histórico de instabilidade na conexão
- Desempenho ruim para o tráfego que atravessa a conexão IPsec
Causas Possíveis
As seguintes são possíveis causas que você pode identificar enquanto soluciona problemas.
- Conectividade do Par
- Isso inclui a capacidade dos pares de alcançarem consistentemente uns aos outros sobre L3.
- Incompatibilidade de configuração IPsec
- Conjuntos de transformação ou incompatibilidades de autenticação podem fazer com que túneis não se formem ou falhem antes que uma nova chave possa ser concluída
- Desempenho do Underlay
- IPsec depende de uma conexão underlay estável para um desempenho satisfatório dentro do túnel.
Nota: Para contas com sites IPsec, se os IPs externos de uma regra RPF sobrepõem-se aos endereços IP de um site IPsec, assegure-se de que a regra exclua as portas de túneis IPsec UDP/500 e UDP/4500.
Solução de Problemas
As etapas para solucionar os sintomas que um Administrador pode encontrar estão listadas abaixo. Essas etapas têm o objetivo de identificar possíveis causas para os problemas enfrentados. As etapas de resolução serão destacadas mais adiante no manual.
Solução de Problemas de Site IPSec Desconectado ou Instável no CMA
Recolhendo Informações de Eventos
Usando a Página Inicial > página de Eventos no CMA, um administrador pode rapidamente obter um histórico de eventos de conectividade para sites IPsec dentro de uma conta. Os eventos podem ser filtrados nos eventos relevantes selecionando o preset 'Status de Conectividade do Site' ou filtrando pelo Tipo de Evento 'Conectividade' e Sub-tipo 'Desconectado'. Você pode ainda filtrar pelo Nome do Site em questão com o campo 'Site de Origem' ou então usar o valor do protocolo do túnel 'IPSEC' para filtrar todos os sites IPsec.
Visualizar o carimbo de data/hora do evento de desconexão relevante do site em questão pode ajudar a focar a investigação. Houve algum evento de rede mais amplo ou evento de energia local conhecido que ocorreu neste carimbo de data/hora? Existe alguma mudança na trilha de auditoria anterior a isso que possa estar correlacionada?
Se nenhum evento de desconexão for encontrado e o túnel ainda for reportado como instável, é possível que o problema ocorra no momento de um processo de nova chave devido a parâmetros incompatíveis entre o Cato e o par remoto. Continue com as etapas abaixo para uma análise mais detalhada.
Visualizando o Histórico de Conexão IPsec do Site
A linha do tempo disponível em Rede > Site > Configurações do Site > IPsec é essencial para solucionar problemas de sites IPsec desconectados.
O CSV fornecido pelo botão Linha do Tempo fornecerá um histórico dos logs de túneis relevantes. Esses logs podem fornecer indicações claras dos problemas que podem estar causando a falta de conectividade na conexão IPsec. Exemplos comuns de mensagens indicativas estão abaixo:
Mensagens que sugerem que os seletores de tráfego não correspondem são evidências de uma incompatibilidade de configuração entre as definições de fase 2 dos pares, especificamente em relação às sub-redes que estarão disponíveis em cada lado do emparelhamento IPsec. Se você vir erros sugerindo que este é o caso, navegue para Resolvendo incompatibilidade de configuração do IPsec.
As mensagens acima também indicam uma incompatibilidade de configuração, desta vez com as cargas de autenticação. Claro, a Chave Pré-Compartilhada (PSK) precisa corresponder a essas cargas para que a conexão seja bem-sucedida. Se isso for evidente em qualquer tentativa de conexão, navegue para Resolvendo incompatibilidade de configuração do IPsec.
A linha do tempo acima exibe uma tentativa de conexão com um par configurado, que não recebeu resposta. Pode-se ver nesta linha do tempo que nenhuma interação com o par ocorreu, e o SA foi fechado devido à inatividade. Este é tipicamente o caso quando não há alcance L3 ao par remoto. Nesses casos, consulte o Resolvendo a Conectividade do Par.
Uma lista completa de possíveis mensagens de erro de linha do tempo para IKEv1 e IKEv2 pode ser encontrada aqui.
Usando Capturas de Pacotes para Solucionar Problemas
Além disso, na página Rede > Site > Configuração do Site > IPsec está a ferramenta de captura de pacotes. Isto ajudará a fornecer rastreamentos de pacotes do tráfego de controle entre os pares. Os problemas destacados acima também estão representados nessas capturas de pacotes.
TS_UNACCEPTABLE
Para sub-redes não correspondentes em um conjunto de transformação, pacotes informativos indicarão um erro. Neste exemplo de IKEv2, a mensagem informativa TS_UNACCEPTABLE é sintomática de uma discrepância na configuração dentro do conjunto de transformações. Para corrigir este problema, navegue para Resolvendo discrepância de configuração IPsec.
NO_PROPOSAL_CHOSEN
Para parâmetros incompatíveis dentro da associação de segurança, qualquer par incluirá um erro dentro do payload. Neste exemplo do IKEv2, o erro NO-PROPOSAL-CHOSEN indica claramente que um dos Algoritmos de Criptografia ou Grupos DH configurados no CMA não corresponde à configuração do par remoto. Isso pode ocorrer durante o estabelecimento inicial do túnel ou o processo de renovação da chave.
AUTHENTICATION_FAILED
A captura abaixo mostra outro exemplo de IKEv2, desta vez um em que a PSK usada para autenticação não correspondeu:
Pacotes Unidirecionais
Capturas de pacotes também podem ajudar a identificar problemas de conectividade no nível IP com pares. No exemplo abaixo, a captura de pacotes mostra apenas tráfego unidirecional de saída, sugerindo que o par é inacessível. Se um Administrador de solução de problemas vê um par inacessível, navegue para Resolvendo Conectividade de Pares.
Em qualquer uma das instâncias acima ou outros indicadores de incompatibilidade de configuração entre pares em IKEv1 ou IKEv2, navegue para Resolvendo incompatibilidade de configuração IPsec.
Solução de problemas de desempenho ruim sobre VPN
Se for observada uma fraca performance sobre a VPN, isso tipicamente assume a forma de Perda de Pacotes, alta Latência ou desconexões frequentes.
A Perda de Pacotes será vista no tráfego passando pelo túnel através das Aplicações que está impactando e pode ser confirmada com um teste de sondas ICMP de um host para outro via Conexão IPsec.
A latência e as desconexões do túnel também serão evidentes no desempenho das Aplicações e também podem ser determinadas através da página de Rede > Monitoramento do Site > Análise de Rede para o site em questão.
Se forem identificados problemas de desempenho, navegue para Resolvendo Desempenho do Subjacente.
Descarte de Pacotes no Azure IPSec
Ao configurar o IPSec com o Azure, a vazão do túnel e os pacotes por segundo (PPS) são determinados pelo SKU do Gateway VPN e os Algoritmos de Criptografia empregados. Por exemplo, de acordo com a documentação da Microsoft, o gateway VpnGw3 Generation2, ao usar GCMAES256, pode lidar com até 140.000 pacotes por segundo (PPS).
Se o tráfego exceder esses Limites, o Azure irá automaticamente descartar os pacotes excedentes, o que pode causar uma degradação notável de desempenho. Um sintoma comum é uma redução no throughput, que pode aparecer na Análise de Rede da CMA como uma queda no Volume de Tráfego. No entanto, uma maneira mais precisa de diagnosticar isso é monitorando diretamente as métricas do Gateway VPN no portal do Azure, que fornece informações em tempo real sobre a vazão do túnel e os valores de PPS para a conexão VPN afetada.
Para mitigar este problema, você pode considerar atualizar para um SKU de IPSec mais alto ou implementar um Azure vSocket, ambos podem aumentar a capacidade do seu túnel VPN e prevenir descartes de pacotes devido à sobrecarga de tráfego.
Resolvendo Problemas Descobertos
Resolvendo Conectividade de Pares
Para cenários em que o par do IPsec não está enviando pacotes para o PoP, mostrado através de entradas de Linha do Tempo ou capturas de pacotes, certifique-se de que o par remoto está configurado para se conectar ao mesmo Endereço IP que foi alocado para o túnel no CMA.
Se esta configuração for confirmada, garanta que o par remoto possa atravessar conexões limitadas por NAT respondendo ao tráfego na porta 4500 assim como na porta 500. O NAT-T (Traversal NAT) deve estar habilitado no par remoto.
Se o dispositivo do par remoto estiver configurado para responder a solicitações ICMP pela internet, você também pode testar sua Geral acessibilidade testando solicitações ICMP para o IP Público do dispositivo.
Verifique se há mudanças recentes no status da página de saúde - Se o PoP estiver enfrentando problemas, isso pode afetar o túnel IPsec (cada túnel está conectado a um Localização do PoP Cato). Você pode Monitorar a Saúde PoP no página de status.
Se o par remoto for um fornecedor de nuvem como Azure ou AWS, você também pode verificar o Status páginas deles.
Se o dispositivo de par ainda estiver inacessível para esta Conexão IPsec, entre em contato com o Administrador para garantir que esteja publicamente acessível para Conexões IPsec.
Resolvendo incompatibilidade de configuração IPsec
Certifique-se de que a configuração do par para o conjunto de transformações corresponda à configuração na página Site > IPsec.
Para configurar a parte Cato do emparelhamento para corresponder a um transform set específico do par, Editar configuração conforme descrito na documentação vinculada para IKEv1 e IKEv2.
Os intervalos de IP (seletores) em ambos os lados do túnel devem corresponder. No CMA, certifique-se de que os intervalos de IP estejam configurados como segue:
- Intervalos de IP Locais (Lado do Par): Navegue para Configurações do Site > Redes e defina as sub-redes localizadas atrás do par IPsec (por exemplo, firewall ou roteador).
- Intervalos de IP Remotos (Lado Cato): Navegue para Configurações do Site > IPSec > Roteamento e defina os intervalos de IP locais permitidos para atravessar o túnel (tipicamente redes de outros sites). Se este campo não estiver configurado, o túnel é considerado uma VPN baseada em rota com seletores implícitos 0.0.0.0 <> 0.0.0.0.
Alguns fornecedores exigem que todas as Sub-redes incluídas no transform set sejam incluídas em apenas uma única mensagem de transform set. Se este for o caso para um par, um Administrador deve utilizar a opção de Configuração Avançada 'IKEv2 Enviar TS Único por payload' em Site > Configuração Avançada.
Resolvendo Desempenho do Subjacente
O foco para resolver o desempenho do subjacente é isolar o desempenho contra o par remoto.
Teste a capacidade do par remoto de efetuar ping em servidores web públicos como 8.8.8.8. Se o atraso ou perda de pacotes for consistente com o do túnel, pode-se concluir que o problema existe dentro do ambiente do par remoto.
Levantando casos para Suporte Cato
Envie um Ticket de Suporte com os Resultados das etapas de solução de problemas acima. Por favor, inclua as seguintes informações no ticket:
- Entradas relevantes da Linha do tempo com carimbos de tempo
- Capturas de pacotes relevantes
- Confirmação de conjuntos de transformação correspondentes, incluindo associações de sub-rede e parâmetros de autenticação/Criptografia
0 comentário
Por favor, entre para comentar.