Show HN: ¿Cómo llegó mi computadora a mi servidor?

• Cuando un visitante abre el sitio web, el servidor ejecuta traceroute hacia la IP pública y muestra como texto en tiempo real la ruta que siguen los paquetes a través de routers y redes
• La herramienta propia ktr incrementa el valor TTL de los paquetes ICMP para recopilar las respuestas de error de cada salto, y al mismo tiempo consulta la información de red de cada hop
• La actualización en pantalla no se implementa con JavaScript, sino enviando continuamente HTML y CSS en una respuesta HTTP abierta, de modo que los resultados aparecen de forma gradual mientras carga la página
• La ruta mostrada es un traceroute inverso enviado desde el servidor hacia la IP del visitante y luego invertido, así que puede no coincidir por completo con la ruta real debido a diferencias de enrutamiento en ambos sentidos
• Las rutas de Internet se forman mediante el peering BGP entre sistemas autónomos (AS) y la propagación de tablas de enrutamiento, por lo que el tráfico viaja siguiendo redes interconectadas

---

Un traceroute personalizado que se genera en cada visita

• El texto verde en la parte superior de la página no es un ejemplo guardado de antemano, sino un traceroute generado al instante para cada visitante mientras carga el sitio web
• El traceroute muestra el recorrido de la computadora del visitante, o de sus paquetes, a través de Internet hasta llegar al servidor que hospeda este sitio web
• La ruta de ejemplo comienza en el router del visitante, pasa por la red del ISP, atraviesa varias redes, entra en la red interna de Hetzner y finalmente llega al servidor
  • Es posible que el primer router no responda al ping, algo común detrás de routers compartidos o VPN
  • En medio puede aparecer (no response), y no todos los servidores responden siempre
• Nombres como core3.sto.hetzner.com son el resultado de hacer una búsqueda DNS inversa sobre la IP 213.239.252.74 obtenida en el traceroute para convertirla en un nombre legible
  • Los nombres de DNS inverso suelen existir principalmente para facilitar la depuración, y muchas veces ni siquiera vuelven a mapearse a la IP original

ktr y traceroute basado en ICMP

• Para implementar el sitio web se usa el programa propio de traceroute ktr
  • El código fuente del sitio también está publicado en GitHub
  • ktr transmite los resultados en tiempo real mientras consulta en paralelo la información de cada salto
• En el enrutamiento de Internet, la computadora o router que procesa un paquete elige el siguiente dispositivo al que lo enviará, y este proceso continúa hasta llegar a un router que pueda mandarlo directamente al destino
• La implementación de ktr usa ICMP
  • ICMP es un protocolo diseñado para enviar información de diagnóstico en Internet
  • Casi todos los dispositivos conectados a Internet soportan ICMP
• El campo TTL (time to live) de un paquete ICMP no representa tiempo real, sino un valor de cuenta regresiva
  • Cada vez que un router reenvía un paquete ICMP, debe reducir el TTL en 1
  • Cuando el TTL llega a 0, el router deja de reenviar el paquete y envía a la IP de origen original un mensaje de error indicando que se alcanzó el número máximo de saltos
• traceroute envía paquetes ICMP con TTL crecientes, como 1, 2 y 3, para recopilar las respuestas de error que regresan desde cada salto
  • Los paquetes de error incluyen información de diagnóstico, como la dirección IP del dispositivo que envió el error
  • Eso permite rastrear la ruta aproximada de un paquete a través de Internet

Una interfaz que parece en tiempo real sin JavaScript

• La página funciona incluso con JavaScript desactivado
  • Desde la perspectiva del navegador, parece que el sitio se está cargando lentamente
  • Para el usuario, parece que el traceroute aparece en tiempo real
