Foxency
Administration Système et Infrastructure

Commandes réseau essentielles sous Linux

Un administrateur passe une grande partie de son temps dans le terminal. Voici les commandes réseau Linux essentielles, regroupées par usage, avec la lecture des résultats et les pièges à éviter.

Par Rédaction Foxency Publié le 6 min de lecture

Terminal Linux affichant les commandes ip, ss et dig utilisées pour le diagnostic réseau

Les distributions Linux modernes ont remplacé les anciens outils ifconfig, route et netstat (paquet net-tools) par la suite iproute2 (ip, ss, bridge). Les anciennes commandes existent encore parfois, mais leur sortie est incomplète (pas de prise en charge correcte de plusieurs adresses par interface, par exemple). Cet article présente les commandes à connaître, organisées par besoin.

Objectif : disposer d'un répertoire de commandes fiables, savoir interpréter leur sortie et éviter les erreurs d'usage. Retrouvez aussi ces commandes dans la référence des commandes réseau.

ip -br link            # vue synthétique : nom, état, adresse MAC
ip -br addr            # vue synthétique des adresses
ip addr show dev ens18 # détail d'une interface
ip -s link show ens18  # compteurs : octets, paquets, erreurs, rejets

$ ip -br addr
lo       UNKNOWN  127.0.0.1/8 ::1/128
ens18    UP       10.10.20.15/24 fe80::be24:11ff:fe2a:1c3/64

L'option -br (brief) rend la sortie lisible ; -c ajoute de la couleur ; -j produit du JSON, utile dans les scripts.

Modifications temporaires (perdues au redémarrage) :

sudo ip link set ens18 up
sudo ip addr add 10.10.20.16/24 dev ens18
sudo ip addr del 10.10.20.16/24 dev ens18

Routage : ip route

ip route                    # table principale
ip -6 route                 # table IPv6
ip route get 8.8.8.8        # route réellement choisie pour une destination
ip rule                     # règles de routage par politique (tables multiples)

$ ip route get 10.50.3.7
10.50.3.7 via 10.10.20.254 dev ens18 src 10.10.20.15 uid 1000

ip route get est précieux : il indique l'interface de sortie, le prochain saut et l'adresse source utilisée, ce qui révèle souvent des problèmes sur les serveurs à plusieurs interfaces.

Voisins : ip neigh

ip neigh show               # cache ARP (IPv4) et NDP (IPv6)
sudo ip neigh flush dev ens18

Un voisin en état FAILED n'a pas répondu à la résolution ARP ou NDP. Voir ARP et ICMP.

Sockets et connexions : ss

sudo ss -tulpn              # ports TCP/UDP en écoute + processus
ss -tan                     # toutes les connexions TCP, sans résolution de noms
ss -tan state established '( dport = :443 or sport = :443 )'
ss -s                       # résumé statistique
ss -ti dst 10.10.20.50      # détails TCP internes : RTT, fenêtre de congestion, retransmissions

Options à retenir : -t TCP, -u UDP, -l en écoute, -p processus (nécessite les droits root pour les processus des autres utilisateurs), -n pas de résolution de noms.

Connectivité : ping, tracepath, traceroute, mtr

ping -c 4 10.10.20.1
ping -c 3 -M do -s 1472 10.50.3.7   # test de MTU (1472 + 28 = 1500)
tracepath -n 203.0.113.10           # chemin et MTU, sans droits root
traceroute -n -T -p 443 203.0.113.10
mtr -rwzbc 50 203.0.113.10          # rapport sur 50 cycles

mtr combine ping et traceroute et affiche les pertes par saut. Attention à l'interprétation : une perte affichée sur un saut intermédiaire mais absente des sauts suivants provient généralement d'une limitation du débit ICMP sur ce routeur, pas d'une perte réelle du trafic.

DNS : dig, host, resolvectl

dig www.exemple.fr              # requête complète, statut et TTL
dig +short www.exemple.fr AAAA
dig @10.10.20.53 intranet.exemple.local
dig -x 203.0.113.10             # résolution inverse
dig exemple.fr MX +noall +answer
resolvectl query www.exemple.fr # passe par le résolveur du système

