Aller au contenu principal
Obtenir

Traceroute sur Mac, iPhone et iPad : trouvez où la route casse

Un vrai traceroute ICMP sur Mac, iPhone et iPad, diffusé saut par saut, et surtout : comment lire ce qui revient.

Par Lucas Russo, développeur de SSHive · Mis à jour le

Télécharger SSHive gratuitementTous les outils réseau
Aussi sur iPhone et iPad
Un service répond mal ou plus du tout, et rien de votre côté ne l'explique. Le DNS résout, le serveur tourne, votre lien local est propre. Ce que vous ne voyez pas, ce sont les quinze ou vingt routeurs situés entre votre machine et cet hôte, et c'est là que se trouve généralement la réponse. Traceroute est l'outil qui rend ces routeurs visibles. Il ne mesure pas votre connexion à un serveur : il reconstitue la suite des sauts que vos paquets empruntent pour l'atteindre, et le temps que chacun met à répondre. Bien lu, il vous dit si le problème vient de vous, de votre opérateur, d'un transitaire ou de la destination, autrement dit s'il faut corriger quelque chose ou ouvrir un ticket, et chez qui. Mal lu, il produit plus de fausses conclusions que n'importe quel autre outil réseau. Un saut rempli d'astérisques ressemble à un routeur mort et ne l'est presque jamais. Un pic à 300 ms au milieu du chemin paraît inquiétant alors qu'il s'agit le plus souvent d'un routeur qui déprioritise votre sonde tout en acheminant le trafic réel sans faiblir. Lire un traceroute, c'est surtout savoir quelles lignes sont des mesures et quelles lignes sont du bruit. SSHive mesure un vrai traceroute sur chacune de ses plateformes Apple : la version Mac App Store, l'iPhone et l'iPad. Il émet ses propres sondes ICMP, une valeur de TTL à la fois, trois sondes par palier, jusqu'à trente sauts, et diffuse l'adresse de chaque routeur et ses temps de réponse à mesure qu'ils arrivent. Rien n'est reformaté, rien n'est inventé. Cela mérite d'être dit clairement, car une version antérieure de cette page affirmait l'inverse. Elle soutenait qu'une application App Store en bac à sable ne peut pas faire de traceroute, faute de sockets ICMP bruts. L'affirmation n'avait jamais été mesurée, et elle est fausse : positionner IP_TTL et lire les réponses Time Exceeded fonctionne depuis un socket ICMP datagramme ordinaire, qui n'exige pas les privilèges root et que le bac à sable autorise. La suite explique le mécanisme, et comment lire la sortie.

Ce que fait SSHive

Ses propres sondes, pas le binaire du système

SSHive fabrique lui-même les sondes plutôt que de déléguer à un binaire, si bien que le même moteur tourne dans la version Mac App Store, sur iPhone et sur iPad. Une valeur de TTL par palier, trois sondes chacune, jusqu'à trente sauts, avec l'adresse du routeur et ses trois temps de réponse sur chaque ligne. Rien n'est fabriqué et aucun service tiers n'intervient : les paquets partent de votre appareil et les réponses y reviennent.

Sortie en direct, saut par saut

Les sauts s'affichent au fur et à mesure qu'ils répondent, ligne par ligne, dans un volet en police à chasse fixe qui défile tout seul. Un indicateur « En cours… » signale que la trace est en cours et le bouton Arrêter l'interrompt aussitôt : pratique quand le chemin bloque sur un saut filtré alors que vous aviez déjà la réponse au saut 6.

La même trace sur iPhone et iPad

Les applications iOS et iPadOS exécutent le même moteur ICMP que le Mac, avec la même limite de trente sauts et les mêmes trois sondes par palier : une trace lancée depuis votre téléphone est donc directement comparable à une trace lancée depuis votre Mac. C'est plus utile qu'il n'y paraît, car tracer le même hôte depuis le réseau cellulaire puis depuis le Wi-Fi du bureau est souvent ce qui désigne le réseau fautif.

Désactivé là où c'est impossible, jamais simulé

Quand le système refuse purement et simplement l'ICMP (certains réseaux d'entreprise et quelques configurations VPN le font), SSHive s'arrête et le dit, au lieu d'afficher une liste de sauts vraisemblable. Un refus est signalé comme un refus. Il en va de même pour un palier qui ne répond jamais : il s'affiche en astérisques, ce qui est un résultat réel et fréquent, pas une erreur.

Tracer, puis se connecter

Un traceroute se termine presque toujours par une question : c'est quoi ce dernier routeur qui répond, et est-ce que je peux entrer sur la machine derrière ? SSHive est avant tout un client SSH, SFTP, RDP et VNC : la réponse est à un onglet. Repérez le dernier saut valide, ouvrez une session vers l'hôte de rebond ou le serveur, et continuez dans la même fenêtre.

