Rédigé par Rédaction CyberSDF / 14 September 2026 / mis à jour 30 October 2026

Diagnostiquer une connexion réseau sous Linux : pas à pas

Pour localiser une panne réseau sous Linux, lisez les couches dans cet ordre : interface, adresse IP, route, résolution DNS, puis service. Les commandes ci-dessous observent l’état de la machine et ne demandent pas de privilège pour la lecture. Notez la sortie et le code de retour avant de passer à l’étape suivante.

Pour un service SSH, comparez l’adresse et le port de destination avec la configuration du client : cela distingue une erreur de cible d’un problème de connectivité.

Pour relier deux machines avec un VPN, vérifiez séparément l’état du pair, les adresses privées et la route attendue avant d’examiner le service distant.

Sur un réseau Tailscale, distinguez l’état du pair, le nom MagicDNS et le service réellement à l’écoute : une résolution réussie ne prouve pas que le service répond.

Commencez avec les commandes de base du terminal si ip, les chemins ou les codes de retour vous sont encore peu familiers. Pour un diagnostic fiable, utilisez d’abord une adresse IP, puis un nom de domaine : cela sépare une panne de route d’un problème DNS.

Dans quel ordre faut-il diagnostiquer une panne réseau ?

1. Interface et adresse : ip -br addr montre si une interface autre que lo possède une adresse.
2. Route : ip route show default indique la passerelle choisie pour sortir du réseau local.
3. Voisinage : ip neigh montre si la machine atteint cette passerelle sur le lien local.
4. Résolution : getent hosts debian.org vérifie le chemin utilisé par les programmes pour traduire un nom en adresse.
5. Service : curl vérifie enfin qu’un serveur répond au protocole attendu.

Une réponse positive à une étape ne valide pas les suivantes. Une interface active peut ne posséder aucune adresse, un DNS fonctionnel peut pointer vers un service arrêté et un serveur web peut filtrer ICMP tout en acceptant HTTPS.

Comment vérifier l’interface et l’adresse IP ?

Voir l’état de toutes les interfaces

ip -br addr

La vue courte affiche l’état, le nom et les adresses de chaque interface. Ignorez lo pour juger l’accès au réseau : 127.0.0.1/8 et ::1/128 désignent uniquement la machine locale. Une interface physique ou Wi-Fi en UP sans adresse utilisable oriente vers le lien, le DHCP ou le gestionnaire réseau. Une interface en DOWN est inactive au niveau du noyau, mais ce constat ne dit pas encore pourquoi.

Lire les détails d’une interface

ip -br link
ip link show dev eth0

Remplacez eth0 par le nom réellement affiché. ip -br link donne une vue rapide ; ip link show dev ajoute notamment l’état du lien, la MTU et le rattachement éventuel à un bridge. Les noms modernes peuvent être enp0s3, wlp4s0 ou autre : ne recopiez pas un nom trouvé sur une autre machine.

Dans ip -br addr, une adresse IPv4 se présente par exemple sous la forme 192.0.2.10/24. Le suffixe indique la taille du réseau, pas une commande à appliquer. Une adresse IPv6 commençant par fe80::/10 est limitée au lien local ; elle ne prouve donc pas à elle seule un accès à Internet.

Comment lire la route et la passerelle ?

Vérifier la route par défaut

ip route show default

Une sortie comme default via 192.0.2.1 dev eth0 proto dhcp indique la passerelle, l’interface de sortie et l’origine de la route. Une sortie vide signifie qu’aucune route par défaut n’est installée. La machine peut encore communiquer avec son réseau local, mais elle ne sait pas où envoyer une adresse extérieure. Le message Network is unreachable s’explique alors par la table de routage, pas par le DNS.

Voir la route retenue pour une cible

ip route get 1.1.1.1

Cette commande tient compte des routes plus spécifiques et des interfaces multiples. Une ligne du type 1.1.1.1 via 192.0.2.1 dev eth0 src 192.0.2.10 uid 1000 permet de lire la passerelle, l’interface et l’adresse source choisies pour cette destination. Si la commande échoue avec une erreur de route, conservez cette erreur : elle est plus utile qu’un redémarrage lancé au hasard.

Examiner le voisinage de la passerelle

ip neigh
ip -4 neigh

La table ARP pour IPv4 et NDP pour IPv6 associe les adresses du réseau local à des voisins connus. REACHABLE indique un voisin contacté récemment, STALE une entrée à rafraîchir et FAILED une résolution qui n’a pas abouti. Une passerelle en FAILED oriente vers le câble, le Wi-Fi, le point d’accès ou le réseau local. Vérifiez l’interface et la route avant d’accuser le serveur distant.

Comment distinguer une panne DNS du reste de la connexion ?

Testez une adresse IP et un nom séparément. Si une adresse répond mais qu’un nom reste introuvable, l’interface et la route ne sont probablement pas le premier problème à traiter. Pour l’erreur exacte Temporary failure in name resolution, suivez le diagnostic détaillé de l’échec temporaire de résolution DNS sous Linux.

Utiliser la résolution du système avec getent

getent hosts localhost
getent hosts debian.org

getent hosts passe par la bibliothèque système et respecte la ligne hosts: de /etc/nsswitch.conf. Une réponse fournit au moins une adresse et un nom ; une sortie vide avec un code de retour non nul signifie que la résolution demandée n’a pas abouti. L’absence de resolvectl ne rend pas ce test inutile.

