Show HN : comment l’ordinateur a-t-il atteint mon serveur ?

• Lorsqu’un visiteur ouvre le site web, le serveur exécute un traceroute vers son adresse IP publique et affiche, comme un texte en temps réel, le trajet des paquets à travers les routeurs et les réseaux
• L’outil maison ktr augmente progressivement la valeur TTL des paquets ICMP, collecte les réponses d’erreur à chaque saut et interroge en parallèle les informations réseau de chaque saut
• Le rafraîchissement de l’écran n’est pas implémenté en JavaScript : il consiste à continuer d’envoyer du HTML et du CSS dans une réponse HTTP ouverte, de sorte que les résultats apparaissent progressivement pendant le chargement de la page
• Le chemin affiché est l’inverse d’un traceroute inverse envoyé par le serveur vers l’adresse IP du visiteur ; en raison des différences de routage entre les deux sens, il peut donc ne pas correspondre exactement au chemin réel
• Les chemins Internet sont formés par le peering BGP entre systèmes autonomes (AS) et par la propagation des tables de routage ; le trafic se déplace en suivant des réseaux interconnectés

---

Un traceroute personnalisé généré à chaque connexion

• Le texte vert en haut de la page n’est pas un exemple préenregistré, mais un traceroute généré à la volée pour le visiteur pendant le chargement du site
• Le traceroute montre le trajet parcouru par l’ordinateur du visiteur, ou par ses paquets, à travers Internet pour atteindre le serveur qui héberge ce site web
• Un chemin d’exemple commence au routeur du visiteur, traverse le réseau du FAI, passe par plusieurs réseaux, entre dans le réseau interne de Hetzner, puis atteint le serveur
  • Le premier routeur peut ne pas répondre au ping ; c’est courant derrière un routeur public ou un VPN
  • Des entrées (no response) peuvent apparaître au milieu, car tous les serveurs ne répondent pas toujours
• Des noms comme core3.sto.hetzner.com sont le résultat d’une résolution DNS inverse effectuée sur l’IP 213.239.252.74 issue du traceroute, afin de la convertir en un nom lisible par un humain
  • Les noms DNS inverses servent surtout à faciliter le débogage, et il arrive souvent qu’ils ne se remappent pas vers l’IP d’origine

ktr et le traceroute basé sur ICMP

• L’implémentation du site utilise le programme de traceroute maison ktr
  • Le code source du site est également publié sur GitHub
  • ktr diffuse les résultats en temps réel tout en interrogeant simultanément les informations de chaque saut
• Dans le routage Internet, l’ordinateur ou le routeur qui traite un paquet choisit le prochain équipement de transmission, et ce processus se poursuit jusqu’à atteindre un routeur capable de l’envoyer directement à destination
• L’implémentation de ktr utilise ICMP
  • ICMP est un protocole conçu pour envoyer des informations de diagnostic sur Internet
  • Presque tous les appareils connectés à Internet prennent en charge ICMP
• Le champ TTL (time to live) d’un paquet ICMP n’est pas une durée réelle, mais une valeur de compte à rebours
  • Chaque fois qu’un routeur transmet un paquet ICMP, il doit réduire le TTL de 1
  • Quand le TTL atteint 0, le routeur cesse de transmettre le paquet et envoie à l’adresse IP d’origine un message d’erreur indiquant que le nombre maximal de sauts a été atteint
• traceroute envoie des paquets ICMP avec des TTL progressivement augmentés, comme 1, 2, 3, afin de collecter les réponses d’erreur renvoyées par chaque saut
  • Les paquets d’erreur contiennent des informations de diagnostic, comme l’adresse IP de l’appareil qui a envoyé l’erreur
  • Cela permet de retracer le chemin approximatif des paquets à travers Internet

Un affichage qui semble temps réel, sans JavaScript

• La page fonctionne même avec JavaScript désactivé
  • Du point de vue du navigateur, le site semble simplement se charger lentement
  • Pour l’utilisateur, le traceroute semble apparaître en temps réel