Gratuit, sans compte

Toute la suite d'outils réseau (traceroute, ping, résolution DNS, whois, MX et vérification DNSBL) fait partie de l'offre gratuite sur chaque plateforme où elle est disponible. Aucun verrou, aucune publicité, aucune inscription. SSHive Pro se paie une seule fois, en achat universel pour Mac, iPhone et iPad, et débloque des fonctions de session, pas les diagnostics.

Comment faire, étape par étape

  1. 1

    Ouvrir les outils réseau

    Sur Mac, cliquez sur l'icône réseau de la barre latérale, ou sur le bouton Outils réseau de l'écran d'accueil. Les deux ouvrent un onglet d'outils à côté de vos sessions : vous tracez un chemin sans fermer ce sur quoi vous travaillez. Sur iPhone et iPad, ces mêmes outils se trouvent dans l'onglet Outils.

  2. 2

    Repérer la carte Traceroute

    Le panneau d'outils regroupe ses cartes en trois sections, et vous pouvez déplacer ou masquer les cartes au sein d'une section pour ne garder que les outils qui vous servent. Traceroute est la dernière carte de la section Joignabilité, après Ping et Test de port.

  3. 3

    Saisir une destination et lancer la trace

    Saisissez un nom d'hôte ou une adresse IP dans le champ (l'exemple affiché est google.com) puis cliquez sur Tracer. SSHive résout la cible, puis commence à sonder avec un TTL de 1, en progressant d'un saut à la fois jusqu'à 30.

  4. 4

    Regarder les sauts arriver

    Les lignes arrivent au fur et à mesure que les routeurs répondent, avec un indicateur « En cours… » pendant la trace. Un saut en astérisques ne répond simplement pas dans le délai imparti : la trace passe au TTL suivant. Cliquez sur Arrêter dès que vous avez vu ce qu'il fallait.

  5. 5

    Agir sur le dernier saut qui répond

    Notez le dernier saut ayant répondu et si la destination a répondu tout court. De là, ouvrez une session SSH, RDP ou VNC vers l'hôte concerné dans la même fenêtre, ou recoupez avec les cartes Ping et Recherche DNS situées au-dessus.

Lire un traceroute sans en tirer de fausses conclusions

Chaque ligne correspond à une valeur de TTL, pas à une mesure de votre connexion. Trois sondes partent par saut, d'où les trois temps de réponse affichés, et leur dispersion compte autant que les valeurs : 10 / 11 / 10 ms, c'est un routeur stable ; 10 / 400 / 11 ms, c'est une sonde qui a attendu dans une file, et cela ne mérite presque jamais d'enquête. Chaque RTT inclut un chemin retour que vous ne voyez pas. La réponse du saut 8 revient par la route dont ce routeur dispose vers vous, qui n'est souvent pas l'inverse du chemin aller. C'est pourquoi le saut 8 peut afficher 90 ms alors que le saut 9 affiche 40 ms. Ce n'est ni une erreur ni une baisse de latence : la réponse du saut 8 a simplement pris un chemin de retour plus lent. Ne soustrayez jamais deux sauts voisins en appelant le résultat « la latence de ce lien ». Les astérisques sont la sortie la plus mal interprétée du réseau. Trois astérisques signifient qu'aucun message ICMP Time Exceeded n'est revenu avant expiration du délai (cinq secondes par défaut sous macOS). Trois causes ordinaires : le routeur ne génère aucune erreur ICMP, ce qui est courant dans les cœurs opérateurs et MPLS ; il limite le débit de génération d'erreurs ICMP et sacrifie la réponse à votre sonde tout en acheminant parfaitement le trafic ; ou un pare-feu bloque la sonde sortante (macOS utilise l'UDP à partir du port 33434) ou l'ICMP de retour. Dans les trois cas, le plan de données va bien. Le test est simple : si un saut postérieur répond, le saut silencieux a bien relayé votre paquet. Seuls des astérisques ininterrompus jusqu'à la fin de la trace veulent dire quelque chose. Même rigueur pour les pics. Un saut à 300 ms entre des voisins à 40 ms est un artefact du plan de contrôle : ce routeur a déprioritisé votre sonde. Ce qui compte, c'est de savoir si l'augmentation persiste sur tous les sauts suivants et jusqu'à la destination. Une marche qui se propage jusqu'au bout est réelle, mais peut relever de la géographie plutôt que d'une panne : une traversée transatlantique coûte ses 70 à 90 ms. Là où la route casse vraiment, c'est au dernier saut qui a répondu : le dernier routeur disposant à la fois d'une route vers votre cible et d'une route vers vous. Si rien après lui ne répond et que la destination reste muette, la rupture est à ce point ou juste après. Un motif de sauts qui se répète indique une boucle de routage. Et !H, !N, !X ou !A sont formels là où les astérisques ne le sont pas : c'est un routeur qui déclare explicitement la destination injoignable ou filtrée administrativement.

