CyberSDF

Reprenez la main sur votre numérique

Illustration de couverture : un terminal affiché sur l'écran d'un ordinateur portable ouvert dans une pièce sombre, avec des commandes de diagnostic réseau et leur résultat affichés à l'écran.

Rédigé par Rédaction CyberSDF · · mis à jour

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

Avertissement global. Ce parcours lit l’état du réseau sans le modifier : aucun ip link set … up/down, aucun ip addr add, aucun ip route add, aucune édition de /etc/resolv.conf, /etc/nsswitch.conf, /etc/hosts, /etc/network/interfaces. sudo apparaît seulement pour expliquer la légitimité d’une commande privilégiée (et pourquoi on s’en passe ici). ping -f (flood), ping -s 65507, mtr et nmap sont volontairement écartés. Quand un garde-fou concerne une section précise, il est rappelé localement ; sinon, cet avertissement global suffit.

L’ordre de lecture quand « ça ne marche pas » est toujours le même : interface → IP → route → DNS → service applicatif. L’arbre ci-dessous condense la méthode ; les sections qui suivent le détaillent.

L’arbre de diagnostic en 30 secondes

Internet / intranet
        │
        ▼
(1) Interface active + IP ? ──── non ──► ip link set … up / DHCP / câble / Wi-Fi
        │
       oui
        ▼
(2) Route par défaut présente ? ── non ──► DHCP / gateway / routage statique
        │
       oui
        ▼
(3) DNS résout un nom ? ─────────── non ──► resolvectl / /etc/resolv.conf / nsswitch
        │
       oui
        ▼
(4) Latence vers la cible ? ────── non ──► tracepath pour isoler le saut fautif
        │
       oui
        ▼
(5) Service applicatif répond ? ─── non ──► curl -I / nc -vz / firewall / proxy

Symptôme → premier test → ce que ça suggère :

Symptôme observé Premier test (lecture seule) Indique en priorité
Pas d’adresse IP sur l’interface ip -br addr → lo seul, ou interface DOWN Interface désactivée, câble/Wi-Fi absent, DHCP en attente
connect: Network is unreachable ip route show default Aucune route par défaut (passerelle absente)
From … Destination Host Unreachable ip neigh (passerelle en FAILED ?) Lien local coupé entre vous et la passerelle
Name or service not known getent hosts debian.org puis resolvectl status Résolveur cassé ou configuration absente
ping 1.1.1.1 répond, curl https://… échoue curl -I --connect-timeout 5 https://debian.org/ Réseau sain, service applicatif ou proxy en cause
ping: socket: Operation not permitted environnement (conteneur / sandbox) Pas un défaut réseau : tester avec tracepath à la place

Une interface active, une route par défaut, un DNS qui résout, un service distant qui répond HTTP — c’est tout ce qu’il faut pour considérer qu’on a une connexion fonctionnelle. Chaque étage se teste en une commande, sans privilège.

Sur quoi s’appuie cette page

Les commandes et sorties citées ont été vérifiées le 14 septembre 2026 dans un environnement Linux « réaliste » :

Les sorties indiquées varient légèrement d’une machine et d’un moment à l’autre (le time= d’un ping, la liste exacte des hôtes debian.org) ; ce qui est reproduit ici, ce sont les champs, colonnes et mots-clés, pas les valeurs au cycle près.

Sources upstream (datées 2026-09-14) :

Portée : Linux moderne (Debian 13, Ubuntu 24.04 LTS, Fedora 43) avec systemd. Sur d’autres distributions ou sans systemd, le diagnostic reste valide pour ip / ping / tracepath / getent ; les sections sur resolvectl et systemd-resolved sont alors à remplacer par l’outil de résolution installé localement.

Comment savoir si ma machine Linux est connectée au réseau ?

Avant tout diagnostic, la première question est binaire : la machine a-t-elle au moins une interface active, avec une adresse IP, et une route vers l’extérieur ? Trois commandes en lecture seule répondent à cette question, sans privilège, sans outil à installer.

Listez vos interfaces avec ip -br addr

ip -br addr

