Skip to main content
Outils réseau

Suivez la route saut par saut et trouvez où elle casse vraiment

Un vrai traceroute système sur macOS et Windows, diffusé ligne par ligne — et surtout : comment lire ce qui revient.

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 exécute un vrai traceroute sur macOS (version en téléchargement direct) et sur Windows : il pilote le traceroute ou le tracert du système avec une limite de 30 sauts et renvoie la sortie telle quelle, ligne par ligne, à mesure que les sauts répondent. Deux limites, annoncées d'emblée. La version Mac App Store ne peut pas exécuter de traceroute : le bac à sable d'Apple n'accorde pas les sockets ICMP bruts nécessaires, la carte est donc affichée désactivée plutôt que simulée. Et SSHive ne mesure pas de vrai traceroute sur iPhone ni sur iPad. L'app iOS affiche un écran Traceroute, mais il s'agit d'un espace réservé : il n'émet pas de sondes à TTL limité et ne mesure pas de sauts réels — sa sortie est purement indicative. La suite explique pourquoi, quoi lancer à la place, et comment lire la sortie que vous obtenez.

Ce que fait SSHive

Le traceroute du système, pas une réécriture

Sur la version macOS en téléchargement direct, SSHive exécute le binaire système /usr/sbin/traceroute avec une limite de 30 sauts, lancé avec des arguments fixes plutôt qu'une ligne de commande interprétée. Vous lisez la sortie d'Apple telle quelle : numéro de saut, nom résolu, adresse IP et trois temps de réponse par ligne. Rien n'est reformaté, rien n'est fabriqué, aucun service tiers n'intervient.

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 « Running » signale que la trace est en cours et le bouton Stop 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.

Le tracert Windows dans le même panneau

Sous Windows, SSHive pilote tracert avec la même limite de 30 sauts et le même volet de sortie. À garder en tête si vous comparez : Windows sonde en ICMP Echo tandis que macOS envoie des datagrammes UDP vers des ports hauts. La même destination peut donc produire des sauts en astérisques différents sur les deux systèmes sans qu'aucun ne se trompe.

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

La version Mac App Store ne peut pas exécuter de traceroute : le bac à sable d'Apple n'accorde pas les sockets ICMP bruts requis. SSHive grise la carte et l'explique, plutôt que de renvoyer un volet vide. SSHive ne propose pas non plus de mesure traceroute sur iPhone ni sur iPad. Pour tracer un chemin depuis un Mac, prenez la version gratuite en téléchargement direct.

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 le 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 est un achat unique, Universel sur 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

    Dans l'application macOS ou Windows, cliquez sur l'icône réseau de la barre latérale, ou sur le bouton « Network tools » 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.

  2. 2

    Repérer la carte Traceroute

    L'onglet d'outils empile ses cartes dans un ordre fixe. Traceroute est la deuxième carte pleine largeur, sous la grille DNS, whois et réputation, à côté de Ping. Sur la version Mac App Store, la carte est présente mais grisée, avec une note expliquant la restriction du bac à sable.

  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 Trace. SSHive transmet la cible au traceroute du système, qui la résout et 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 « Running » 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 Stop 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 DNS Lookup 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 frequentes

