Diagnostic réseau Linux : guide pratique par scénario

Quand un service ne répond pas, la question n’est pas “quelle commande utiliser ?” mais “à quelle couche se situe le problème ?”. Ce guide vous donne une méthodologie de diagnostic réseau structurée : vous partez du symptôme, suivez un parcours logique, et identifiez la cause. Les commandes sont organisées par scénario d’incident, pas par ordre alphabétique.

Ce que vous allez apprendre

• Diagnostiquer méthodiquement un problème réseau en suivant les couches OSI
• Choisir la bonne commande selon le symptôme observé
• Interpréter les résultats pour identifier la cause racine
• Utiliser les outils modernes (ip, ss, mtr) plutôt que les commandes dépréciées

Commandes modernes vs héritées

Les commandes ifconfig, route et netstat sont dépréciées depuis 2009. Utilisez leur remplacement moderne :

Ancienne	Moderne	Pourquoi changer
ifconfig	ip addr	Plus complet, scriptable, maintenu
route	ip route	Syntaxe unifiée, IPv6 natif
netstat	ss	10x plus rapide, filtres puissants
traceroute	mtr	Temps réel, stats cumulées
nslookup	dig	Sortie parsable, options avancées

Glissez pour voir

Prérequis

Avant de diagnostiquer efficacement, maîtrisez ces fondamentaux :

• Modèle OSI : comprendre les 7 couches et leur rôle
• Adressage IP : notation CIDR, masques, sous-réseaux
• Protocoles : TCP vs UDP, ICMP, DNS
• Routage : passerelle par défaut, tables de routage

Fondamentaux des réseaux Modèle OSI, protocoles, adressage

Je suis en incident : quel parcours suivre ?

Identifiez votre symptôme et suivez le parcours correspondant :

Symptôme	Parcours	Première commande
Machine distante injoignable	Hôte injoignable	ping -c 3 <ip>
Service/port ne répond pas	Port ne répond pas	nc -zv <ip> <port>
Résolution de nom échoue	DNS ne fonctionne pas	dig <domaine>
Connexion lente ou instable	Réseau lent	mtr <destination>
Requête HTTP en erreur	HTTP ne fonctionne pas	curl -I <url>

Glissez pour voir

Hôte distant injoignable

Symptôme : Impossible de joindre une machine distante (SSH timeout, ping sans réponse, connexion refusée).

1. Vérifier la connectivité de base

   ping -c 3 192.168.1.100

   Si réponse → L’hôte est joignable, le problème est ailleurs (port, firewall applicatif).

   Si timeout → Continuez le diagnostic (ICMP peut être bloqué).

2. Vérifier votre propre configuration IP

   ip addr show
   # Chercher : inet 192.168.x.x/24 sur l'interface active

   Vérifier : L’interface a-t-elle une IP ? Est-elle dans le bon sous-réseau ?

3. Vérifier la route vers la destination

   ip route get 192.168.1.100
   # Résultat attendu : via 192.168.1.1 dev eth0

   Si “unreachable” → Problème de routage, vérifier la passerelle.

4. Vérifier la passerelle par défaut

   ip route show default
   # Résultat attendu : default via 192.168.1.1 dev eth0

   Si absente → Ajouter avec ip route add default via <gateway>.

5. Tester la passerelle elle-même

   ping -c 3 192.168.1.1

   Si timeout → Problème entre vous et le routeur (câble, switch, VLAN).

6. Tracer le chemin complet

   mtr -r -c 10 192.168.1.100

   Interpréter : À quel saut la perte de paquets commence-t-elle ?

Le ping timeout ne signifie pas 'machine éteinte'

De nombreux pare-feu bloquent ICMP par défaut. Une machine peut être parfaitement fonctionnelle tout en ne répondant pas au ping. Testez toujours un port spécifique avec nc -zv avant de conclure.

Commandes de diagnostic IP essentielles

# Afficher toutes les interfaces et leurs IP
ip addr show

# Afficher uniquement les interfaces UP
ip link show up

# Afficher la table de routage complète
ip route show

# Afficher les voisins ARP (résolution MAC)
ip neigh show

# Afficher les statistiques d'interface
ip -s link show eth0

Le port ne répond pas

Symptôme : Connexion refusée ou timeout sur un port spécifique (SSH, HTTP, base de données).

