Saltar al contenido principal
Descargar

Traceroute en Mac, iPhone y iPad: encuentra dónde se rompe la ruta

Un traceroute ICMP real en Mac, iPhone y iPad, salto a salto en directo, y lo que nadie explica: cómo leer lo que vuelve.

Por Lucas Russo, desarrollador de SSHive · Actualizado el

Descargar SSHive gratisTodas las herramientas de red
También en iPhone y iPad
Un servicio va lento o no responde y nada de tu lado lo explica. El DNS resuelve, el servidor contesta en local, tu enlace está limpio. Lo que no puedes ver son los quince o veinte routers que hay entre tu máquina y ese host, y ahí suele estar la respuesta. Traceroute es la herramienta que hace visibles esos routers. No mide tu conexión a un servidor: reconstruye la secuencia de saltos que siguen tus paquetes para llegar hasta él y cuánto tarda cada uno en responder. Bien leído, te dice si el problema es tuyo, de tu operador, de un proveedor de tránsito o del destino, que es la diferencia entre arreglar algo y abrir un ticket a quien corresponde. Mal leído, produce más conclusiones erróneas que ninguna otra herramienta de red. Un salto lleno de asteriscos parece un router muerto y casi nunca lo es. Un pico de 300 ms a mitad de la ruta resulta alarmante cuando lo normal es que sea un router que da menos prioridad a tu sonda mientras reenvía el tráfico de producción sin despeinarse. Leer un traceroute consiste sobre todo en saber qué líneas son medidas y qué líneas son ruido. SSHive mide un traceroute real en todas las plataformas Apple en las que se publica: la versión del Mac App Store, iPhone y iPad. Envía sus propias sondas ICMP, un valor de TTL cada vez, tres sondas por salto, hasta treinta saltos, y emite la dirección y los tiempos de cada router según llegan. Nada se reformatea y nada se inventa. Conviene decirlo sin rodeos, porque una versión anterior de esta página afirmaba lo contrario. Sostenía que una app del App Store en sandbox no puede hacer traceroute, porque necesitaría sockets ICMP raw. Nunca se midió, y es falso: fijar IP_TTL y leer las respuestas Time Exceeded funciona desde un socket ICMP de datagramas corriente, que no necesita root y que el App Sandbox permite. Todo lo que sigue explica el mecanismo y cómo leer la salida.

Qué hace SSHive

Sondas propias, no el binario del sistema

SSHive construye las sondas por su cuenta en vez de delegar en un binario, así que el mismo motor corre en la versión del Mac App Store, en iPhone y en iPad. Un valor de TTL por salto, tres sondas cada uno, hasta treinta saltos, con la dirección del router y sus tres tiempos de ida y vuelta en cada línea. Nada se sintetiza y ningún servicio de terceros se interpone: los paquetes salen de tu dispositivo y las respuestas vuelven a él.

Salida en directo, salto a salto

Los saltos aparecen según responden, línea a línea, en un panel monoespaciado que se desplaza solo. Una insignia «Ejecutando…» indica que la traza sigue en curso, y Detener la cancela al momento, útil cuando una ruta se atasca en un salto filtrado y ya tenías la respuesta en el salto 6. Nunca tienes que aguantar una ejecución completa de 30 saltos.

La misma traza en iPhone y iPad

Las apps de iOS y iPadOS ejecutan el mismo motor ICMP que el Mac, con el mismo techo de treinta saltos y las mismas tres sondas por salto, así que una traza lanzada desde el móvil es directamente comparable con otra lanzada desde el Mac. Eso importa más de lo que parece: trazar el mismo host desde la red móvil y desde el Wi-Fi de la oficina suele ser lo que señala de quién es la red culpable.

Desactivado donde no puede funcionar, nunca simulado

Cuando el sistema rechaza el ICMP de plano (algunas redes corporativas y unas cuantas configuraciones de VPN lo hacen), SSHive se detiene y lo dice, en lugar de imprimir una lista de saltos de aspecto verosímil. Un rechazo se informa como rechazo. Lo mismo vale para un salto que no responde nunca: se dibuja con asteriscos, que es un resultado real y frecuente, no un error.

Traza y luego conecta

Un traceroute casi siempre acaba en una pregunta: ¿qué es ese último router que responde, y puedo entrar en la máquina que hay detrás? SSHive es ante todo un cliente SSH, SFTP, RDP y VNC, así que la respuesta está a una pestaña. Identifica el último salto bueno, abre una sesión contra el jump host o el servidor y sigue trabajando en la misma ventana.