La sortie condense chaque interface réseau sur une seule ligne, avec trois colonnes : STATE, INTERFACE et ADDR. Une interface en UP est active ; une interface en DOWN est désactivée au niveau du noyau. L’interface lo (loopback) est toujours présente, avec l’adresse 127.0.0.1/8 et souvent une adresse IPv6 ::1/128 ; elle représente votre propre machine, pas le réseau.

Lisez l’état d’une interface précise avec ip link show dev IFNAME

Pour une vue détaillée d’une interface précise, après avoir repéré son nom dans la liste courte :

ip -br link
ip link show dev eth0

La commande ip -br link affiche la liste condensée avec STATE, MODE et INTERFACE. La commande ip link show dev IFNAME détaille ensuite les champs state UP, mtu 1500, qdisc, master. Le nom de l’interface dépend de la machine : eth0, enp0s3, wlp4s0, wlp0s20f3 selon le pilote et le numéro de bus PCI.

Repérez l’adresse IP et le masque en notation CIDR

Une adresse IPv4 avec masque s’écrit 192.0.2.10/24 : les 24 premiers bits forment le masque 255.255.255.0. Une adresse IPv6 link-local commence par fe80::/10 et n’est routable que sur le lien local. L’adresse 127.0.0.0/8 est réservée au loopback : 127.0.0.1 est votre propre machine, jamais le réseau.

ip link set eth0 down (désactive une interface) et ip addr add 192.0.2.10/24 dev eth0 (ajoute une adresse) modifient l’état du réseau ; aucune de ces commandes n’est exécutée dans ce parcours. Pour reconfigurer une interface, la fiche de configuration réseau (Debian Handbook, NetworkManager) reste la voie autorisée.

Comment lire la route par défaut et la passerelle ?

Une machine connectée a une route par défaut (default via …) qui dit au noyau par où envoyer le trafic destiné aux adresses hors du réseau local. Cette route et sa passerelle se lisent en deux commandes, complétées par la table ARP/NDP.

Affichez la table de routage avec ip route show default

ip route show default

La sortie affiche une ligne type default via 192.0.2.1 dev eth0 proto static : default via est l’adresse de la passerelle (gateway), dev est l’interface de sortie, proto est l’origine de la route (static pour une route configurée à la main, dhcp pour une route attribuée automatiquement). L’absence de ligne default signifie qu’aucune route par défaut n’est active : c’est la cause la plus fréquente du message « Network is unreachable ».

Vérifiez où passe une adresse précise avec ip route get ADRESSE

ip route get 1.1.1.1

La sortie affiche le détail du chemin pour une adresse précise : 1.1.1.1 via 192.0.2.1 dev eth0 src 192.0.2.10 uid 1000. via est la passerelle, dev l’interface, src l’adresse source utilisée par votre machine, uid l’identifiant utilisateur. Cette commande est utile quand la table de routage contient plusieurs routes et que vous voulez savoir laquelle s’applique à une cible précise.

Lisez la table ARP/NDP avec ip neigh

ip -4 neigh
ip neigh show

La table ARP (IPv4) et NDP (IPv6) liste les voisins L2 connus : leur adresse IP, leur adresse MAC, et leur état. Un voisin en REACHABLE a été contacté récemment ; un voisin en STALE doit être rafraîchi ; un voisin en FAILED n’a pas répondu. Si votre passerelle apparaît en FAILED dans la table ARP, c’est un indice fort que le lien local est coupé (câble, Wi-Fi, switch).

ip route add 192.0.2.0/24 via 192.0.2.1 (ajoute une route) et ip neigh flush all (vide la table ARP) modifient l’état du réseau ; aucune de ces commandes n’est exécutée dans ce parcours. Une route ajoutée manuellement disparaît au prochain redémarrage ; un vidage de la table ARP ne corrige pas un problème de lien local.

Reconnaissez le message « Cannot open netlink socket » comme limite d’environnement