Questions fréquentes

Le traceroute fonctionne-t-il vraiment dans la version Mac App Store, sous bac à sable ?+
Oui, sans rien en moins. L'idée répandue du contraire repose sur une confusion entre deux types de socket. Le traceroute doit positionner IP_TTL sur les sondes sortantes et lire les réponses ICMP Time Exceeded renvoyées par les routeurs. Un socket brut serait effectivement refusé par le bac à sable, mais un socket ICMP datagramme fait les deux, n'exige pas root, et il est autorisé. Mesuré sous sandbox-exec avec les entitlements réels de l'application : setsockopt(IP_TTL) passe et les paliers remontent, routeur par routeur. Une réserve découverte à la dure : com.apple.security.network.client seul ne suffit pas, les réponses sont alors refusées en EPERM ; network.server est également nécessaire, et SSHive déclare les deux.
Peut-on lancer un traceroute depuis un iPhone ou un iPad ?+
Oui, et il s'agit d'une vraie mesure, pas d'une illustration. iOS n'autorise pas le lancement de processus et ne dispose d'aucun binaire setuid : une application ne peut donc pas appeler le traceroute du système, d'où l'idée répandue que la chose est impossible. Mais la contrainte ne porte que sur Network.framework, l'API de haut niveau d'Apple, qui n'a aucun transport ICMP. En dessous, la couche de sockets BSD est intacte : SSHive ouvre socket(AF_INET, SOCK_DGRAM, IPPROTO_ICMP), positionne IP_TTL sur chaque sonde et lit les réponses Time Exceeded, exactement comme sur Mac. Trente sauts, trois sondes par palier. Tracer le même hôte depuis le réseau cellulaire puis depuis le Wi-Fi est souvent le moyen le plus rapide d'établir quel réseau est en cause.
Que signifient trois astérisques dans un traceroute ?+
Qu'aucune des trois sondes de ce TTL n'a reçu de message ICMP Time Exceeded avant expiration du délai. En général, le routeur est configuré pour ne pas émettre d'erreurs ICMP, il en limite le débit, ou un pare-feu a bloqué la sonde ou la réponse. Cela ne signifie presque jamais qu'il est en panne. Si un saut ultérieur répond, ce routeur silencieux a parfaitement relayé votre paquet. Seuls des astérisques ininterrompus jusqu'à la fin de la trace constituent un vrai signal.
Pourquoi un saut intermédiaire affiche-t-il 300 ms quand la destination en affiche 40 ?+
Parce que répondre à votre sonde n'est pas le travail de ce routeur. Générer un ICMP Time Exceeded relève du plan de contrôle, traité par un processeur qui lui donne volontairement une faible priorité, tandis que le trafic relayé reste sur le chemin rapide. Un pic qui ne se propage pas aux sauts suivants est un artefact, pas une panne. Seule une hausse qui persiste sur tous les sauts suivants et jusqu'à la destination correspond à ce que subit réellement le trafic.
La trace s'arrête au saut 12 sans atteindre l'hôte. Le réseau est-il coupé ?+
Pas forcément. Beaucoup de destinations derrière un répartiteur de charge, un frontal anycast ou un pare-feu cloud ignorent silencieusement les sondes traceroute tout en servant le trafic TCP normalement : une trace qui s'éteint près de la fin alors que le service fonctionne est attendue. Vérifiez d'abord la connectivité sur le vrai port (c'est précisément le rôle du moteur TCP du ping). Si le service est réellement injoignable, le saut 12 est votre preuve : c'est le dernier routeur ayant une route vers la cible et une route vers vous, la rupture est donc à ce point ou juste après.
Peut-on changer la limite de sauts, ou sonder en UDP plutôt qu'en ICMP ?+
Pas depuis la carte SSHive. La trace s'exécute avec une limite fixe de 30 sauts, des sondes ICMP et trois sondes par palier, sans option de protocole, de port ni de nombre de sondes, et sans enrichissement ASN ou géographique. Si vous avez besoin de ces options sur Mac, /usr/sbin/traceroute les accepte dans le Terminal ; la carte sert au cas courant : tracer un hôte vite, sans quitter vos sessions, et sur iPhone et iPad, où aucun Terminal ne peut prendre le relais.
Traceroute fait-il partie de SSHive Pro ?+
Non. Traceroute et le reste de la suite d'outils réseau sont gratuits sur toutes les plateformes, sans verrou, sans publicité et sans compte à créer. SSHive Pro se paie une seule fois, en achat universel pour Mac, iPhone et iPad, sans abonnement ; il débloque des fonctions de session, pas les diagnostics.

TTL, erreurs ICMP, et comment une app en bac à sable y parvient quand même

Un en-tête IPv4 contient un champ TTL de 8 bits (appelé Hop Limit en IPv6) dont l'unique rôle est d'empêcher les paquets de circuler indéfiniment. Chaque routeur qui relaie un paquet le décrémente de un ; à zéro, il jette le paquet et renvoie un message ICMP Time Exceeded, type 11 code 0, émis depuis l'interface par laquelle le paquet est arrivé. Traceroute transforme ce mécanisme d'échec en mesure. Il envoie une sonde avec un TTL de 1, qui meurt au premier routeur et provoque une erreur qui l'identifie. Puis un TTL de 2, puis 3, en progressant d'un saut à la fois. Trois sondes par TTL produisent les trois temps affichés sur chaque ligne. La détection de la cible dépend du type de sonde : le traceroute BSD de macOS envoie des datagrammes UDP vers des ports hauts improbables à partir de 33434 et considère un ICMP Port Unreachable (type 3, code 3) comme le signal d'arrivée, tandis que tracert sous Windows envoie des ICMP Echo Request et s'arrête sur un Echo Reply. Cette différence n'est pas cosmétique : les pare-feu traitent très différemment les sondes UDP et l'ICMP Echo, si bien qu'une même destination produit légitimement des sauts en astérisques différents depuis un Mac et depuis une machine Windows. Vérifiez les deux avant d'accuser un routeur. Ce qui mène à la question que tout le monde tranche de travers, y compris une version antérieure de cette page : une application en bac à sable peut-elle seulement faire cela ? Le raisonnement qui conclut que non tient en trois temps. /usr/sbin/traceroute est installé setuid root sous macOS alors que /sbin/ping ne l'est pas, donc traceroute exigerait des privilèges que ping n'a pas ; le bac à sable n'accorde aucun privilège de ce type ; donc pas de traceroute dans une application App Store. Chaque étape paraît raisonnable et la conclusion est pourtant fausse, car la prémisse confond le type de sonde retenu par le traceroute BSD avec le traceroute en tant que technique. Ce binaire sonde en datagrammes UDP et il lui faut un socket brut pour lire les erreurs ICMP qu'ils provoquent, d'où le setuid. Sondez en ICMP Echo, et les réponses arrivent sur ce même socket ICMP datagramme que le ping utilise déjà sans privilèges. setsockopt(IP_TTL) n'est pas un appel privilégié. SSHive ne pilote donc aucun binaire système. Il ouvre socket(AF_INET, SOCK_DGRAM, IPPROTO_ICMP), positionne le TTL, envoie trois requêtes Echo par palier, et lit ce qui revient : un Time Exceeded qui nomme un routeur, une réponse Echo signifiant que la destination a répondu, ou rien en deux secondes, ce qui s'affiche en astérisque. Tout cela a été mesuré sous sandbox-exec avec les entitlements réels de l'application avant d'être livré, et a révélé un piège qui mérite d'être répété : avec com.apple.security.network.client seul, la sonde part et la réponse est refusée en EPERM, un échec silencieux qui ressemble exactement à un réseau filtrant. com.apple.security.network.server est également nécessaire. SSHive déclare les deux, et c'est pourquoi la version App Store, sous bac à sable, trace vraiment au lieu d'aligner une colonne d'astérisques. iOS arrive au même point par le même chemin. Network.framework expose TCP, UDP, QUIC et TLS, et aucun ICMP, mais ce n'est pas la seule API disponible : la couche de sockets BSD en dessous accepte le même socket ICMP datagramme, et l'exemple SimplePing d'Apple le démontre depuis des années. Les versions iPhone et iPad exécutent la même boucle de trente sauts et trois sondes que le Mac. Connaissez les limites avant de vous y fier : plafond fixe de 30 sauts, aucune option de protocole, de port ou de nombre de sondes, et aucun enrichissement ASN ou géographique. Comme les sondes sont des ICMP Echo plutôt que de l'UDP, un pare-feu qui autorise l'un et jette l'autre peut produire un motif d'astérisques différent de celui de /usr/sbin/traceroute ; aucun des deux résultats n'est faux, et les comparer est parfois la façon dont on trouve le pare-feu.

Outils liés

Ping

Recherche DNS

Whois