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?
ping
traceroute
DJA
fuente
fuente
Respuestas:
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í .
fuente
tracepath...tracerouteen la mayoría de Linux, que envía datagramas UDP, aunque no estoy seguro de lo que hace la versión de Windows. Los saltos intermedios deben enviar un ICMP TTL EXCEDIDO para cualquier tipo de paquete, no solo ICMP.tracerten Windows 7 envía solicitudes de eco ICMP.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 hacia216.58.220.100, puede suponer que los paquetes con la dirección de destino usarán66.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 ruta216.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
tracertypingque 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 que66.249.95.234se comporten de manera muy diferente dependiendo de si necesita: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.
fuente
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.
fuente