Sur un conteneur ou un sandbox sans accès au socket netlink, les commandes ip a, ip r, ip neigh, ip route get et ss renvoient toutes Cannot open netlink socket: Address family not supported by protocol. Ce message n’est pas un comportement normal d’une machine de bureau ou d’un serveur Debian/Ubuntu : c’est un indice que l’environnement d’exécution n’a pas accès au noyau via netlink (la famille de sockets spéciale qu’utilisent ip et ss pour parler au sous-système réseau du noyau). Dans ce cas, la suite du diagnostic lecture-seule n’est pas exécutable dans l’environnement ; passer à une machine où ip répond est la voie.

À noter. ip lit et écrit via le socket netlink (famille AF_NETLINK) ; resolvectl ne fait pas de même, voir section suivante.

Comment vérifier que le DNS fonctionne ?

Une machine peut avoir une route et une interface saines, mais un résolveur DNS cassé : ping 1.1.1.1 répond, ping debian.org échoue avec « Name or service not known ». Deux commandes lisent l’état du DNS sans le modifier.

Lisez l’état du résolveur avec resolvectl status

resolvectl status

La sortie affiche plusieurs blocs. Le bloc Global liste les protocoles activés (+LLMNR, -LLMNR, +DNSOverTLS) et le resolv.conf mode: stub ou full : le mode stub indique que systemd-resolved intercepte le trafic DNS local avant de le transmettre à un DNS amont. Les blocs Link N (eth0) listent les serveurs DNS utilisés par chaque interface.

Comment resolvectl cause avec systemd-resolved. resolvectl dialogue avec systemd-resolved via D-Bus (bus système, interface org.freedesktop.resolve1.Manager), pas via netlink. La commande ip est celle qui passe par netlink pour parler au noyau. Quand resolvectl status affiche Failed to connect to netlink, ça veut dire que resolvectl n’a pas réussi à interroger une autre partie du système via netlink ; le bloc Global reste affiché via D-Bus. Ce n’est pas un échec total.

Résolvez un nom avec getent hosts

getent hosts localhost
getent hosts debian.org

La commande getent hosts lit /etc/nsswitch.conf (ligne hosts:) et applique l’ordre qui y est défini : d’abord /etc/hosts (files), puis le résolveur (dns). Pour localhost, elle renvoie ::1 localhost ip6-localhost ip6-loopback. Pour debian.org, elle renvoie les adresses IPv4/IPv6 officielles du domaine. getent hosts fonctionne même quand resolvectl est absent : elle passe par la libc et /etc/nsswitch.conf.

getent hosts nom-inconnu ne renvoie rien à l’écran et retourne un code de sortie 2 quand le nom n’est trouvé ni dans /etc/hosts, ni via le résolveur configuré ; ce n’est pas un message d’erreur de type « No such file or directory » (qui appartient à d’autres commandes GNU comme cat ou stat). Quand getent hosts nom-inconnu est vide, on regarde alors resolvectl status, /etc/resolv.conf et /etc/nsswitch.conf pour identifier la source défaillante.

Lisez /etc/resolv.conf comme information, jamais comme configuration

ls -l /etc/resolv.conf

Sur une distribution moderne, ce fichier est souvent un lien symbolique vers ../run/systemd/resolve/stub-resolv.conf (mode stub de systemd-resolved). Le modifier directement peut être ineffective (le contenu est écrasé par systemd-resolved) et peut casser la résolution. Ce fichier est lu comme information dans ce parcours ; aucune édition n’est demandée.

/etc/resolv.conf peut prendre plusieurs formes selon l’environnement :

Le contenu typique en mode stub est nameserver 127.0.0.53 (proxy local de systemd-resolved). En mode direct ou uplink, on trouve les adresses des serveurs DNS amont (nameserver 1.1.1.1). Dans tous les cas, ce fichier se lit, il ne s’édite pas dans ce parcours.

resolvectl dns eth0 1.1.1.1 (modifie le DNS actif sur une interface) et sudo systemctl restart systemd-resolved (redémarre le service DNS) modifient l’état du résolveur ; aucune de ces commandes n’est exécutée dans ce parcours. Pour changer durablement de serveur DNS, la configuration de systemd-resolved (/etc/systemd/resolved.conf) ou de NetworkManager reste la voie.

