¿Qué muestra Traceroute? Cómo leer los resultados

Traceroute parece más seguro de lo que realmente es. El resultado llega como líneas ordenadas y numeradas, pero esas líneas son observaciones de una serie de sondas, no un mapa perfecto de Internet.

Traceroute muestra los saltos de capa 3 de respuesta entre un origen y un destino, además de muestras de respuesta de ida y vuelta desde el origen a cada salto. No garantiza que todos los enrutadores sean visibles, ni mide el retraso entre dos saltos vecinos ni prueba la pérdida de paquetes. Una respuesta en blanco puede significar simplemente que un dispositivo decidió no responder a la sonda.

Lo que realmente muestra traceroute

Un traceroute clásico intenta revelar el camino, una respuesta a la vez. Por cada salto visible, puede informar un número de salto, una dirección IP, un nombre de host opcional y una o más muestras de tiempo de ida y vuelta. el Modelo de medición de ruta de seguimiento del IETF los identifica como campos de resultados comunes.

La palabra cuidadosa es respondiendo. Una fila representa una interfaz que respondió a una sonda, no necesariamente un enrutador físico completo y ciertamente no todos los dispositivos que manejaron el tráfico. Dos direcciones en el mismo número de salto pueden ser respondedores alternativos en una ruta con equilibrio de carga. Es posible que una fila faltante todavía esté reenviando paquetes perfectamente.

Por lo tanto, Traceroute se lee mejor como una observación de ruta desde una fuente, en un momento, utilizando un método de sonda. Ejecútelo más tarde, desde un VPN, o desde otra red y el resultado puede cambiar. Ese es un comportamiento de enrutamiento normal, no automáticamente una falla.

El pequeño truco TTL detrás de cada salto

El mecanismo es inteligente. En IPv4, cada paquete reenviado lleva un valor de tiempo de vida, generalmente tratado como un límite de saltos. Un enrutador lo reduce antes de reenviar. Cuando el valor caduca, ese enrutador puede devolver un mensaje de tiempo ICMP excedido en lugar de pasar el paquete hacia adelante.

Traceroute primero envía una o más sondas con TTL 1. Caducan en el primer salto enrutado. El siguiente conjunto usa TTL 2 y puede llegar un salto más. El proceso continúa hasta que el destino responde o la herramienta alcanza su máximo configurado. IPv6 utiliza un campo llamado literalmente Límite de saltos, pero la idea del descubrimiento es similar. Los detalles del protocolo están documentados en RFC 5388 y el especificación IPv6.

La respuesta del destino depende de la implementación. Un rastreo tradicional basado en UDP a menudo finaliza cuando el destino informa que no se puede acceder al puerto elegido. ventanas tracert utiliza sondas ICMP Echo y finaliza cuando el destino responde. También existen variantes basadas en TCP. Esta es la razón por la que dos programas traceroute pueden realizar el mismo recorrido básico y enviar diferentes tipos de sondas.

Cómo leer una línea de salida

Considere una línea común al estilo de Windows con un número de salto, tres valores de tiempo y una dirección. Las columnas son simples una vez que dejas de pedirles que hagan más de lo que pueden.

Los tres valores intermedios merecen una atención especial. Son tres intentos separados. Microsoft las describe como mediciones de ida y vuelta desde su dispositivo hasta ese salto y de regreso en su informe oficial. documentación `tracert`. No son tres etapas de un viaje de paquete, y no son un resumen mínimo/promedio/máximo ya preparado.

Un RTT también incluye la ruta de respuesta y el tiempo de procesamiento en el dispositivo que responde. El enrutamiento de Internet puede ser asimétrico, por lo que la respuesta puede regresar por una ruta diferente. RFC 9198 explica por qué este tipo de sincronización ICMP no es una estimación reproducible del retraso de una aplicación. Trate el número como una muestra de un extremo a otro entre la fuente y el respondedor, no como un cronómetro colocado en un cable entre dos enrutadores.

Los asteriscos son silencio, no un veredicto

Un asterisco significa que la sonda no recibió una respuesta antes de su tiempo de espera. Eso es todo lo que significa por sí solo. El enrutador puede filtrar ese tipo de sonda, limitar la velocidad de las respuestas ICMP, restar prioridad a las respuestas del plano de control o enviar una respuesta que se pierde en el camino de regreso.

