Niveau 🟡 intermédiaire
Durée estimée : 20 min · Prérequis : TLS et certificats
ping, ip, ss, dig/resolvectl, traceroute et tcpdump pour un premierDiagnostiquer un problème réseau sans méthode, c'est comme chercher une panne électrique en
testant des ampoules au hasard dans toute la maison. Une démarche par couches — d'abord la prise
murale (l'adresse), puis le disjoncteur (la connectivité), puis l'appareil lui-même (le
service) — trouve la panne bien plus vite qu'un tâtonnement.
Un problème réseau se situe presque toujours à l'une de ces couches, dans cet ordre de
vérification logique :
ip a, ip route (vu enpingdig, resolvectl query (vu enss -tulnp (vu entraceroutetcpdump — le dernier recours, le plusping envoie des paquets ICMP à une machine cible et mesure si elle répond, et en combien
de temps. Une absence de réponse ne prouve pas toujours une panne : certains pare-feux bloquent
volontairement ICMP tout en laissant passer d'autres protocoles — un « ping » qui échoue n'est
donc qu'un indice, pas une conclusion définitive.
traceroute révèle chaque étape (chaque routeur) traversée entre la machine et une
destination, avec le temps de trajet jusqu'à chacune. Utile pour identifier où un trafic
s'arrête quand il n'atteint jamais sa destination — la dernière étape qui répond situe
approximativement le point de blocage.
tcpdump capture le contenu réel des paquets qui transitent sur une interface réseau —
l'outil le plus puissant et le plus détaillé de cette liste, réservé aux cas où les outils
précédents n'ont pas suffi à comprendre ce qui se passe précisément dans l'échange.
🧪 Honnêtement, sur notre exemple :
ping,ip a/ip -br addr,resolvectl statuset
ss -tulnont réellement servi à diagnostiquer des problèmes concrets sur ce serveur (par
exemple un souci de résolution.internalinvisible depuis l'intérieur d'un conteneur, faute
de partager le fichier/etc/hostsdu client).dig,tracerouteettcpdumpsont présentés
ici comme des outils standards et largement utilisés dans le métier — mais non testés sur
ce serveur à ce jour, faute d'en avoir eu besoin.
Chaque étape élimine une catégorie de causes avant de passer à la suivante — inutile de sortir
tcpdump pour un problème qu'un simple ping ou ip a aurait déjà révélé.
ping -c4 192.0.2.10
# Envoie 4 paquets et s'arrête -- -c évite un ping infini par défaut
ip -br addr
# Vue compacte ("brief") des interfaces et de leurs adresses
resolvectl status
# Affiche, interface par interface, quel serveur DNS est réellement utilisé
ss -tulnp
# Ports en écoute côté local -- vu en détail en M1
dig +short exemple.com
# Résolution DNS rapide -- vu en détail dans la page DNS de ce module
traceroute exemple.com
# Chemin réseau, étape par étape, vers une destination
sudo tcpdump -i eth0 port 443
# Capture le trafic HTTPS sur l'interface eth0 -- nécessite les droits root
Choisis une machine et une cible réseau accessibles. Suis l'ordre de la théorie ci-dessus :
ip a → ping → dig/resolvectl → ss -tulnp. Si chaque étape répond normalement, la
chaîne complète (adresse, connectivité, résolution, port) fonctionne.
| Symptôme | Cause probable | Solution |
|---|---|---|
Conclure à une panne réseau sur un simple échec de ping |
Certains pare-feux bloquent ICMP sans bloquer le reste du trafic | Tester aussi le port réel du service (ss, ou une connexion directe) avant de conclure |
Sortir directement tcpdump pour un problème simple |
Réflexe de l'outil le plus impressionnant plutôt que le plus adapté | Suivre l'ordre des couches : adresse, connectivité, résolution, port, chemin, contenu — dans cet ordre |
Diagnostiquer un problème DNS .internal depuis l'intérieur d'un conteneur |
Un conteneur ne partage généralement pas le fichier /etc/hosts de la machine hôte ou du client |
Vérifier la résolution depuis la machine cliente réelle, pas depuis l'intérieur du conteneur concerné |
ping qui échoue n'est qu'un indice, pas une preuve définitive de panne.dig, traceroute et tcpdump sont des outils standards du métier — même non testés sur un.internal doit se vérifier depuis la machine cliente concernée, pas depuis/etc/hosts.Parce que certains pare-feux bloquent volontairement le protocole ICMP (utilisé par ping) tout
en laissant passer normalement d'autres types de trafic vers le même service.
Adresse IP (ip a) → connectivité (ping) → résolution de nom (dig/resolvectl) → port
ouvert (ss) → chemin réseau (traceroute) → contenu du trafic (tcpdump).
Parce qu'un conteneur ne partage généralement pas le fichier /etc/hosts de la machine cliente
réelle — un nom .internal peut donc y être invisible sans que cela révèle un vrai problème
réseau.
Choisis un site web que tu connais et exécute, dans l'ordre : ping, dig +short, puis
traceroute vers son nom de domaine. Note à quelle étape, si le service était en panne, tu
aurais obtenu la première indication du problème.
ping ·
traceroute ·
tcpdump ·
ICMP
Cette formation est proposée par Deladev, studio web de Loïc D. — création de sites et d'applications, accompagnement et formation sur mesure.
Les projets réalisés · Prestations et tarifs · Le blog tech · Me contacter
Écrite par Loïc D. avec l'assistance de Claude (Anthropic) — un travail à deux.
© 2026 Deladev — publiée sous licence CC BY-NC-ND 4.0. Vous pouvez la lire, y renvoyer par un lien, la partager et la citer en créditant la source. La revendre, l'utiliser dans une prestation ou une formation payante, la republier même partiellement ailleurs, en diffuser une version modifiée ou l'exploiter pour entraîner un modèle d'IA nécessitent une autorisation écrite — pour un usage interne en entreprise, c'est souvent oui, il suffit de demander.