Comment mesurer la latence et la perte de paquets ?

Une fois la route et le DNS confirmés, la mesure de latence vérifie qu’une cible externe répond réellement. La commande ping envoie des paquets ICMP ECHO_REQUEST et mesure le temps round-trip.

Mesurez le loopback avec ping -c 3 127.0.0.1

ping -c 3 -W 1 127.0.0.1

La sortie affiche trois lignes time=0.0XX ms, puis un résumé 3 packets transmitted, 3 received, 0% packet loss. 127.0.0.1 est l’adresse de boucle locale : elle teste votre propre machine, jamais le réseau. Si le loopback ne répond pas, c’est la pile TCP/IP elle-même qui est en cause, pas le réseau.

Mesurez une cible externe avec ping -c 3 1.1.1.1

ping -c 3 1.1.1.1

1.1.1.1 est l’adresse IP publique de Cloudflare, choisie pour sa stabilité et sa disponibilité. Si la commande répond avec un time= raisonnable, le chemin réseau vers Internet fonctionne.

Le TTL n’est pas un identifiant d’OS. Le TTL (Time To Live) observé dans une réponse ICMP dépend du TTL initial choisi par l’émetteur (64 pour Linux/Unix, 128 pour Windows, 255 pour certains routeurs) moins le nombre de sauts traversés. Chaque routeur le décrémente, certains réseaux le réécrivent, et un hôte peut ajuster son TTL initial. C’est une heuristique dégradée, pas un fingerprint fiable : ne l’utilisez pas pour identifier un système d’exploitation à distance.

Mesurez un nom de domaine avec ping -c 3 exemple.org

ping -c 3 debian.org

Cette commande combine la résolution DNS et la mesure de latence. Si le ping échoue avec « Name or service not known », c’est le DNS qui est cassé, pas le réseau. Si le ping résout le nom et échoue ensuite avec « Destination Host Unreachable » ou « Request timeout », c’est le réseau qui est en cause.

Comprenez le message ping: socket: Operation not permitted

Si ping renvoie ping: socket: Operation not permitted, c’est que le programme a basculé sur un socket ICMP brut (SOCK_RAW) qui exige la capacité CAP_NET_RAW. Quand est-ce que ping a besoin de CAP_NET_RAW ? Selon le manuel ping(8) :

  1. le programme est utilisé pour des requêtes non echo (-N : Node Information Queries) ;
  2. le champ d’identification est mis à 0 avec -e ;
  3. le noyau ne supporte pas les ICMP datagram sockets ;
  4. l’utilisateur n’est pas autorisé à créer un ICMP echo socket (sysctl net.ipv4.ping_group_range restrictif, ou binaire sans cap_net_raw ni setuid).

Sur un noyau Linux ≥ 5.17 (et ≥ 5.15.19, 5.10.96, 5.4.176, 4.19.228, 4.14.265), ping peut utiliser un ICMP datagram socket pour les requêtes echo classiques, sans CAP_NET_RAW. Sur un conteneur ou un sandbox, l’erreur Operation not permitted peut venir du namespace restrictif (CAP manquante dans le user namespace) aussi bien que de l’absence totale de CAP_NET_RAW.

Ne pas traiter setcap cap_net_raw+p /usr/bin/ping comme une correction directe du diagnostic. Modifier les capacités d’un binaire sans avoir vérifié le paquet installé, le contenu de ping_group_range, le contexte du conteneur et la politique de sécurité locale peut ouvrir une porte non souhaitée ou rester sans effet sur un binaire recréé au prochain upgrade. Pour un diagnostic ponctuel, tracepath (sans privilège) reste utilisable. Pour activer ping sur un poste personnel, se référer à la documentation de la distribution (sysctl net.ipv4.ping_group_range, capabilities, setuid selon les cas).

ping -f (flood : un paquet par milliseconde) et ping -s 65507 (fragmentation volontaire) sont volontairement écartés de ce parcours : le premier est assimilé à un déni de service sur un réseau partagé, le second peut perturber des équipements intermédiaires. La commande ping -c N suffit à mesurer la latence et la perte.