• Al conectarse, el servidor recibe una solicitud HTTP desde la dirección IP del visitante y de inmediato ejecuta un traceroute hacia esa IP
• El servidor envía primero la parte inicial de la respuesta HTTP y mantiene la conexión abierta
  • ktr entrega al servidor las actualizaciones del traceroute
  • El servidor renderiza el HTML correspondiente y lo envía a la computadora del visitante
  • Cuando termina el traceroute, envía el resto del texto y el contenido del sitio web, y luego cierra la conexión
• La razón por la que las líneas del traceroute parecen actualizarse gradualmente desde arriba en lugar de agregarse abajo es la inserción de bloques CSS
  • Una página web normalmente solo puede cargarse hacia adelante
  • Cada vez que se actualiza la visualización del traceroute, también se inserta CSS para ocultar la visualización anterior
  • Como el navegador renderiza el CSS mientras la página sigue cargando, parece como si la pantalla se editara con el paso del tiempo

Limitaciones del traceroute inverso

• La ruta que muestra la página no es exactamente igual a “la ruta por la que los paquetes del visitante llegaron al servidor”
• Para calcular la ruta real, sería necesario poder ejecutar traceroute desde la computadora del visitante hacia el servidor
• La implementación ejecuta traceroute desde el servidor hacia la computadora del visitante y luego muestra el resultado invertido
  • Por eso el traceroute de la parte superior parece cargarse en orden inverso
• El traceroute inverso sacrifica algo de precisión
  • Si los paquetes viajan en dirección contraria, cada dispositivo puede tomar decisiones de enrutamiento distintas
  • Basta con que un solo dispositivo tome una decisión diferente para que cambie toda la ruta posterior
• Aun así, la ruta suele ser aproximadamente similar, y la diferencia probablemente se limite a qué routers específicos ven los paquetes

Sistemas autónomos y consultas WHOIS

• Las “redes” que aparecen en el traceroute se refieren a sistemas autónomos (AS)
  • Un AS es un conjunto de routers y servidores conectados entre sí de forma privada
  • Normalmente pertenece a una misma empresa
• Los propietarios de un AS determinan la forma de Internet al decidir con qué otros AS conectarse
  • El tráfico de Internet se mueve pasando por AS que tienen acuerdos de peering entre sí
• Aunque Internet parezca una red abierta, en realidad es una red de redes propiedad de empresas, y su acceso y control dependen de transacciones financieras y procesos burocráticos
• Si quieres tu propio sistema autónomo, puedes solicitar un ASN a uno de los cinco registros regionales de Internet (RIR)
  • Sin el respaldo de una empresa o sin suficientes puntos de conexión a Internet, es difícil que te lo aprueben
  • Números como AS4766 en el traceroute son ASN
• ktr usa el protocolo WHOIS para obtener información sobre el AS dueño de la IP de cada salto
  • Varias organizaciones rastrean qué AS incluye qué direcciones IP
  • Muchas organizaciones ofrecen consultas de ASN por WHOIS
• También se usa PeeringDB para identificar información de empresas
  • PeeringDB tiene información sobre aproximadamente un tercio de todos los sistemas autónomos
  • Con los resultados de esas consultas y varios cientos de líneas de sentencias if, se genera la explicación del recorrido por las redes
• La especificación del protocolo WHOIS casi no define estructura alguna
  • Básicamente solo establece que se abre una conexión TCP, se envía la consulta y el servidor devuelve la información antes de cerrar la conexión
  • La estructura real de las respuestas WHOIS se parece más a una convención creada por los administradores de cada servidor, y hasta los nombres de los campos necesarios pueden variar, como origin u originas
  • El parser de ktr no es tanto un parser estricto como una forma de leer el resultado de WHOIS como lo haría una persona para encontrar el ASN necesario

Cómo BGP construye las rutas de Internet

• Los routers situados en los bordes de las redes deciden a qué red enviar después un paquete, y el mismo proceso se repite hasta llegar a la red donde está el dispositivo de destino
• Esos routers de borde intercambian entre sí información sobre redes alcanzables mediante el Border Gateway Protocol (BGP)
  • BGP es el protocolo que da forma a Internet
  • Los usuarios comunes no pueden hablar directamente con BGP
