Commandes réseau Linux : ip, ss, ping, traceroute, dig et curl pour le diagnostic

Les commandes réseau Linux couvrent presque tout le diagnostic du quotidien : ip affiche les adresses et les routes, ss les ports ouverts et les connexions, ping et traceroute vérifient qu'un hôte répond, dig interroge le DNS et curl teste la réponse d'un service web. Vous trouverez ci-dessous un aide-mémoire avec les options utiles, ainsi qu'un ordre de vérification pour trouver la cause quand « le réseau ne marche pas ».

Aide-mémoire : les commandes réseau Linux en un tableau

ip : adresses, interfaces et routes

La commande ip, fournie par le paquet iproute2, a remplacé les anciennes ifconfig et route. Les sous-commandes peuvent être abrégées : ip a équivaut à ip addr, ip r à ip route. L'option -br donne une sortie concise, et -c la colore.

$ ip -br addr
lo               UNKNOWN        127.0.0.1/8 ::1/128
eth0             UP             192.168.1.25/24 fe80::a00:27ff:fe4e:66a1/64
docker0          DOWN           172.17.0.1/16

Si une interface n'a pas d'adresse du réseau attendu ou se trouve en état DOWN, inutile d'aller plus loin : le problème se situe à ce niveau.

Ajouter une adresse IP et activer une interface

sudo ip link set eth0 up
sudo ip addr add 192.168.1.50/24 dev eth0
sudo ip addr del 192.168.1.50/24 dev eth0

Les modifications faites avec ip ne survivent pas au redémarrage. Les réglages permanents se font dans la configuration du système : netplan sous Ubuntu, NetworkManager (nmcli) sous Fedora et RHEL, systemd-networkd sur les serveurs.

Routes et passerelle par défaut

$ ip route
default via 192.168.1.1 dev eth0 proto dhcp metric 100
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.25

$ ip route get 10.20.0.5
10.20.0.5 via 192.168.1.1 dev eth0 src 192.168.1.25 uid 1000

La ligne default via indique la passerelle vers laquelle part tout ce qui ne correspond à aucune route plus précise. Sans cette ligne, il n'y a pas d'accès à Internet, même si le réseau local fonctionne. Ajouter une route : sudo ip route add 10.20.0.0/16 via 192.168.1.254.

ss : quels ports sont ouverts et qui les écoute

ss a remplacé netstat et fonctionne plus vite. La combinaison la plus courante est ss -tulpn :

$ sudo ss -tulpn
Netid State  Recv-Q Send-Q Local Address:Port  Peer Address:Port Process
tcp   LISTEN 0      511          0.0.0.0:80         0.0.0.0:*     users:(("nginx",pid=812,fd=6))
tcp   LISTEN 0      128          0.0.0.0:22         0.0.0.0:*     users:(("sshd",pid=640,fd=3))
tcp   LISTEN 0      151        127.0.0.1:3306       0.0.0.0:*     users:(("mysqld",pid=901,fd=21))

Faites attention à l'adresse : 0.0.0.0 signifie que le service accepte les connexions sur toutes les interfaces, 127.0.0.1 seulement en local. C'est une cause fréquente de base de données « injoignable » depuis une autre machine.

Savoir qui occupe un port

sudo ss -ltnp 'sport = :8080'
sudo ss -tn dst 10.0.0.7          # connexions vers une adresse précise
ss -tan state time-wait | wc -l   # nombre de sockets en TIME-WAIT

ping : l'hôte est-il joignable ?

ping envoie des requêtes ICMP echo et affiche le temps de réponse et les pertes. Sous Linux, il tourne indéfiniment : indiquez le nombre de paquets avec l'option -c.

$ ping -c 4 8.8.8.8
64 bytes from 8.8.8.8: icmp_seq=1 ttl=117 time=12.4 ms
...
--- 8.8.8.8 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3005ms
rtt min/avg/max/mdev = 12.1/12.5/13.0/0.3 ms