Comment suivre le chemin réseau vers un hôte distant ?

Quand ping échoue vers une cible lointaine, tracepath permet de voir à quel saut le paquet s’arrête. C’est l’alternative sans privilège à traceroute.

Tracez avec tracepath sans sudo

tracepath -n -m 3 127.0.0.1

La sortie affiche une ligne 1: 127.0.0.1 0.201ms reached, suivie d’un résumé Resume: pmtu 65535 hops 1 back 1. tracepath est conçu sans privilège : il fonctionne sans sudo sur une distribution classique. Le mot reached confirme que la cible a répondu ; le pmtu 65535 est la MTU par défaut du loopback (la valeur exacte du time= varie d’un essai à l’autre selon la charge instantanée du loopback).

Tracez vers une cible externe avec tracepath -n 1.1.1.1

tracepath -n 1.1.1.1

La sortie affiche une ligne par saut, numérotée 1:, 2:, 3:, etc., avec le temps mesuré à chaque routeur intermédiaire. Un routeur qui ne renvoie pas d’ICMP apparaît avec un ? ; un chemin asymétrique est signalé par asym. Cette commande ne modifie rien ; elle lit le chemin réseau vu par votre machine.

Comment tracepath reconstruit le chemin

tracepath envoie des sondes UDP avec un TTL croissant ; il récupère ensuite les erreurs ICMP « TTL exceeded » du noyau via la file d’erreur Linux (MSG_ERRQUEUE, depuis Linux 2.2). En IPv4, les routeurs commerciaux ne renvoient pas assez d’information dans leurs messages d’erreur ICMP ; tracepath utilise alors la technique de Van Jacobson (sweep d’une plage de ports UDP) pour reconstituer le chemin. En IPv6, la file d’erreur Linux suffit et tracepath -6 est cité en exemple canonique d’utilisation de cette interface noyau. MSG_ERRQUEUE est documenté dans recvmsg(2)/socket(7) ; ce n’est pas une norme RFC réseau, et notamment pas la RFC 3168 (qui concerne ECN — Explicit Congestion Notification).

tracepath vs traceroute

Outil Méthode par défaut Privilège par défaut Cas d’usage
tracepath UDP + file d’erreur Linux (IPv6) ou UDP sweep (IPv4) Pas de privilège Diagnostic ponctuel sans privilège
traceroute UDP (-U), ICMP (-I), TCP (-T), UDPLITE (-UL) Dépend de la méthode et du noyau Diagnostic avancé, sélection explicite de méthode

traceroute est plus riche en options mais peut exiger des privilèges selon la méthode : la méthode UDP par défaut active un raw socket ICMP ; les méthodes ICMP (-I, autorisé pour un utilisateur non privilégié si le noyau ≥ 3.0 IPv4 / ≥ 3.11 IPv6 supporte les datagram ICMP sockets) et TCP (-T, half-open) restent utilisables par un utilisateur standard. Pour un diagnostic ponctuel, tracepath couvre le besoin standard.

mtr (Matt’s traceroute, live) et traceroute -T (TCP, pour traverser certains pare-feux stricts) relèvent d’un parcours dédié ; ils ne sont pas demandés ici.

Comment tester la couche transport et le service applicatif ?

ping ne teste que la couche ICMP. Une machine peut parfaitement répondre au ping et refuser un service applicatif (pare-feu applicatif, proxy, service en panne). Un diagnostic complet inclut donc un test curl ou nc.

Tester un service HTTPS avec curl

curl -I --connect-timeout 5 https://debian.org/

curl -I (HEAD) récupère uniquement les en-têtes de réponse, sans télécharger le corps de la page. --connect-timeout 5 borne le temps d’établissement de la connexion TCP/TLS à 5 secondes. Une réponse 200, 301, 302 confirme que la couche applicative passe. Une erreur Couldn't connect to server ou un timeout TCP sépare un problème « ICMP passe, service ne répond pas » d’un problème réseau.

Tester un port TCP avec nc -vz (si nc est disponible)

nc -vz debian.org 443

