Diagnostiquer un problème réseau sous Linux

Quand le réseau ne répond plus, 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 racine. Les commandes sont organisées par scénario d'incident, pas par ordre alphabétique. Cette page applique au réseau la méthode générale de diagnostic du parcours Dépanner : observer avant d'agir, et ne changer qu'une chose à la fois.

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 (paquet net-tools) sont dépréciées depuis plus de quinze ans au profit de la suite iproute2. 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	Beaucoup plus rapide, filtres puissants
traceroute	mtr	Temps réel, stats cumulées
nslookup	dig	Sortie parsable, options avancées

Glissez pour voir

Prérequis

Diagnostiquer, c'est comparer ce que vous observez avec ce qui devrait se passer. Sans modèle mental du cheminement d'un paquet, les commandes de ce guide ne sont qu'une liste à recopier. Assurez-vous de maîtriser 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 ?

En situation de panne, le réflexe le plus coûteux est de lancer des commandes au hasard. Ce tableau vous oriente : identifiez votre symptôme, lancez la première commande pour qualifier le problème, puis suivez le parcours correspondant, détaillé plus bas.

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 en timeout, ping sans réponse, connexion refusée). Si c'est spécifiquement votre accès SSH qui est perdu, en particulier après une modification de sshd_config, suivez plutôt le parcours dédié Retrouver l'accès SSH à un serveur : le diagnostic ci-dessous couvre le cas général d'un hôte injoignable.

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

La commande ip regroupe tout ce que faisaient ifconfig, route et arp : interfaces, adresses, routes et voisins ARP. Ces cinq invocations couvrent l'essentiel d'un état des lieux réseau, à connaître par cœur avant d'aller plus loin :

# 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). La nature du refus est déjà un indice : Connection refused signifie que la machine répond mais que rien n'écoute, un timeout pointe vers un pare-feu qui jette les paquets en silence.

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 pare-feu de la distribution (sur le serveur)

   # Ubuntu/Debian avec UFW
   sudo ufw status verbose
   
   # RHEL/AlmaLinux/Rocky avec firewalld
   sudo firewall-cmd --list-all

   Vérifier : Le port ou le service concerné est-il autorisé ?

4. Inspecter les règles bas niveau (si aucun gestionnaire n'est actif)

   sudo nft list ruleset | grep -E "22|ssh"
   # Ou sur les systèmes encore en iptables :
   sudo iptables -L -n -v | grep -E "22|ssh"

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

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.

Si le test nc réussit mais que l'application ne renvoie aucune réponse utile (la connexion s'ouvre puis reste muette, ou systemctl affiche active (running) alors que rien ne fonctionne), le problème n'est plus réseau : c'est le processus lui-même qui est en cause. Poursuivez avec Un service actif qui ne répond pas.

Commandes ss essentielles

ss remplace netstat pour inspecter les sockets : ports en écoute, connexions établies, processus associés. Son langage de filtres évite de tout afficher puis de trier avec grep, ce qui compte sur un serveur qui gère des milliers de connexions :

# 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. Interroger directement votre serveur DNS

   dig @192.168.1.1 google.com +short

   Si timeout → Le serveur DNS est injoignable ou le port 53 est filtré.

   Si SERVFAIL ou REFUSED → Le serveur répond mais refuse ou échoue à résoudre.

5. Vérifier le cache DNS local

   # Sur les systèmes utilisant systemd-resolved (Ubuntu par défaut)
   resolvectl statistics
   resolvectl flush-caches

Commandes dig essentielles

dig interroge les serveurs DNS et affiche la réponse brute : type d'enregistrement, TTL, serveur qui a répondu. C'est ce niveau de détail qui manque à nslookup et qui permet de distinguer un cache périmé d'une zone mal configurée :

# 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. C'est le diagnostic le plus délicat, parce que « lent » peut venir de la latence, de la perte de paquets ou d'une bande passante saturée : chaque cause a son outil.

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

mtr combine ping et traceroute en continu : il rejoue le trajet en boucle et cumule les statistiques par saut, ce qui rend visibles les problèmes intermittents qu'un traceroute unique rate. Le mode TCP est précieux quand les routeurs filtrent ICMP :

# 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. curl permet de découper le temps de réponse étape par étape (DNS, connexion TCP, négociation TLS, premier octet) et de désigner le maillon fautif.

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. Court-circuiter le DNS

   # Récupérer l'IP réelle du serveur
   dig +short example.com
   
   # Forcer curl à utiliser cette IP sans passer par le DNS
   curl --resolve example.com:443:<ip> https://example.com

   Si ça marche avec l'IP directe → Le problème vient de la résolution DNS, pas du serveur web.

Commandes curl pour le diagnostic

curl est bien plus qu'un téléchargeur : ses options -v, -w et -I en font une sonde HTTP complète, capable de mesurer chaque étape de la requête et d'isoler un problème de certificat, de redirection ou de timeout :

# 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

# Code HTTP seul (pratique en script)
curl -s -o /dev/null -w "%{http_code}\n" https://example.com

Boîte à outils par intention

Une fois les parcours assimilés, ce qui reste en mémoire, c'est l'intention (« je veux voir mes routes », « je veux tester un port »), pas l'option exacte. Ces trois tableaux servent d'aide-mémoire : partez de ce que vous voulez faire, la commande suit.

