Observer son réseau
ip addr, ip route, ping et traceroute en diagnostic.
Objectifs
À la fin de cette leçon, vous saurez :
- lister interfaces et adresses avec
ip addr, et lire la sortie ligne par ligne ; - lire la table de routage avec
ip route; - diagnostiquer une panne réseau de proche en proche avec
ping; - suivre un chemin complet avec
tracerouteet interpréter les étoiles.
🔗 Pour vous rafraîchir la mémoire : adresses, masques et réseaux locaux
Voir ses interfaces : ip addr
ip addr
Sortie type, annotée :
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 ...
link/loopback 00:00:00:00:00:00 brd ...
inet 127.0.0.1/8 scope host lo ← adresse IPv4 + masque
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 ...
link/ether 02:42:c0:a8:41:02 ... ← adresse matérielle (MAC)
inet 192.168.65.3/24 brd 192.168.65.255 scope global eth0
Lecture des éléments qui comptent au quotidien :
- numéro + nom d'interface (
lo,eth0...) ; l'étatUPsignifie active ; inet <adresse>/<masque>: votre identité sur ce segment — ici192.168.65.3/24, donc réseau192.168.65.x;link/ether ...: l'adresse MAC, identifiant matériel de la carte (utile uniquement dans le réseau local immédiat ; ne traverse jamais les routeurs). À distinguer clairement de l'IP, qui elle voyage de bout en bout.
Pour aller à l'essentiel d'un coup d'œil :
$ ip -brief addr
lo UNKNOWN 127.0.0.1/8 ::1/128
eth0 UP 192.168.65.3/24
Version compacte : interface, état, adresses. Parfaite pour un premier diagnostic.
Lire sa table de routage : ip route
ip route
default via 192.168.65.1 dev eth0
192.168.65.0/24 dev eth0 proto kernel scope link src 192.168.65.3
Deux lignes, deux règles complémentaires :
| Ligne | Règle |
|---|---|
192.168.65.0/24 dev eth0 ... src 192.168.65.3 | « ce quartier est joignable directement par eth0 » |
default via 192.168.65.1 dev eth0 | « tout le reste → confie-le à la passerelle » |
Toute connexion sortante consulte cette table de haut en bas : si la destination colle à un préfixe connu, route directe ; sinon, la règle default s'applique. Vous pouvez vérifier quelle règle s'applique à une destination précise :
ip route get 8.8.8.8
# 8.8.8.8 via 192.168.65.1 dev eth0 src 192.168.65.3
ip route get 192.168.65.50
# 192.168.65.50 dev eth0 src 192.168.65.3 ← pas de "via" : direct !
Cette commande est un excellent outil pédagogique : elle exécute le raisonnement du masque (leçon précédente) devant vous.
Tester la joignabilité : ping
ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=115 time=14.2 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=115 time=13.9 ms
^C
--- 8.8.8.8 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max = 13.9/14.05/14.2 ms
ping envoie des petits paquets ICMP et attend l'écho : il mesure joignabilité, temps aller-retour (latence) et pertes. Lecture des chiffres : time=14.2 ms est l'aller-retour complet ; 0% packet loss signifie que tout est revenu. On interrompt avec Ctrl+C — souvenez-vous, cela rend le code 130.
Détail qui boucle avec le chapitre 2 : ping aussi a un code de retour !
ping -c 1 -W 2 192.168.65.99 ; echo $?
# 100% packet loss → code 1 (échec)
ping -c 1 -W 2 192.168.65.1 ; echo $?
# réponse reçue → code 0 (succès)
C'est pourquoi les scripts de diagnostic utilisent ping dans des conditions (ping -c1 host && echo "réseau ok").
La méthode de diagnostic de proche en proche
La force de ping vient de l'ordre des tests — toujours du plus proche au plus loin :
| Test | Si KO | Si OK |
|---|---|---|
ping 127.0.0.1 | pile TCP/IP cassée (très rare) | continuez |
ping <passerelle> | problème LOCAL : câble, Wi-Fi, interface | réseau local OK → continuez |
ping 8.8.8.8 | problème SORTANT : box, FAI | Internet OK → le problème est ailleurs (DNS ? service ?) |
Chaque échec localise l'étage défaillant. Notez la dernière case : si Internet répond mais qu'un site ne se charge pas, le coupable n'est plus le réseau IP — c'est probablement la résolution de nom (DNS, chapitre 10) ou le service lui-même.
⚠️ Limite honnête : certains serveurs bloquent volontairement l'ICMP. Un ping KO vers une destination lointaine ne prouve donc pas une panne — c'est un indice, pas un verdict. D'où l'intérêt du test suivant.
Suivre le chemin : traceroute
traceroute example.com
traceroute to example.com (93.184.216.34), 30 hops max, 60 byte packets
1 192.168.65.1 (192.168.65.1) 0.4 ms ← votre box/passerelle
2 10.20.30.1 (10.20.30.1) 8.1 ms ← réseau interne FAI
3 par-th2-cr1.example.net 12.6 ms ← backbone FAI
4 * * * ← ce saut ne répond pas
5 93.184.216.34 15.3 ms ← arrivée
Chaque ligne = un équipement traversé (hop), avec sa latence mesurée trois fois. Ce que cette trace raconte : vous sortez par la passerelle, entrez dans le réseau du fournisseur d'accès, puis les backbones, puis la destination. Les * * * signifient qu'un routeur a choisi de ne pas répondre aux sondes traceroute — fréquent et bénin tant que les sauts suivants répondent.
Lecture utile pour nous, développeurs web : la latence croît avec chaque saut géographique. C'est la raison concrète pour laquelle on héberge ses services près de ses utilisateurs, et pourquoi un CDN change la vie d'un site international — sujets de la fin du cursus.
Exercice
Sur votre VM :
- Notez votre adresse IP, son masque et le nom de votre interface principale.
- Identifiez votre passerelle par défaut, puis vérifiez avec
ip route getcomment serait jointe : votre passerelle,1.1.1.1. - Pinguez successivement
127.0.0.1, la passerelle,1.1.1.1. Comparez les latences et expliquez l'écart. - Tracez la route vers
example.com. Combien de sauts avant de sortir de votre réseau local ? - Écrivez une commande unique qui teste si
1.1.1.1est joignable et affiche « internet ok » seulement en cas de succès.
Résumé
ip addr(identités) →ip route(règles de départ) →ping(joignabilité) →traceroute(chemin).- Diagnostic TOUJOURS de proche en proche : soi → passerelle → Internet.
- ping KO ≠ panne certaine (ICMP filtrable) ; traceroute montre où ça coince.
ip route get <destination>: le raisonnement de routage exécuté sous vos yeux.
Correction disponibleCherchez d’abord par vous-même.Voir la correction
Correction
Réponses détaillées
Questions 1-2. Exemple type :
adresse : 192.168.65.3/24 sur eth0
passerelle : 192.168.65.1
$ ip route get 192.168.65.1
192.168.65.1 dev eth0 src 192.168.65.3 ← direct (même /24)
$ ip route get 1.1.1.1
1.1.1.1 via 192.168.65.1 dev eth0 src 192.168.65.3 ← via la passerelle
La présence ou non de via matérialise la frontière local/distant calculée par le masque.
Question 3. Latences croissantes attendues :
127.0.0.1 ~0.03 ms aucun câble traversé (miroir logiciel)
passerelle < 1–5 ms un seul équipement physique voisin
1.1.1.1 5–50 ms dizaines de kilomètres + plusieurs équipements
La distance physique ET le nombre de sauts se lisent directement dans le temps. Au-delà de ~200 ms pour un site européen, quelque chose d'inhabituel se produit (satellite, VPN, congestion...).
Question 4. Typiquement 1 à 3 premiers sauts locaux (VM → éventuel hôte Docker → box), puis le réseau du FAI. Le premier saut public identifie déjà votre fournisseur — son nom apparaît souvent littéralement dans la trace.
Question 5.
ping -c 1 -W 2 1.1.1.1 > /dev/null && echo "internet ok"
Lecture : un seul paquet (-c 1), attente max 2 s (-W 2), jette poliment la sortie (> /dev/null, seul le code de retour intéresse — réflexe de la leçon 2-03), puis enchaîne conditionnellement avec &&. Cette ligne est un vrai fragment de script de monitoring professionnel.