Réseau Linux : ip, ss, dig, curl, tcpdump — tutoriel pas-à-pas

📍 Article principal du programme : Linux fondamentaux 2026 — commandes, services, dépannage
Ce tutoriel fait partie du programme « Linux fondamentaux ». Pour la vue d’ensemble, lisez d’abord le guide principal.

Introduction

Quand un site renvoie une erreur 502, quand une API répond après dix secondes au lieu de cinquante millisecondes, quand un serveur ne ping plus, la cause est rarement une seule. Elle se cache dans une chaîne de couches successives : l’interface réseau, le routage, le pare-feu, la résolution DNS, la connexion TCP, la négociation TLS, la requête HTTP, la réponse de l’application. Diagnostiquer signifie descendre couche par couche jusqu’à trouver la rupture, pas tester au hasard. Ce tutoriel vous donne les commandes, l’ordre, et la méthode, en huit étapes appliquées sur un serveur Linux moderne (Ubuntu 24.04/26.04 LTS, Debian 13, AlmaLinux 9, Rocky Linux 9).

Prérequis

• Un serveur Linux et un compte avec accès sudo (la majorité des outils réseau exigent les privilèges).
• Le paquet iproute2 (présent par défaut sur toutes les distributions modernes).
• Connaissance de base de TCP/IP : adresses, ports, DNS, HTTP. Une lecture rapide du chapitre 1 du manuel TCP/IP suffit.
• Niveau attendu : intermédiaire débutant.
• Temps estimé : 90 minutes.

Étape 1 — Comprendre les couches à diagnostiquer

Avant de taper la première commande, ayez en tête le modèle simplifié sur lequel s’appuie tout diagnostic : interface physique → adressage IP → routage → pare-feu local → port en écoute → service applicatif. Une panne se loge dans l’une de ces six couches, et les outils diffèrent à chaque niveau. La règle d’or : descendez progressivement, et ne sautez aucune étape — un curl qui échoue ne vous dit pas si c’est le DNS, le TCP, le TLS ou l’application. Il faut tester chacun.

Cette discipline distingue un diagnostic en cinq minutes d’un tâtonnement d’une heure. Un VPS qui ne répond plus à curl https://exemple.com peut avoir : son interface en panne (couche 1), son adresse IP non attribuée (couche 2), une route par défaut absente (couche 3), un pare-feu qui bloque le retour (couche 4), aucun service écoutant sur le port 443 (couche 5), ou Nginx qui plante en boucle (couche 6). Les cinq commandes des prochaines étapes couvrent ces six couches en moins de soixante secondes.

Étape 2 — Inspecter les interfaces et les adresses

La commande historique ifconfig est obsolète depuis Debian 8 et n’est plus installée par défaut. La référence en 2026 est ip, fournie par iproute2. Elle est plus puissante, plus précise, et expose des fonctionnalités modernes (VLAN, VRF, namespaces) que ifconfig ne connaît pas.

ip addr                              # liste les interfaces et leurs adresses IPv4/IPv6
ip -br addr                          # version compacte, plus lisible
ip link                              # état physique des interfaces (up/down, MAC)
ip -s link show eth0                 # statistiques de paquets et erreurs
ip -6 addr                           # uniquement IPv6

La sortie de ip -br addr tient sur quelques lignes et donne immédiatement la photo réseau : lo UNKNOWN 127.0.0.1/8 ::1/128 (la boucle locale) et eth0 UP 10.0.0.5/24 fe80::.../64 (l’interface principale du VPS). Si eth0 apparaît avec DOWN ou sans adresse IP, vous avez votre première piste — l’interface n’est pas active. ip -s link show eth0 ajoute les compteurs de paquets reçus, transmis, en erreur et abandonnés ; un nombre élevé d’erreurs indique un problème matériel ou de pilote, sujet rare en VPS mais fréquent sur du baremetal.

Étape 3 — Vérifier la table de routage

Une fois l’interface active, la machine a besoin de savoir où envoyer les paquets pour atteindre Internet. C’est le rôle de la route par défaut, qui pointe vers la passerelle de l’hébergeur.

ip route                             # table IPv4
ip -6 route                          # table IPv6
ip route get 1.1.1.1                 # quel chemin pour atteindre 1.1.1.1 ?

Sur un VPS sain, vous voyez en général deux ou trois lignes : la route directe sur le sous-réseau de l’hébergeur (10.0.0.0/24 dev eth0), et la route par défaut (default via 10.0.0.1 dev eth0). L’absence de route par défaut explique 100 % des pannes du type « le serveur ping son voisin mais pas Google ». La commande ip route get 1.1.1.1 est particulièrement utile : elle simule le calcul de routage pour une adresse précise et affiche l’interface, la passerelle et l’adresse source sélectionnées. Si elle retourne « Network is unreachable », votre route par défaut manque ou est cassée.

Étape 4 — Lister les ports en écoute

Une fois certain que la machine est connectée à Internet, vérifiez quels services écoutent et sur quels ports. La commande netstat est dépréciée depuis Debian 8 et son remplaçant officiel est ss, plus rapide et plus complet.