• À la connexion, le serveur reçoit la requête HTTP provenant de l’adresse IP du visiteur et lance immédiatement un traceroute vers cette IP
• Le serveur envoie d’abord le début de la réponse HTTP, puis garde la connexion ouverte
  • ktr transmet les mises à jour du traceroute au serveur
  • Le serveur rend le HTML correspondant et l’envoie à l’ordinateur du visiteur
  • Une fois le traceroute terminé, il envoie le reste du texte et du contenu du site web, puis ferme la connexion
• Si les lignes du traceroute semblent se mettre à jour progressivement depuis le haut plutôt que depuis le bas, c’est grâce à une insertion de blocs CSS
  • Une page web ne peut, par défaut, se charger que vers l’avant
  • À chaque mise à jour de l’affichage du traceroute, le serveur insère aussi du CSS qui masque l’affichage précédent
  • Comme le navigateur rend le CSS pendant le chargement, l’écran donne l’impression d’être modifié au fil du temps

Les limites du traceroute inverse

• Le chemin affiché par la page n’est pas exactement « le chemin par lequel les paquets du visiteur ont atteint le serveur »
• Pour calculer le chemin réel, il faudrait pouvoir exécuter un traceroute depuis l’ordinateur du visiteur vers le serveur
• L’implémentation exécute un traceroute depuis le serveur vers l’ordinateur du visiteur, puis affiche le résultat à l’envers
  • C’est pourquoi le traceroute en haut de page semble se charger en ordre inverse
• Le traceroute inverse sacrifie une partie de la précision
  • Lorsque les paquets circulent dans la direction opposée, chaque appareil peut prendre des décisions de routage différentes
  • Il suffit qu’un seul appareil prenne une autre décision pour que le reste du chemin change
• Le chemin reste toutefois globalement similaire ; les différences se situent probablement surtout au niveau du routeur précis qui voit passer le paquet

Systèmes autonomes et requêtes WHOIS

• Les « réseaux » qui apparaissent dans le traceroute désignent des systèmes autonomes (AS)
  • Un AS est un ensemble de routeurs et de serveurs interconnectés de manière privée
  • Il appartient généralement à la même entreprise
• Le propriétaire d’un AS choisit à quels autres AS se connecter, ce qui détermine la forme d’Internet
  • Le trafic Internet circule à travers des AS qui ont conclu entre eux des accords de peering
• Internet ressemble à un réseau ouvert, mais c’est en réalité un réseau de réseaux appartenant à des entreprises, où l’accès et le contrôle dépendent de transactions financières et de procédures bureaucratiques
• Si vous voulez votre propre système autonome, vous pouvez demander un ASN à l’un des cinq registres Internet régionaux (RIR)
  • Sans le soutien d’une entreprise ou sans points de contact suffisants avec Internet, la demande a peu de chances d’être acceptée
  • Les nombres comme AS4766 dans un traceroute sont des ASN
• ktr utilise le protocole WHOIS pour obtenir les informations sur l’AS propriétaire de chaque IP de saut
  • Plusieurs organisations suivent quel AS contient quelles adresses IP
  • De nombreuses organisations proposent des recherches d’ASN via WHOIS
• PeeringDB est également utilisé pour identifier les informations d’entreprise
  • PeeringDB possède des informations sur environ un tiers de l’ensemble des systèmes autonomes
  • Les résultats de recherche sont combinés à plusieurs centaines de lignes d’instructions if pour générer les descriptions de traversée des réseaux
• La spécification du protocole WHOIS définit très peu de structure
  • Elle précise essentiellement qu’il faut établir une connexion TCP, envoyer ce que l’on souhaite rechercher, puis que le serveur renvoie des informations avant de fermer la connexion
  • La structure réelle des réponses WHOIS relève plutôt de conventions créées par les administrateurs de serveurs, et les noms des champs nécessaires peuvent varier, comme origin ou originas
  • Le parseur de ktr ressemble moins à un parseur strict qu’à la façon dont une personne lirait un résultat WHOIS pour y trouver l’ASN nécessaire

Comment BGP crée les chemins sur Internet

• Les routeurs situés aux frontières des réseaux décident vers quel réseau envoyer ensuite un paquet, et le même processus se répète jusqu’à atteindre le réseau où se trouve l’appareil de destination
• Ces routeurs de frontière échangent, via le Border Gateway Protocol (BGP), des informations sur les réseaux qu’ils peuvent atteindre
  • BGP est le protocole qui façonne la structure d’Internet
  • Un utilisateur ordinaire ne peut pas parler directement BGP
