Traceroute sur Linux, lire un chemin réseau sans se tromper

Traceroute on Linux sert à visualiser le chemin approximatif suivi par des paquets entre votre machine et une destination. Ce n’est pas un outil magique qui “voit Internet”, mais un diagnostic très utile pour comprendre où une connexion ralentit, se perd ou change de route.

Pour approfondir ce point, consultez créer utilisateur sudo linux, qui traite plus précisément de créer un utilisateur sudo sous linux sans perdre l’accès admin.

Sur Linux, la commande peut s’utiliser en UDP, ICMP ou TCP selon les options et les droits disponibles. Elle s’appuie sur le champ TTL des paquets IP : chaque saut décrémente cette valeur, et les routeurs intermédiaires peuvent répondre quand elle tombe à zéro. C’est cette mécanique qui permet d’afficher une liste de sauts sans avoir accès aux routeurs traversés.

La bonne lecture consiste à regarder les tendances, pas à paniquer au premier astérisque. Un saut muet, une latence élevée au milieu ou un nom DNS étrange ne signifie pas toujours que le problème est là.

Autrement dit, traceroute donne une piste de lecture, pas un verdict définitif sur la panne ou l’opérateur responsable.

Installer traceroute sur Linux

La commande n’est pas toujours installée par défaut. Sur Debian, Ubuntu et distributions proches, elle se trouve généralement dans le paquet traceroute. Sur Fedora, RHEL ou dérivés, le nom du paquet reste souvent explicite, mais l’outil peut cohabiter avec tracepath fourni par iputils.

sudo apt update
sudo apt install traceroute

sudo dnf install traceroute

Avant de conclure qu’un réseau bloque tout, vérifiez d’abord que l’outil existe sur votre machine. Une erreur du type commande introuvable relève du système local, pas de la route Internet. Cette distinction évite de perdre du temps sur un faux diagnostic réseau.

Lancer une commande simple

La forme la plus directe consiste à donner un nom de domaine ou une adresse IP. La commande envoie plusieurs sondes avec des TTL croissants, puis affiche les réponses reçues pour chaque saut. Le résultat varie selon la distribution, la version et les options compilées.

traceroute example.com
traceroute 1.1.1.1

Chaque ligne correspond à un saut. Vous voyez souvent un numéro, un nom d’hôte ou une adresse IP, puis plusieurs temps de réponse. Ces temps représentent les réponses aux sondes envoyées pour ce saut. Ils ne doivent pas être lus comme un débit, mais comme une mesure de latence à un instant donné, avec ses limites et ses priorités propres.

Pour éviter les lenteurs liées à la résolution DNS inverse, vous pouvez utiliser l’option -n. Elle affiche les adresses IP sans essayer de retrouver les noms. C’est souvent plus clair quand vous cherchez un problème de route plutôt qu’un joli libellé réseau.

traceroute -n example.com

Comprendre les sauts et les astérisques

Un saut est un équipement réseau qui a répondu à une sonde. Il peut s’agir de votre box, d’un routeur d’opérateur, d’un équipement de transit, d’un pare-feu ou d’une infrastructure du fournisseur de destination. Le premier saut correspond souvent à votre passerelle locale.

Les astérisques apparaissent quand aucune réponse n’est reçue dans le délai prévu. Cela peut indiquer un filtrage ICMP, une priorité très basse donnée aux réponses de diagnostic, une perte ponctuelle ou un équipement configuré pour ne pas répondre. Un astérisque isolé n’est donc pas une preuve de panne.

Le signal devient plus intéressant quand plusieurs lignes successives ne répondent plus et que la destination reste inaccessible. Là, vous avez peut-être une coupure, un filtrage ou une route qui ne revient pas correctement. Même dans ce cas, traceroute indique une piste, pas une responsabilité contractuelle.

Lire la latence sans se tromper

Beaucoup d’erreurs viennent d’une lecture trop rapide de la latence. Si un routeur intermédiaire affiche 200 ms mais que les sauts suivants et la destination répondent à 25 ms, ce routeur a probablement dépriorisé sa réponse de diagnostic. Le trafic utile ne passe pas forcément avec cette latence.

À l’inverse, si la latence augmente à partir d’un saut et reste élevée jusqu’à la destination, l’information devient plus solide. Vous voyez alors un changement durable dans le chemin. Il peut venir d’un transit international, d’une saturation, d’un tunnel, d’un routage indirect ou d’un fournisseur plus éloigné que prévu.

Regardez aussi la stabilité entre les trois sondes d’une même ligne. Trois valeurs proches sont plus faciles à interpréter qu’une valeur basse, une valeur très haute et un timeout. Dans ce dernier cas, refaites le test plusieurs fois avant de décider.