ss -tlnp                             # ports TCP en écoute, avec PID/programme
ss -tunlp                            # TCP et UDP, en écoute, numérique, avec PID
ss -s                                # statistiques agrégées des sockets
ss -tnp dst :443                     # connexions TCP actives vers un port 443 distant
ss -tnp state established            # connexions établies

Les drapeaux : -t TCP, -u UDP, -l en écoute, -n numérique (pas de résolution DNS, plus rapide), -p nom du processus (exige sudo). La sortie d’ss -tlnp est le réflexe quand un service ne répond pas : si 0.0.0.0:443 n’apparaît pas, c’est que Nginx (ou ce qui devait écouter) n’est pas démarré ou écoute sur la mauvaise interface. La distinction 0.0.0.0 (toutes les interfaces) versus 127.0.0.1 (boucle locale uniquement) est cruciale : une base PostgreSQL qui n’écoute que sur 127.0.0.1 est inaccessible depuis l’extérieur même si le port 5432 est ouvert dans le pare-feu.

Étape 5 — Inspecter le pare-feu

Le pare-feu est la cause invisible de la moitié des pannes réseau : tout est correctement configuré, mais une règle bloque silencieusement la connexion. La commande dépend de la distribution. Sur Ubuntu et Debian, l’outil de haut niveau est ufw ; sur Alma et Rocky, c’est firewalld avec firewall-cmd. Tous deux pilotent la même mécanique sous-jacente : nftables (l’évolution moderne d’iptables, désormais le moteur par défaut depuis Debian 10 et RHEL 8).

# Ubuntu / Debian
sudo ufw status verbose

# Alma / Rocky
sudo firewall-cmd --list-all

# Bas niveau (toutes distributions)
sudo nft list ruleset                # règles nftables effectives
sudo iptables -L -n -v               # ancien outil, encore utile sur quelques systèmes

La sortie d’ufw status verbose affiche les règles dans l’ordre, avec leur destination et leur action. Si vous voyez « Default: deny (incoming) » et que seul le port 22 est explicitement autorisé, votre site web sur le port 443 est forcément filtré — d’où la 502 mystérieuse. La correction est sudo ufw allow 443/tcp ; pour une règle plus restrictive avec une plage IP précise, sudo ufw allow from 1.2.3.4 to any port 5432. Pour firewalld, l’équivalent est sudo firewall-cmd --permanent --add-service=https && sudo firewall-cmd --reload.

Étape 6 — Tester la connectivité distante

À ce stade, l’interface, le routage, les ports et le pare-feu sont vérifiés côté serveur. Reste à tester la chaîne réelle, depuis l’extérieur. Cinq commandes couvrent l’essentiel.

ping -c 4 1.1.1.1                    # connectivité ICMP brute
ping -c 4 google.com                 # ICMP + DNS combinés
mtr --report --report-cycles 5 google.com    # traceroute en temps réel
dig +short example.com               # résolution DNS sans fioritures
dig +short MX exemple.fr             # serveurs mail d'un domaine
nslookup exemple.com 1.1.1.1         # forcer un résolveur précis
curl -v https://exemple.com          # négociation TLS + requête HTTP avec trace

Le réflexe d’enchaînement : ping IP brute (couche 3), ping nom de domaine (couche 3 + DNS), dig isolé pour valider que le DNS résout bien (élimine la moitié des fausses pistes), mtr pour voir où le paquet se perd entre vous et la cible, puis curl -v pour la couche applicative. Une commande curl qui négocie le TLS, envoie la requête, mais reçoit une 502 du serveur : le problème est applicatif, pas réseau. Une commande curl qui timeout sur la connexion TCP : le problème est entre la couche 3 et la couche 4, à diagnostiquer côté serveur. mtr affiche la perte de paquets à chaque saut intermédiaire ; un saut qui passe de 0 % à 90 % de perte localise le routeur fautif.

Étape 7 — Capturer le trafic avec tcpdump

Quand les couches précédentes paraissent saines mais que le problème persiste, descendre au niveau du paquet est nécessaire. tcpdump capture le trafic brut sur une interface — très intrusif si mal utilisé, indispensable pour les cas vraiment retors.

# Voir tout le trafic HTTPS sur eth0 (interrompre avec Ctrl-C)
sudo tcpdump -i eth0 -n port 443

# Capturer 100 paquets sur le port 5432 (PostgreSQL) et écrire dans un fichier
sudo tcpdump -i eth0 -n -c 100 port 5432 -w postgres.pcap

# Voir les requêtes DNS sortantes
sudo tcpdump -i eth0 -n port 53

# Voir les SYN sans ACK (problème classique de pare-feu)
sudo tcpdump -i eth0 -n "tcp[tcpflags] == tcp-syn"

Le fichier .pcap produit s’ouvre ensuite dans Wireshark, qui décode chaque paquet et affiche la chaîne de négociation lisiblement. C’est l’outil ultime pour comprendre pourquoi un client se déconnecte après le SYN ACK ou pourquoi une requête HTTPS reçoit un RST inattendu. Attention : tcpdump peut générer plusieurs gigaoctets en quelques minutes sur un serveur chargé ; limitez toujours avec -c (nombre de paquets) ou un filtre BPF restrictif. Sur un VPS de production, la capture doit rester courte et ciblée.