Piège classique : dig interroge directement les serveurs DNS et ignore /etc/hosts ainsi que l'ordre défini dans /etc/nsswitch.conf. Pour reproduire exactement ce que voit une application, utilisez getent hosts www.exemple.fr.

HTTP et services : curl

curl -I https://www.exemple.fr                    # en-têtes seulement
curl -sv https://www.exemple.fr -o /dev/null      # détails de connexion et TLS
curl --resolve www.exemple.fr:443:10.10.20.80 https://www.exemple.fr/
curl -w '%{time_connect} %{time_starttransfer} %{time_total}\n' -o /dev/null -s https://www.exemple.fr

L'option --resolve force l'adresse IP utilisée pour un nom, sans modifier le DNS : idéal pour tester un nouveau serveur avant une bascule. Les variables -w mesurent le temps de connexion TCP, le délai avant le premier octet et le temps total.

Tester un port : nc

nc -vz 10.10.20.80 443
nc -vzu 10.10.20.53 53          # UDP : résultat peu fiable, voir ci-dessous

Pour UDP, l'absence de message d'erreur ne prouve pas que le port est ouvert. Préférez le client du protocole (dig pour DNS, par exemple). Les options exactes de nc varient selon la variante installée (OpenBSD netcat, Ncat).

Capture de paquets : tcpdump

sudo tcpdump -D                                   # lister les interfaces
sudo tcpdump -ni ens18 host 10.10.20.50
sudo tcpdump -ni ens18 'tcp port 443 and host 10.10.20.50' -c 100
sudo tcpdump -ni any 'udp port 53'
sudo tcpdump -ni ens18 -w /tmp/capture.pcap -C 100 -W 5   # rotation : 5 fichiers de 100 Mo

L'option -n évite la résolution des noms (plus rapide, et n'ajoute pas de trafic DNS à la capture). Les filtres suivent la syntaxe BPF. Les fichiers .pcap s'analysent ensuite dans Wireshark.

Une capture peut contenir des mots de passe transmis en clair, des données personnelles ou des informations confidentielles. Limitez la durée et le filtre au strict nécessaire, protégez les fichiers et supprimez-les après analyse. Ne capturez que sur des réseaux dont vous avez la responsabilité.

Matériel et lien : ethtool

sudo ethtool ens18              # débit, duplex, auto-négociation, lien détecté
sudo ethtool -S ens18           # statistiques détaillées du pilote
sudo ethtool -i ens18           # pilote et micrologiciel

Link detected: no oriente immédiatement vers un problème physique : câble, port, module optique.

NetworkManager : nmcli

nmcli general status
nmcli device status
nmcli connection show
nmcli device show ens18          # adresse, passerelle, DNS obtenus
nmcli device wifi list           # réseaux Wi-Fi visibles (poste de travail)

Tableau d'équivalence ancien / nouveau

Ancienne commande (net-tools) Équivalent iproute2
ifconfig ip addr, ip link
route -n ip route
arp -n ip neigh
netstat -tulpn ss -tulpn
netstat -i ip -s link
brctl show bridge link, ip link show type bridge

Erreurs courantes

  • Oublier -n : la résolution de noms ralentit les commandes et peut les bloquer si le DNS est en panne.
  • Croire qu'un ip addr add survivra au redémarrage.
  • Utiliser dig pour diagnostiquer un problème lié à /etc/hosts.
  • Lancer tcpdump sans filtre sur un serveur chargé, au risque de saturer le disque ou la console.
  • Mal interpréter les pertes intermédiaires de mtr.

Conclusion

Avec ip, ss, dig, curl et tcpdump, vous couvrez la quasi-totalité des diagnostics réseau sous Linux, de la couche physique à l'application. Associez ces outils à une démarche structurée, décrite dans Méthodologie de dépannage d'un réseau informatique, et vous isolerez les pannes rapidement.

Références