Comando Traceroute para Linux

Rastree dónde va un paquete de datos con traceroute El comando traceroute se usa en Linux para mapear el viaje que realiza un paquete de información desde su origen hasta su destino.

Rastree dónde va un paquete de datos con traceroute

El comando traceroute se usa en Linux para mapear el viaje que realiza un paquete de información desde su origen hasta su destino. Un uso para traceroute es localizar cuándo se produce la pérdida de datos en una red, lo que podría significar que un nodo está inactivo.

Debido a que cada salto en el registro refleja un nuevo servidor o enrutador entre la PC de origen y el destino deseado, revisar los resultados de un escaneo de traceroute también le permite identificar puntos lentos que pueden afectar negativamente el tráfico de su red.

La sintaxis de traceroute y otra información que se describe a continuación es aplicable solo a máquinas Linux. Traceroute se usa de manera diferente en Windows.

Cómo funciona Traceroute

Evaluar la ruta específica que sigue el tráfico de red (o encontrar la puerta de enlace errónea que descarta sus paquetes) presenta varios desafíos de solución de problemas. Traceroute utiliza el campo time to live del protocolo IP para solicitar una respuesta ICMP TIME_EXCEEDED de cada puerta de enlace a lo largo de la ruta a un host de destino.

El único parámetro que debe incluir cuando ejecuta el comando traceroute es el nombre de host o la dirección IP del destino.

Sintaxis e interruptores de Traceroute

traceroute [ -dFInrvx ] [ -f first_ttl ] [ -g puerta de enlace ] [ -i iface ] [ -m max_ttl] [ -p puerto ] [ -q nqueries ] [ -s src_addr ] [ – t tos ] [ -w tiempo de espera ] [ -z pausemsecs ] host [ packetlen ]

Si bien lo anterior es cómo se debe escribir el comando traceroute para que funcione en la línea de comando, el rendimiento o la salida del comando se pueden cambiar especificando uno o más interruptores opcionales.

Interruptores de comando Traceroute
Switch Explicación
-f Establezca el tiempo de vida inicial utilizado en el primer paquete de sonda saliente.
-F Establezca el bit «no fragmentar».
-d Habilitar depuración de nivel de socket.
-g Especifique una puerta de enlace de ruta de origen suelta (8 como máximo).
-i Especifique una interfaz de red para obtener la dirección IP de origen para los paquetes de sonda salientes. Esto normalmente solo es útil en un host con múltiples hosts. (Consulte el indicador -s para obtener otra forma de hacerlo).
-I Use ICMP ECHO en lugar de datagramas UDP.
-m Establezca el tiempo máximo de vida (número máximo de saltos) utilizado en los paquetes de sonda salientes. El valor predeterminado es 30 saltos (el mismo valor predeterminado utilizado para las conexiones TCP).
-n Imprimir direcciones de salto numéricamente en lugar de simbólica y numéricamente (guarda una búsqueda de dirección de nombre de servidor de nombres para cada puerta de enlace encontrada en la ruta).
-p Establezca el número de puerto UDP base utilizado en las sondas (el valor predeterminado es 33434). Traceroute espera que nada esté escuchando en los puertos UDP base a base + nhops – 1 en el host de destino (por lo que se devolverá un mensaje ICMP PORT_UNREACHABLE para finalizar el rastreo de ruta). Si algo está escuchando en un puerto en el rango predeterminado, esta opción se puede usar para elegir un rango de puerto no utilizado.
-r Omita las tablas de enrutamiento normales y envíe directamente a un host en una red conectada. Si el host no está en una red conectada directamente, se devuelve un error. Esta opción se puede usar para hacer ping a un host local a través de una interfaz que no tiene una ruta a través de él (por ejemplo, después de que enrutado (8C) la interfaz haya dejado caer la interfaz).
-s Use la siguiente dirección IP (que generalmente se proporciona como un número IP, no un nombre de host) como la dirección de origen en los paquetes de sonda salientes. En los hosts con alojamiento múltiple (aquellos con más de una dirección IP), esta opción se puede usar para forzar que la dirección de origen sea diferente a la dirección IP de la interfaz en la que se envía el paquete de la sonda. Si la dirección IP no es una de las direcciones de interfaz de esta máquina, se devuelve un error y no se envía nada. (Consulte el indicador -i para obtener otra forma de hacerlo).
-t Establezca el tipo de servicio en paquetes de sonda en el siguiente valor (valor predeterminado cero). El valor debe ser un entero decimal en el rango de 0 a 255. Esta opción se puede usar para ver si los diferentes tipos de servicio dan como resultado diferentes rutas.(Si no está ejecutando 4.4bsd, esto puede ser académico, ya que los servicios de red normales como telnet y ftp no le permiten controlar los TOS.) No todos los valores de TOS son legales o significativos; consulte las especificaciones de IP para ver las definiciones. Los valores útiles son probablemente ` -t 16 ‘(bajo retraso) y` -t 8 ‘ (alto rendimiento ).
-v Salida detallada. Se enumeran los paquetes ICMP recibidos que no sean TIME_EXCEEDED y UNREACHABLE.
-w Establezca el tiempo (en segundos) para esperar una respuesta a una sonda (por defecto 5 segundos).
-x Alternar sumas de comprobación de IP. Normalmente, esto evita que traceroute calcule sumas de comprobación de IP. En algunos casos, el sistema operativo puede sobrescribir partes del paquete saliente pero no volver a calcular la suma de verificación; por lo tanto, en algunos casos, el valor predeterminado es no calcular sumas de verificación y el uso de -x hace que se calculen. Tenga en cuenta que las sumas de verificación generalmente se requieren para el último salto cuando se usan sondas ICMP ECHO ( -I ), por lo que siempre se calculan cuando se usa ICMP.
-z Establece el tiempo (en milisegundos) para pausar entre sondas (valor predeterminado 0). Algunos sistemas como Solaris y enrutadores de Cisco, limitan la velocidad de los mensajes icmp. Un buen valor para usar con esto es 500 (por ejemplo, 1/2 segundo).