1. Tester la connectivité au port

   nc -zv 192.168.1.100 22
   # Succès : Connection to 192.168.1.100 22 port [tcp/ssh] succeeded!
   # Échec : nc: connect to 192.168.1.100 port 22 (tcp) failed: Connection refused

   Connection refused → Le port n’est pas en écoute côté serveur.

   Timeout → Un firewall bloque le flux.

2. Vérifier que le service écoute (sur le serveur)

   ss -tlnp | grep :22
   # Attendu : LISTEN 0 128 0.0.0.0:22 *:* users:(("sshd",pid=1234,fd=3))

   Si aucune ligne → Le service n’est pas démarré.

   Si 127.0.0.1:22 → Le service n’écoute que sur localhost.

3. Vérifier le firewall local (sur le serveur)

   sudo iptables -L -n -v | grep -E "22|ssh"
   # Ou avec nftables :
   sudo nft list ruleset | grep -E "22|ssh"

   Chercher : Une règle DROP ou REJECT sur le port concerné.

4. Vérifier le pare-feu UFW (si installé)

   sudo ufw status verbose
   # Vérifier que le port est autorisé

5. Tester depuis le serveur lui-même

   nc -zv 127.0.0.1 22

   Si OK en local mais pas à distance → Firewall ou configuration d’écoute.

Commandes ss essentielles

# Tous les ports TCP en écoute avec le processus
ss -tlnp

# Tous les ports UDP en écoute
ss -ulnp

# Connexions TCP établies
ss -tn state established

# Filtrer par port
ss -tn 'sport == :22'

# Filtrer par adresse distante
ss -tn 'dst 192.168.1.0/24'

# Statistiques détaillées des connexions
ss -ti

Le DNS ne fonctionne pas

Symptôme : Impossible de résoudre un nom de domaine (ping google.com échoue, mais ping 8.8.8.8 fonctionne).

1. Tester la résolution DNS

   dig google.com +short
   # Attendu : 142.250.xxx.xxx

   Si vide ou SERVFAIL → Problème DNS.

2. Vérifier le serveur DNS configuré

   cat /etc/resolv.conf
   # nameserver 192.168.1.1
   # ou nameserver 127.0.0.53 (systemd-resolved)

3. Tester avec un DNS public

   dig @8.8.8.8 google.com +short

   Si ça marche → Votre DNS local est défaillant.

4. Tester la connectivité au serveur DNS

   nc -zvu 192.168.1.1 53
   # DNS utilise UDP port 53

5. Vérifier le cache DNS local

   # Avec systemd-resolved
   resolvectl statistics
   resolvectl flush-caches

Commandes dig essentielles

# Requête simple (enregistrement A)
dig google.com

# Réponse courte uniquement
dig google.com +short

# Enregistrements MX (serveurs mail)
dig google.com MX

# Résolution inverse (IP vers nom)
dig -x 8.8.8.8

# Tracer la délégation DNS complète
dig google.com +trace

# Utiliser un serveur DNS spécifique
dig @1.1.1.1 google.com

# Afficher uniquement la section réponse
dig google.com +noall +answer

Le réseau est lent

Symptôme : Latence élevée, connexions qui traînent, timeouts intermittents.

1. Mesurer la latence et les pertes

   mtr -r -c 20 google.com

   Interpréter :

   • Loss% > 5% = problème de congestion ou de lien
   • Avg > 100ms vers un serveur local = anormal
   • StDev élevé = connexion instable

2. Identifier le goulot d’étranglement

   Regarder à quel saut la latence augmente brusquement ou les pertes commencent.

3. Tester la bande passante

   # Sur le serveur distant
   iperf3 -s
   
   # Sur votre machine
   iperf3 -c <serveur> -t 30

4. Surveiller le trafic en temps réel

   # Vue globale par connexion
   sudo iftop -i eth0
   
   # Statistiques d'interface
   ip -s link show eth0

5. Vérifier les erreurs d’interface

   ip -s link show eth0 | grep -E "errors|dropped|overrun"
   # Tout doit être à 0

Commandes mtr essentielles

# Rapport après 10 envois
mtr -r -c 10 google.com

# Mode continu (interactif)
mtr google.com

# Afficher les IP sans résolution
mtr -n google.com

# Utiliser TCP au lieu d'ICMP
mtr --tcp -P 443 google.com

# Utiliser UDP
mtr --udp google.com