Options utiles : -i 0.2 pour l'intervalle, -W 2 pour le délai d'attente, -4 / -6 pour la version du protocole, -s 1472 -M do pour tester le MTU sans fragmentation. Gardez à l'esprit que de nombreux serveurs et clouds bloquent l'ICMP : l'absence de réponse au ping ne signifie pas forcément que l'hôte est hors service.

traceroute et mtr : où les paquets se perdent

traceroute affiche les nœuds traversés jusqu'à la cible. Des étoiles sur certains sauts sont normales : un routeur intermédiaire peut ne pas répondre. Le signe inquiétant, c'est quand les étoiles se succèdent jusqu'à la fin du chemin.

traceroute -n example.com        # sans noms DNS, plus rapide
sudo traceroute -T -p 443 example.com   # TCP au lieu d'UDP, passe mieux les pare-feu
tracepath example.com            # sans root, affiche aussi le MTU

mtr combine ping et traceroute et met à jour en temps réel les statistiques de perte pour chaque saut. Pour générer un rapport : mtr -rwc 50 example.com.

dig : vérifier le DNS

dig, fourni par le paquet dnsutils (bind-utils sous RHEL), est l'outil de référence pour vérifier le DNS. La forme courte n'affiche que la réponse :

$ dig +short example.com
93.184.215.14

$ dig example.com MX +short
$ dig @8.8.8.8 example.com A       # interroger un serveur précis
$ dig -x 8.8.8.8 +short            # enregistrement inverse (PTR)
$ dig +trace example.com           # parcourir la chaîne depuis les serveurs racine

Dans la sortie complète, regardez le champ status : NOERROR — l'enregistrement existe, NXDOMAIN — le domaine n'existe pas, SERVFAIL — le serveur n'a pas pu répondre (souvent un problème DNSSEC ou un serveur faisant autorité injoignable). Si dig @8.8.8.8 répond mais que dig simple ne répond pas, le coupable est le résolveur local : vérifiez /etc/resolv.conf et resolvectl status.

Notez que dig ne lit pas /etc/hosts. Pour tester la résolution d'un nom comme le ferait une application, utilisez getent hosts example.com.

curl : vérifier HTTP et API

curl répond à la dernière question : le service répond-il, et que renvoie-t-il exactement ?

$ curl -s -o /dev/null -w '%{http_code} %{time_connect} %{time_total}\n' https://example.com
200 0.041 0.187

Les messages d'erreur de curl indiquent bien la couche concernée : Could not resolve host — DNS, Connection refused — port fermé ou aucun service à l'écoute, Connection timed out — paquets bloqués par un pare-feu ou pas de route, SSL certificate problem — problème de certificat.

Ordre de diagnostic : « le réseau ne marche pas »

1. Interface et adresse : ip -br addr — l'interface est UP et possède une adresse.
2. Passerelle : ip route — la ligne default via existe ; ping -c 3 <passerelle>.
3. Réseau externe par IP : ping -c 3 1.1.1.1. Si cela répond, le routage fonctionne.
4. DNS : dig +short example.com. Une réponse vide ou une erreur alors que le ping par IP fonctionne indique un problème de résolveur.
5. Port : nc -zv host 443 ou curl -v. Sur le serveur, ss -tulpn montre si le service écoute et sur quelle adresse.
6. Pare-feu : sudo nft list ruleset, sudo iptables -L -n, sudo ufw status.
7. Application : curl -I et les journaux du service (journalctl -u nginx).

Procédez du bas vers le haut sans sauter d'étapes : en quelques minutes, vous identifiez le niveau où se trouve le problème, au lieu de redémarrer tout au hasard.

Anciennes et nouvelles commandes

Sur les distributions récentes, net-tools est souvent absent : mieux vaut prendre l'habitude des nouvelles commandes.

Conclusion

Pour le diagnostic courant, six commandes réseau Linux suffisent : ip, ss, ping, traceroute, dig et curl. Vérifiez couche par couche — adresse, route, DNS, port, application — et l'erreur se trouve vite. Les commandes réseau et l'analyse des pannes typiques sont travaillées en pratique dans le cours Linux.