Rédigé par Rédaction CyberSDF / 14 September 2026 / mis à jour 23 September 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.

Si le service distant utilise SSH, vérifier un accès SSH permet de séparer la configuration du client du problème de réseau.

Si le besoin est de relier deux machines plutôt que de diagnostiquer une panne, la configuration de WireGuard sur Linux montre où vérifier le handshake, la route et les adresses privées.

Pour vérifier un réseau Tailscale, commencez par distinguer l’état du pair, le nom MagicDNS et le service réellement écouté, puis suivez la procédure Tailscale sur Linux.

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.

La séquence qui évite les faux diagnostics

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.

Commencer par 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.

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.

Séparer le 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.

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

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.

Repère mesuré le 17 septembre 2026 : dans un environnement Linux restreint, ping -c 3 -W 1 127.0.0.1 a renvoyé Operation not permitted, tandis que tracepath -n -m 3 127.0.0.1 a atteint la cible en 0.622ms, avec un PMTU de 65535 et un seul saut. La différence identifie une capacité manquante pour ping, pas une panne du loopback.

1:  127.0.0.1  0.622ms reached
    Resume: pmtu 65535 hops 1 back 1

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. Le manuel de ip et le manuel de ping détaillent les options disponibles sur la distribution installée.

Interpréter l’erreur avant de toucher au 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.

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.

Choisir la suite sans modifier 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.