Tracert VPN de site para site

Question

Não sei ao certo como devo ir com essa questão, mas atualmente tenho uma configuração VPN de site para site e estamos tendo problemas importantes de conexão entre os dois sites. Eu fiz um tracert e recebi um resultado estranho:

    Tracing route to 192.168.251.209 over a maximum of 30 hops

  1    <1 ms    <1 ms    <1 ms  10.5.1.254
  2     *        *        *     Request timed out.
  3     *        *        *     Request timed out.
  4   102 ms   101 ms   103 ms  192.168.251.209

Alguém sabe por que a solicitação expirou duas vezes antes de encontrar 192.168.251.209? Temos a VPN site a site há mais de um ano e nunca tivemos nenhum problema. Eu nunca tive uma razão para executar um ping constante para verificar a perda de pacotes antes, mas quando eu fiz hoje a perda de pacotes é de cerca de 13%. Posso fazer ping em outros grupos e sites de VPN (google.com/shop.com) com 0% de perda de pacotes.

    

Answer 1

Saltos não responsivos no meio de um traceroute são perfeitamente razoáveis - significa apenas que o que quer que esteja diminuindo o TTL nesses saltos não quer (ou não pode) mandar de volta um pacote de erros.

Para diagnosticar o problema com a VPN, você precisará fazer capturas de pacotes, mais traceroutes e pings e ter uma ideia muito melhor sobre a arquitetura e os dispositivos envolvidos antes de ter qualquer esperança de rastrear o problema. Se você deseja obter ajuda eficaz aqui, provavelmente precisará obter todas essas informações e, em seguida, colocá-las em uma pergunta aqui de forma adequadamente condensada.

    

Answer 2

Does anyone know why the request timed out twice before finding 192.168.251.209?

É provavelmente um destes:

• Os sistemas entre eles são bloco ICMP ou qualquer protocolo que sua implementação do traceroute esteja usando.
• Os sistemas entre você não têm um caminho direto para responder à sua rede.

Answer 3

Congestionamento, falha no equipamento, problemas de roteamento.

Não sei como uma captura de pacote ajudará. Você verá apenas que muitos pacotes não chegam ao outro lado e estão sendo retransmitidos. Se você não controlar o hardware em todo o túnel, entre em contato com o seu SP para obter ajuda. Se fizer isso, comece a examinar os registros desse equipamento.

Os sistemas não responsivos podem ser sobrecarregados a ponto de não conseguirem responder ao traceroute, pois os pacotes provavelmente seriam direcionados à CPU para serem manipulados.