Lire le résolveur actif

resolvectl status
ls -l /etc/resolv.conf
grep '^hosts:' /etc/nsswitch.conf

resolvectl status indique les serveurs DNS associés aux interfaces et le mode utilisé par systemd-resolved. /etc/resolv.conf est souvent un lien symbolique vers un fichier sous /run, mais NetworkManager ou un fichier statique peuvent gérer la résolution. La ligne hosts: montre si la machine consulte d’abord /etc/hosts, le DNS ou un autre module.

Lisez ces fichiers avant toute action. Éditer directement /etc/resolv.conf peut être sans effet si un service le régénère, et modifier /etc/nsswitch.conf peut casser la résolution locale. Le bon correctif dépend du gestionnaire réseau réellement installé.

Comment tester la cible puis le service ?

Mesurer la pile locale et une cible IP

ping -c 3 -W 1 127.0.0.1
ping -c 3 -W 1 1.1.1.1

Le premier test concerne le loopback : il vérifie la pile réseau locale, pas la sortie Internet. Le second ajoute le chemin vers une adresse extérieure sans solliciter le DNS. Regardez le nombre de paquets reçus, le pourcentage de perte et les temps time=. Un échec ICMP ne suffit pas à conclure que la connexion est coupée, car un pare-feu peut filtrer les requêtes ping.

Ajouter la résolution à la mesure

ping -c 3 -W 1 debian.org

Cette variante combine résolution et ICMP. Name or service not known situe l’échec avant l’envoi du paquet. Si le nom est traduit mais que les réponses ICMP manquent, le DNS a fonctionné ; examinez alors le filtrage ou utilisez un test applicatif.

Suivre le chemin avec tracepath

tracepath -n -m 3 1.1.1.1

-n évite une résolution DNS pour les routeurs traversés et -m 3 limite l’essai à trois sauts. Chaque ligne donne un saut et un temps ; un ? signifie qu’un équipement n’a pas répondu à la sonde, pas nécessairement que le chemin est rompu. tracepath est pratique dans un environnement où ping n’a pas les capacités nécessaires.

Vérifier le protocole réellement utilisé par le service

curl -sS -o /dev/null -w '%{http_code}\n' --connect-timeout 5 https://debian.org/

Cette commande établit une connexion HTTPS, ignore le corps téléchargé et affiche le code HTTP. Un code 200, 301 ou 302 prouve que le serveur a répondu ; un délai d’attente ou une erreur de connexion ne porte pas la même information qu’un 403 ou un 500. Pour consulter seulement les en-têtes, curl -I --connect-timeout 5 https://debian.org/ convient, mais certains services traitent mal la méthode HEAD.

Pour un port TCP précis, utilisez nc seulement s’il est déjà installé :

nc -vz -w 5 debian.org 443

succeeded indique que la connexion TCP au port a été établie. Connection refused signifie que l’hôte a répondu sans accepter ce service ; timed out laisse ouvertes plusieurs hypothèses, dont un filtrage ou une route défaillante.

Comment interpréter l’erreur avant de modifier le système ?

Conservez le message exact et le code de sortie. Relancer la même commande ne change pas la couche en cause. Un test vers une adresse IP n’examine pas le DNS, et un test DNS ne prouve pas qu’un service HTTPS accepte une connexion.

Que faire quand l’environnement limite les commandes ?

Dans un conteneur ou un sandbox, ip peut afficher Cannot open netlink socket: Address family not supported by protocol. Le noyau ou l’espace de noms réseau ne fournit alors pas l’accès netlink attendu par les commandes de lecture. Ce message décrit l’environnement d’exécution ; il ne permet pas de diagnostiquer l’interface de la machine hôte.

ping peut également échouer avec Operation not permitted lorsque le processus ne dispose pas de CAP_NET_RAW ou que la plage ping_group_range est restrictive. N’ajoutez pas une capacité au binaire et ne lancez pas setcap pour contourner le symptôme sans avoir identifié le paquet, le conteneur et la politique de sécurité. Pour une mesure ponctuelle sans privilège, essayez plutôt tracepath si la commande est disponible.

Sur une machine de bureau, les commandes ip -br addr, ip route show default, ip neigh, getent hosts et curl se lancent normalement sans sudo. Les commandes qui changent l’état, comme ip link set, ip route add, resolvectl dns ou systemctl restart, appartiennent à une étape d’administration avec sauvegarde et procédure adaptée à la distribution.

Quelle étape suivre ensuite sans modifier le système au hasard ?

Si l’interface n’a pas d’adresse, relevez son nom, son état et les journaux du gestionnaire réseau avant de choisir entre DHCP, Wi-Fi ou configuration statique. Si la route manque, recherchez le service qui devait l’installer. Si le DNS échoue, comparez getent, resolvectl, /etc/hosts et /etc/resolv.conf avant de changer un serveur. Si HTTPS répond mais qu’un service local reste en échec, utilisez la lecture des journaux systemd pour examiner l’unité concernée.

Les anciens outils ifconfig, route, arp et netstat ne sont pas nécessaires pour cette lecture : les distributions modernes fournissent généralement ip et ss via iproute2. La capture avec tcpdump, le filtrage avec nftables et la configuration d’un VPN répondent à d’autres questions et peuvent modifier ou exposer du trafic. Pour comprendre les droits qui empêchent ensuite une action locale, consultez l’explication des permissions Linux.