Gratis y sin cuenta

Toda la suite de herramientas de red (traceroute, ping, resolución DNS, whois, consulta MX y comprobaciones DNSBL) está en el nivel gratuito en todas las plataformas donde existe. Ninguna tiene barrera de función, ni anuncios, ni registro. SSHive Pro se paga una sola vez, como compra universal para Mac, iPhone y iPad, y desbloquea funciones de sesión, no el diagnóstico.

Cómo hacerlo, paso a paso

  1. 1

    Abre las herramientas de red

    En el Mac, haz clic en el icono de red de la barra lateral o en el botón Herramientas de red de la pantalla de bienvenida. Cualquiera de los dos abre una pestaña de herramientas propia junto a tus sesiones, así que puedes trazar una ruta sin cerrar aquello en lo que estás trabajando. En iPhone y iPad, esas mismas herramientas están en la pestaña Herramientas.

  2. 2

    Localiza la tarjeta Traceroute

    El panel de herramientas agrupa sus tarjetas en tres secciones, y puedes mover u ocultar tarjetas dentro de una sección para quedarte solo con las herramientas que de verdad usas. Traceroute es la última tarjeta de la sección Alcanzabilidad, después de Ping y Prueba de puerto.

  3. 3

    Introduce un destino y lanza la traza

    Escribe un nombre de host o una dirección IP en el campo (el marcador muestra ej. google.com) y pulsa Rastrear. SSHive lo resuelve y empieza a sondear con un TTL de 1, avanzando hacia fuera salto a salto, hasta 30.

  4. 4

    Observa cómo llegan los saltos

    Las líneas van llegando a medida que cada router responde, con una insignia «Ejecutando…» mientras la traza está activa. Un salto con asteriscos simplemente no contesta dentro del tiempo de espera, y la traza pasa al siguiente TTL. Pulsa Detener en cuanto hayas visto lo que necesitabas.

  5. 5

    Actúa sobre el último salto que responde

    Anota el último salto que respondió y si el destino llegó a responder siquiera. Desde ahí, abre en la misma ventana una sesión SSH, RDP o VNC contra el host correspondiente, o contrasta el objetivo con las tarjetas Ping y Búsqueda DNS de más arriba.

Leer un traceroute sin llegar a la conclusión equivocada

Cada línea es un valor de TTL, no una medida de tu conexión. Salen tres sondas por salto, así que obtienes tres tiempos de ida y vuelta, y la dispersión importa tanto como los valores: 10 / 11 / 10 ms es un router estable, mientras que 10 / 400 / 11 ms es una sonda que quedó encolada detrás de algo y rara vez merece investigarse. Todo RTT incluye un camino de vuelta que nunca ves. La respuesta del salto 8 regresa por la ruta que ese router tenga hacia ti, que a menudo no es la inversa del camino de ida. Por eso el salto 8 puede marcar 90 ms mientras el salto 9 marca 40 ms. No es un error y la latencia no ha bajado: la respuesta del salto 8 simplemente tomó un camino de vuelta más lento. Nunca restes dos saltos contiguos y llames al resultado la latencia de ese enlace. Los asteriscos son la salida peor interpretada de todas las redes. Tres de ellos significan que no volvió ningún ICMP Time Exceeded antes de agotarse el tiempo de espera (cinco segundos por omisión en macOS). Hay tres causas corrientes: el router no genera errores ICMP en absoluto, algo normal en los núcleos de operador y MPLS; limita la tasa de generación de errores ICMP, y descarta la respuesta a tu sonda mientras reenvía el tráfico de producción perfectamente; o un cortafuegos bloquea la sonda saliente (macOS usa UDP desde el puerto 33434 hacia arriba) o el ICMP de vuelta. En los tres casos el plano de datos está sano. La prueba es sencilla: si responde cualquier salto posterior a los asteriscos, el salto mudo reenvió tu paquete correctamente. Solo los asteriscos que llegan sin interrupción hasta el final de la traza te dicen algo. La misma disciplina vale para los picos. Un salto a 300 ms entre vecinos a 40 ms es un artefacto del plano de control: ese router dio menos prioridad a tu sonda. Lo que importa es si un aumento persiste en todos los saltos posteriores y hasta el destino. Un escalón que se mantiene hasta el final es real, aunque puede ser geografía y no avería: un tramo transatlántico cuesta sus 70 a 90 ms y siempre los costará. Donde una ruta se rompe de verdad es en el último salto que respondió: el último router con ruta hacia tu objetivo y ruta de vuelta hacia ti. Si nada posterior contesta y el destino tampoco lo hace nunca, el fallo está en ese punto o justo después. Un patrón que repite los mismos saltos es un bucle de enrutamiento. Y !H, !N, !P o !X son concluyentes donde los asteriscos no lo son: un router que informa explícitamente de host, red o protocolo inalcanzable, o de ruta filtrada administrativamente.