L’option -v rend la commande bavarde ; -z ferme la connexion dès la connexion TCP établie, sans envoyer de données. succeeded confirme que le port 443 est ouvert ; Connection timed out ou Connection refused donne une piste différente. Si nc (netcat) n’est pas installé, curl -v telnet://… ou un script bash simple sur /dev/tcp peuvent servir de repli.

ping qui échoue ≠ « Internet est mort »

Un ping qui échoue vers l’extérieur ne signifie pas qu’Internet est inaccessible : certains réseaux filtrent ICMP à la sortie (pare-feu d’entreprise, hotspot public). Si ping 1.1.1.1 ne répond pas mais que curl -I --connect-timeout 5 https://debian.org/ répond, le réseau fonctionne ; c’est le service ICMP qui est filtré. Le diagnostic final passe toujours par un test applicatif, pas par ping seul.

Comment reconnaître les trois messages d’erreur les plus fréquents ?

Trois messages reviennent dans la plupart des diagnostics réseau. Les reconnaître évite de relancer un service au hasard.

Network is unreachable : pas de route vers la cible

ping 198.51.100.1
connect: Network is unreachable

Ce message signifie que la table de routage ne contient aucune route vers le réseau de la cible — souvent aucune route par défaut. Vérifiez avec ip route show default : si la commande ne renvoie rien, c’est la cause. Relancer un service réseau ne corrige pas une route manquante.

Destination Host Unreachable : route présente mais hôte absent

ping 192.0.2.250
From 192.0.2.1 icmp_seq=1 Destination Host Unreachable

Ce message signifie qu’une route existe, mais que le saut suivant (souvent la passerelle) n’a pas répondu. Vérifiez ip route show default et ip neigh : si la passerelle est en FAILED dans la table ARP, le lien local est coupé. Ce n’est pas un problème de DNS : l’adresse IP a été contactée, le réseau a répondu que l’hôte est absent.

Name or service not known : DNS cassé

ping domaine-inconnu.test
ping: domaine-inconnu.test: Name or service not known

Ce message signifie que le résolveur n’a pas pu traduire le nom en IP. Vérifiez resolvectl status et getent hosts ; lisez /etc/resolv.conf pour identifier le DNS configuré. Ce n’est pas un problème de réseau : la pile réseau fonctionne, c’est la résolution de nom qui est en cause.

Différencier ces trois messages avant toute modification

Avant de relancer un service ou de modifier un fichier, lisez le message exact. sudo systemctl restart NetworkManager ne corrige ni un DNS cassé si /etc/resolv.conf est sain, ni une route manquante si la passerelle est absente. Le bon réflexe est : lire, identifier, comprendre la cause, puis décider.

Comment lire les fichiers utiles sans les modifier ?

Trois fichiers influencent la résolution de nom et la configuration réseau locale. Ils sont utiles à lire, jamais à éditer dans ce parcours.

Lisez /etc/nsswitch.conf (ligne hosts:)

grep '^hosts:' /etc/nsswitch.conf
hosts:          files dns

La ligne hosts: définit l’ordre des sources consultées par getent hosts : files (lecture de /etc/hosts) puis dns (résolveur). Cette ligne varie selon la distribution : Debian/Ubuntu livrent souvent files dns, Fedora peut livrer files dns mdns4_minimal [NOTFOUND=return] dns, certaines variantes inversent l’ordre. Lire la ligne sur la machine locale reste le bon réflexe ; ne présumez pas qu’elle est universelle. Aucune modification n’est demandée dans ce parcours.

Lisez /etc/hosts comme information

cat /etc/hosts
127.0.0.1 localhost
::1 localhost ip6-localhost ip6-loopback

Le fichier /etc/hosts associe des adresses IP à des noms canoniques et des alias. Les alias locaux (par exemple un serveur de développement sur 127.0.0.1) n’ont pas besoin de DNS. Ce fichier est lu comme information ; aucune édition n’est demandée.

Lisez /etc/resolv.conf comme information

cat /etc/resolv.conf
nameserver 127.0.0.53