UDP, ICMP ou TCP : quelle méthode choisir ?

Selon les systèmes, traceroute envoie par défaut des sondes UDP. L’option -I demande une approche ICMP Echo, proche de l’idée de ping. L’option -T utilise des sondes TCP SYN, souvent utiles quand des pare-feu laissent mieux passer le trafic web que les diagnostics classiques.

traceroute -I example.com
traceroute -T -p 443 example.com

Ces variantes ne donnent pas toujours le même chemin. Un réseau peut filtrer ICMP, autoriser TCP 443, limiter UDP ou répondre différemment selon la politique de sécurité. Pour une destination web, un test TCP vers le port 443 peut être plus proche de l’usage réel qu’un traceroute UDP standard.

Il faut toutefois rester prudent. Certains modes demandent des droits particuliers selon la distribution, la configuration des capacités Linux et la version de l’outil. Si une option échoue, cela peut venir du poste local, pas forcément du réseau testé.

Quand utiliser tracepath à la place

tracepath est une alternative pratique quand vous voulez un diagnostic rapide sans entrer dans toutes les options de traceroute. La manpage Linux le présente comme un outil proche de traceroute, mais plus simple, avec une découverte du Path MTU sur le chemin.

tracepath example.com
tracepath 1.1.1.1

Le Path MTU correspond à la taille maximale qu’un paquet peut prendre sur le chemin sans fragmentation problématique. C’est précieux quand une connexion semble ouverte mais que certains transferts se bloquent, notamment avec VPN, tunnels, liens opérateurs ou configurations réseau atypiques.

Pour approfondir ce point, consultez find in files linux, qui traite plus précisément de find in files linux, rechercher dans vos fichiers sans vous tromper.

Pour un usage courant, gardez une règle simple : ping pour vérifier que ça répond, traceroute pour voir le chemin, tracepath si vous suspectez un souci de MTU ou si vous voulez un outil plus direct.

Diagnostiquer une panne avec méthode

Commencez local. Vérifiez l’adresse IP, la passerelle, la résolution DNS et la connectivité vers votre routeur. Si votre premier saut ne répond pas ou si vous n’avez pas de passerelle par défaut, traceroute vers Internet ne vous apprendra pas grand-chose.

ip route
ping -c 4 1.1.1.1
ping -c 4 example.com
traceroute -n example.com

La comparaison entre adresse IP et nom de domaine est importante. Si ping 1.1.1.1 fonctionne mais que le domaine échoue, vous regardez peut-être un problème DNS, pas un problème de routage. Si les deux échouent dès le départ, revenez à la passerelle, au Wi-Fi, au câble, au VPN ou au pare-feu local.

Ensuite seulement, observez la route. Notez le dernier saut qui répond, la latence qui persiste, les changements entre plusieurs essais et l’heure du test. Pour un incident intermittent, une capture isolée a peu de valeur ; une série courte de mesures est beaucoup plus exploitable.

Un bon dépannage consiste aussi à changer un seul paramètre à la fois. Testez d’abord depuis le Wi-Fi, puis depuis l’Ethernet si possible. Coupez ensuite le VPN, changez de DNS seulement après avoir confirmé que le domaine pose problème, puis comparez avec un partage de connexion mobile. Cette progression évite d’attribuer à Internet un défaut qui vient en réalité de la couche locale.

Quand vous testez un serveur que vous administrez, gardez la même logique : vérifiez le pare-feu local, la règle de sécurité cloud, la table de routage, puis seulement les opérateurs intermédiaires. Un traceroute bloqué à l’approche du serveur peut venir d’une politique volontaire qui ignore ICMP ou UDP, alors que le service web répond parfaitement sur TCP 443.

Le plus utile est souvent de croiser les preuves avant d’ouvrir un ticket ou de modifier une configuration stable.

Cas particuliers à connaître

Avec un VPN, traceroute peut montrer un chemin très différent de celui attendu. Tout le trafic peut partir vers le point de sortie du tunnel, puis rejoindre la destination depuis un autre pays ou un autre opérateur. Si vous diagnostiquez une lenteur, testez avec et sans VPN avant de conclure à une saturation distante.

Pour approfondir ce point, consultez Réutiliser un câble PTT-298 pour un réseau, qui traite plus précisément de réutiliser un câble ptt-298 pour un réseau rj45 fiable.

Dans un réseau d’entreprise, le filtrage peut être encore plus strict. Les sondes ICMP ou UDP peuvent être bloquées, tandis que le trafic web sortant reste autorisé. Dans ce cas, un traceroute TCP vers le port réellement utilisé donne souvent une lecture plus proche du flux applicatif. Pour un dépôt Git, une API ou une console SaaS, adaptez le port plutôt que d’utiliser une commande générique sans contexte.

