Posso rastrear para um endereço IP, mas não o ping

No Windows, se eu rastrear para o Google, recebo o seguinte;

C:\Users\Dave>tracert -d -w 100 www.google.com

Tracing route to www.google.com [216.58.220.100]
over a maximum of 30 hops:

  1    <1 ms    <1 ms    <1 ms  192.168.1.1
  2    17 ms     *       16 ms  [redacted]
  3    17 ms    16 ms    17 ms  [redacted]
  4    34 ms    34 ms    34 ms  150.101.33.18
  5    35 ms    43 ms    33 ms  72.14.221.174
  6    33 ms    33 ms    33 ms  66.249.95.234
  7    31 ms    31 ms    31 ms  209.85.142.11
  8    33 ms    33 ms    38 ms  216.58.220.100

Trace complete.

Agora, se eu executar ping no terceiro último endereço IP de 66.249.95.234, obtive este ...

C:\Users\Dave>ping 66.249.95.234

Pinging 66.249.95.234 with 32 bytes of data:
Request timed out.
Request timed out.
Request timed out.
Request timed out.

Ping statistics for 66.249.95.234:
    Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),

Como é que o 'ping' interno a rastrear funciona de alguma maneira diferente do ping real? Como eles são diferentes? O que preciso fazer para que o ping funcione como o tracert?

Tudo tem a ver com o funcionamento do tracert. O ping é um ICMP direto do ponto A ao ponto B, que atravessa redes por meio de regras de roteamento. O Tracert funciona de maneira muito diferente, apesar de usar o ICMP.

O Tracert trabalha visando o salto final, mas limitando o TTL e aguardando um tempo excedido na mensagem e, em seguida, aumentando-o em um para a próxima iteração. Portanto, a resposta que obtém não é uma resposta de eco do ICMP à solicitação de eco do ICMP do host ao longo do caminho, mas uma mensagem de tempo excedido desse host - portanto, embora esteja usando o ICMP, está usando de uma maneira muito diferente. .

Você pode ler mais detalhes sobre isso aqui .

Primeiro de tudo, seus dois comandos estão enviando pacotes com endereços IP de destino diferentes. Isso significa que eles podem seguir rotas diferentes.

Quando você vir 66.249.95.234a rota 216.58.220.100, poderá presumir que os pacotes com o endereço de destino 66.249.95.234usariam a mesma rota até chegar a esse ponto. No entanto, essa não é uma suposição válida.

É totalmente válido que a rota 66.249.95.234seja mais longa que a rota 216.58.220.100. Às vezes, acontece que não existe uma rota que possa levar seus pacotes para esse roteador intermediário, mas não seria uma rede bem projetada, se fosse esse o caso.

Não sei se os comandos tracerte que pingvocê está usando usam o mesmo protocolo. A maioria das implementações de ping usa pacotes de solicitação de eco ICMP. No entanto, existem implementações de traceroute que suportam uma ampla variedade de protocolos, incluindo solicitação de eco ICMP, pacotes TCP SYN e UDP. Se os dois estiverem usando protocolos diferentes, isso pode ser um fator que contribui para a obtenção de resultados diferentes.

Finalmente, mesmo que todos os pacotes cheguem 66.249.95.234, é possível que 66.249.95.234se comportem de maneira totalmente diferente, dependendo se é necessário:

• Encaminhar o pacote
• Produzir um erro ICMP em um pacote endereçado a si próprio
• Produzir um erro ICMP em um pacote endereçado a outra pessoa

Optar por descartar pacotes silenciosamente em apenas um dos três casos obviamente quebrará muitas ferramentas de diagnóstico de rede, o que, no entanto, não impede que alguns administradores de sistema o façam de qualquer maneira.

Como a segurança na rede tem aumentado constantemente, uma coisa fácil que muitas pessoas fazem agora é basicamente desativar os aspectos do protocolo ICMP. Isso evita responder a traceroutes e retornar o FQDN do salto. Às vezes, os administradores bloqueiam muito as coisas, mesmo que um ping não funcione. Esta é uma decisão do administrador do sistema envolvido.

Também existe a possibilidade de o sistema estar lidando com uma carga de rede extensa; o ICMP geralmente tem uma prioridade muito baixa no processamento em comparação com dados reais.