• La primera versión de BGP se describe en RFC 1105, publicado en 1989 por ingenieros de Cisco e IBM
  • Tras el prototipo de ARPANET de 1969, en el que los mensajes se transmitían de forma parcial, varias universidades, organismos gubernamentales y empresas empezaron a construir sus propias redes y a interconectarlas
  • En 1990 apareció BGP v2
  • En 1994, BGP v4 fue definido en RFC 1654
  • BGP v4 fue revisado y parchado en 1995 y 2006, y sigue usándose para seleccionar rutas entre redes interconectadas en la Internet moderna

Rutas BGP, peering y tablas de enrutamiento

• Un border gateway, es decir, un router en el límite de un sistema autónomo, mantiene una tabla de enrutamiento: una lista de todas las rutas BGP que conoce
• Cada ruta BGP especifica un camino de ASN que puede seguirse para llegar al AS que controla un conjunto concreto de direcciones IP
• Las rutas BGP se forman a través de relaciones de peering entre AS
  • Si los border gateway de dos AS hacen peering, el tráfico puede pasar entre ambos routers
  • Además comparten información actualizada sobre las rutas BGP que conocen
• Por ejemplo, si el Router A del AS0001 y el Router B del AS0002 están conectados físicamente y quieren hacer peering, intercambian mensajes BGP para establecer una sesión BGP
  • El Router A aprende que para las rutas BGP que comienzan con AS0002 debe pasar por el Router B
  • El Router B también aprende la información en sentido contrario
• Los peers comparten las rutas que conocen mediante el proceso de route advertisement
  • Si el Router A le anuncia al Router B todas las rutas que conoce, el Router B añade a su tabla de enrutamiento las rutas que comienzan con AS0001
  • Si otro peer del Router A le anuncia una nueva ruta, el Router A también se la retransmite al Router B
• A medida que esos anuncios se propagan por toda la red de AS, cada border gateway termina conociendo uno o más AS path para llegar a cualquier IP de Internet
• Cuando un router necesita enviar un paquete a una IP específica, busca en su tabla de enrutamiento una ruta hacia el AS que controla esa IP
  • Después elige la “mejor” ruta según varias heurísticas
  • Entre esas heurísticas están la búsqueda de la ruta más corta y preferencias o rechazos codificados de forma explícita para ciertos AS
  • Luego el router envía el paquete al gateway router con peering hacia el primer AS de la ruta elegida

Cómo leer un traceroute desde la perspectiva de BGP

• El AS path del traceroute de ejemplo es AS4766 → AS201011 → AS24940
• En algún momento, el paquete llegó a uno de los routers de AS4766, y ese router tenía peering con un router de AS201011
  • El router determinó en su tabla de enrutamiento que la IP de destino era alcanzable por una ruta que comenzaba con AS201011
  • Luego envió el paquete al router conectado de AS201011
• Dentro de un mismo ASN pueden aparecer varios saltos
  • Como los seis saltos a través de Hetzner Online, el traceroute no muestra solo routers en el borde del AS, sino todos los routers por los que pasó el paquete
• Si los routers internos de un AS conocen una ruta interna eficiente, pueden preferirla por encima de una ruta BGP externa
  • Las rutas internas pueden aprenderse mediante iBGP, otros protocolos de enrutamiento internos o configuraciones codificadas manualmente
• Lo que realmente determina la conectividad en Internet no son los saltos internos, sino los acuerdos de peering entre distintos AS

[GN⁺]

Opiniones de Hacker News

