Puedo tracertar a una dirección IP, pero no hacer ping

En Windows, si llego a Google, obtengo lo siguiente;

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.

Ahora, si hago ping a la tercera última dirección IP de 66.249.95.234, obtengo esto ...

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),

¿Cómo es que el 'ping' interno para tracert de alguna manera funciona de manera diferente al del ping real? ¿En qué se diferencian? ¿Qué debo hacer para que el ping funcione como tracert?

Todo tiene que ver con el funcionamiento de tracert. Ping es ICMP directo desde el punto A al punto B, que atraviesa las redes a través de reglas de enrutamiento. Tracert funciona de manera muy diferente, aunque utiliza ICMP.

Tracert funciona apuntando al salto final, pero limitando el TTL y esperando un mensaje de tiempo excedido, y luego incrementándolo en uno para la próxima iteración. Por lo tanto, la respuesta que obtiene no es una respuesta de eco ICMP a la solicitud de eco ICMP del host en el camino, sino un mensaje de tiempo excedido de ese host, por lo que a pesar de que está utilizando ICMP, lo está utilizando de una manera muy diferente .

Puedes leer más detalles al respecto aquí .

En primer lugar, sus dos comandos están enviando paquetes con diferentes direcciones IP de destino. Eso significa que pueden tomar diferentes rutas.

Cuando vea 66.249.95.234en la ruta hacia 216.58.220.100, puede suponer que los paquetes con la dirección de destino usarán 66.249.95.234la misma ruta hasta llegar a ese punto. Sin embargo, esa no es una suposición válida.

Es completamente válido que la ruta 66.249.95.234sea ​​más larga que la ruta 216.58.220.100. A veces incluso sucede que no hay una ruta que pueda llevar sus paquetes a ese enrutador intermedio, pero no sería una red bien diseñada, si ese fuera el caso.

No sé si los comandos tracerty pingque está utilizando ambos usan el mismo protocolo. La mayoría de las implementaciones de ping utilizan paquetes de solicitud de eco ICMP. Sin embargo, existen implementaciones de traceroute que admiten una amplia gama de protocolos, incluida la solicitud de eco ICMP, TCP SYN y paquetes UDP. Si los dos usan protocolos diferentes, eso podría ser un factor que contribuya a ver resultados diferentes.

Finalmente, incluso si todos los paquetes llegaran 66.249.95.234, es posible que 66.249.95.234se comporten de manera muy diferente dependiendo de si necesita:

• Reenviar el paquete
• Producir un error ICMP en un paquete dirigido a sí mismo
• Producir un error ICMP en un paquete dirigido a otra persona.

Elegir soltar paquetes silenciosamente en solo uno de los tres casos obviamente va a romper muchas herramientas de diagnóstico de red, lo que sin embargo no impide que algunos administradores de sistemas lo hagan de todos modos.

Como la seguridad en la red ha aumentado constantemente, una cosa fácil que muchas personas hacen ahora es básicamente deshabilitar aspectos del protocolo ICMP. Esto evita responder a traceroutes y devolver el FQDN desde el salto. A veces, los administradores bloquean las cosas, incluso si un ping no funciona. Esta es una decisión del administrador del sistema involucrado.

También existe la posibilidad de que el sistema maneje una carga de red extensa, por lo general, ICMP tiene una prioridad muy baja en el procesamiento en comparación con los datos reales.