Méthodologie de diagnostic réseau

Un service ne répond pas ? Une connexion timeout ? Avant de blâmer le réseau, appliquez une méthode de diagnostic systématique. Ce guide synthétise tout ce que vous avez appris dans les modules précédents et vous donne un arbre de décision, une checklist rapide et un tableau des outils par symptôme. L'objectif : identifier en quelques minutes si le problème vient du réseau ou de l'application.

Ce que vous allez apprendre

• Appliquer une méthode systématique : diagnostiquer du plus proche au plus loin.
• Suivre un arbre de décision réseau : localhost, passerelle, Internet, DNS, service.
• Interpréter les erreurs courantes : refused, timeout, name not found, no route.
• Choisir le bon outil selon le symptôme (ip, ping, dig, nc, traceroute, mtr).
• Éviter les pièges du diagnostic : redémarrage réflexe, changer plusieurs variables à la fois.

Prérequis

• Avoir suivi les modules précédents (IP, DNS, TCP/UDP, ICMP, HTTP)
• Un terminal Linux, macOS ou WSL
• Connaissances des commandes : ip, ping, dig, nc, curl, ss

Ce guide est une synthèse

Vous n'avez pas besoin de maîtriser parfaitement chaque outil. L'important est de savoir quel outil utiliser pour quel symptôme et de suivre une méthode logique.

La méthode en 5 étapes

Le diagnostic réseau suit toujours la même logique : du plus proche au plus loin. On vérifie d'abord la machine locale, puis la passerelle, puis Internet, puis le DNS, puis le service distant.

1. Vérifier la connectivité locale

   Votre machine a-t-elle une adresse IP ? L'interface réseau est-elle active ?

   ip addr show
   ping -c 2 127.0.0.1

   Si ça échoue : Interface down, pas d'IP (DHCP ?)

2. Vérifier la passerelle

   Pouvez-vous atteindre votre routeur (gateway) ?

   ip route | grep default
   ping -c 2 $(ip route | grep default | awk '{print $3}')

   Si ça échoue : Route manquante, passerelle down, câble débranché

3. Vérifier Internet

   Pouvez-vous atteindre une IP publique connue ?

   ping -c 2 8.8.8.8

   Si ça échoue : Problème de routage Internet, firewall, FAI

4. Vérifier le DNS

   La résolution de noms fonctionne-t-elle ?

   dig google.com +short

   Si ça échoue : Problème DNS, /etc/resolv.conf mal configuré

5. Vérifier le service distant

   Le port du service est-il ouvert et répond-il ?

   nc -zv <host> <port>
   curl -I https://<host>/

   Si ça échoue : Service arrêté, firewall applicatif, erreur applicative

Les questions clés à se poser

Avant de lancer des commandes, posez-vous ces questions qui orientent le diagnostic :

Question	Implication
Est-ce que ça marchait avant ?	Si oui, qu'est-ce qui a changé ? (mise à jour, config, firewall)
Est-ce que ça marche en local ?	Distingue problème réseau vs applicatif
Est-ce que ça marche depuis une autre machine ?	Distingue problème client vs serveur
D'autres services sont-ils affectés ?	Problème global (réseau) vs isolé (service)
L'erreur est-elle immédiate ou après un délai ?	Immédiate = refusé, Délai = filtré/timeout

Glissez pour voir

Le réflexe du « qu'est-ce qui a changé ? »

Dans 80% des cas, un problème réseau qui "fonctionnait avant" est causé par un changement récent : mise à jour, modification de configuration, nouvelle règle firewall, changement DNS. Commencez toujours par identifier ce qui a changé.

Checklist de diagnostic rapide

Copiez-collez cette checklist pour un diagnostic express :

#!/bin/bash
# Checklist diagnostic réseau

echo "=== 1. Interface et IP ==="
ip addr show | grep -E "state|inet "

echo -e "\n=== 2. Route par défaut ==="
ip route show | grep default

echo -e "\n=== 3. Ping passerelle ==="
GATEWAY=$(ip route | grep default | awk '{print $3}')
ping -c 2 $GATEWAY

echo -e "\n=== 4. Ping Internet ==="
ping -c 2 8.8.8.8

echo -e "\n=== 5. Résolution DNS ==="
dig google.com +short

echo -e "\n=== 6. Test port (modifier host/port) ==="
# nc -zv <host> <port>
echo "Exécuter : nc -zv <host> <port>"

Résultat attendu : chaque étape doit réussir. La première qui échoue indique la zone du problème.

Interprétation des erreurs courantes

« Connection refused »

Le service écoute mais refuse la connexion, ou le port est fermé.