Interpretando los resultados

Traceroute describe la ruta que sigue un paquete IP a un host de Internet al lanzar paquetes de sonda UDP con un pequeño TTL (tiempo de vida) y luego escuchar una respuesta ICMP «tiempo excedido» desde una puerta de enlace. Comenzamos nuestras sondas con un TTL de uno y aumentamos en uno hasta que obtengamos un «puerto inalcanzable» ICMP (lo que significa que el paquete llegó a su destino) o alcanzamos un valor máximo de intentos, que por defecto es de 30 saltos y se puede cambiar con la bandera -m .

Cuando se ejecuta el traceroute, envía tres sondas en cada configuración TTL y luego imprime una línea en la consola que muestra el TTL, la dirección de la puerta de enlace y el tiempo de ida y vuelta de cada sonda. Si las respuestas de la sonda provienen de diferentes puertas de enlace, se imprime la dirección de cada sistema de respuesta. Si no hay respuesta dentro de un intervalo de tiempo de espera de cinco segundos (cambiado con el indicador -w ), se imprime un asterisco para esa sonda.

Para evitar que el host de destino se vea abrumado por el procesamiento de paquetes de sonda UDP, el puerto de destino se establece en un valor que ese dispositivo no utilizará. Si una red o servicio en el destino usa ese puerto, cambie el valor usando el indicador -p .

Una muestra de uso y salida devolverá resultados similares a este ejemplo:

 [yak 71]% traceroute nis.nsf.net. 
traceroute to nis.nsf.net (35.1.1.48), 30 saltos máximo, paquete de 38 bytes
1 helios.ee.lbl. gov (128.3.112.1) 19 ms 19 ms 0 ms
2 lilac-dmc.Berkeley.EDU (128.32.216.1) 39 ms 39 ms 19 ms
3 lilac-dmc.Berkeley.EDU (128.32. 216.1) 39 ms 39 ms 19 ms
4 ccngw-ner-cc.Berkeley.EDU (128.32.136.23) 39 ms 40 ms 39 ms
5 ccn-nerif22.Berkeley.EDU (128.32.168.22) 39 ms 39 ms 39 ms
6 128.32.197.4 (128.32.197.4) 40 ms 59 ms 59 ms
7 131.119.2.5 (131.119.2.5) 59 ms 59 ms 59 ms
8 129.140 .70.13 (129.140.70.13) 99 ms 99 ms 80 ms
9 129.140.71.6 (129.140.71.6) 139 ms 239 ms 319 ms
10 129.140.81.7 (129.140.81.7) 220 ms 199 ms 199 ms
11 nic.merit.edu (35.1.1.48) 239 ms 239 ms 239 ms

La segunda y la tercera línea son iguales. Este resultado se relaciona con un núcleo con errores en el sistema del segundo salto, lbl-csam.arpa, que reenvía paquetes con un TTL cero (un error en la versión distribuida de 4.3 BSD). Debe adivinar qué ruta están tomando los paquetes entre países, ya que NSFNet (129.140) no proporciona traducciones de dirección a nombre para sus NSSes.

Un ejemplo más interesante es:

 [yak 72]% traceroute allspice.lcs.mit.edu. 
