1 Introducción a Traceroute
Traceroute es una de las herramientas de diagnóstico de red más utilizadas después del ping debido a su simplicidad y amplia gama de aplicaciones. Las posibles aplicaciones de traceroute van desde la simple solución de problemas de red hasta escaneos a gran escala que revelan la topología de red subyacente. Sin embargo, debido a que traceroute no se creó teniendo en cuenta las tecnologías de red modernas, se enfrenta a muchos problemas en el entorno de red actual. Estos problemas generalmente se manifiestan como resultados de retorno de sonda extraños o incorrectos. Esto afecta en gran medida las capacidades de diagnóstico y análisis de la red de traceroute, especialmente en redes grandes. A continuación, introduciremos gradualmente el principio de traceroute y los problemas que enfrenta la herramienta en el entorno de red actual.
2 Principio de trazado de ruta
Classic Traceroute funciona mediante el envío de solicitudes de eco ICMP (las llamadas sondas) con un TTL fijo. Los valores TTL generalmente comienzan en 1 y se incrementan en cada sonda. Los enrutadores en la ruta reducen el TTL en uno en cada salto al reenviar el paquete y envían un error de tiempo de espera de ICMP TTL si el TTL llega a cero. Por lo tanto, traceroute recibe un mensaje de error de cada salto entre él y el destino, que contiene la dirección IP de cada salto. traceroute también puede calcular el RTT para cada salto restando el tiempo en que se recibió el error cuando se envió la sonda. Finalmente, cuando la sonda llega a su destino, traceroute recibe una respuesta de eco ICMP y se detiene. El flujo de mensajes básicos de traceroute se muestra en el siguiente diagrama:
Las variantes modernas de traceroute también incluyen compatibilidad con UDP y TCP, así como con IPv6. La única diferencia con ICMP cuando se usa UDP o TCP es que los paquetes recibidos desde el destino suelen ser paquetes ICMP de puerto inalcanzable o TCP RST, respectivamente. Las excepciones típicas son cuando el paquete está bloqueado por un firewall o el puerto está en uso, en cuyo caso no se devuelve ningún error.
3 Entorno de red actual
La escala de la Internet actual se ha expandido muchas veces en comparación con la red inicial. Por lo tanto, han surgido muchas tecnologías para ayudar a mejorar la capacidad de carga de la red y la velocidad de transmisión, entre las que el balanceo de carga y MPLS (Multi-Protocol Label Switching) son muy representativas . Los detalles se dan a continuación.
3.1 Equilibrio de carga
El equilibrio de carga normalmente distribuye paquetes a través de varios enlaces o rutas diferentes. Los mecanismos de equilibrio de carga generalmente se dividen en tres categorías, que se explican a continuación.
- Equilibrio de carga por flujo. El equilibrio de carga por flujo intenta distribuir paquetes de acuerdo con los llamados flujos. Un flujo generalmente se identifica por una tupla de 5 del paquete correspondiente, a saber, la dirección IP, el protocolo y el puerto. Esto se hace para que los paquetes que pertenecen a la misma conexión se entreguen a su destino en el mayor orden posible.
- Equilibrio de carga por paquete. El balanceo de carga por paquete distribuye cada paquete individualmente a través de los enlaces disponibles. Por lo general, los paquetes se distribuyen aleatoriamente o por turnos. Tiene la ventaja de que requiere menos trabajo dentro del enrutador, pero por otro lado suele introducir una gran fluctuación en la conexión, especialmente si las diferentes rutas no tienen la misma longitud. El equilibrio de carga por paquete generalmente causa la mayoría de los problemas con traceroute debido a su naturaleza aleatoria.
- Equilibrio de carga por destino. El equilibrio de carga por destino distribuye los paquetes en función de su destino. Es básicamente lo mismo que el enrutamiento clásico y, por lo general, tiene poco o ningún impacto en la red. Traceroute suele ser completamente inmune al equilibrio de carga por destino.
3.2 MPLS (conmutación de etiquetas multiprotocolo)
La conmutación de etiquetas multiprotocolo, o MPLS, descrita en RFC 3031, se utiliza para enrutar eficientemente paquetes de datos en redes grandes, como Internet. Por lo general, cada enrutador debe tomar sus propias decisiones de enrutamiento en función de la información contenida en el encabezado IP. Dado que las direcciones IP están ampliamente distribuidas en Internet, generalmente se requiere que los enrutadores tengan tablas de enrutamiento muy grandes. Además, dado que solo unos pocos campos en el encabezado de IP (es decir, direcciones de origen y destino y TTL) se usan para el enrutamiento, esto genera una sobrecarga innecesaria. MPLS usa su propio encabezado, que encapsula el paquete original. De esta manera, solo el primer enrutador tiene que examinar el encabezado IP y asignar una clase de equivalencia de reenvío, o FEC, al paquete en el nuevo encabezado. Esto especifica los destinos que se consideran equivalentes para las decisiones de enrutamiento. Dado que la mayoría de los destinos se pueden combinar en grandes porciones, las tablas correspondientes pueden ser muy pequeñas. Los enrutadores posteriores pueden tomar decisiones de enrutamiento basadas en el FEC más corto y manejable en el encabezado MPLS. Dado que el valor TTL se puede copiar de un lado a otro entre los encabezados IP y MPLS, los enrutadores MPLS también pueden respetar el valor TTL establecido en el paquete original. Además, RFC 4950 permite la generación y el consumo de paquetes ICMP en el contexto de MPLS. Por lo tanto, los enrutadores MPLS pueden brindar soporte básico para traceroute.
4 Desafíos de Traceroute
Las siguientes son descripciones de las excepciones de traceroute más comunes y su comportamiento específico. Para cada excepción, se muestra un flujo de mensajes de muestra, junto con la salida correspondiente.
4.1 Enrutamiento anónimo
Esta es la anomalía más básica, donde faltan uno o más saltos en la salida de traceroute. Esto suele ocurrir cuando el enrutador tiene un firewall o está configurado de otro modo para no generar errores de superación de ICMP TTL. La siguiente figura muestra un flujo de mensajes de muestra para esta excepción y la salida correspondiente. Los tres asteriscos resaltados a continuación, que indican que no se ha recibido respuesta a la encuesta correspondiente, son indicadores clave de esta anomalía.
4.2 Destino sin respuesta
Otra excepción es la ausencia de destinos en los resultados de traceroute. En este caso, traceroute sigue escaneando hasta que alcanza el valor máximo de TTL de la sonda o es interrumpido por otra restricción. Un ejemplo es detenerse después de un cierto número de intentos fallidos. Un efecto secundario peculiar de esta excepción es que puede faltar un número arbitrario de saltos al final de la salida. Un caso común de destinos perdidos son los destinos protegidos por cortafuegos. La siguiente imagen muestra un ejemplo de esta excepción. La salida nuevamente contiene los tres asteriscos típicos de los sondeos fallidos y continúa hasta que se alcanza el TTL máximo.
4.3 Valor RTT incorrecto
Por lo general, hay dos razones para esta anomalía: rutas de paquetes asimétricas o enrutamiento MPLS. Cuando las rutas respectivas hacia y desde el destino son asimétricas, es decir, los paquetes se enrutan por diferentes rutas hacia y desde el destino, es posible que el tiempo de ida y vuelta no refleje el tiempo real que tarda el paquete en llegar al destino. luego se muestra que es engañoso el valor de. La ruta real en realidad puede ser más corta o más larga que la indicada por el tiempo de ida y vuelta, según la situación. La siguiente figura muestra tal escenario, con los tiempos correspondientes resaltados en la salida. Si la ruta de retorno salta de una ruta más larga a una ruta más corta, el RTT medido por traceroute será aún más corto, es decir, la salida mostrará un aumento de TTL negativo para el último enlace.
Se producen resultados similares en los enlaces MPLS, donde el paquete de respuesta debe viajar hasta el final de la ruta MPLS hasta que regresa al remitente de la sonda. Dado que los enrutadores MPLS puros solo conocen el siguiente salto del paquete, no pueden devolver inmediatamente los errores ICMP. En su lugar, deben usar la ruta donde se encontraba el paquete original. El efecto de esto es que todos los paquetes se transmiten primero al último salto MPLS. Por lo tanto, el tiempo de ida y vuelta para cada salto en la ruta MPLS que se muestra en traceroute refleja aproximadamente el tiempo de ida y vuelta hasta el último enrutador MPLS. La siguiente imagen muestra un ejemplo de esta excepción. Un sello característico de esta anomalía son los tiempos de ida y vuelta casi iguales para múltiples saltos en la salida de traceroute, como se destaca a continuación.
4.4 Eslabones perdidos
Esta excepción significa que faltan enlaces en la salida de traceroute, que están presentes en la topología real. El motivo habitual es el equilibrio de carga, en este caso cuando todos los paquetes se enrutan en una ruta. La siguiente imagen muestra un ejemplo de esta excepción. Debería aparecer otro enlace en las dos líneas resaltadas en la salida.
4.5 Enlaces incorrectos
En este caso, existe una mala conexión entre los saltos sondeados por traceroute. Por lo general, ocurre en enlaces de carga equilibrada, cuando algunos paquetes se enrutan a través de una ruta y algunos paquetes se enrutan en otra ruta. Un ejemplo se muestra en la siguiente figura. Los enlaces de error se muestran en las dos líneas resaltadas en la salida. Esta anomalía es en realidad un gran problema con las redes modernas, especialmente porque no es obvia para los usuarios que no entienden la topología real. Como tal, puede llevar a las personas a sacar conclusiones erróneas sobre la red o los problemas que está tratando de resolver.
4.6 Bucles de enrutamiento
Esta es una de las anomalías más complejas en las que se pierden algunos saltos mientras que otros aparecen varias veces, es decir, los paquetes parecen viajar en bucles o círculos. El caso de operación por turnos más común es el balanceo de carga para rutas de diferente longitud. Otro ejemplo podría ser un enlace MPLS, donde la dirección del último enrutador MPLS se usa para errores ICMP, como cuando los enrutadores intermedios carecen de direcciones IP. Un ejemplo raro es cuando un paquete con un TTL de cero se reenvía al siguiente salto, por ejemplo, por un enrutador defectuoso. Los bucles generalmente solo ocurren en enlaces de carga balanceada donde la diferencia de longitud es mayor que 1. PM describe un flujo de mensajes de muestra. Las dos filas resaltadas a continuación muestran los saltos que se probaron dos veces. Sin embargo, la salida correspondiente también puede ser razonable en caso de que haya un bucle o bucle de reenvío real.
4.7 Camino de malla
Las rutas de malla se encuentran entre las anomalías más complejas y muestran algunos enlaces adicionales mientras que faltan otros. Esta anomalía solo ocurre cuando se envían varias sondas para un salto. Por lo general, se debe al equilibrio de carga, que ocurre cuando algunas sondas se reenvían en una ruta y otras en otras rutas. Esto hará que la salida de traceroute se confunda por completo. La topología real y los resultados de detección de traceroute se muestran en la siguiente figura.
5 posibles soluciones
A continuación se presentan varias soluciones para las diversas excepciones presentadas anteriormente. Por supuesto, estas soluciones solo pueden limitar el impacto de las anomalías antes mencionadas en la mayoría de los casos.
5.1 Trazado de ruta de París
Paris traceroute fue desarrollado para corregir la mayoría de las deficiencias encontradas en el clásico traceroute, especialmente con respecto a las redes de equilibrio de carga. La característica distintiva de Paris traceroute es que intenta influir activamente en las decisiones de enrutamiento en enlaces de carga equilibrada por flujo. Para ello, configura cuidadosamente los campos de encabezado en los paquetes de sondeo que envía, que se tienen en cuenta mediante el equilibrio de carga por flujo.
- Documento relacionado: Seguimiento de trayectos múltiples con Paris traceroute
- Herramientas relacionadas: https://paris-traceroute.net/download/
5.2 Paquetes de detección UDP y TCP
Las variantes modernas de traceroute también admiten el envío de sondas UDP o TCP en lugar de solicitudes de eco ICMP, como se mencionó anteriormente. Dado que la mayoría de los enrutadores y firewalls bloquean las solicitudes de eco ICMP, la mayoría de las implementaciones modernas de traceroute en realidad usan UDP de manera predeterminada. Otra ventaja de las sondas UDP es que no requieren privilegios de root para enviar sondas en sistemas Linux. El sondeo de TCP generalmente solo se usa en circunstancias muy específicas, generalmente para eludir firewalls muy restrictivos o atravesar puertas de enlace NAT. El principal argumento en contra de TCP es que intenta crear una conexión que luego introduce estado en la red. Además, hay más aplicaciones escuchando en TCP que en UDP. De hecho, la mayoría de las implementaciones utilizan el puerto TCP 80 de forma predeterminada para facilitar el paso de los cortafuegos. Para borrar una conexión pendiente, se requiere un paquete TCP RST adicional. En general, el enrutamiento anónimo o las anomalías de destino faltante pueden mitigarse mediante el uso de UDP o TCP en lugar de solicitudes de eco ICMP.
5.3 Búsqueda de números AS
Los números AS se pueden consultar desde bases de datos, como la base de datos RIPE, para la identificación de direcciones IP de operadores de red y la detección de límites de red. Esta información se puede usar para contactar a un administrador en caso de una falla en la red. También hay un algoritmo moderno que combina información BGP con información de múltiples bases de datos para producir resultados más precisos.
5.4 Decodificación de etiquetas MPLS
La etiqueta MPLS decodificada, es decir, FEC, se devuelve en el paquete de error ICMP extendido, como se define en RFC 4950. Facilita el diagnóstico de problemas relacionados con MPLS y también permite una interpretación más precisa de la salida de traceroute. Esto es especialmente útil si se sospecha de anomalías relacionadas con MPLS, como tiempos de ida y vuelta incorrectos o bucles causados por el enrutamiento MPLS.
5.5 Trazado de ruta inversa
La tecnología de rastreo de ruta inversa se utiliza para rastrear la ruta que toma un paquete desde una fuente remota hasta un host local. Se pueden diagnosticar problemas de red adicionales y se puede simplificar la interpretación de la salida existente examinando la ruta de retorno del paquete. Esto es especialmente importante para las excepciones relacionadas con rutas asimétricas. Hay una propuesta para hacer esto realmente sin la interacción del sistema de destino. Sin embargo, requiere el uso de la opción Record Route o RR IP, que registra el número de saltos que ha recorrido el paquete. Esto se hace para registrar la ruta de retorno de cada paquete. La opción RR se inventó como una alternativa a traceroute, pero dado que requería la interacción de enrutadores individuales, generalmente no se admitía y se abandonaba. También puede registrar solo 8 saltos en ambas direcciones, razón por la cual el método requiere múltiples hosts, los llamados "puntos ventajosos", entre el objetivo y el host local. Por lo tanto, este enfoque no es factible para los usuarios que no cuentan con los recursos necesarios. Finalmente, es necesario falsificar la dirección IP de origen en las sondas enviadas para redirigir la respuesta a dicho host, lo que la mayoría de los enrutadores impiden.
6 Referencias
Jobst M E. Anomalías de Traceroute [J]. Red, 2012, 9.