Cause probable	Vérification	Solution
Service non démarré	systemctl status <service>	Démarrer le service
Port mal configuré	ss -tuln | grep <port>	Vérifier la config du service
Firewall local	iptables -L ou nft list ruleset	Ouvrir le port

Glissez pour voir

« Connection timed out »

Le paquet ne revient jamais. Souvent un firewall qui drop silencieusement.

Cause probable	Vérification	Solution
Firewall distant	traceroute <host>	Contacter l'admin du firewall
Routage incorrect	ip route get <ip>	Vérifier les routes
FAI bloquant	Tester depuis un autre réseau	VPN ou contacter le FAI

Glissez pour voir

« Name or service not known »

La résolution DNS a échoué.

Cause probable	Vérification	Solution
Serveur DNS down	dig @8.8.8.8 example.com	Utiliser un DNS alternatif
/etc/resolv.conf vide	cat /etc/resolv.conf	Ajouter nameserver 8.8.8.8
Domaine inexistant	dig example.com	Vérifier l'orthographe
Cache DNS	resolvectl flush-caches (systemd-resolved)	Vider le cache

Glissez pour voir

« No route to host »

La machine ne sait pas comment atteindre la destination.

Cause probable	Vérification	Solution
Pas de route par défaut	ip route	Ajouter la gateway
Gateway down	ping <gateway>	Vérifier le routeur
VLAN/subnet incorrect	ip addr	Vérifier l'adresse IP

Glissez pour voir

« Host unreachable »

La destination est connue mais inaccessible (souvent ICMP unreachable reçu).

Cause probable	Vérification	Solution
Machine éteinte	ip neigh (présence dans la table de voisinage ?)	Allumer la machine
Firewall bloquant	traceroute <host>	Vérifier les règles firewall
Problème réseau intermédiaire	mtr <host>	Identifier le routeur défaillant

Glissez pour voir

Outils par symptôme

Symptôme	Outils à utiliser	Ce qu'on cherche
Pas d'IP	ip addr, dhclient -v	Interface UP, adresse assignée
Pas de route	ip route, traceroute	Route par défaut, chemin vers destination
DNS KO	dig, nslookup, /etc/resolv.conf	Résolution fonctionnelle, serveur DNS accessible
Port fermé/filtré	nc -zv, ss -tuln, nmap	Port ouvert, service écoutant
Latence élevée	ping, mtr, traceroute	RTT, routeur lent identifié
Paquets perdus	ping -c 100, mtr	% de perte, localisation
Erreur HTTP	curl -v, logs serveur	Code de statut, message d'erreur
Certificat TLS	curl -v, openssl s_client	Validité, chaîne de confiance

Glissez pour voir

Cas pratiques de diagnostic

Cas 1 : « curl timeout »

Un curl https://api.example.com/health ne répond pas.

1. Tester la résolution DNS

   dig api.example.com +short

   Résultat : 203.0.113.42 ✅

2. Tester la connectivité IP

   ping -c 2 203.0.113.42

   Résultat : timeout ❌

3. Tester le port directement

   nc -zv 203.0.113.42 443

   Résultat : timeout ❌

4. Tracer le chemin

   traceroute 203.0.113.42

   Résultat : s'arrête à un routeur intermédiaire

5. Conclusion

   Firewall ou problème de routage entre vous et le serveur. Contacter l'admin réseau.

Cas 2 : « Connection refused »

Un curl http://localhost:8080/api retourne "Connection refused".

1. Vérifier si le service écoute

   ss -tuln | grep 8080

   Résultat : rien ❌

2. Vérifier l'état du service

   systemctl status mon-api

   Résultat : inactive (dead) ❌

3. Démarrer le service

   sudo systemctl start mon-api

4. Revérifier

   ss -tuln | grep 8080
   curl http://localhost:8080/api

   Résultat : LISTEN sur 8080 ✅, réponse API ✅

Cas 3 : « Name resolution failed »

Un curl https://mon-service.internal/ échoue avec "Could not resolve host".

1. Tester avec dig

   dig mon-service.internal +short

   Résultat : rien ❌

2. Vérifier le serveur DNS configuré

   cat /etc/resolv.conf

   Résultat : nameserver 10.0.0.1

3. Tester ce serveur DNS

   dig @10.0.0.1 mon-service.internal +short

   Résultat : timeout ❌

4. Tester un DNS public

   dig @8.8.8.8 mon-service.internal +short

   Résultat : rien (domaine .internal non public)

5. Conclusion

   Le DNS interne (10.0.0.1) est down ou le domaine n'y est pas configuré. Contacter l'admin DNS.

Bonnes pratiques de diagnostic

À faire