"Je veux voir..."

Ces commandes sont en lecture seule : elles affichent l'état du système sans rien modifier, vous pouvez les lancer sans risque même en production.

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 nft list ruleset	-

Glissez pour voir

"Je veux tester..."

Ces commandes émettent du trafic actif vers une cible : réservez-les aux machines dont vous avez la responsabilité ou l'autorisation.

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..."

Ces commandes croisent les informations pour remonter à la source : quel processus détient un port, à qui appartient une adresse.

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

Dépannage express

Ce tableau condense les pannes réseau les plus fréquentes avec leur cause probable et la solution à tenter en premier. Il ne remplace pas les parcours détaillés ci-dessus, mais il suffit souvent à débloquer les cas simples.

Symptôme	Cause probable	Solution
ping OK vers l'IP, échec vers le nom	DNS défaillant	Tester dig @8.8.8.8, vérifier /etc/resolv.conf
Connection refused sur un port	Service arrêté ou en écoute sur 127.0.0.1	ss -tlnp, redémarrer le service, corriger l'adresse d'écoute
Timeout sur un port précis, ping OK	Pare-feu qui jette les paquets	ufw status (Ubuntu), firewall-cmd --list-all (RHEL), nft list ruleset
Aucune IP sur l'interface	DHCP en échec ou interface DOWN	ip link set <iface> up, puis Netplan sur Ubuntu ou NetworkManager sur RHEL
Destination Host Unreachable	Passerelle absente ou mauvaise route	ip route show default, ajouter la route par défaut
Latence élevée par intermittence	Congestion ou perte sur un saut	mtr -r -c 20 <cible> pour localiser le saut fautif

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é

Les outils de diagnostic réseau sont à double tranchant : les mêmes commandes qui vous aident à localiser une panne servent aussi à cartographier un réseau, intercepter du trafic ou obtenir une élévation de privilèges. Avant de les installer partout et de distribuer des droits sudo, mesurez ce que chacun permet réellement.

Commandes à utiliser avec précaution

tcpdump avec sudo : L'option -z exécute une commande arbitraire à chaque rotation du fichier de capture. Un utilisateur autorisé à lancer sudo tcpdump sans restriction d'arguments peut s'en servir pour obtenir un shell root. Ne donnez jamais un accès sudo global à tcpdump.

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 : Certaines variantes (nc.traditional, ncat) acceptent l'option -e, qui connecte un shell au réseau. Ne jamais l'utiliser en production.

Au-delà de ces cas extrêmes, l'installation même de ces outils augmente la surface d'attaque d'un serveur : nmap peut déclencher des alertes de sécurité, tcpdump capture des données sensibles (mots de passe, tokens), netcat peut servir de backdoor et iftop exige des privilèges élevés pour capturer le trafic. 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

Quand l'incident se répète, autant scripter le diagnostic : ces trois scripts enchaînent les vérifications des parcours précédents et produisent un état des lieux complet en une commande, pratique à archiver dans un post-mortem.

Diagnostic complet d'un hôte

Ce script combine ping, route, test des ports standards et traceroute : c'est le parcours « hôte injoignable » automatisé.

#!/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

Ce script interroge les enregistrements A, NS et MX d'un domaine, puis compare la réponse de deux DNS publics : une divergence signale un problème de propagation ou un résolveur local défaillant.

#!/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

Ce script mesure le timing détaillé d'une requête (DNS, connexion, TLS, premier octet) puis affiche les en-têtes de réponse : de quoi situer la lenteur avant d'accuser le backend.

#!/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

Mettre en pratique

Une méthode de diagnostic ne s'acquiert que face à une vraie panne. Le lab vous met devant une machine dont la connexion réseau est tombée : à vous de remonter les couches avec ip, ss et ping, de localiser la cause racine et de rétablir le trafic.

Lab pratique

Diagnostiquer et rétablir une connexion réseau tombée

$ dsoxlab run l4-network-troubleshoot

Environnement : VM·Durée : ~25 min

Validé : l'état du système est vérifié après reboot, pas la commande tapée.

Première fois ? Qu'est-ce que dsoxlab et comment l'installer

dsoxlab est la ligne de commande qui prépare un environnement jetable (un shell isolé ou une VM), déroule le scénario du lab, puis vérifie l'état réel du système et calcule un score. Rien n'est installé ni cassé sur votre poste de travail.

Installer la CLI dsoxlab, une seule fois :

uv tool install dsoxlab   # ou : pipx install dsoxlab
git clone https://github.com/stephrobert/linux-dsoxlab-training.git
cd linux-dsoxlab-training

Lancer ce lab, puis valider votre travail :

dsoxlab run l4-network-troubleshoot
dsoxlab check l4-network-troubleshoot

Voir tous les labs : dsoxlab list-labs. Suivre sa progression : dsoxlab progress.

Contrôle de connaissances

Vérifiez que l'essentiel de ce guide est acquis. Les questions portent uniquement sur ce qui vient d'être expliqué ici.

Contrôle de connaissances

Validez vos connaissances avec ce quiz interactif

6 questions

6 min.

70% 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

Pour aller plus loin

• Un service actif qui ne répond pas : Quand le port répond mais que l'application reste muette.
• Retrouver l'accès SSH à un serveur : Connection refused, timeout, Permission denied : chaque symptôme a sa cause.
• 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 →