O ping a partir do gateway IPsec usa outro endereço de origem

Faça ping ao lado remoto a partir do gateway IPsec, não receba resposta e conclua que o túnel está quebrado, enquanto cada carga de trabalho atrás do gateway cursa tráfego normalmente. Os dois resultados não se contradizem. Um ping iniciado no gateway é um pacote com origem local, e o gateway escolhe um endereço de origem da sua própria tabela de rotas. Essa escolha pode diferir dos endereços que o tráfego real do site usa, o que muda qual política corresponde e qual rota de volta se aplica. Decida o que o teste deve provar antes de ler qualquer coisa no resultado.

Três perguntas diferentes que um ping pode responder

A primeira pergunta é se o extremo remoto é acessível, sequer, a partir deste host. A segunda é se os seletores do túnel ou a política baseada em rotas admitem tráfego de uma origem específica. A terceira é se o tráfego encaminhado de uma carga de trabalho atrás do gateway funciona de ponta a ponta. Um comando não pode responder às três, e o endereço de origem é o que as separa.

Escolha primeiro a pergunta. Caso contrário, um ping falhado torna-se prova da teoria que você já tinha.

Por que o gateway escolhe um endereço que você não esperava

Quando você faz ping a um destino, a pilha local escolhe uma origem da rota que corresponde a ele. Num túnel baseado em rotas isso pode ser o endereço de enlace da interface do túnel, que em muitos projetos de site é um par 169.254.x.x escolhido para o salto ponto a ponto. Esses endereços existem para fazer a ligação funcionar; não são anunciados como redes de origem de aplicações no lado remoto.

Assim, o extremo remoto pode receber um pedido de eco de um endereço para o qual não tem rota de volta, ou de um que nenhum seletor corresponde. O túnel pode estar são e o ping falhar mesmo assim, e é exatamente esse o falso negativo de que trata este artigo.

Escolha a origem deliberadamente

Num gateway Linux controlado, escolha uma origem que já esteja atribuída localmente: ping -c 4 -I 10.30.0.1 10.40.0.20. Os endereços aqui são ilustrativos, então substitua pelo endereço interno real do gateway e por um destino remoto real, e confirme que a origem escolhida pertence a este dispositivo e é admitida pela política do site.

Não peça emprestado o endereço de uma carga de trabalho para o teste. Fingir ser um host que não está atribuído ao gateway cria um resultado que ninguém consegue reproduzir, e em algumas pilhas falha de formas que parecem uma falha do túnel.

Leia o caminho de volta, não apenas o pedido

Verifique qual origem chega realmente ao destino remoto, incluindo qualquer tradução deliberada pelo caminho. Depois verifique a rota de volta do lado remoto para essa origem e os seletores ou a política que a permitem. Um pedido que chega com uma origem inesperada é uma questão de encaminhamento e política, não de criptografia.

Aqui também uma captura ajuda mais do que outro ping: mostra a origem que o extremo remoto viu, e é o endereço que a resposta dele tem de alcançar.

Depois teste a carga de trabalho

O teste decisivo é um ping de um host comum atrás do gateway para um host comum atrás do gateway remoto. Isso exercita o papel de encaminhamento do gateway, a origem real da aplicação e o caminho de volta verdadeiro, que é o fluxo com que os utilizadores se importam.

Mantenha os resultados separados nas suas notas: acessibilidade a partir do gateway, admissão pela política para uma origem escolhida e tráfego encaminhado. Um ping fixado com sucesso é prova útil de que o túnel transporta algo; não é prova de que todos os fluxos encaminhados funcionam. E uma origem de gateway escolhida automaticamente que não é alcançável não é prova de que o túnel do site está em baixo.

Não acrescente uma rota geral para 169.254.0.0/16 só para obter uma resposta de diagnóstico. Isso troca um teste enganador por uma decisão de encaminhamento permanente, e a pessoa seguinte herda-a sem o contexto.