Un asterisco entre dos tiempos medidos significa que una de las tres sondas quedó sin respuesta. Tres asteriscos o "Solicitud agotada" significa que ninguna de las sondas de esa fila respondió a tiempo. Si los saltos posteriores (incluido el destino) aún responden, el seguimiento continuó más allá de ese TTL, por lo que la fila silenciosa no demuestra un error de reenvío. El enrutamiento de rutas múltiples significa que es posible que esas sondas posteriores no hayan seguido exactamente la misma secuencia de respuesta. El propio ejemplo de Microsoft muestra filas con tiempo de espera agotado seguidas de una respuesta de destino exitosa.

Este es un mal diagnóstico común en la lectura de traceroute: tratar cada salto silencioso como una pérdida de paquetes. Reenviar tráfico y responder sondas de diagnóstico son trabajos diferentes. Un enrutador puede realizar lo primero mientras rechaza el segundo.

Para una investigación de pérdidas real, utilice mediciones repetidas. En Windows, Ruta de acceso combina el descubrimiento de rutas con una serie más larga de sondas y calcula estadísticas. Incluso entonces, la pérdida reportada *a* un enrutador intermedio debe compararse con saltos posteriores antes de concluir que el tráfico reenviado se ve afectado.

Cómo no culpar al enrutador equivocado

La pregunta útil no es "¿Qué fila tiene el número más grande?" Es “¿Dónde comienza un cambio y persiste hasta llegar al destino?”

La distancia, la congestión, el Wi-Fi, el enrutamiento VPN, las colas y el comportamiento del respondedor pueden cambiar el RTT. Una sola muestra alta es una pista, no una convicción. Busque un patrón repetido que continúe en saltos posteriores y coincida con el síntoma real del usuario.

Traceroute tampoco mide la capacidad de descarga o carga. Si la queja es "la conexión se siente lenta en todas partes", un prueba de velocidad de internet comprueba el rendimiento, la latencia y la fluctuación de forma más directa. Las dos herramientas responden a preguntas diferentes.

Lo que traceroute no puede mostrar de manera confiable

Traceroute ofrece una instantánea de la ruta rápida. Leerlo bien significa saber qué omite esa instantánea.

• Es posible que no revele cada salto de Capa 3; Algunos dispositivos nunca responden a las sondas.
• Normalmente no muestra conmutadores de capa 2 transparentes. Esos dispositivos reenvían tramas sin aparecer como saltos de IP.
• Observa la ruta de sondeo directa, mientras que cada respuesta puede tomar una ruta de retorno diferente.
• Puede probar una de varias rutas de igual costo en lugar de todas las rutas posibles.
• No establece porcentajes estables de pérdida de paquetes a partir de un puñado de sondas.
• No puede probar la ruta que tomará cada flujo de aplicaciones, especialmente cuando los protocolos de sondeo difieren.
• Una dirección IP o un nombre de host no es una lectura exacta de la ubicación física.

Utilice la prueba vecina que coincida con la pregunta no resuelta. Si un sitio web responde pero un servicio en particular no, se debe realizar un análisis cuidadosamente control de puerto Puede probar puertos TCP públicos seleccionados desde el borde ClockTools. Si los rangos privados o los límites CIDR confunden el seguimiento, el calculadora de subred IP ayuda a separar las partes de red y host.

Tipos de tracert, traceroute y sonda

Windows nombra el comando tracert. macOS, Linux, BSD y muchos dispositivos de red de uso común trazarruta. El resultado resulta familiar en todas las plataformas, pero las sondas predeterminadas pueden diferir.

ventanas tracert envía solicitudes ICMP Echo con valores TTL crecientes. El traceroute tradicional tipo Unix comúnmente comienza con UDP, aunque las implementaciones y opciones también pueden usar ICMP o TCP. Evite la regla general de que "traceroute siempre usa UDP" o "traceroute siempre usa ICMP". El programa y el método elegido deciden.

Para un seguimiento rápido de Windows sin búsquedas de nombres de host, utilice tracert /d ejemplo.com. En un sistema típico macOS o Linux, comience con traceroute ejemplo.com y lea el manual de ese sistema para conocer las opciones de protocolo y tiempo de espera. el /d flag puede acelerar un seguimiento de Windows omitiendo la resolución de nombre inversa-DNS, pero no oculta las direcciones IP en la salida.

