traceroute no imprime la ruta completa a veces

Supervisando mi red, me di cuenta hace algún tiempo de que traceroute solía imprimir rutas más completas de lo que está haciendo ahora ... y, ahora mismo, a veces traceroute omite algunos dispositivos.

Por ejemplo, esta es una ruta de seguimiento más completa, incluida mi puerta de enlace:

$ sudo traceroute -F xxx.xx.136.5

traceroute to xxx.xx.136.5 (xxx.xx.136.5), 30 hops max, 60 byte packets

 1  * * *

 2  192.168.1.1 (192.168.1.1)  1.607 ms  1.604 ms  1.627 ms

 3  xxx.xx.136.5 (xxx.xx.136.5)  3.286 ms  5.729 ms  7.416 ms

Ahora, exactamente el mismo comando omite mi puerta de enlace:

$ sudo traceroute -F xxx.xx.136.5

traceroute to xxx.xx.136.5 (xxx.xx.136.5), 30 hops max, 60 byte packets

1  xxx.xx.136.5 (xxx.xx.136.5)  24.004 ms  28.267 ms  42.343 ms

Estos comandos se dieron en la misma máquina.

¿Cómo puedo configurar para tener siempre la ruta completa?

Cualquier forma de traceroute funciona incrementando el TTL de un paquete IP en uno. El primer paquete tiene un TTL de uno y el enrutador 1 disminuye el temporizador y envía un mensaje de error a través de ICMP (Tiempo de vida excedido). Traceroute estándar * NIX usa UDP, Windows tracert ICMP, también hay versiones que usan TCP.

Hay diferentes casos por los que no ves un salto:

• La gente piensa que ICMP es malo y lo bloquea. Esto conducirá a muchos problemas (por ejemplo, descubrimiento de PMTU).
• La gente solo piensa en ventanas y bloquea UDP. Intenta correr traceroute -Icon el truco.
• también puede intentar usar tcptraceroute
• Si un enrutador está ocupado enrutando paquetes, no tengo los recursos para enviar paquetes ICMP.

Prefiero usar tcptraceroutepara un mejor detalle del enrutamiento de salto a salto.

tcptracerouteesencialmente pasa por alto la mayoría del firewall protector que ignora los paquetes ICMP que utiliza traceroute. Use el puerto 80 o 53.

Si su puerta de enlace tiene una opción de registro, actívela. Puede encontrar una entrada que explique el comportamiento observado. Un enrutador puede interpretar ICMP repetido como DOS.

... aunque, intuitivamente, uno podría esperar que la fuente esté en la red externa.

He descubierto lo que realmente pasa con traceroute (y mtr, tpctraceroute, etc.) en mi intranet. Es mi propio enrutador que esconde los saltos conocidos. Mi enrutador (como TP-Link WAP, con Linux 2.6.15) usa para ocultar los saltos a rutas conocidas. Entonces, vg, al dar traceroute en google, generará solo un salto, el propio google, porque mi enrutador conoce muy bien la ruta (permanezco todo el día usando google). Pero, solo conectando una PC directamente en el punto de acceso, luego dando traceroute hacia google, devuelve toda la ruta desde aquí a google.

Entonces, ahora sé lo que está sucediendo, pero no por qué lo hace de esta manera.

Como solución alternativa, utilizo el tracerout proporcionado por el Linux incorporado que se ejecuta en el enrutador (problemático): es decir, el enrutador que, a través de mi PC, oculta los saltos, en su propio sistema integrado proporciona una interfaz que ejecuta el tracerout correctamente ...

Lo que sea, gracias por la respuesta!

Al implementar un nuevo host, noté que la ruta de seguimiento solo mostraría la dirección de la puerta de enlace local, la dirección en la LAN del host, pero todos los demás saltos se mostraban como * 's.

Cuando ejecuté TCPDUMP en el mismo host mientras hacía la ruta de seguimiento, pude ver que el ICMP TTL excedía los mensajes generados por los nodos en la ruta, pero TRACEROUTE simplemente no mostraba las direcciones IP ... solo más * 's.

El host tenía dos interfaces de red, la interfaz A, que tenía una ruta predeterminada configurada, y la interfaz B, que tenía una ruta estática hacia el destino. Era la interfaz B en la que estaba ejecutando la ruta de rastreo que solo mostraba * 's.

Para tratar de resolver el problema, agregué otra ruta estática al segundo salto, el siguiente enrutador en la ruta, para poder trabajar en una ruta mucho más corta. Cuando comencé la prueba por primera vez, el segundo salto solo se mostró como *, pero tan pronto como agregué una ruta estática a la ruta de seguimiento de la red, se mostró su dirección IP.

Hice una ruta de seguimiento al destino final nuevamente y noté que todas las direcciones IP que generaban ICMP TTL excedieron los mensajes para poder asegurarme de que el enrutamiento de la interfaz B tenía todas estas redes configuradas estáticamente. Cuando hice esto, ahora podía ver todas las IP enumeradas en el resultado de las rutas de rastreo.

Por lo tanto, parece que si la interfaz que recibe los mensajes de ICMP TTL excedido no tiene enrutamiento de regreso a esa dirección, entonces no se muestra en los resultados de la ruta de seguimiento. Estoy seguro de que alguien en la comunidad puede explicar por qué se comporta así, pero un host con múltiples interfaces que ejecuta una ruta de rastreo en una interfaz que no tiene la ruta predeterminada configurada es una pérdida de tiempo.