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

Question

No Windows, se eu traçar 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 pingar o terceiro último endereço IP de 66.249.95.234, obtenho 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 ao tracert funciona de alguma maneira diferente do ping real? Como eles são diferentes? O que eu preciso fazer para fazer o ping funcionar como tracert?

    

Answer 1

Tudo tem a ver com o funcionamento do tracert. Ping é o ICMP direto do ponto A para o ponto B, que atravessa as redes através das regras de roteamento. Tracert funciona muito diferente, apesar de usar o ICMP.

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

Você pode ler mais detalhes sobre aqui .

    

Answer 2

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

Quando você vir 66.249.95.234 na rota em direção a 216.58.220.100 , você pode assumir que os pacotes com o endereço de destino 66.249.95.234 usariam a mesma rota até chegar a esse ponto. Isso, no entanto, não é uma suposição válida.

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

Não sei se os comandos tracert e ping que você 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 gama 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 ver resultados diferentes.

Por fim, mesmo que todos os pacotes atinjam 66.249.95.234 , é possível que 66.249.95.234 se comporte de maneira totalmente diferente, dependendo da necessidade de:

• Encaminhar o pacote
• Produza um erro ICMP em um pacote endereçado a si mesmo
• Produza um erro ICMP em um pacote endereçado a outra pessoa

A escolha de descartar os pacotes silenciosamente em apenas um dos três casos obviamente vai quebrar muitas ferramentas de diagnóstico de rede, o que, no entanto, não impede que alguns administradores de sistema o façam.

    

Answer 3

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

Há também a possibilidade de que o sistema esteja lidando com uma carga de rede extensiva, o ICMP é geralmente muito baixo em prioridade ao ser processado em comparação com dados reais.