Pourquoi Traceroute est-il grisé dans la version Mac App Store de SSHive ?+
Parce que traceroute exige des sockets ICMP bruts, que le bac à sable de macOS n'accorde pas aux applications de l'App Store. L'autorisation « client réseau » couvre les connexions sortantes, pas la fabrication de paquets. Plutôt que de renvoyer un volet vide, SSHive affiche la carte désactivée avec cette explication. Le reste du panneau fonctionne sur la version App Store : ping (sonde TCP), résolution DNS, whois, MX et DNSBL. Pour un vrai traceroute sur Mac, utilisez la version gratuite en téléchargement direct.
Peut-on lancer un traceroute depuis un iPhone ou un iPad ?+
Pas avec SSHive, et la contrainte vient de la plateforme, pas de l'application : iOS n'autorise pas le lancement de processus, ne dispose d'aucun binaire setuid et n'expose aucune API publique permettant d'émettre des sondes à TTL limité et de recevoir les erreurs ICMP. SSHive ne propose donc pas de mesure traceroute sur iPhone ni sur iPad. Les diagnostics mobiles sont le ping (sonde TCP), la résolution DNS, le whois sur le port TCP 43, le MX et le DNSBL. Pour tracer un chemin depuis un téléphone, connectez-vous en SSH à une machine et lancez traceroute dessus.
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. 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 forcer des sondes ICMP au lieu d'UDP ?+
Pas depuis la carte SSHive. La trace s'exécute avec une limite fixe de 30 sauts et le type de sonde par défaut de la plateforme — UDP vers des ports hauts sous macOS, ICMP Echo sous Windows — sans option de protocole, de port ni de nombre de sondes. La sortie est du texte brut, sans tableau structuré ni enrichissement ASN ou géographique. Si vous avez besoin de ces options sous macOS, le binaire sous-jacent les accepte dans le Terminal ; la carte sert au cas courant : tracer un hôte vite, sans quitter vos sessions.
Traceroute fait-il partie de SSHive Pro ?+
Non. Traceroute et le reste de la suite d'outils réseau sont gratuits sur chaque plateforme où ils sont disponibles, sans verrou, sans publicité et sans compte à créer. SSHive Pro est un achat unique, Universel sur Mac, iPhone et iPad, sans abonnement ; il débloque des fonctions de session, pas les diagnostics. La version macOS gratuite en téléchargement direct est d'ailleurs celle qui exécute un vrai traceroute : l'option la plus complète ici ne coûte rien.

TTL, erreurs ICMP, et pourquoi une app en bac à sable ne peut pas le faire

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. Le problème d'implémentation est un problème de privilèges. Fixer le TTL paquet par paquet et, surtout, recevoir les erreurs ICMP de retour exige un socket que le système ne distribue pas aux processus ordinaires. C'est précisément pour cela que /usr/sbin/traceroute est installé setuid root sous macOS alors que /sbin/ping ne l'est pas : ping peut utiliser un socket ICMP non privilégié, traceroute non. Une application en bac à sable n'hérite d'aucun de ces privilèges. L'autorisation « client réseau » couvre les connexions sortantes ; elle ne couvre ni la fabrication de paquets ni la lecture de l'ICMP brut, et le bac à sable refuse purement et simplement les sockets bruts. C'est toute la raison pour laquelle traceroute est indisponible dans la version Mac App Store de SSHive. La carte s'affiche désactivée avec une note explicite plutôt que d'échouer en silence : un outil de diagnostic qui ne renvoie rien sans rien dire est pire qu'un outil qui explique pourquoi il ne peut pas tourner. Sur la version macOS en téléchargement direct, il n'y a pas de bac à sable : SSHive lance le binaire système avec des arguments fixes — la limite de 30 sauts et la cible, jamais une ligne de commande interprétée — et redirige sa sortie vers le panneau au fil de l'eau. Windows suit le même chemin via tracert. iOS et iPadOS sont encore plus stricts : aucun lancement de processus, aucun binaire setuid, le traceroute système ne peut donc pas être piloté comme sur macOS et Windows. Réimplémenter la boucle de sondes sur des sockets BSD reste possible, mais ce n'est pas ce que SSHive embarque aujourd'hui : il n'y a donc pas de mesure traceroute sur iPhone ni sur iPad. Les diagnostics mobiles sont ceux qui peuvent être faits honnêtement : ping TCP, résolution DNS, whois interrogé directement sur le port TCP 43, MX et DNSBL. Pour tracer un chemin depuis un téléphone, la réponse pratique est celle pour laquelle SSHive existe : ouvrir une session SSH vers une machine qui dispose de traceroute et l'exécuter là-bas. Connaissez les limites avant de vous y fier : plafond fixe de 30 sauts, aucune option de protocole, de port ou de nombre de sondes, sortie en texte brut sans tableau structuré ni enrichissement ASN ou géographique, et dépendance au binaire traceroute du système, qui doit être présent dans le PATH.