• Hola, soy Lexi. Tengo 17 años y últimamente me interesa entender más a fondo cómo funcionan las computadoras y mostrarlo de formas nuevas.
  Hace unos meses publiqué https://cpu.land, y la discusión relacionada está en https://news.ycombinator.com/item?id=37062422.
  Después de cpu.land sentí mucha presión por crear otro resultado enorme, pero no tenía ninguna idea que me entusiasmara, así que estuve probando varios proyectos personales. En el proceso de aprender por casualidad cómo funciona Internet, terminé creando desde cero un programa de traceroute que se transmite en tiempo real a un sitio web.
  Nunca había visto algo así en la web, y pensé que era una forma bastante nueva e interesante de visualizar la estructura de Internet, así que lo pulí y lo convertí en un sitio bonito.
  En el proceso aprendí muchas cosas interesantes sobre BGP y la estructura de Internet, así que combiné la herramienta de traceroute con un texto para compartir ese conocimiento.
  Todavía sigo retocándolo y seguro que el código se va a romper en algún lado, así que me gustaría que me avisen si tienen sugerencias.
  Por cierto, el motivo de usar Rust es que, aunque no creo que la elección del lenguaje de programación sea tan importante, quería escribir rápido un programa de bajo nivel confiable y me gustaron los elementos básicos de manejo de errores de Rust.

  • Si “nunca viste algo así en la web”, busca looking glass bgp y vas a encontrar cosas parecidas.
    Uno de los primeros programas CGI que hice hace casi 30 años fue un script en Perl que envolvía traceroute y transmitía los resultados con server push.
    Lo viejo vuelve a ser nuevo, pero aun así la presentación del sitio es muy buena.
    Como referencia, el TTL de IPv4 legalmente está en segundos, pero como ningún router consume más de 1 segundo y el decremento mínimo es 1, en la práctica se usa como conteo de saltos. Los middleboxes que quieren mantenerse ocultos a veces ni siquiera lo reducen.
    Además, traceroute en Linux/Unix por defecto usa UDP hacia puertos altos normalmente cerrados para los paquetes de sondeo, en vez de ICMP, porque históricamente era menos probable que UDP fuera descartado o filtrado que ICMP.
    Preguntar cómo funciona traceroute es una de mis preguntas de entrevista, pero la mayoría no lo sabe y, si lo sabe, la pregunta pierde valor. Aunque haga muchas preguntas sobre TCP/IP, mucha gente no logra razonar desde primeros principios; aun así, creo que ver si pueden resolverlo es una pregunta razonable de resolución de problemas.
    Ej.: https://www.bgplookingglass.com/
    https://www.oreilly.com/openbook/cgi/ch06_06.html
  • Gran proyecto. Tengo una sugerencia seria y otra más ligera.
    Me pregunto si usar TCP o UDP en vez de ICMP podría dar resultados más precisos. El traceroute tradicional también tiene una opción UDP, mtr [1] puede usar TCP o UDP, y tcptraceroute [2] puede usar TCP.
    Y queda perfecto meter una cita de Talking Heads: “And you may ask yourself, well, how did I get here?” [3]
    [1] https://github.com/traviscross/mtr
    [2] https://linux.die.net/man/1/tcptraceroute
    [3] https://en.wikipedia.org/wiki/Once_in_a_Lifetime_(Talking_He...
  • Estás haciendo muchas más cosas geniales de las que yo hacía a los 17. Si te gustó “I, Robot”, también te recomiendo Stories of Your Life and Others de Ted Chiang. La película Arrival se basó en una de las obras de esa colección de cuentos.
  • Es un buen sitio para explicar traceroute, así que resulta útil. Creo que podría usarlo para explicar para qué sirve traceroute a varios técnicos a los que estoy capacitando para mantener la red de la empresa.
    Ahora solo falta averiguar cómo hacer que traceroute funcione en cada salto desde una estación de trabajo específica hasta un switch de acceso Cisco de la empresa, un switch core, un túnel BGP que va por AWS Transit Gateway y, finalmente, la tabla de enrutamiento VPC de una instancia EC2; entonces quizá pueda llamarme encargado de redes.
  • Genial. Me puse nervioso pensando que quizá se vería el circuito de Tor.
    Por desgracia, demasiados nodos ignoraron los paquetes de traceroute, así que solo pareció que mi nodo de salida se conectaba a Linode y que Linode se conectaba a tu computadora.
    En el traceroute hacia adelante pasa algo parecido: responde un router y responde el servidor, y con suerte se ve más o menos un nodo de la red del ISP. El resto está fuertemente bloqueado.