Voir la section « Lisez /etc/resolv.conf comme information, jamais comme configuration » plus haut : ce fichier peut être un lien symbolique (stub/uplink de systemd-resolved), un fichier géré par NetworkManager, ou un fichier statique selon la distribution. Aucune édition n’est demandée.

Toute modification de /etc/nsswitch.conf, /etc/hosts ou /etc/resolv.conf exige une procédure autorisée, avec sauvegarde préalable et relecture de la documentation Debian ou NetworkManager. Ce parcours reste en lecture seule : les fichiers sont consultés comme information, pas comme configuration à modifier.

Quand sudo est-il légitime pour diagnostiquer ?

Le parcours précédent fonctionne en lecture seule, sans privilège. Quelques cas demandent sudo, mais ils sont l’exception et doivent suivre une décision documentée.

Comprenez pourquoi ip ne nécessite pas sudo en lecture

ip -br addr, ip route show default, ip neigh, ip link show, ip route get lisent l’état du noyau via le socket netlink (famille AF_NETLINK, partagée avec ss, tc). Un utilisateur non privilégié peut les exécuter sur la plupart des distributions Linux. Les opérations qui modifient l’état (ip link set, ip addr add, ip route add, ip neigh flush) exigent en revanche CAP_NET_ADMIN et donc sudo — mais aucune n’est exécutée dans ce parcours.

Comprenez pourquoi ping peut demander CAP_NET_RAW

Voir la section « Comprenez le message ping: socket: Operation not permitted » plus haut. Le critère n’est pas « ping exige toujours CAP_NET_RAW », mais « ping exige CAP_NET_RAW selon la méthode et le support noyau ». Sur une machine de bureau Debian/Ubuntu classique, ping est setuid root ou dispose de la capacité, et l’utilisateur ordinaire peut l’exécuter. Sur un conteneur ou un environnement restreint, ping peut renvoyer ping: socket: Operation not permitted même pour ping 127.0.0.1 ; ce message est un indice d’environnement, pas une erreur de diagnostic.

sudo ip link set … up/down, sudo ip addr add, sudo ip route add modifient la configuration réseau active ; aucune n’est exécutée dans ce parcours. Pour reconfigurer durablement une interface, la documentation NetworkManager ou /etc/network/interfaces reste la voie autorisée.

sudo systemctl restart NetworkManager (ou systemd-networkd, systemd-resolved) redémarre un service réseau ; non demandé dans ce parcours. Redémarrer un service sans procédure documentée peut couper la connexion en cours, supprimer des routes attribuées par DHCP, et laisser la machine dans un état partiellement configuré. Pour un redémarrage légitime, ouvrez un ticket d’administration ou consultez la documentation Debian Handbook.

Quelles opérations faut-il laisser de côté quand on débute ?

Quatre familles d’opérations méritent leur propre parcours et ne sont pas illustrées ici.

Pourquoi ifconfig, route -n, arp -n et netstat sont documentés mais hors parcours

Ces outils appartiennent au paquet historique net-tools, remplacé par ip (iproute2) et ss depuis la fin des années 2000. Les distributions modernes ne les installent plus par défaut ; les sortir pour les exécuter ajoute un paquet sans gain pédagogique. Ce parcours enseigne les commandes standard actuelles : ip, ping, tracepath, resolvectl, getent, ss.

Pourquoi tcpdump, Wireshark et nmap sont hors périmètre

tcpdump et Wireshark capturent du trafic réseau, ce qui pose des questions légales et de vie privée sur un réseau partagé. nmap peut être assimilé à un scan actif, visible dans les journaux des hôtes scannés. Aucun de ces outils n’est demandé dans ce parcours ; la fiche sœur de durcissement Linux traitera les usages offensifs dans un cadre documenté.

Pourquoi la configuration réseau (statique, DHCP, VLAN, bridge) est ailleurs

netplan, /etc/network/interfaces, nmcli connection …, systemd-networkd relèvent de la configuration. La fiche sœur Services et journaux systemd : diagnostiquer pas à pas couvre le diagnostic des services, sans toucher à la configuration réseau. Ce parcours s’arrête au strict diagnostic en lecture seule.