Étape 8 — Vérification de bout en bout

Pour valider que tout votre arsenal fonctionne, déroulez la séquence suivante sur un serveur de test. Elle teste chacune des six couches dans l’ordre et confirme que la chaîne complète est saine.

echo "=== Couche 1-2 : interface ===" && ip -br addr show eth0
echo "=== Couche 3 : route par défaut ===" && ip route get 1.1.1.1
echo "=== Couche 4 : ports en écoute ===" && sudo ss -tlnp | grep -E ":(22|80|443) "
echo "=== Couche 4 : pare-feu ===" && sudo ufw status 2>/dev/null || sudo firewall-cmd --list-all 2>/dev/null
echo "=== Couche 5 : DNS ===" && dig +short cloudflare.com
echo "=== Couche 5 : connectivité externe ===" && curl -s -o /dev/null -w "%{http_code} %{time_total}s\n" https://1.1.1.1
echo "✓ tout va bien"

Sur un serveur sain, vous voyez l’interface UP, une passerelle valide, les ports SSH et HTTP/HTTPS en écoute, des règles de pare-feu qui autorisent les ports nécessaires, une réponse DNS, et une réponse HTTP 200 en moins d’une seconde. Si l’une de ces étapes échoue, vous avez une localisation précise du problème — ce qui transforme un dépannage de deux heures en correction de dix minutes.

Erreurs fréquentes

Tutoriels associés

• SSH : clés, config, tunnels et hardening
• Dépannage Linux méthodique

Pour approfondir

• 🔝 Retour au guide principal : Linux fondamentaux 2026
• Pages de manuel : man ip, man ss, man tcpdump, man dig, man curl.
• Documentation iproute2 — wiki.linuxfoundation.org/networking/iproute2
• nftables wiki officiel — wiki.nftables.org
• Cloudflare Learning Center : networking — cloudflare.com/learning
• Wireshark, analyseur de paquets graphique — wireshark.org

FAQ

Pourquoi netstat et ifconfig ne sont plus recommandés ?
Le paquet net-tools qui les fournit est en mode maintenance depuis 2011 et n’est plus installé par défaut sur les distributions modernes. Les outils ip et ss du paquet iproute2 exposent l’intégralité des fonctionnalités du noyau Linux moderne (VLAN, namespaces, multipath routing, BPF), ce que net-tools ne sait pas faire. Apprenez les nouvelles commandes une fois, vous serez bons partout.

Comment voir le trafic d’un seul processus ?
La commande nethogs classe le trafic par processus en temps réel ; ss -tnp liste les connexions actives avec leur PID et le programme. Pour une trace plus profonde, strace -e trace=network -p PID intercepte les appels système réseau d’un processus précis. Pour les conteneurs, nsenter permet d’entrer dans le namespace réseau du conteneur et d’y lancer ss ou tcpdump sans installer ces outils dedans.

Comment diagnostiquer un problème DNS ?
Quatre niveaux d’investigation. cat /etc/resolv.conf montre les résolveurs configurés sur la machine. dig @1.1.1.1 exemple.com teste un résolveur précis sans dépendre de la conf locale. dig +trace exemple.com rejoue la résolution récursive depuis les serveurs racine. Enfin, resolvectl status sur les systèmes systemd-resolved donne la vue d’ensemble des résolveurs effectifs par interface.

Faut-il désactiver IPv6 sur un serveur ?
Non. IPv6 est désormais activé par défaut sur tous les hébergeurs sérieux et représente désormais la majorité du trafic chez certains opérateurs (le baromètre Google a franchi 50 % d’utilisateurs IPv6 fin mars 2026). Désactiver IPv6 revient à se couper d’une partie du Web et à diverger des standards modernes. La bonne pratique est de configurer le pare-feu pour IPv4 ET IPv6 (ip6tables ou nft couvrent les deux).

Comment mesurer la bande passante effective entre deux machines ?
iperf3 est l’outil de référence. Sur le serveur : iperf3 -s. Sur le client : iperf3 -c adresse-serveur -t 30. Le test pousse du trafic pendant trente secondes et affiche le débit réel en bits/s. Pour mesurer la latence et la gigue, iperf3 -u -b 100M en mode UDP. C’est la méthode propre pour évaluer la bande passante annoncée d’un VPS, ou diagnostiquer un goulet d’étranglement réseau entre deux serveurs.

Comment voir l’historique des connexions sortantes d’un serveur ?
Le journal auth.log trace les connexions SSH entrantes mais pas les sorties applicatives. Pour les capturer, deux approches. Avec conntrack, le suivi des connexions du noyau, vous pouvez extraire les flux actifs : sudo conntrack -L. Pour un historique complet, auditd avec une règle -a always,exit -F arch=b64 -S connect écrit chaque appel connect() dans /var/log/audit/audit.log — méthode lourde mais précise pour les enquêtes de sécurité.