• Dices que “BGP es el protocolo que le da forma a Internet, y no se le puede hablar directamente”, pero en realidad es sorprendentemente fácil que una persona obtenga un ASN y hable BGP.
  Si te interesa crear herramientas de este tipo, vale la pena probarlo. Si te interesa, también tengo una guía introductoria que escribí hace un tiempo: https://qt.ax/asn

• Esto es menos “cómo mi computadora llega a tu servidor” y más la ruta inversa de cómo tu servidor llega a mi computadora. Es muy probable que el enrutamiento en ambos sentidos sea bastante distinto.

  • Dentro del texto hay una sección Front to Back, Back to Front que de hecho trata este tema.
    En resumen, según mi experiencia, las redes atravesadas suelen ser muy parecidas, y en cualquiera de las dos direcciones el contenido es relevante e interesante.
  • En la época de los bang paths era divertido ver cuán distinto era el bang path del remitente respecto del bang path para responder, e inferir qué diferencias de conectividad de red generaban la asimetría.

• Hay un paper interesante sobre cómo funciona traceroute. Algo que quienes no vienen del mundo de redes suelen pasar por alto es que traceroute no necesariamente es simétrico. La ruta de retorno puede ser distinta
  https://archive.nanog.org/sites/default/files/traceroute-201...

  • Hoy hubo una interrupción de Internet en Egipto por un problema de Telecom Egypt, y los traceroute hacia el mismo destino tomaron 8 rutas distintas
    Diría que es el doble de la cantidad de ECMP que había visto hasta ahora en Internet
    Además, el tráfico de nuestra oficina en El Cairo hacia el core del Reino Unido y el tráfico en sentido contrario también toman rutas distintas. London→Cairo es directo y sigue teniendo mucha pérdida, pero Cairo→London ahora pasa por ntt y se ve bien. Si no se arregla para mañana, quizá tengamos que cambiar la preferencia local
  • Rara vez, la ruta de datos en sí también puede ser asimétrica. Por ejemplo, en casos como satélites que usan uplink terrestre
  • Gracias, lo voy a leer. También traté esa dualidad en el artículo

• Dijeron que “WHOIS es un protocolo interesante para crear un parser”, pero en la práctica es casi imposible
  Las respuestas son esencialmente de formato libre, y puede que el servidor ni siquiera responda. Yo también lo intenté: hace 10 años pude hacer un parser provisional que funcionaba para el 90% de las direcciones o dominios, pero el resto era imposible de manejar
  Hoy está peor, y casi todo está oculto detrás de protecciones de privacidad. Dicen que protegen la PII, pero los registros WHOIS originalmente no estaban pensados para contener datos personales, sino contactos de operadores de red
  Creo que esto es culpa de ICANN. ICANN tenía una regla que exigía que las redes ofrecieran servidores WHOIS públicos, pero no la hizo cumplir, y ahora descartó esa regla

  • ¿WHOIS no debería incluir email, teléfono y dirección física? Si es una empresa quizá no sea PII, pero si es el WHOIS de un sitio web personal, no veo cómo eso no sería información personal
  • RDAP contiene parte de la información de WHOIS en formato JSON legible por máquina. No todo, pero me parece mejor
    Aunque no todos operan servidores RDAP. Ojalá ICANN/IANA o alguien obligara a hacerlo
    La información del operador de red también puede ser PII. Mi información es PII, y como tengo un nombre de dominio, poner mi información en WHOIS es poner PII en WHOIS
    Los servicios de privacidad simplemente me reenvían todo excepto el spam
    Si fuera una empresa, no veo una buena razón para permitir servicios de privacidad, pero no todos los dominios pertenecen todavía a grandes empresas
  • Sobre la parte de que se puede hacer un parser provisional para el 90% de las direcciones o dominios, pero el resto es difícil: ¿no podría ayudar hoy la IA generativa? Algo como “aquí está el whois, extrae la información que quiero”

