Commandes réseau Linux essentielles

Sur les systèmes Linux modernes, les commandes réseau essentielles proviennent de la suite iproute2 : ip permet d’inspecter les interfaces et les routes, ss liste les sockets et les ports en écoute, et ip neigh lit le cache ARP.

Si vous vous êtes déjà connecté en shell sur un conteneur tout neuf, avez tapé ifconfig par pure habitude et reçu un command not found en retour, voilà pourquoi. La mémoire musculaire a survécu aux binaires d’une bonne décennie.

Ces commandes remplacent les anciens binaires de net-tools (ifconfig, route, netstat, arp), que Red Hat classe parmi les commandes à ne plus utiliser et qui, bien souvent, ne sont même pas installées sur les distributions actuelles. Cette référence regroupe les commandes par tâche (vérification des interfaces, routage, connectivité, DNS, ports et trafic) et se conclut par un cheminement de dépannage « symptôme vers commande » que vous pouvez suivre de bout en bout.

Qu’est-ce qui a remplacé ifconfig, netstat et route sous Linux ?

net-tools est considéré comme obsolète depuis le début des années 2000, iproute2 étant le remplaçant activement développé. Le paquet net-tools-deprecated d’openSUSE documente la correspondance canonique, une commande pour une :

Privilégiez la forme iproute2. Sur un conteneur minimal ou un serveur fraîchement installé, les anciens binaires peuvent être absents : les scripts qui appellent ifconfig ou netstat échouent alors avec command not found.

Interfaces et adresses

ip addr (ou son alias ip a) affiche chaque interface ainsi que les adresses IPv4/IPv6 qui lui sont assignées : c’est l’équivalent moderne d’ifconfig. Utilisez ip link pour activer ou désactiver une interface, et hostname -I pour n’afficher que les adresses IP de la machine.

ip addr                       # all interfaces + addresses (alias: ip a)
ip addr show eth0             # one interface only
sudo ip link set eth0 down    # take an interface offline
sudo ip link set eth0 up      # bring it back online
hostname -I                   # print all IP addresses, space-separated

Un seul binaire, ip, couvre les adresses, les interfaces, le routage et les tunnels. hostname -I est le moyen le plus rapide de récupérer une adresse dans un script sans avoir à analyser la sortie d’ip addr.

Routage

ip route affiche et modifie la table de routage du noyau, en remplacement de l’ancienne commande route. Exécutée sans argument, elle montre où va le trafic et quelle passerelle fait office de passerelle par défaut.

ip route                                      # view the routing table
ip route get 1.1.1.1                          # show which route a destination uses
sudo ip route add 10.0.0.0/24 via 192.168.1.1 # add a static route

ip route get est le moyen le plus rapide de répondre à la question « quelle interface et quelle passerelle seront utilisées pour cette destination ? ». Utile lorsqu’un hôte est joignable depuis un réseau mais pas depuis un autre.

Connectivité et chemin réseau

ping vérifie si un hôte répond ; traceroute et mtr montrent par où passent les paquets et où ils se perdent. Limitez toujours ping par un compteur : ping -c 5 example.com envoie cinq paquets puis s’arrête, au lieu de tourner indéfiniment.

ping -c 5 example.com     # send 5 ICMP echoes, then stop
traceroute example.com    # trace the hop-by-hop path
sudo traceroute -T -p 443 example.com  # trace using TCP to port 443
mtr example.com           # live ping + traceroute in one view

Laissé à ses valeurs par défaut, traceroute abandonne après 30 sauts et dimensionne chaque sonde à 60 octets en IPv4, 80 octets en IPv6. L’ajout de -T remplace les sondes UDP par défaut par des sondes TCP, qui franchissent les pare-feux bloquant les sondes standard. mtr example.com combine ping et traceroute en une vue unique et vivante, ce qui permet de suivre en temps réel la perte de paquets saut par saut. À noter que traceroute et mtr ne sont souvent pas préinstallés : ajoutez-les avec sudo apt install mtr traceroute (Debian/Ubuntu) ou sudo dnf install mtr traceroute (RHEL/Fedora).

Résolutions DNS

dig est l’outil principal pour les requêtes DNS : +short réduit la sortie à la réponse, -x effectue une résolution inverse, et @serveur cible un résolveur précis. nslookup et host couvrent le même terrain de façon plus succincte.

dig +short example.com            # just the resolved A record(s)
dig -x 8.8.8.8                    # reverse lookup: IP -> hostname
dig +short example.com @8.8.8.8   # query Google's public resolver directly
host example.com                  # terse forward/reverse lookup
nslookup example.com              # interactive-capable lookup

Interroger explicitement un résolveur est l’étape d’isolation déterminante : pour distinguer une panne DNS d’un résolveur local défaillant, exécutez dig +short example.com @8.8.8.8 ; si cette requête aboutit alors que votre résolveur par défaut échoue, le problème vient de votre résolveur, pas du domaine.

Comment savoir ce qui occupe un port sous Linux ?

Pour identifier le processus qui occupe un port, exécutez ss -tulnp | grep :8080. L’option -p affiche le PID et le nom du processus propriétaire du socket. C’est la solution à l’erreur « port already in use » lorsqu’un serveur ou un conteneur refuse de se lier au port.

ss -tlnp                    # all listening TCP sockets + owning process
ss -tulnp | grep :8080      # what's bound to port 8080 (TCP + UDP)