traceroute to allspice.lcs.mit.edu (18.26.0.115), 30 saltos máximo
1 helios.ee.lbl. gov (128.3.112.1) 0 ms 0 ms 0 ms
2 lilac-dmc.Berkeley.EDU (128.32.216.1) 19 ms 19 ms 19 ms
3 lilac-dmc.Berkeley.EDU (128.32. 216.1) 39 ms 19 ms 19 ms
4 ccngw-ner-cc.Berkeley.EDU (128.32.136.23) 19 ms 39 ms 39 ms
5 ccn-nerif22.Berkeley.EDU (128.32.168.22) 20 ms 39 ms 39 ms
6 128.32.197.4 (128.32.197.4) 59 ms 119 ms 39 ms
7 131.119.2.5 (131.119.2.5) 59 ms 59 ms 39 ms
8 129.140 .70.13 (129.140.70.13) 80 ms 79 ms 99 ms
9 129.140.71.6 (129.140.71.6) 139 ms 139 ms 159 ms
10 129.140.81.7 (129.140.81.7) 199 ms 180 ms 300 ms
11 129.140.72.17 (129.140.72.17) 300 ms 239 ms 239 ms
12 * * *
13 128.121.54.72 (128.121.54.72) 259 ms 499 ms 279 ms
14 * * *
15 * * *
16 * * *
17 * * *
18 ALLSPICE.LCS.MIT.EDU (18.26.0.115) 339 ms 279 ms 279 ms

Tenga en cuenta que las puertas de enlace a las 12, 14, 15, 16 y 17 saltos no envían mensajes ICMP de «tiempo excedido» o los envían con un TTL demasiado pequeño para comunicarse con nosotros. Las líneas 14 a 17 ejecutan el código MIT C Gateway que no envía mensajes de «tiempo excedido».

La puerta de enlace silenciosa 12 en el ejemplo anterior puede ser el resultado de un error en el código de red BSD 4. [23] y sus derivados: las máquinas que ejecutan el código 4.3 y anteriormente envían un mensaje inalcanzable usando el TTL que quede en el datagrama original. Para las puertas de enlace, el TTL restante es cero, se garantiza que el «tiempo excedido» de ICMP no nos lo devolverá. El comportamiento de este error es ligeramente más interesante cuando aparece en el sistema de destino:

 1 helios.ee.lbl.gov (128.3.112.1) 0 ms 0 ms 0 ms 
2 lilac-dmc.Berkeley.EDU (128.32.216.1) 39 ms 19 ms 39 ms
3 lilac-dmc.Berkeley.EDU (128.32.216.1) 19 ms 39 ms 19 ms
4 ccngw-ner-cc.Berkeley.EDU (128.32.136.23) 39 ms 40 ms 19 ms
5 ccn- nerif35.Berkeley.EDU (128.32.168.35) 39 ms 39 ms 39 ms
6 csgw.Berkeley.EDU (128.32.133.254) 39 ms 59 ms 39 ms
7 * * *
8 * * *
9 * * *
10 * * *
11 * * *
12 * * *
13 rip.Berkeley.EDU (128.32.131.22) 59 ms! 39 ms! 39 ms!

Observe que hay 12 «puertas de enlace» (13 es el destino final) y que falta la última mitad. Lo que realmente sucede es que el servidor llamado rip (un Sun-3 con Sun OS 3.5) está usando el TTL de nuestro datagrama de llegada como el TTL en su respuesta ICMP. Entonces, la respuesta expirará en la ruta de retorno (sin notificación enviada a nadie, ya que los ICMP no se envían para ICMP) hasta que analicemos con un TTL que sea al menos el doble de la longitud de la ruta; en otras palabras, la extracción es realmente solo siete salta lejos

Una respuesta que vuelve con un TTL de 1 es una pista de que este problema existe. Traceroute imprime a! después del tiempo si el TTL es menor o igual a 1. Dado que los proveedores envían una gran cantidad de software obsoleto (DEC Ultrix, Sun 3.x) o no estándar (HPUX), espere ver este problema con frecuencia y tenga cuidado al elegir el host objetivo de sus sondas.

Otras posibles anotaciones después del tiempo son ! H , ! N o ! P (host, red o protocolo inalcanzable), ! S (ruta de origen fallida), ! F- (fragmentación necesaria: se muestra el valor de descubrimiento de MTU de ruta RFC1191), ! X (comunicación prohibida administrativamente) , ! V (violación de precedencia de host), ! C (corte de precedencia vigente) o ! (código inalcanzable de ICMP). Estos códigos están definidos por RFC1812, que reemplaza a RFC1716. Si casi todas las sondas resultan en algún tipo de host inalcanzable, Traceroute se dará por vencido y saldrá.

Este programa está diseñado para su uso en pruebas, mediciones y administración de redes. Debe usarse principalmente para el aislamiento manual de fallas. Debido a la carga que podría imponer en la red, no es aconsejable usar traceroute durante las operaciones normales o desde scripts automáticos.

Rate article
labsfabs.com
Add a comment