• Toujours tester du plus proche au plus loin
• Noter ce qui fonctionne ET ce qui échoue
• Tester une seule variable à la fois
• Vérifier les logs (journalctl, /var/log/)
• Comparer avec une machine qui fonctionne
• Documenter le problème et la solution

À éviter

• Blâmer "le réseau" sans vérification
• Changer plusieurs choses en même temps
• Ignorer les messages d'erreur exacts
• Oublier de vérifier le firewall local
• Supposer que "ça marchait" sans vérifier
• Redémarrer en espérant que ça se règle

Le piège du redémarrage

Redémarrer un service ou une machine peut masquer le vrai problème. Avant de redémarrer, collectez les informations de diagnostic (logs, état des connexions, processus). Le redémarrage devrait être la solution de dernier recours, pas le premier réflexe.

Validation des acquis

Testez votre méthodologie avec ces exercices :

1. Simuler un problème DNS

   Modifiez temporairement /etc/resolv.conf pour pointer vers un serveur inexistant, puis diagnostiquez.

2. Bloquer un port avec iptables

   sudo iptables -A INPUT -p tcp --dport 22 -j DROP

   Diagnostiquez pourquoi SSH ne répond plus (depuis une autre session !), puis retirez la règle.

3. Arrêter un service

   Arrêtez un service web et utilisez la checklist pour identifier le problème.

Dépannage rapide (table de référence)

Symptôme	Première commande	Si ça échoue
Pas de réseau du tout	ip addr	Interface down, pas d'IP
Ping gateway échoue	ip route	Route manquante
Ping 8.8.8.8 échoue	traceroute 8.8.8.8	Routage/firewall intermédiaire
DNS ne résout pas	dig @8.8.8.8 domain	Problème DNS local
Port timeout	nc -zv host port	Firewall distant
Port refused	ss -tuln | grep port	Service non démarré
HTTP 5xx	curl -v URL	Logs serveur
Certificat invalide	openssl s_client -connect host:443	Date/CN/CA

Glissez pour voir

À retenir

• Toujours diagnostiquer du plus proche au plus loin : localhost → gateway → Internet → DNS → service
• « Connection refused » = port fermé ou service arrêté → vérifier ss -tuln
• « Connection timeout » = firewall qui drop silencieusement → vérifier avec traceroute
• « Name not found » = problème DNS → vérifier /etc/resolv.conf et dig
• Les logs sont vos meilleurs amis : journalctl -u service, /var/log/
• Documenter le problème ET la solution pour la prochaine fois
• Le redémarrage masque le problème, le diagnostic le résout

FAQ : questions fréquentes sur le diagnostic réseau

Comment diagnostiquer un problème réseau méthodiquement ?

On diagnostique du plus proche au plus loin : d'abord l'interface et l'IP locale (ip addr), puis la passerelle (ip route, ping gateway), puis Internet (ping 8.8.8.8), puis le DNS (dig), enfin le service distant (nc -zv, curl). La première étape qui échoue localise la zone du problème.

Quelle différence entre « connection refused » et « connection timed out » ?

Connection refused : la machine répond par un RST (port fermé, service arrêté, ou pare-feu en REJECT), mais l'hôte est joignable. Connection timed out : aucune réponse, un pare-feu jette le paquet en silence (DROP) ou l'hôte est injoignable. Refused = échec immédiat, timeout = longue attente.

Comment savoir si le problème vient du réseau ou de l'application ?

On teste en local d'abord : si curl localhost ou ss montrent le service qui écoute et répond, le réseau est hors de cause. On teste ensuite depuis une autre machine pour distinguer client et serveur. Si d'autres services sont touchés, c'est un problème réseau global, pas applicatif.

Quels outils utiliser selon le symptôme réseau ?

Pas d'IP : ip addr. Pas de route : ip route, traceroute. DNS KO : dig, resolvectl. Port fermé ou filtré : nc -zv, ss -tuln. Latence ou pertes : ping, mtr. Erreur HTTP : curl -v. Problème TLS : openssl s_client. Les outils ip, ss, dig remplacent les anciens ifconfig, netstat et nslookup.

Pourquoi ne faut-il pas redémarrer en premier réflexe ?

Le redémarrage masque la cause sans la corriger : le problème reviendra, et vous perdez l'état (connexions, logs, processus) qui permettait de comprendre. Avant de redémarrer, collectez les informations de diagnostic. Le redémarrage est la solution de dernier recours, pas le premier geste.

Prochaines étapes

Homelab réseau Mettez en pratique avec un lab de 2 VMs et une passerelle NAT

Commandes réseau de base Revoyez les outils fondamentaux du diagnostic

ICMP et ping Approfondissez les messages d'erreur ICMP

TCP vs UDP Comprenez les différences pour mieux diagnostiquer

×

📖 Voir la documentation →