Traceroute: cada paquete tiene TTL == 1

Estoy trabajando en Wireshark lab-IP en redes de computadoras: un enfoque de arriba hacia abajo y no entiendo por qué cada paquete que normalmente expiró tiene un TTL de 1.

Aquí está mi archivo de captura de Wireshark. https://www.dropbox.com/s/rr5wgze9j20gzvu/traceroute-56.pcapng?dl=0

Capturé la ejecución del tracerouteprograma en Linux (con la opción de 56 bytes), como se ejecuta con el siguiente comando:

traceroute http://gaia.cs.umass.edu 56

Puede ver que la mayoría de los paquetes TTL == 1 y no sé por qué, ya que aprendí que cada salto posterior tiene un TTL de +1 (o más).

PD:

• Estoy usando Lubuntu en VMware con red puenteada al host.
• Lo capturé con wireshark en la máquina host (Windows)
• Estoy conectado a un AP inalámbrico usando su propio servidor DHCP sobre el protocolo NAT

Permítanme intentar responder esto, porque es un poco más complicado de lo que parece inicialmente.

Parece que ya conoce el funcionamiento básico de, traceroutepero antes que nada, aquí hay un resumen muy pequeño:

tracerouteintenta determinar todos los pasos intermedios desde su host a un host de destino, o solo la distancia, es decir, el número de saltos, desde su host a un host de destino. Para ello, comienza a enviar paquetes al host de destino con un número de puerto de destino "aleatorio" y un TTL que comienza en 1 y sigue aumentando.
La idea es que cada enrutador intermedio disminuya el TTL en 1. Por lo tanto, si TTL alcanza 0 (en realidad, nunca lo hace, ya que el enrutador que está a punto de disminuirlo a 0 produce un error antes), el enrutador devolverá un ICMP Mensaje de error " Tiempo de vida excedido ", por ejemplo, número de paquete 24 en su archivo de captura. Lo que obtienes de eso es que tu destino está más lejos y es por eso que sigues aumentando el TTL.
Cuando su paquete tiene un TTL que es lo suficientemente grande como para llegar al destino, recibirá un mensaje de error ICMP diferente: " Destino inalcanzable (puerto inalcanzable) ", por ejemplo, número de paquete 208 en su archivo de captura. Lo que obtienes de eso es que el último TTL utilizado es el número de saltos entre tú y el nodo de destino. La razón por la que obtiene un error es simplemente porque está enviando un mensaje a un puerto "aleatorio" que el nodo de destino (con suerte) no está escuchando.

Ahora entrando en detalles para su archivo de captura: en
la página del manual traceroutepodemos ver que cada TTL se usa 3 veces (opción '-q') y el protocolo predeterminado utilizado es UDP (opción '-P'). Al examinar los primeros 3 paquetes UDP, es decir, los paquetes 8-9-10 , podemos ver que el TTL es 1 . Los siguientes 3, es decir, 11-12-13 , tienen un TTL 2 y así sucesivamente. Entonces, desde la perspectiva de la fuente, todo parece ir bien.

Luego, después de un tiempo dependiente del retraso de la red, comenzamos a recibir los mensajes de error anticipados. Por lo tanto, podemos ver que los paquetes 24-25-26 son paquetes de error " Tiempo de vida excedido ", lo que significa que el destino está más lejos.

Este intercambio de intentos y errores continúa, hasta que, finalmente, el paquete 208 y en adelante puede ver mensajes de error " Puerto inalcanzable ", lo que significa que se ha alcanzado su destino.

Al contar los paquetes que envía y las respuestas, puede descubrir incluso a partir de la traza que TTL realmente funcionó, pero es una tarea tediosa :)

Espero que haya ayudado

Su cliente solo envía los primeros tres paquetes con un TTL de 1. Los siguientes tres se envían con un TTL de 2. Los siguientes tres se envían con un TTL de 3. Y así sucesivamente.

Una forma más fácil de ver esto es establecer el campo IP TTL como su propia columna en Wireshark. Simplemente haga clic derecho en el valor TTL en cualquier paquete y seleccione "Aplicar como columna":

A partir de ahí, puede ver que los paquetes 8,9,10 tienen un TTL de 1. Y los paquetes 11,12,13 tienen un TTL de 2. Y así sucesivamente.

Esto está sucediendo porque así es como funciona Traceroute. Aprovecha lo que hace un enrutador cuando disminuye un TTL a 0. En lugar de continuar reenviando el paquete, envía de vuelta al cliente original un "mensaje ICMP TTL caducado en tránsito" (vea el paquete # 24 en su captura) .

Entonces, como cliente, cuando envía el primer conjunto de paquetes con un TTL de 1, el primer enrutador de la ruta responde con el mensaje TTL caducado. Luego mide cuánto tiempo tardó en recibir el mensaje TTL caducado cuando envió los mensajes iniciales, y eso le da sus primeros tres valores en la salida de Traceroute.

Luego, envía otro conjunto de tres paquetes con un TTL de 2. El primer enrutador de la ruta disminuye esto a 1 y luego lo reenvía al siguiente enrutador de la ruta. Al recibirlo, cuando ese segundo enrutador lo recibe, disminuye el TTL a 0, lo que le indica que deje caer el paquete y le envíe el TTL caducado en tránsito.

El proceso continúa hasta que su cliente haya recibido (bueno, tres) mensajes TTL caducados de cada enrutador en tránsito entre usted y el destino final en el que está ejecutando su traceroute.