traceroute : lire la route que prennent tes paquets

Ce qui suit explique comment `traceroute` fonctionne, comment l'installer sur une Debian ou une Ubuntu récente, et surtout comment interpréter ce qu'il renvoie — parce que la sortie brute est souvent mal lue.

Ce qu'il te faut

• Une machine Linux avec accès root ou `sudo` (le programme a besoin de fabriquer des paquets ICMP ou UDP bruts, ce qui demande `CAP_NET_RAW`).
• `traceroute` version 2.1.0 ou plus récente. Sur Debian 12 et Ubuntu 24.04, c'est la version packagée.
• Un accès réseau sortant. Derrière un proxy d'entreprise ou un VPN qui filtre l'ICMP, tu verras moins de choses.
• Facultatif mais utile : `tcptraceroute` (paquet `tcptraceroute`) et `tracepath` (paquet `iputils-tracepath`).

Étape 1 — Installer le paquet

Sur Debian et Ubuntu, `traceroute` n'est pas installé par défaut dans les images minimales.

```bash sudo apt update sudo apt install traceroute ```

Vérifie la version installée :

```bash traceroute --version ```

Tu dois voir quelque chose comme `Modern traceroute for Linux, version 2.1.0`. Si le paquet vient d'un dépôt ancien, tu auras la version 2.0.21, qui fonctionne mais gère moins bien les options TCP.

Étape 2 — Comprendre le mécanisme TTL avant de lancer quoi que ce soit

Chaque paquet IP porte un champ `TTL` (Time To Live) dans son en-tête. À l'origine c'était un compteur de secondes, aujourd'hui c'est un compteur de sauts.

Quand un routeur reçoit un paquet, il décrémente le TTL de 1. Si le TTL tombe à zéro, le routeur jette le paquet et renvoie un message ICMP `Time Exceeded` à l'expéditeur.

`traceroute` exploite exactement ça. Il envoie un premier paquet avec TTL=1. Le premier routeur décrémente, tombe à zéro, renvoie `Time Exceeded`. `traceroute` note l'adresse. Puis il envoie TTL=2, le deuxième routeur répond, et ainsi de suite jusqu'à la destination.

Tu n'as besoin d'aucun logiciel spécial sur les routeurs intermédiaires. C'est pour ça que l'outil marche partout depuis 1987.

Étape 3 — Lancer un traceroute simple

```bash traceroute pixzo.com ```

La sortie liste chaque hop avec trois temps de réponse en millisecondes. Trois, parce que `traceroute` envoie trois sondes par défaut et affiche les trois RTT.

Une étoile `*` signifie qu'aucune réponse n'est revenue dans le délai d'attente. Ce n'est pas une preuve que le hop n'existe pas — c'est une preuve qu'il ne répond pas.

Étape 4 — Basculer sur TCP quand l'ICMP est filtré

Beaucoup de réseaux d'entreprise et de fournisseurs bloquent l'ICMP entrant. Résultat : ton traceroute classique s'arrête à mi-chemin avec des étoiles.

L'option `-T` envoie des paquets TCP SYN au lieu d'UDP. Ça passe là où l'ICMP ne passe pas, parce que le port 443 est presque toujours ouvert.

```bash sudo traceroute -T -p 443 pixzo.com ```

Le `sudo` est nécessaire : fabriquer des paquets TCP bruts demande les mêmes privilèges que l'ICMP.

Le coût de cette méthode : certains firewalls stateful voient ces SYN comme des tentatives de connexion et les loguent. Tu laisses des traces. Sur ton propre réseau, ça n'a pas d'importance. Chez un client, préviens avant.

Étape 5 — Utiliser tracepath quand tu n'as pas les droits root

`tracepath` fait le même travail mais n'a pas besoin de privilèges élevés. Il utilise UDP avec un port non privilégié.

```bash tracepath pixzo.com ```

Il fait aussi la découverte du MTU (Path MTU Discovery), ce que `traceroute` ne fait pas par défaut. Si tu cherches pourquoi une connexion VPN casse sur les gros paquets, `tracepath` te le dira plus vite.

En échange, tu perds le contrôle fin sur le protocole et le port. Pour un diagnostic rapide, c'est le bon compromis.

Étape 6 — Geler les résolutions DNS pour aller plus vite

Par défaut, `traceroute` fait une résolution DNS inverse sur chaque hop. Sur un chemin de vingt routeurs, ça peut prendre plusieurs secondes.

L'option `-n` désactive cette résolution et affiche les adresses IP brutes.

```bash traceroute -n pixzo.com ```

Tu gagnes du temps, tu perds les noms. Quand tu sais déjà quel réseau tu regardes, les noms ne servent à rien.

Étape 7 — Augmenter le nombre de sondes et la taille des paquets

Pour repérer un problème intermittent, une seule sonde par hop ne suffit pas. `-q` règle le nombre de sondes par hop :

```bash traceroute -q 5 pixzo.com ```

Pour tester un MTU ou reproduire un problème qui n'apparaît que sur de gros paquets, `-s` règle la taille du payload :

```bash traceroute -s 1400 pixzo.com ```

Un chemin qui répond en 1400 octets mais pas en 1500 est un chemin avec un MTU réduit quelque part. C'est fréquent sur les tunnels et les VPN.

Étape 8 — Comparer avec ping avant de conclure

`ping` te dit si la destination répond et en combien de temps. `traceroute` te dit par où le trafic passe.

```bash ping -c 4 pixzo.com ```

Si `ping` répond et que `traceroute` s'arrête avant la fin, le problème est dans le retour des messages `Time Exceeded`, pas dans la connectivité. Le chemin fonctionne, c'est le diagnostic qui est aveugle.

Si `ping` échoue aussi, tu as un vrai problème de routage ou de filtrage en amont.

Vérification

Le traceroute a fonctionné si la dernière ligne affiche l'adresse de destination, pas une étoile.

```bash traceroute -n -q 1 pixzo.com | tail -n 3 ```

Tu dois voir l'IP cible en dernière position avec un RTT mesuré. Si la dernière ligne est une étoile ou un hop intermédiaire, tu n'as pas atteint la destination — mais tu as quand même une information utile : tu sais jusqu'où le trafic va.

Problèmes courants

Toutes les lignes sont des étoiles dès le premier hop. Ton pare-feu local bloque l'ICMP sortant, ou tu n'as pas les droits. Vérifie avec `sudo` et regarde `iptables -L OUTPUT`. Sur un poste d'entreprise, c'est souvent une politique imposée que tu ne peux pas contourner.

Le traceroute s'arrête au même hop à chaque essai, mais `ping` passe. Ce hop filtre l'ICMP `Time Exceeded` tout en laissant passer le trafic. C'est courant chez les gros transitaires. Essaie `traceroute -T -p 443` : la réponse viendra d'un autre chemin, ou pas du tout, mais tu sauras que c'est un filtrage et pas une panne.

Les RTT sautent de 5 ms à 200 ms au milieu du chemin. Regarde si les sauts suivants redescendent. Un pic isolé suivi d'un retour à la normale est souvent un routeur qui priorise mal l'ICMP — il répond lentement aux sondes mais fait passer le trafic normalement. Un pic qui reste haut sur tous les hops suivants indique un vrai goulot.

RFC 1393, qui proposait une méthode alternative via une option IP, est classée obsolète depuis longtemps. Personne ne l'a déployée. Le TTL, lui, n'a pas bougé — et il ne bougera pas, parce que tout le routage IP repose dessus.