• En vez de hacer un rastreo ICMP ECHO separado, se podría ir un paso más allá aprovechando la conexión HTTP TCP existente entre el navegador del cliente y el servidor web
  Eso permitiría atravesar el NAT o firewall con estado del lado del cliente

  • Interesante. Me pregunto cómo funcionaría con traceroute real
  • A eso se le llama parasitic traceroute

• Hay trabajos previos sobre reverse traceroute
  https://research.cs.washington.edu/networking/astronomy/reve...
  Paper: http://www.cs.washington.edu/homes/ethan/papers/reverse_trac...
  Video: http://www.usenix.org/multimedia/nsdi10katz-bassett

• También vale la pena saber que los paquetes de una sesión TCP suelen tomar rutas asimétricas al pasar por Internet. En mi experiencia, las razones más comunes fueron reglas de negocio relacionadas con costos y errores humanos
  Si piensas en cómo funciona IP, esto en sí no es particularmente problemático, pero puede hacer que el ruteo sea más difícil de entender

  • Tengo una anécdota divertida
    Boise State University y University of Idaho son universidades en extremos opuestos del estado de Idaho. UIdaho, al norte, está cerca de Spokane y la mayor parte de sus conexiones vienen de Seattle; Boise está más cerca de Salt Lake y suele conectarse a través de Portland o Salt Lake City
    La zona central del estado entre ambas universidades es montañosa, así que casi no había conexiones grandes, pero antes UofIdaho tenía aulas remotas en la región sur, por lo que existía un enlace pequeño
    En algún momento a fines de los 90, un ingeniero de red de BSU y un ingeniero de UofI se dieron cuenta de que tenían switches y equipos de ruteo en el mismo edificio, y conectaron un cable Ethernet entre ambos
    El resultado fue un desastre. Las dos redes empezaron a anunciarse BGP entre sí, y esa conexión se anunció a todo Internet. De repente apareció un salto muy corto entre las redes del lado de Seattle y las del lado de Salt Lake City, y esa pobre pequeña línea T1 quedó completamente saturada
    Curiosamente, solo pasó en una dirección. Boise anunció la ruta, pero Idaho no, así que el tráfico básicamente se rompió en una sola dirección
    Por supuesto, desconectaron el cable, y años después, cuando trabajé en UofIdaho, seguía siendo bien sabido que esas dos redes no debían volver a conectarse jamás. Irónicamente, en ese momento yo estaba llevando adelante un programa para desplegar I2 en ambas universidades

• En mi dispositivo no veo ningún salto intermedio entre mi equipo y el servidor. Solo como referencia

  • Sí, perdón. Hacker News hizo que el servidor quedara bastante sobrecargado
    Estoy trabajando en eso ahora mismo y espero que pronto funcione mejor. Mientras tanto aumenté los timeouts, así que cargará más lento, pero debería funcionar mejor
  • Quizá funcione mejor si no miras HN desde dentro del datacenter de Linode :P

• También vale la pena mencionar mtr. Lo uso mucho más seguido que traceroute
  Ayuda a diagnosticar pérdidas intermitentes de paquetes y permite entender el flujo en promedio
  Este artículo de APNIC explica con más detalle mtr y cómo leer sus resultados, y también aborda cómo MPLS puede ocultar la ruta real
  https://blog.apnic.net/2022/03/28/how-to-properly-interpret-...
  Rastrear con UDP también puede ser útil a veces, y conviene tener en cuenta que muchos routers descartan ICMP de forma selectiva cuando están bajo carga
  Buen artículo y muy bien expresado