el término ruta de seguimiento generalmente se refiere a una utilidad similar a Unix relacionada con una interfaz y un modelo de privilegios diferentes. MTR y WinMTR repiten las sondas a lo largo del tiempo. PathPing agrega estadísticas repetidas después de descubrir la ruta. Elija entre ellos según si necesita una instantánea de ruta rápida o una medición sostenida.

Donde encaja ClockTools

Una página de navegador normal no puede abrir las mismas sondas ICMP, UDP o TCP sin formato que un comando de terminal local. Los entornos limitados del navegador y el tiempo de ejecución de ClockTools Cloudflare Worker no exponen el control TTL de paquetes requerido, por lo que ClockTools no inventa una tabla de saltos.

el ClockTools Diagnóstico de ruta de seguimiento trabaja dentro de ese límite. El protocolo HTTP y el RTT del cliente describen la etapa del navegador a ClockTools. Una solicitud pública independiente HTTP o HTTPS se ejecuta desde el borde ClockTools hasta el destino e informa la accesibilidad, el estado, el tiempo de respuesta, el tipo de contenido y las redirecciones. Es útil para una verificación rápida del sitio web desde afuera hacia adentro, pero no es la tabla de salto local de su computadora portátil.

En la captura de pantalla, la leyenda 1 marca el aviso de limitación; La leyenda 2 marca los datos de respuesta objetivo. El ejemplo utiliza ejemplo.com, un dominio de documentación pública (no un host privado) y generaliza el código de borde específico de la solicitud.

Utilice una URL pública que sea de su propiedad, que administre o que tenga permiso para probar. Si el objetivo responde rápidamente desde el borde pero se siente lento en su dispositivo, vale la pena verificar el Wi-Fi local, una ruta ISP, un VPN, la carga del dispositivo o el comportamiento del navegador, pero las dos pruebas también se originan desde diferentes puntos de vista y pueden usar diferentes rutas. Si falla tanto desde el borde como localmente, DNS, el alojamiento, el firewall o la disponibilidad del destino se vuelven más plausibles.

Una secuencia práctica de resolución de problemas

Comience con el síntoma, no con el cajón de herramientas.

• ¿Se puede acceder al sitio web desde fuera de su conexión? Ejecute el diagnóstico de ruta ClockTools y observe el estado, las redirecciones y el tiempo de respuesta.
• ¿Toda tu conexión es lenta? Compare el rendimiento, el ping y la fluctuación con una prueba de velocidad de Internet.
• ¿Necesita la vista local salto a salto? Ejecutar tracert o trazarruta en el dispositivo y la red afectados.
• ¿Un servicio falla mientras el host responde? Verifique solo el puerto TCP público autorizado relevante desde el borde ClockTools.
• ¿Apareció una vez un RTT alto o un tiempo de espera? Repita el rastro. El comportamiento persistente en sentido descendente importa más que una sola fila dramática.
• ¿Estás comparando direcciones públicas y privadas? ¿Cuál es mi IP? identifica su dirección pública visible, mientras que la calculadora de subred ayuda con los rangos de redes privadas.

Ese orden evita un error común: utilizar un diagnóstico para responder a todas las preguntas de la red. La accesibilidad, la observación de rutas, la pérdida sostenida, el rendimiento y la disponibilidad del servicio están relacionados, pero no son intercambiables.

Comparta los resultados de traceroute de forma segura

Un seguimiento puede exponer direcciones IP públicas y privadas, nombres de host internos, nombres de proveedores, patrones de sincronización y partes del diseño de una red. Antes de colocar el resultado en un foro, ticket, artículo o captura de pantalla, elimine los detalles que el destinatario no necesita.

Redacte los nombres de dispositivos internos, los nombres de usuario integrados en los nombres de host, las direcciones privadas cuando la topología sea irrelevante y las direcciones públicas si no desea que se asocien con la publicación. Mantenga una estructura suficiente para que el problema siga siendo comprensible: los números de saltos, la presencia de tiempos de espera y tiempos representativos suelen ser suficientes.

No asumas tracert /d anonimiza un rastro. Omite la resolución de nombres; todavía muestra las direcciones IP que responden. Recuerde también que una suposición de geolocalización de IP no es una ubicación física precisa, pero puede revelar un proveedor o una región amplia.

La mejor lectura de traceroute es modesta. Le indica qué sondas recibieron respuestas, cuánto tiempo tardaron esos viajes de ida y vuelta y dónde puede comenzar un patrón. Se vuelve realmente útil cuando combina esa evidencia con pruebas repetidas y el síntoma que está tratando de explicar.