• La première version de BGP est décrite dans la RFC 1105, publiée en 1989 par des ingénieurs de Cisco et d’IBM
  • Après l’envoi partiel d’un message sur le prototype ARPANET en 1969, plusieurs universités, agences gouvernementales et entreprises ont commencé à créer leurs propres réseaux et à les interconnecter
  • BGP v2 est sorti en 1990
  • En 1994, BGP v4 a été spécifié dans la RFC 1654
  • BGP v4 a fait l’objet de révisions et de correctifs en 1995 et 2006, et reste utilisé pour choisir les chemins entre réseaux interconnectés dans l’Internet moderne

Chemins BGP, peering et tables de routage

• Un border gateway, routeur situé à la frontière d’un système autonome, maintient une table de routage : la liste de tous les chemins BGP qu’il connaît
• Chaque chemin BGP spécifie un chemin d’ASN pouvant être suivi pour atteindre l’AS qui contrôle un ensemble donné d’adresses IP
• Les chemins BGP se forment au moyen des relations de peering entre AS
  • Lorsque les border gateways de deux AS deviennent peers, du trafic peut circuler entre les deux routeurs
  • Ils partagent et tiennent à jour les informations de chemins BGP qu’ils connaissent mutuellement
• Par exemple, si le Router A d’AS0001 et le Router B d’AS0002 sont physiquement connectés et veulent établir un peering, ils échangent des messages BGP pour établir une session BGP
  • Router A apprend que les chemins BGP commençant par AS0002 doivent passer par Router B
  • Router B apprend aussi les informations dans le sens opposé
• Les peers partagent les chemins qu’ils connaissent via le processus d’annonce de routes (route advertisement)
  • Si Router A annonce à Router B tous les chemins qu’il connaît, Router B ajoute à sa table de routage les chemins commençant par AS0001
  • Si un autre peer de Router A annonce un nouveau chemin, Router A le transmet aussi à Router B
• À mesure que ces annonces se propagent dans l’ensemble du réseau d’AS, chaque border gateway finit par connaître un ou plusieurs AS path permettant d’atteindre une IP donnée sur Internet
• Lorsqu’un routeur doit envoyer un paquet vers une IP donnée, il cherche dans sa table de routage le chemin vers l’AS qui contrôle cette IP
  • Il sélectionne ensuite le « meilleur » chemin au moyen de plusieurs heuristiques
  • Ces heuristiques incluent la recherche du chemin le plus court et des préférences ou répulsions codées en dur pour certains AS
  • Le routeur envoie le paquet au gateway router appairé avec le premier AS du chemin choisi

Lire un résultat de traceroute du point de vue de BGP

• L’AS path du traceroute d’exemple est AS4766 → AS201011 → AS24940
• À un moment donné, le paquet a atteint l’un des routeurs d’AS4766, qui était appairé avec un routeur d’AS201011
  • Le routeur a déterminé, à partir de sa table de routage, que l’IP de destination était atteignable via un chemin commençant par AS201011
  • Il a ensuite envoyé le paquet au routeur AS201011 connecté
• Plusieurs sauts peuvent apparaître au sein d’un même ASN
  • Comme les six sauts à travers Hetzner Online, traceroute montre non seulement les routeurs de frontière entre AS, mais tous les routeurs traversés par le paquet
• Les routeurs internes à un AS peuvent privilégier un chemin interne plutôt qu’un chemin BGP externe s’ils connaissent un itinéraire interne efficace
  • Les chemins internes peuvent être appris via BGP interne, via d’autres protocoles de routage internes ou par codage en dur
• Le facteur clé qui détermine la joignabilité sur Internet n’est pas le nombre de sauts internes, mais les accords de peering entre différents AS

[GN⁺]

Avis de Hacker News