L’HTTP ne fonctionne pas

Symptôme : Page web inaccessible, erreur 502/503/504, timeout sur une API.

1. Tester la connectivité HTTP

   curl -I https://example.com
   # HTTP/2 200 = OK

2. Mesurer les temps de réponse

   curl -w "DNS: %{time_namelookup}s\nConnect: %{time_connect}s\nTLS: %{time_appconnect}s\nFirst byte: %{time_starttransfer}s\nTotal: %{time_total}s\n" -o /dev/null -s https://example.com

   Interpréter :

   • DNS > 1s → Problème de résolution
   • Connect > 1s → Problème réseau ou serveur saturé
   • TLS > 2s → Négociation TLS lente
   • First byte > 5s → Backend lent

3. Tester sans TLS (si applicable)

   curl -I http://example.com

4. Vérifier les en-têtes de réponse

   curl -v https://example.com 2>&1 | head -50

5. Tester avec un autre DNS

   curl --resolve example.com:443:93.184.216.34 https://example.com

Commandes curl pour le diagnostic

# En-têtes uniquement
curl -I https://example.com

# Verbose (détails connexion)
curl -v https://example.com

# Ignorer les erreurs de certificat (test uniquement)
curl -k https://example.com

# Timeout personnalisé
curl --connect-timeout 5 --max-time 10 https://example.com

# Suivre les redirections
curl -L https://example.com

# Avec timing détaillé
curl -w "@curl-timing.txt" -o /dev/null -s https://example.com

Boîte à outils par intention

”Je veux voir…”

Intention	Commande	Exemple
Mon IP et interfaces	ip addr show	ip a
Ma table de routage	ip route show	ip r
Les ports en écoute	ss -tlnp	-
Les connexions établies	ss -tn state established	-
Le trafic en temps réel	sudo iftop -i eth0	-
Les voisins ARP	ip neigh show	ip n
Les règles firewall	sudo iptables -L -n -v	-

Glissez pour voir

”Je veux tester…”

Intention	Commande	Exemple
Si une machine répond	ping -c 3 <ip>	ping -c 3 8.8.8.8
Si un port est ouvert	nc -zv <ip> <port>	nc -zv 192.168.1.1 22
La route vers une destination	mtr -r <ip>	mtr -r google.com
La résolution DNS	dig <domaine>	dig google.com +short
La bande passante	iperf3 -c <serveur>	-
Un endpoint HTTP	curl -I <url>	curl -I https://api.example.com

Glissez pour voir

”Je veux identifier…”

Intention	Commande	Exemple
Quel process utilise un port	ss -tlnp | grep :<port>	ss -tlnp | grep :80
Les connexions d’une IP	ss -tn 'dst <ip>'	ss -tn 'dst 10.0.0.1'
Le propriétaire d’une IP	dig -x <ip>	dig -x 8.8.8.8
Les serveurs DNS d’un domaine	dig <domaine> NS	dig google.com NS
La version d’un service	nmap -sV -p <port> <ip>	nmap -sV -p 22 192.168.1.1

Glissez pour voir

Pièges courants du diagnostic réseau

Le ping ne répond pas = machine éteinte ?

Non. ICMP est souvent filtré. Une machine peut être parfaitement accessible sur ses ports de service tout en ignorant les pings. Testez toujours avec nc -zv sur un port spécifique.

Le port est ouvert = le service fonctionne ?

Non. Un port peut être en écoute (LISTEN) sans que le service soit fonctionnel. Par exemple, un serveur web peut écouter sur le port 80 mais renvoyer des erreurs 500. Testez toujours le protocole applicatif (curl, mysql -e "SELECT 1").

La résolution DNS fonctionne = pas de problème DNS ?

Non. Le cache DNS peut masquer un problème. Videz le cache (resolvectl flush-caches) et retestez. Vérifiez aussi le TTL des enregistrements.

traceroute montre des * = routeur en panne ?

Non. Les * * * signifient que le routeur ne répond pas aux paquets ICMP TTL-exceeded, pas qu’il est en panne. Le trafic peut très bien passer. Seule une perte de paquets constante à partir d’un saut indique un problème.

ss montre ESTABLISHED = connexion active ?

Pas toujours. Une connexion peut rester en ESTABLISHED même si l’autre extrémité est morte (half-open). Les keepalives TCP détectent ça, mais avec un délai. Vérifiez les compteurs de trafic (ss -ti).