Sur IPv6, pensez aussi à vérifier la famille d’adresses. Certaines machines résolvent un domaine en IPv6 puis basculent ensuite en IPv4, ou l’inverse. Si la panne ne touche qu’une partie des usages, un test explicite peut clarifier la piste.

traceroute -4 example.com
traceroute -6 example.com

Cette séparation est importante quand le réseau local annonce IPv6 mais que la connectivité réelle est instable. Vous pouvez avoir un service parfaitement accessible en IPv4 et lent en IPv6, ou un chemin IPv6 plus direct que le chemin IPv4. Sans test séparé, les symptômes paraissent incohérents alors qu’ils relèvent simplement de deux routes différentes.

Les limites à connaître

Traceroute ne montre pas toujours le chemin réel du trafic applicatif. Internet utilise souvent des routes asymétriques : le paquet aller et la réponse retour peuvent passer par des chemins différents. L’outil dépend donc des réponses reçues, pas d’une carte complète du réseau.

Cette limite devient importante quand vous comparez deux utilisateurs. L’un peut sortir par un opérateur fibre national, l’autre par un VPN d’entreprise, un relais mobile ou une passerelle cloud. Ils consultent la même destination, mais ne traversent pas forcément les mêmes réseaux, ni dans le même ordre. Deux traceroutes contradictoires peuvent donc être vrais en même temps, surtout si la destination utilise du CDN, de l’anycast ou des politiques de routage différentes selon la source.

Autre limite : les routeurs traitent les paquets de transit et les réponses de diagnostic différemment. Un équipement peut router correctement votre trafic tout en répondant lentement aux sondes traceroute. C’est fréquent sur des infrastructures chargées ou volontairement durcies.

Enfin, les noms DNS inverses peuvent être trompeurs. Ils donnent parfois une ville, un opérateur ou un rôle réseau, mais ces libellés ne sont pas une preuve absolue de localisation. Pour un diagnostic sérieux, gardez les adresses IP, les horaires, les tests croisés et la destination exacte.

Pour approfondir ce point, consultez script bash linux, qui traite plus précisément de écrire son premier script bash sous linux sans partir dans tous les sens.

Exemples de lectures fréquentes

Si les premiers sauts répondent puis que tout disparaît après votre opérateur, le blocage peut être plus loin dans le transit ou côté destination. Si seul un saut intermédiaire affiche des astérisques, mais que la destination répond, il n’y a probablement pas de panne à cet endroit.

Si la latence explose dès le premier saut, cherchez plutôt un problème local : Wi-Fi saturé, routeur domestique en difficulté, VPN, partage de connexion instable ou machine qui consomme beaucoup de bande passante. Si la hausse apparaît au passage vers un autre pays ou un autre opérateur, vous observez peut-être un détour réseau.

Si le traceroute TCP vers 443 fonctionne mais pas le traceroute UDP, cela peut simplement signifier que les sondes UDP sont filtrées. Pour un site web, le test TCP sera souvent plus parlant. Pour un service spécifique, testez le port concerné quand l’outil et vos droits le permettent.

Bonnes pratiques pour partager un résultat

Quand vous demandez de l’aide, ne collez pas seulement une capture floue. Donnez la commande exacte, l’heure, le réseau utilisé, la destination, le contexte et le symptôme. Par exemple : “depuis fibre opérateur X, le site répond lentement depuis 21 h, traceroute TCP 443 joint”.

Masquez les adresses privées ou informations internes si nécessaire, mais conservez assez de détails pour que quelqu’un puisse comprendre. Un traceroute sans contexte ne dit pas si le problème concerne une connexion web, un VPN, un serveur de jeu, un dépôt Git ou une API.

Si vous administrez le serveur de destination, faites aussi un test dans l’autre sens quand c’est possible. Les routes retour comptent autant que les routes aller, et traceroute depuis un seul poste peut raconter une histoire incomplète.

Ce qu’il faut retenir

Traceroute sur Linux est un outil de lecture du chemin réseau. Il aide à situer une coupure, un détour ou une latence persistante, mais il ne désigne pas automatiquement le coupable. Ses résultats dépendent des protocoles utilisés, des pare-feu, des priorités de réponse et des routes retour.

La méthode fiable tient en trois étapes : vérifier le local, comparer plusieurs commandes, puis lire les tendances. Commencez par ping, utilisez traceroute -n, testez ICMP ou TCP si besoin, et gardez tracepath sous la main quand le MTU peut être en cause.