infra / reseaux-tcp-ip
Diagnostic réseau (ping, traceroute, tcpdump, Wireshark)
Explication
Ce que vous allez apprendre
- Appliquer une méthode de diagnostic réseau systématique, couche par couche
- Interpréter correctement ce que
pingettracerouterévèlent (et ne révèlent pas) - Capturer du trafic réseau en ligne de commande avec
tcpdumpet filtrer ce qui t'intéresse - Rapatrier une capture
.pcapet l'analyser visuellement dans Wireshark - Distinguer un problème de perte de paquets d'un problème de latence avec
mtr
Dans quel contexte ?
Un développeur reçoit un ticket "le site est lent" sans plus de détails. Plutôt que de deviner, il applique la méthode en couches : ping confirme que le serveur répond, mtr -rw exemple.com révèle une forte perte de paquets sur un saut précis chez l'un des transitaires réseau, et non sur le serveur lui-même. Cette information change tout : le problème n'est pas applicatif, il est réseau, en dehors de son infrastructure.
Diagnostiquer, c'est réduire méthodiquement l'espace des causes possibles
Face à "ça ne marche pas" côté réseau, la tentation est de tester au hasard. Une bonne démarche de diagnostic procède au contraire de façon systématique, couche par couche : vérifier d'abord que le lien physique existe, puis que l'adressage IP fonctionne, puis que le chemin (routage) est correct, puis que le port applicatif répond, et enfin que le protocole applicatif lui-même fonctionne. Cette méthode reprend directement le modèle de couches vu en tout début de cours, appliqué concrètement.
| Étape | Outil | Ce que ça vérifie |
|---|---|---|
| 1 | ip link, ethtool | Le lien physique est-il up ? |
| 2 | ping | La connectivité IP fonctionne-t-elle ? |
| 3 | traceroute, mtr | Le chemin réseau est-il correct ? |
| 4 | nc -zv, ss | Le port applicatif répond-il ? |
| 5 | curl -v | Le protocole applicatif fonctionne-t-il vraiment ? |
Astuce
tcpdump capture en ligne de commande (indispensable sur un serveur distant sans interface graphique), mais l'analyse visuelle dans Wireshark est bien plus confortable. Le réflexe pro : capturer sur le serveur avec tcpdump -w capture.pcap, rapatrier le fichier avec scp, puis l'ouvrir localement dans Wireshark.
ping, traceroute, et ce qu'ils révèlent vraiment
ping confirme uniquement qu'une machine répond à un niveau très basique (ICMP), pas que le service que tu veux réellement utiliser fonctionne. traceroute va plus loin en révélant le chemin emprunté, saut par saut, ce qui permet d'identifier précisément où un problème de routage ou de perte de paquets survient plutôt que de simplement constater "ça ne marche pas".
tcpdump : voir la vérité, pas des suppositions
Beaucoup de bugs réseau ne peuvent être compris qu'en observant réellement ce qui transite sur le câble. tcpdump capture ce trafic en ligne de commande — indispensable sur un serveur distant sans interface graphique — pendant que Wireshark permet ensuite une analyse visuelle bien plus confortable du fichier de capture obtenu. Comprendre cette complémentarité (capturer là où c'est nécessaire, analyser là où c'est confortable) est une compétence professionnelle centrale.
Distinguer perte de paquets et latence
Ce sont deux problèmes différents avec des symptômes différents : mtr, qui combine ping et traceroute en continu, permet de localiser précisément à quel saut du trajet la perte ou le ralentissement se produit, plutôt que de le deviner.
Commandes & code
Diagnostic réseau
# --- Méthode : diagnostiquer couche par couche, du plus bas niveau au plus haut ---
# 1. La carte réseau est-elle up ?
ip link show eth0
ethtool eth0 # vitesse, duplex, statut du lien physique
# 2. La connectivité IP fonctionne-t-elle ?
ping -c4 192.168.1.1 # passerelle locale d'abord
ping -c4 8.8.8.8 # puis Internet (IP directe, court-circuite le DNS)
ping -c4 exemple.com # puis résolution DNS + Internet
# 3. Le chemin réseau (routage) est-il correct ?
traceroute exemple.com
mtr -rw exemple.com # mode rapport, cumule les pertes par saut sur plusieurs paquets
# 4. Le port applicatif répond-il ?
nc -zv exemple.com 443
ss -tan | grep :443
# 5. Le protocole applicatif fonctionne-t-il vraiment ?
curl -v https://exemple.com
# --- tcpdump : capture de paquets en ligne de commande ---
sudo tcpdump -i eth0 # capture tout sur l'interface (bruyant)
sudo tcpdump -i eth0 -n host 10.0.1.10 # filtre par IP, -n = pas de résolution DNS (plus rapide)
sudo tcpdump -i eth0 -n port 443 # filtre par port
sudo tcpdump -i eth0 -n 'tcp[tcpflags] & tcp-syn != 0' # uniquement les paquets SYN
sudo tcpdump -i any -n -c 100 -w capture.pcap # capture 100 paquets vers un fichier
tcpdump -r capture.pcap -n # relit un fichier de capture existant
sudo tcpdump -i eth0 -n -A port 80 # -A affiche le contenu ASCII (HTTP en clair)
# Filtres combinés utiles en debug
sudo tcpdump -i eth0 -n 'host 10.0.1.10 and port 443 and tcp[tcpflags] & (tcp-syn|tcp-rst) != 0'
# --- Wireshark (notions) : analyse graphique d'une capture ---
# 1. Capturer avec tcpdump sur le serveur distant (souvent pas de GUI en prod) :
sudo tcpdump -i eth0 -w /tmp/capture.pcap -c 500
# 2. Rapatrier le fichier en local :
scp serveur:/tmp/capture.pcap ./
# 3. Ouvrir capture.pcap dans Wireshark pour une analyse visuelle :
# - Follow TCP Stream : reconstruit une conversation complète
# - Filtres d'affichage : http, tcp.port==443, ip.addr==10.0.1.10, tcp.analysis.retransmission
# --- Diagnostiquer une perte de paquets/latence ---
ping -c 100 -i 0.2 exemple.com | tail -3 # 100 paquets rapprochés, stats de perte en résumé
mtr -c 50 --report exemple.com # identifie précisément QUEL saut perd des paquetsRésumé
- Diagnostiquer du bas vers le haut : lien physique -> IP -> routage -> port -> protocole applicatif.
tcpdumpcapture en ligne de commande (idéal sur un serveur sans interface graphique) ; Wireshark analyse ensuite le fichier.pcap.mtrcombine ping et traceroute en continu : le meilleur outil pour localiser précisément un saut qui perd des paquets.
Exercices pratiques
Mission : localiser un problème réseau derrière un ticket vague
Objectif : Appliquer la méthode de diagnostic en couches pour transformer un ticket vague ('le site est lent') en cause précise et localisée.
Contexte
Un ticket dit simplement "le site exemple.com est lent". mtr -rw exemple.com montre 0% de perte sur les 5 premiers sauts, puis 40% de perte constante à partir du 6e saut jusqu'à la destination. Le ping direct vers exemple.com réussit malgré tout, avec une latence variable.