Preguntas frecuentes

¿Funciona de verdad el traceroute en la versión del Mac App Store con sandbox?+
Sí, y sin recortes de ningún tipo. La creencia habitual de que no puede se basa en confundir dos tipos de socket. El traceroute necesita fijar IP_TTL en las sondas salientes y leer las respuestas ICMP Time Exceeded que devuelven los routers. Un socket raw sí lo rechazaría el App Sandbox, pero un socket ICMP de datagramas hace las dos cosas, no necesita root y está permitido. Medido bajo sandbox-exec con los entitlements propios de la app: setsockopt(IP_TTL) funciona y los saltos vuelven, router a router. Una advertencia aprendida por las malas: com.apple.security.network.client a secas no basta, porque entonces las respuestas se rechazan con EPERM; hace falta también network.server, y SSHive declara los dos.
¿Puedo lanzar un traceroute desde un iPhone o un iPad?+
Sí, y es una medida auténtica, no una ilustración. iOS no permite lanzar subprocesos y no tiene binarios setuid, así que una app no puede sin más llamar al traceroute del sistema, que es la razón por la que se suele dar por imposible. Pero la restricción está solo en Network.framework, la API de alto nivel de Apple, que no tiene transporte ICMP. Debajo, la capa de sockets BSD está intacta: SSHive abre socket(AF_INET, SOCK_DGRAM, IPPROTO_ICMP), fija IP_TTL en cada sonda y lee las respuestas Time Exceeded, exactamente como en el Mac. Treinta saltos, tres sondas cada uno. Trazar el mismo host desde la red móvil y desde el Wi-Fi suele ser la vía más rápida para establecer de quién es la red culpable.
¿Qué significan tres asteriscos en un traceroute?+
Que ninguna de las tres sondas de ese TTL recibió un ICMP Time Exceeded antes de agotarse el tiempo de espera. Normalmente significa que el router está configurado para no emitir errores ICMP, que les aplica límite de tasa, o que un cortafuegos descartó la sonda o la respuesta. Rara vez significa que el router esté roto. Si responde cualquier salto posterior, ese router mudo reenvió tu paquete perfectamente. Solo los asteriscos que continúan sin interrupción hasta el final de la traza son una señal real.
¿Por qué un salto intermedio marca 300 ms cuando el destino marca 40 ms?+
Porque responder a tu sonda no es el trabajo de ese router. Generar un ICMP Time Exceeded es trabajo del plano de control, que atiende una CPU que deliberadamente le da poca prioridad, mientras el tráfico que reenvía se queda en la vía rápida. Un pico que no se propaga a los saltos siguientes es un artefacto, no una avería. Solo un aumento que persiste en todos los saltos posteriores y hasta el destino refleja algo que el tráfico experimenta de verdad.
La traza se detiene en el salto 12 y no llega nunca al host. ¿Está caída la red?+
No necesariamente. Muchos destinos detrás de balanceadores de carga, frontales anycast o cortafuegos en la nube descartan en silencio las sondas de traceroute mientras sirven el tráfico TCP con normalidad, así que una traza que se apaga cerca del final mientras el servicio funciona es lo esperable. Confírmalo con una prueba de conectividad contra el puerto real (justo lo que hace el motor TCP del ping) antes de concluir nada. Si el servicio es realmente inalcanzable, el salto 12 es tu prueba: es el último router que tenía ruta hacia tu objetivo y ruta de vuelta hacia ti, así que la rotura está ahí o inmediatamente después.
¿Puedo cambiar el límite de saltos, o sondear con UDP en lugar de ICMP?+
No desde la tarjeta de SSHive. La traza se ejecuta con un techo fijo de 30 saltos, sondas ICMP y tres sondas por salto, sin opciones de protocolo, puerto ni número de sondas, y sin enriquecimiento de ASN ni de geolocalización. Si necesitas esos parámetros en un Mac, /usr/sbin/traceroute los acepta directamente en el Terminal; la tarjeta está para el caso corriente de trazar un host rápido sin salir de tus sesiones, y para iPhone y iPad, donde no hay Terminal al que recurrir.
¿El traceroute forma parte de SSHive Pro?+
No. El traceroute y el resto de la suite de herramientas de red son gratis en todas las plataformas, sin barrera de función, sin anuncios y sin cuenta que crear. SSHive Pro se paga una sola vez, como compra universal para Mac, iPhone y iPad, sin suscripción; desbloquea capacidades del lado de las sesiones, no el diagnóstico.