Pourquoi le pare-feu et le VPN sont ailleurs

nftables, iptables, ufw, firewalld relèvent de la politique de filtrage ; WireGuard et OpenVPN relèvent du tunnel applicatif. Ces sujets ont chacun leur propre parcours dans une fiche dédiée. Ce parcours ne touche ni au filtrage, ni au tunnel : il se limite à constater que la machine voit ou ne voit pas le réseau.

Où aller ensuite pour un parcours plus large ?

Pour un tour d’horizon du terminal et des parcours Linux publiés, partez de la section Linux et terminal de CyberSDF. Pour un premier contact avec un terminal GNU, le guide de survie en ligne de commande couvre l’essentiel. Pour reprendre les premières commandes avant ce parcours, Commandes Linux de base : se repérer, créer et copier sans risque prépare le terrain. Pour la suite logique après la lecture des interfaces et des fichiers, Fichiers et répertoires Linux : les manipuler sans perte et Permissions et utilisateurs Linux : comprendre avant de modifier complètent la lecture. Pour le diagnostic des services (et non du réseau), Services et journaux systemd : diagnostiquer pas à pas reste la fiche de référence.

Questions fréquentes avant de continuer

Quelle différence entre ip -br addr et ip address show ?

-br (synonyme --brief) condense chaque interface sur une seule ligne avec STATE, INTERFACE et ADDR. ip address show (ou ip addr) affiche la vue détaillée avec toutes les propriétés : adresse IPv4, adresse IPv6, masque, scope, flags, qdisc. Les deux lisent la même source du noyau ; ip -br addr est la lecture courte pour débutant, ip addr show est la lecture complète pour diagnostic.

Pourquoi ping affiche-t-il « socket: Operation not permitted » ?

Voir la section « Comprenez le message ping: socket: Operation not permitted ». La cause la plus probable sur un conteneur est l’absence de CAP_NET_RAW dans le user namespace, ou un binaire ping sans setuid/cap. Sur une machine physique, l’utilisateur peut simplement ne pas disposer de cap_net_raw sur le binaire. Ce message est un indice d’environnement, pas une erreur de diagnostic. Pour mesurer un chemin sans privilège, tracepath reste utilisable.

Pourquoi resolvectl status affiche-t-il « Failed to connect to netlink: Address family not supported by protocol » ?

resolvectl communique avec systemd-resolved principalement via D-Bus, pas via netlink (voir section « Comment resolvectl cause avec systemd-resolved »). La mention « Failed to connect to netlink » peut apparaître quand resolvectl tente un appel annexe via netlink et que le socket n’est pas disponible (par exemple en conteneur). Le bloc Global reste affiché ; getent hosts reste utilisable comme repli.

Quelle différence entre Network is unreachable et Destination Host Unreachable ?

Network is unreachable signifie que la table de routage ne contient aucune route vers le réseau de la cible (souvent aucune route par défaut). Destination Host Unreachable signifie qu’une route existe, mais que le saut suivant (souvent la passerelle) n’a pas répondu. Les deux se distinguent en lisant ip route show default : pas de sortie ⇒ premier cas ; sortie présente mais passerelle en FAILED dans ip neigh ⇒ second cas.

Que faire si getent hosts nom-inconnu ne renvoie rien ?

Sortie vide + code retour 2 est le comportement normal quand le nom n’est trouvé ni dans /etc/hosts, ni via le résolveur configuré. Vérifiez resolvectl status, cat /etc/resolv.conf et grep '^hosts:' /etc/nsswitch.conf pour identifier la source défaillante. Ne modifiez aucun de ces fichiers sans procédure autorisée : un changement d’ordre dans nsswitch.conf peut casser la résolution locale.

Comment savoir si je peux quitter l’exercice ?

Vous pouvez fermer le terminal à tout moment : aucune commande de ce parcours ne modifie l’état du système, aucun fichier réseau n’est touché, aucune interface n’est activée ou désactivée, aucun service n’est redémarré, aucun privilège n’est élevé. Pour une revisite, relancez simplement ip -br addr et ip route show default pour revoir l’état du réseau.