• Bonjour, je suis Lexi. J’ai 17 ans, et en ce moment ce qui m’intéresse, c’est de mieux comprendre comment fonctionnent les ordinateurs et de le montrer d’une façon nouvelle.
  Il y a quelques mois, j’ai publié https://cpu.land, avec la discussion associée ici : https://news.ycombinator.com/item?id=37062422
  Après cpu.land, je me sentais très poussée à produire un autre gros résultat, mais je n’avais pas vraiment d’idée qui me motivait. J’ai donc bricolé divers projets personnels, puis, en apprenant par hasard comment Internet fonctionne, j’ai fini par créer de zéro un programme traceroute diffusé en temps réel sur un site web.
  Je n’avais jamais vu ce genre de chose sur le web, et comme je trouvais que c’était une manière assez nouvelle et sympa de visualiser la structure d’Internet, je l’ai peaufinée et transformée en joli site.
  En chemin, j’ai appris beaucoup de choses intéressantes sur BGP et la structure d’Internet, donc j’ai combiné l’outil traceroute avec un article qui partage ces connaissances.
  Je continue encore à y travailler, et le code va forcément casser quelque part, donc si vous avez des suggestions, je serais ravie de les entendre.
  Au passage, pourquoi Rust ? Je ne pense pas que le choix du langage de programmation soit extrêmement important, mais je voulais écrire rapidement un programme bas niveau fiable, et j’aime les primitives de gestion d’erreurs de Rust.

  • Si vous « n’avez jamais vu ça sur le web », cherchez looking glass bgp : vous trouverez des choses similaires.
    L’un des premiers programmes CGI que j’ai créés il y a près de 30 ans était un script Perl qui enveloppait traceroute et diffusait les résultats en server push.
    Les vieilles choses redeviennent nouvelles, mais la présentation du site est tout de même très réussie.
    Au passage, le TTL IPv4 est légalement exprimé en secondes, mais aucun routeur ne consomme plus d’une seconde, et comme la décrémentation minimale est de 1, il est de fait utilisé comme un nombre de sauts. Les middleboxes qui veulent rester cachées peuvent même ne pas le décrémenter du tout.
    Autre point : sous Linux/Unix, traceroute utilise par défaut pour ses paquets de sondage de l’UDP vers des ports élevés généralement fermés, plutôt que de l’ICMP, parce qu’historiquement l’UDP avait moins de chances d’être supprimé ou filtré que l’ICMP.
    Demander comment fonctionne traceroute fait partie de mes questions d’entretien, mais la plupart des gens ne le savent pas, et s’ils le savent déjà, la question perd de sa valeur. Même quand on pose beaucoup de questions sur TCP/IP, beaucoup n’arrivent pas à raisonner à partir des premiers principes ; voir s’ils peuvent tout de même le déduire me semble une question raisonnable de résolution de problème.
    Exemple : https://www.bgplookingglass.com/
    https://www.oreilly.com/openbook/cgi/ch06_06.html
  • Super projet. J’ai une suggestion sérieuse et une autre plus légère.
    Je me demande si utiliser TCP ou UDP au lieu d’ICMP permettrait d’obtenir des résultats plus précis. Le traceroute traditionnel a aussi une option UDP, mtr [1] peut utiliser TCP ou UDP, et tcptraceroute [2] peut utiliser TCP.
    Et il y a une citation de Talking Heads qui irait parfaitement : « 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...
  • Tu fais beaucoup plus de choses cool que moi à 17 ans. Si tu as aimé « I, Robot », je recommande aussi Stories of Your Life and Others de Ted Chiang. Le film Arrival est basé sur une nouvelle de ce recueil.
  • C’est un bon site pour expliquer traceroute, donc utile. Je pense pouvoir m’en servir pour expliquer à quoi sert traceroute à plusieurs techniciens que je forme à la maintenance du réseau de l’entreprise.
    Maintenant, il ne me reste plus qu’à comprendre comment faire fonctionner traceroute à chaque saut depuis un poste donné jusqu’à la table de routage VPC d’une instance EC2, en passant par le switch d’accès Cisco de l’entreprise, le switch cœur, puis le tunnel BGP vers l’AWS Transit Gateway, et on pourra m’appeler responsable réseau.
  • Super. J’ai eu peur qu’on voie le circuit Tor.
    Malheureusement, trop de nœuds ignorent les paquets traceroute, donc ça donnait seulement l’impression que mon nœud de sortie se connectait à Linode, et que Linode se connectait à ton ordinateur.
    Sur un traceroute dans le sens direct, c’est similaire : le routeur répond, le serveur répond, et avec un peu de chance on voit peut-être un nœud du réseau du FAI. Le reste est bien verrouillé.