TTL, errores ICMP y cómo una app en sandbox lo consigue igualmente

Una cabecera IPv4 lleva un campo TTL de 8 bits (en IPv6 se llama Hop Limit) cuyo único propósito es impedir que los paquetes circulen para siempre. Cada router que reenvía un paquete le resta uno; cuando llega a cero, el router descarta el paquete y devuelve un mensaje ICMP Time Exceeded, tipo 11 código 0, con origen en la interfaz por la que llegó el paquete. Traceroute convierte ese modo de fallo en una medida. Envía una sonda con TTL 1, que muere en el primer router y provoca un error que lo nombra. Luego TTL 2, luego TTL 3, avanzando hacia fuera salto a salto. Tres sondas por TTL producen los tres tiempos de cada línea. Cómo se reconoce el destino depende del tipo de sonda: el traceroute BSD de macOS envía datagramas UDP a puertos altos improbables a partir del 33434 y trata un ICMP Port Unreachable (tipo 3, código 3) como señal de llegada, mientras que el tracert de Windows envía peticiones ICMP Echo y se detiene ante una Echo Reply. Esa diferencia no es cosmética. Los cortafuegos tratan las sondas UDP y el ICMP Echo de forma muy distinta, así que un mismo destino produce legítimamente saltos con asteriscos distintos desde un Mac y desde una máquina Windows; conviene comprobar ambos antes de culpar a un router. Lo que nos lleva a la pregunta que todo el mundo contesta mal, incluida una versión anterior de esta página: ¿puede siquiera hacer esto una app en sandbox? El razonamiento que dice que no va así. /usr/sbin/traceroute se instala setuid root en macOS mientras que /sbin/ping no, luego traceroute debe de necesitar privilegios que ping no necesita; el App Sandbox no concede tales privilegios; por lo tanto, no hay traceroute en una app del App Store. Cada paso suena razonable y la conclusión sigue siendo falsa, porque la premisa confunde el tipo de sonda que eligió el traceroute BSD con el traceroute como técnica. Ese binario sondea con datagramas UDP y necesita un socket raw para leer los errores ICMP que provocan, de ahí el setuid. Sondea con ICMP Echo en su lugar y las respuestas llegan al mismo socket ICMP de datagramas que el ping ya usa sin privilegios. setsockopt(IP_TTL) no es una llamada privilegiada. Así que SSHive no pilota ningún binario del sistema. Abre socket(AF_INET, SOCK_DGRAM, IPPROTO_ICMP), fija el TTL, envía tres peticiones Echo por salto y lee lo que vuelve: un Time Exceeded que nombra a un router, una Echo Reply que significa que el destino respondió, o nada en dos segundos, que se imprime como un asterisco. Eso se midió bajo sandbox-exec con los entitlements reales de la app antes de publicar nada, y reveló una trampa que merece repetirse: con com.apple.security.network.client a secas, la sonda sale y la respuesta se rechaza con EPERM, un fallo silencioso que se parece exactamente a una red que filtra. Hace falta también com.apple.security.network.server. SSHive declara los dos, y por eso la versión del App Store, en su sandbox, traza de verdad en vez de alinear una columna de asteriscos. iOS llega al mismo sitio por el mismo camino. Network.framework expone TCP, UDP, QUIC y TLS, y nada de ICMP, pero no es la única API disponible: la capa de sockets BSD que hay debajo acepta el mismo socket ICMP de datagramas, y el ejemplo SimplePing del propio Apple lleva años demostrándolo. Las versiones de iPhone y iPad ejecutan el mismo bucle de treinta saltos y tres sondas que el Mac. Conoce los límites antes de apoyarte en ella. El techo de saltos está fijado en 30, no hay parámetros de protocolo, puerto ni número de sondas, y no hay enriquecimiento de ASN ni de geolocalización. Como las sondas son ICMP Echo y no UDP, un cortafuegos que permita uno y descarte el otro puede producir un patrón de asteriscos distinto del que daría /usr/sbin/traceroute: ninguno de los dos resultados es erróneo, y compararlos es a veces justo la forma de encontrar el cortafuegos.

Herramientas relacionadas

Ping

Consulta DNS

Whois