Avertissements de sécurité

Commandes à utiliser avec précaution

tcpdump avec sudo : L’option -z permet d’exécuter des commandes arbitraires. Ne jamais donner les droits sudo tcpdump sans restriction.

# DANGER : permet d'obtenir un shell root
sudo tcpdump -w /dev/null -z /bin/sh

nmap sur des réseaux tiers : Scanner sans autorisation est illégal dans la plupart des pays. Limitez-vous à vos propres réseaux ou obtenez une autorisation écrite.

netcat -e : Ouvre un shell accessible depuis le réseau. Ne jamais utiliser en production.

Outils à ne pas installer en production

Ces outils sont utiles pour le diagnostic mais introduisent des risques :

• nmap : Outil offensif, peut déclencher des alertes de sécurité
• tcpdump : Capture des données sensibles (mots de passe, tokens)
• netcat : Peut servir de backdoor
• iftop : Nécessite des privilèges élevés

Préférez des bastions de diagnostic dédiés plutôt que d’installer ces outils sur vos serveurs de production.

Recettes prêtes à l’emploi

Diagnostic complet d’un hôte

#!/bin/bash
# diagnostic-host.sh <ip>
HOST=$1

echo "=== Diagnostic de $HOST ==="
echo -e "\n--- Ping ---"
ping -c 3 $HOST

echo -e "\n--- Route ---"
ip route get $HOST

echo -e "\n--- Ports standards ---"
for port in 22 80 443; do
  nc -zv -w 2 $HOST $port 2>&1
done

echo -e "\n--- Traceroute ---"
mtr -r -c 5 $HOST

Diagnostic DNS complet

#!/bin/bash
# diagnostic-dns.sh <domaine>
DOMAIN=$1

echo "=== Diagnostic DNS de $DOMAIN ==="

echo -e "\n--- Résolution A ---"
dig $DOMAIN A +short

echo -e "\n--- Serveurs de noms ---"
dig $DOMAIN NS +short

echo -e "\n--- Serveurs mail ---"
dig $DOMAIN MX +short

echo -e "\n--- Test avec DNS publics ---"
echo "Google (8.8.8.8):"
dig @8.8.8.8 $DOMAIN +short
echo "Cloudflare (1.1.1.1):"
dig @1.1.1.1 $DOMAIN +short

Diagnostic HTTP complet

#!/bin/bash
# diagnostic-http.sh <url>
URL=$1

echo "=== Diagnostic HTTP de $URL ==="

echo -e "\n--- Timing ---"
curl -w "DNS: %{time_namelookup}s\nConnect: %{time_connect}s\nTLS: %{time_appconnect}s\nFirst byte: %{time_starttransfer}s\nTotal: %{time_total}s\nHTTP code: %{http_code}\n" -o /dev/null -s "$URL"

echo -e "\n--- En-têtes ---"
curl -I -s "$URL" | head -20

Contrôle de connaissances

Contrôle de connaissances

Validez vos connaissances avec ce quiz interactif

8 questions

5 min.

80% requis

Informations

• Le chronomètre démarre au clic sur Démarrer
• Questions à choix multiples, vrai/faux et réponses courtes
• Vous pouvez naviguer entre les questions
• Les résultats détaillés sont affichés à la fin

Démarrer le quiz

Lance le quiz et démarre le chronomètre

À retenir

1. Diagnostiquer par couche OSI : physique → liaison → réseau → transport → application
2. Utiliser les commandes modernes : ip remplace ifconfig/route, ss remplace netstat
3. Un ping timeout ne prouve rien : ICMP est souvent filtré, testez le port réel
4. Un port ouvert ≠ service fonctionnel : testez toujours le protocole applicatif
5. mtr > traceroute : vision continue, statistiques, détection des problèmes intermittents
6. dig > nslookup : sortie parsable, options avancées, trace complète
7. Sécurité : tcpdump et nmap sont dangereux en production, utilisez des bastions dédiés
8. Documenter les résultats : gardez une trace des commandes et sorties pour les post-mortems

Prochaines étapes

Nmap : scan de réseau Exploration avancée et audit de sécurité

Tcpdump : capture de trafic Analyse des paquets réseau

Netcat : le couteau suisse Tests de connectivité et transferts

Rappels juridiques Ce que la loi autorise et interdit

×

📖 Voir la documentation →