Les options se lisent ainsi : t = TCP, u = UDP, l = en écoute (listening), n = numérique (pas de résolution de noms), p = processus. Afficher le nom du processus pour des sockets dont vous n’êtes pas propriétaire exige les droits root : préfixez donc la commande par sudo. ss est le remplaçant moderne de netstat, et la page de manuel de netstat elle-même qualifie la commande de largement obsolète et renvoie vers ss, basé sur netlink, lorsqu’un serveur chargé comporte de nombreux sockets à lister. C’est là que réside la différence de performance : ss interroge le noyau via netlink, tandis que netstat lit les fichiers texte de /proc/net. Une fois le PID identifié, arrêtez le processus avec kill <pid>.

Trafic et transfert

tcpdump capture les paquets en direct, tandis que curl, wget et nc testent l’accessibilité et transfèrent des fichiers. Utilisez tcpdump pour voir exactement ce qui circule sur le réseau lorsque les outils de plus haut niveau ne donnent aucune réponse.

sudo tcpdump -i eth0 port 80    # capture HTTP traffic on eth0
curl -v https://example.com     # verbose HTTP request, headers and TLS
wget -O out.html https://example.com  # download to a file
nc -zv example.com 443          # check if a port is open (no data sent)

Capturer les paquets d’une interface avec tcpdump requiert des privilèges élevés, ce qui signifie en pratique l’exécuter avec sudo (ou attribuer la capacité CAP_NET_RAW au binaire). nc -zv hôte port est le test de port le plus rapide en une seule ligne : -z scanne sans envoyer de données, -v affiche le résultat. Sur Docker Desktop, host.docker.internal se résout automatiquement, si bien que nc -zv host.docker.internal 8080 atteint l’hôte depuis l’intérieur d’un conteneur. Sur Docker Engine pour Linux, vous devez le déclarer vous-même en démarrant le conteneur avec --add-host=host.docker.internal:host-gateway (pris en charge depuis Docker Engine 20.10).

Cheminement de dépannage : du symptôme à la commande

Associez le symptôme à un chemin de décision et progressez en partant de votre machine vers l’extérieur.

• Hôte injoignable → ping -c 5 hôte pour tester l’accessibilité, puis traceroute hôte ou mtr hôte pour repérer où les paquets se perdent, puis ip route pour confirmer l’existence d’une route et d’une passerelle valides.
• « Port already in use » → ss -tulnp | grep :<port> pour trouver le PID propriétaire, puis kill <pid> ou utilisez un autre port.
• Échec DNS → dig +short example.com via votre résolveur, puis dig +short example.com @8.8.8.8 via un résolveur public ; si seule la requête publique aboutit, la faute revient à votre résolveur local.
• Lien lent ou saturé → sudo iftop ou bmon pour visualiser la bande passante par connexion en temps réel (installation avec sudo apt install iftop bmon).

Chaque commande de ces enchaînements confirme ou élimine une couche (liaison, routage, résolution de noms, socket) : vous circonscrivez ainsi la panne au lieu de procéder par intuition.

Tournez-vous d’abord vers les outils iproute2 (ip, ss, ip neigh), ne repliez-vous sur net-tools que sur les systèmes qui l’embarquent encore, et suivez les cheminements « symptôme vers commande » ci-dessus la prochaine fois qu’une liaison de port échoue ou qu’un hôte devient injoignable.

FAQ

Quelle est la différence entre ss et netstat, et sont-ils interchangeables ?

Ils ne sont pas interchangeables. ss est le remplaçant moderne, et la page de manuel de netstat elle-même décrit la commande comme largement obsolète et renvoie vers ss. ss demande les données de socket au noyau via netlink, tandis que netstat lit les fichiers texte de /proc/net, ce qui explique pourquoi ss tient mieux la charge sur les serveurs comportant de nombreux sockets. Les deux listent les connexions et les ports en écoute, mais les scripts devraient appeler ss, car netstat peut ne pas être installé.

Comment trouver et arrêter le processus qui utilise un port précis sous Linux ?

Exécutez ss -tulnp | grep :8080 pour trouver le socket lié à ce port ; l'option -p affiche le PID et le nom du processus propriétaire. Afficher le nom des processus pour des sockets dont vous n'êtes pas propriétaire exige les droits root : préfixez donc la commande par sudo. Une fois le PID identifié, arrêtez le processus avec kill suivi du PID. Cela résout l'erreur « port already in use » lorsqu'un serveur ou un conteneur refuse de se lier au port.

Pourquoi ifconfig renvoie-t-il command not found sur mon serveur ?

Parce qu'ifconfig appartient au paquet net-tools, que de nombreuses distributions modernes n'installent plus par défaut. Red Hat classe ifconfig et route parmi les commandes remplacées par iproute2, RHEL n'inclut plus net-tools dans son installation par défaut depuis la version 7, et Debian fait de même depuis Debian 9. Utilisez plutôt ip addr pour consulter les interfaces et les adresses, ou installez net-tools manuellement si un script hérité exige l'ancien binaire.

Comment savoir si un problème DNS vient du domaine ou de mon résolveur local ?

Interrogez directement un résolveur public avec dig +short example.com @8.8.8.8 et comparez le résultat à celui de dig +short example.com via votre résolveur par défaut. Si la requête publique aboutit mais pas celle par défaut, la faute revient à votre résolveur local, pas au domaine. La syntaxe @serveur force dig à contourner le résolveur configuré, ce qui isole la panne d'un côté sans modifier la configuration du système.

Pourquoi traceroute ou mtr ne sont-ils pas installés sur mon système ?

traceroute, mtr, whois, nmap et iftop ne sont souvent pas inclus dans les installations minimales ou par défaut, d'où le message command not found. Installez-les avec sudo apt install mtr traceroute sur Debian et Ubuntu, ou sudo dnf install mtr traceroute sur RHEL et Fedora. Contrairement à ip et ss, fournis par défaut avec iproute2, ces outils d'analyse de chemin et de scan doivent généralement être ajoutés via le gestionnaire de paquets.