• Il est dit que « BGP est le protocole qui donne sa forme à Internet, et qu’on ne peut pas lui parler directement », mais en réalité, il est étonnamment facile pour un particulier d’obtenir un ASN et de parler BGP.
  Si créer ce genre d’outil vous intéresse, ça vaut le coup d’essayer. Si ça vous tente, j’ai aussi un guide d’introduction que j’avais écrit : https://qt.ax/asn

• Ce n’est pas tant « comment mon ordinateur atteint ton serveur » que l’inverse de la façon dont ton serveur atteint mon ordinateur. Le routage dans les deux sens a de fortes chances d’être assez différent.

  • Il y a en fait une section Front to Back, Back to Front dans l’article qui traite de ce sujet.
    En résumé, d’après mon expérience, les réseaux traversés sont généralement très similaires, et dans les deux sens le contenu est pertinent et intéressant.
  • À l’époque des bang paths, c’était amusant de comparer à quel point le bang path de l’expéditeur différait de celui utilisé pour la réponse, et d’en déduire quelles différences de connectivité réseau créaient cette asymétrie.

• Il existe un article intéressant sur le fonctionnement de traceroute. Un point que les personnes qui ne viennent pas du réseau oublient souvent, c’est que traceroute n’est pas forcément symétrique. Le chemin de retour peut être différent
  https://archive.nanog.org/sites/default/files/traceroute-201...

  • Aujourd’hui, il y a eu une panne Internet en Égypte à cause d’un problème chez Telecom Egypt, et les traceroute vers la même destination ont emprunté 8 chemins différents
    C’est sans doute deux fois plus d’ECMP que ce que j’avais vu jusqu’ici sur Internet
    Et le trafic entre notre bureau du Caire et le cœur de réseau au Royaume-Uni, ainsi que le trafic dans l’autre sens, empruntent eux aussi des chemins différents. London→Cairo est direct et subit encore de fortes pertes, mais Cairo→London passe maintenant par ntt et semble correct. Si ce n’est pas réparé d’ici demain, il faudra peut-être modifier la préférence locale
  • C’est rare, mais le chemin des données lui-même peut aussi être asymétrique. Par exemple dans le cas d’un satellite utilisant une liaison montante terrestre
  • Merci, je vais lire ça. J’ai aussi abordé cette dualité dans l’article

• Il disait que « WHOIS est un protocole intéressant pour écrire un parseur », mais en réalité c’est presque impossible
  Les réponses sont fondamentalement en format libre, et le serveur peut tout simplement ne pas répondre. J’ai essayé aussi : il y a 10 ans, j’avais pu bricoler un parseur ad hoc qui fonctionnait pour 90 % des adresses ou domaines, mais le reste était ingérable
  Aujourd’hui, c’est encore pire, et presque tout est caché derrière des protections de confidentialité. On prétend protéger les PII, mais les enregistrements WHOIS n’étaient pas censés contenir des informations personnelles : ils étaient censés contenir les contacts des opérateurs réseau
  Pour moi, c’est la faute de l’ICANN. L’ICANN avait une règle obligeant les réseaux à fournir un serveur WHOIS public, mais ne l’a pas appliquée, et a maintenant abandonné cette règle

  • WHOIS n’est-il pas censé contenir une adresse e-mail, un numéro de téléphone et une adresse physique ? Pour une entreprise ce n’est peut-être pas de la PII, mais pour le WHOIS d’un site personnel, je ne vois pas comment on peut dire que ce ne sont pas des données personnelles
  • RDAP contient une partie des informations WHOIS dans un format JSON lisible par machine. Pas tout, mais c’est mieux à mon avis
    Cela dit, tout le monde n’exploite pas un serveur RDAP. Ce serait bien que l’ICANN/IANA, ou quelqu’un, l’impose
    Les informations sur les opérateurs réseau peuvent aussi être de la PII. Mes informations sont des PII, et puisque j’ai un nom de domaine, mettre mes informations dans WHOIS revient à mettre de la PII dans WHOIS
    Les services de protection de la confidentialité ne font que tout me transmettre, sauf le spam
    Pour une entreprise, je ne vois pas de bonne raison d’autoriser un service de confidentialité, mais tous les domaines n’appartiennent pas encore à de grandes entreprises
  • Sur la partie où l’on peut faire un parseur ad hoc qui marche pour 90 % des adresses ou domaines, mais où le reste est obscur, est-ce que l’IA générative ne pourrait pas aider aujourd’hui ? Du genre : « voici un whois, extrais-moi les informations que je veux »

• Au lieu d’une trace ICMP ECHO séparée, on peut aller plus loin en exploitant la connexion HTTP TCP existante entre le navigateur client et le serveur web
  Cela permettrait de traverser le NAT ou le pare-feu à états côté client

  • Intéressant. Je me demande comment cela fonctionnerait avec un vrai traceroute
  • Ça s’appelle un parasitic traceroute

• Il existe des travaux antérieurs sur le reverse traceroute
  https://research.cs.washington.edu/networking/astronomy/reve...
  Article : http://www.cs.washington.edu/homes/ethan/papers/reverse_trac...
  Vidéo : http://www.usenix.org/multimedia/nsdi10katz-bassett

• Il faut aussi savoir que les paquets d’une session TCP empruntent souvent des chemins asymétriques sur Internet. D’après mon expérience, les raisons les plus courantes étaient des règles métier liées aux coûts, et des erreurs humaines
  Quand on réfléchit au fonctionnement de l’IP, ce n’est pas vraiment un problème en soi, mais cela peut rendre le routage plus difficile à comprendre

  • J’ai une anecdote amusante
    Boise State University et University of Idaho se trouvent aux deux extrémités de l’État de l’Idaho. UIdaho, au nord, est proche de Spokane et la plupart de ses connexions viennent de Seattle, tandis que Boise est plus proche de Salt Lake et se connecte souvent via Portland ou Salt Lake City
    Le centre de l’État entre les deux universités est montagneux et disposait de très peu de grandes liaisons, mais UofIdaho avait autrefois des salles de cours à distance dans le sud, donc il existait une petite ligne
    À un moment à la fin des années 90, un ingénieur réseau de BSU et un ingénieur de UofI ont découvert qu’ils avaient des switches et des équipements de routage dans le même bâtiment, et ont tiré un câble Ethernet entre les deux
    Le résultat a été catastrophique. Les deux réseaux ont commencé à s’annoncer mutuellement en BGP, et cette liaison a été propagée à tout Internet. Soudain, un saut très court est apparu entre les réseaux côté Seattle et côté Salt Lake City, et la pauvre petite ligne T1 a été totalement saturée
    Fait intéressant, cela ne se produisait que dans un sens. Boise annonçait la route, mais Idaho ne le faisait pas, si bien que le trafic était en pratique cassé dans un seul sens
    Évidemment, le câble a été débranché, et quelques années plus tard, quand je travaillais à UofIdaho, tout le monde savait qu’il ne fallait absolument jamais reconnecter ces deux réseaux. Ironiquement, à l’époque, je pilotais un programme de déploiement d’I2 dans les deux universités

• Sur mon appareil, je ne vois aucune étape intermédiaire entre mon appareil et le serveur. Pour info

  • Oui, désolé. Le serveur a été pas mal mis à genoux à cause de Hacker News
    Je suis dessus en ce moment même, et j’espère que ça fonctionnera mieux bientôt. En attendant, j’ai augmenté les timeouts : le chargement sera plus long, mais ça devrait mieux marcher
  • Ça marcherait peut-être mieux si tu ne consultais pas HN depuis le datacenter de Linode :P

• mtr mérite aussi d’être mentionné. Je l’utilise bien plus souvent que traceroute
  Il aide à diagnostiquer les pertes de paquets intermittentes et permet d’avoir une vue moyenne du flux
  Cet article de l’APNIC explique plus en détail mtr et la manière de lire ses résultats, et aborde aussi la façon dont MPLS peut masquer le chemin réel
  https://blog.apnic.net/2022/03/28/how-to-properly-interpret-...
  Tracer en UDP est aussi parfois utile, et il faut garder à l’esprit que beaucoup de routeurs suppriment sélectivement l’ICMP lorsqu’ils sont sous charge
  Bon article, et très bien formulé