Diagnostiquer le réseau Linux avec ip, ss et curl

À la fin de ce tutoriel, vous saurez inspecter interfaces et routes avec la commande ip, résoudre le DNS, lire les ports en écoute via ss, tester la connectivité (ping, tracepath) et interroger HTTP avec curl — le trio de diagnostic réseau du junior DevOps.

Niveau : Débutant · Temps estimé : 40–50 min · Versions testées : Ubuntu 22.04 / 24.04, Debian 12 ; notes Rocky/Alma 9 · Dernière vérification : 2026-09-10

Slug proposé : linux-reseau-ip-ss-curl · Série : P5 Linux Basics · Remplace / fusionne : N/A — création

Prérequis

• Avoir suivi Contrôler processus et services Linux avec ps, top et systemctl (systemctl, journalctl)
• Une VM ou WSL jetable (Ubuntu/Debian ou Rocky/Alma 9) avec accès réseau sortant
• Terminal bash ; aucune IP / secret de production dans les commandes ou captures
• Optionnel : dnsutils / bind-utils (dig, nslookup), traceroute ou iputils-tracepath

Coût estimé : 0 €. Lab : commandes lecture + appels HTTP vers des endpoints publics d’exemple (example.com, httpbin.org).

Ce que nous allons construire

Interfaces & routes (ip addr / route / link)
  → DNS (/etc/resolv.conf, resolvectl, getent)
  → Ports en écoute (ss -tulpn)
  → Connectivité (ping, tracepath)
  → HTTP (curl GET, -I, -v, -o, codes)
  → Pare-feu (ufw status, aperçu)
  → Diagnostic « service down » (ss + curl + journalctl)
  → Vérification + nettoyage lab

(Schéma à remplacer par une image locale Excalidraw / draw.io, alt : « Réseau Linux : ip, ss, curl, DNS et ports — diagnostic junior DevOps ».)

Sixième chapitre de Linux Basics. Sur le cloud, les mêmes réflexes s’appliquent aux Security Groups AWS et aux Services Kubernetes : d’abord « qui écoute où ? », puis « le client reçoit-il une réponse HTTP ? ».

Étape 1 — Réseau : interfaces et routes (ip addr, ip route, ip link)

ifconfig et route (paquet net-tools) sont obsolètes sur les distros modernes. La suite iproute2 fournit ip.

# Interfaces + adresses (IPv4/IPv6)
ip -br addr
ip addr show
# État des liens (UP/DOWN, MAC)
ip -br link
# Table de routage : passerelle par défaut
ip route show
ip -4 route get 1.1.1.1

Commande	Rôle	Remplace
ip addr / ip a	Adresses sur chaque interface	ifconfig
ip link / ip l	État du lien (UP, MTU, MAC)	partie ifconfig
ip route / ip r	Routes et default via …	route -n

Ubuntu/Debian : souvent eth0, ens3, enp0s3 ou wlan0. Rocky/Alma : même outil ip ; noms d’interfaces NetworkManager similaires. En lab, notez l’interface UP qui porte une adresse privée (ex. 10.x / 192.168.x) — n’affichez pas d’IP de prod dans vos notes publiques.

Étape 2 — DNS : resolv.conf, resolvectl, getent

Sans résolution de noms, curl https://example.com échoue même si le réseau IP marche.

# Fichier classique (souvent géré par systemd-resolved / NetworkManager)
cat /etc/resolv.conf
# Ubuntu/Debian avec systemd-resolved
resolvectl status 2>/dev/null | head -n 40 || true
# Résolution via libc (portable)
getent hosts example.com
getent ahosts example.com | head
# Optionnel si installé : dig / nslookup
# Ubuntu/Debian : sudo apt install -y dnsutils
# Rocky/Alma   : sudo dnf install -y bind-utils
dig +short example.com A 2>/dev/null || nslookup example.com 2>/dev/null | head -n 12 || true

getent hosts suffit au quotidien. dig / nslookup affinent (TTL, serveur interrogé) — utiles en incident DNS, pas obligatoires pour ce chapitre.

Étape 3 — Ports en écoute avec ss (remplace netstat)

Le mot-clé ss linux désigne l’outil moderne pour sockets. Préférez ss à netstat : plus rapide, maintenu avec le noyau, pas besoin du vieux net-tools.

# TCP/UDP en écoute + processus (-p peut demander sudo pour tout voir)
ss -tulpn
# Filtrer un port (ex. SSH 22, HTTP 80)
ss -tulpn | grep -E ':22|:80|:443' || true
# Synthèse sockets établis
ss -s

Flag	Sens
-t	TCP
-u	UDP
-l	listening (écoute)
-n	ports numériques (pas de noms de service)
-p	processus propriétaire

Lire une ligne : adresse locale (0.0.0.0:22 = toutes interfaces), état LISTEN, colonne process (sshd, nginx, …). Qui écoute sur un port ? → ss -tulpn | grep ':PORT'.

Étape 4 — Connectivité : ping et traceroute / tracepath

# ICMP vers un hôte public (Ctrl+C pour arrêter ; -c limite le nombre)
ping -c 3 example.com
# Chemin approximatif (tracepath souvent présent sans root ; traceroute via paquet)
tracepath -n 1.1.1.1 2>/dev/null | head -n 15 || traceroute -n -m 8 1.1.1.1 2>/dev/null | head -n 15 || echo "installez iputils-tracepath ou traceroute"

ping vérifie joignabilité ICMP (un pare-feu peut le bloquer sans bloquer HTTPS). tracepath / traceroute montrent les sauts — utile pour un timeout « loin » vs « local ». Bref : si ping échoue, testez quand même curl -I https://… avant de conclure.

Étape 5 — HTTP avec curl : GET, -I, -v, -o, codes

curl est le client HTTP/S de référence en CLI.

# GET simple (corps)
curl -sS https://example.com/ | head -n 5
# En-têtes seulement (HEAD) — idéal pour un check rapide
curl -sSI https://example.com/
# Verbose : DNS, TLS, requête/réponse (lab)
curl -sS -v -o /dev/null https://example.com/ 2>&1 | head -n 40
# Sauver le corps dans un fichier lab
mkdir -p /tmp/lab-reseau
curl -sS -o /tmp/lab-reseau/example.html -w "HTTP %{http_code} time %{time_total}sn" https://example.com/
# API publique safe (httpbin) — pas de secret
curl -sS https://httpbin.org/get | head -c 400 ; echo
curl -sSI https://httpbin.org/status/200 | head -n 5

Codes utiles : 200 OK, 301/302 redirect, 404 introuvable, 500/502/503 côté serveur. -f fait échouer curl sur ≥400 ; -w '%{http_code}' extrait le code pour un script. Ne collez jamais de jetons d’API de prod dans l’historique du shell.

Étape 6 — Pare-feu : ufw status (aperçu)

Sur Ubuntu/Debian, UFW enveloppe iptables/nftables :

# Lecture seule — n’activez/désactivez pas ufw sur une VM distante sans console
sudo ufw status verbose 2>/dev/null || echo "ufw absent ou non installé (OK en lab minimal)"
# Rocky/Alma : firewalld plutôt que ufw
sudo firewall-cmd --state 2>/dev/null || true
sudo firewall-cmd --list-all 2>/dev/null | head -n 30 || true

Si Status: active et qu’un port n’apparaît pas en ALLOW, le service peut tourner (ss OK) mais rester injoignable de l’extérieur — même logique qu’un Security Group trop strict. Durcissement ufw + fail2ban : bonus hors série (linux-ufw-fail2ban, à paraître).

Étape 7 — Diagnostiquer « service down » : ss + curl + journalctl

Enchaînement DevOps type :

1. Le process écoute-t-il ? ss -tulpn | grep ':PORT'
2. Répond-il en local ? curl -sSI http://127.0.0.1:PORT/
3. Le service systemd est-il actif ? systemctl status nom + journalctl -u nom -n 50 (voir tuto processus & systemd)
4. Pare-feu / SG ? ufw status ou console cloud

# Lab lecture : SSH souvent en écoute — sans toucher la config
ss -tulpn | grep -E ':22s' || ss -tuln | grep ':22'
# HTTP local si un service lab tourne ; sinon example.com depuis la machine
curl -sSI --max-time 5 http://127.0.0.1:80/ 2>&1 | head -n 8 || true
curl -sSI --max-time 5 https://example.com/ | head -n 8
# Lien logs (adaptez le nom d’unit)
journalctl -u ssh -n 5 --no-pager 2>/dev/null || journalctl -u sshd -n 5 --no-pager 2>/dev/null || true

Symptôme fréquent : systemctl dit active, mais ss ne montre pas le port → mauvais Listen / bind ; ou ss OK et curl timeout distant → réseau / pare-feu.

Étape 8 — Lab jetable et nettoyage

mkdir -p /tmp/lab-reseau
# Capture lecture seule pour vos notes (pas de secrets)
{
  echo "=== ip -br addr ==="
  ip -br addr
  echo "=== ip route ==="
  ip route
  echo "=== ss -tuln (sans -p) ==="
  ss -tuln | head -n 30
  echo "=== curl -I example.com ==="
  curl -sSI --max-time 10 https://example.com/ | head -n 10
} > /tmp/lab-reseau/diag.txt
wc -l /tmp/lab-reseau/diag.txt
# Nettoyage
rm -rf /tmp/lab-reseau
echo "lab réseau nettoyé — OK"

Validé si : ip addr/route lus, DNS via getent, ss -tulpn compris, curl -I + code HTTP, enchaînement service down esquissé, /tmp/lab-reseau supprimé.

Erreurs fréquentes

Symptôme	Cause	Correction
ip: command not found	Très vieux système / chroot minimal	Installer iproute2
curl: (6) Could not resolve host	DNS cassé	getent hosts, resolvectl, /etc/resolv.conf
curl: (7) Failed to connect	Rien n’écoute / pare-feu	ss -tulpn puis ufw/SG
ss sans process names	Manque -p ou droits	sudo ss -tulpn
ping OK, HTTPS KO	ICMP ≠ TCP 443	Tester curl -v / certificats
Habitude ifconfig/netstat	Outils dépréciés	Migrer vers ip et ss

Quiz (3 questions)

1. Pourquoi préférer ss à netstat ?
– A. ss est plus lent mais coloré
– B. ss est l’outil moderne (iproute2), plus rapide et maintenu ; netstat dépend de net-tools obsolète
– C. ss ne montre jamais les ports

2. Comment voir qui écoute sur un port ?
– A. ss -tulpn | grep ':PORT' (éventuellement avec sudo)
– B. Uniquement cat /etc/passwd
– C. chmod 777

3. À quoi sert curl -I ?
– A. Installer un paquet
– B. Demander les en-têtes HTTP (HEAD) sans télécharger tout le corps — check rapide de disponibilité / code
– C. Ouvrir un tunnel SSH

Réponses : 1‑B · 2‑A · 3‑B

FAQ

Pourquoi préférer ss à netstat ?
ss (socket statistics) fait partie d’iproute2, lit les infos directement depuis le noyau, et affiche listening/établis avec -tulpn. netstat appartient à net-tools, rarement installé par défaut sur les images cloud récentes. Même réflexe que ip vs ifconfig.

Comment voir qui écoute sur un port ?
ss -tulpn | grep ':8080' (adaptez le port). La colonne process indique le binaire/PID. Sans -p ou sans droits, les noms de process peuvent être masqués : utilisez sudo en lab.

À quoi sert curl -I ?
-I / --head envoie une requête HEAD : vous voyez le statut HTTP et les headers (Server, Content-Type, redirections) sans récupérer le body. Parfait pour un health-check rapide avant un GET complet ou un -o fichier.

Pour aller plus loin

• man ip, man ss, man curl, man resolvectl
• Bonus prévu : ufw + fail2ban (sécuriser un VPS)
• Prochain tuto : scripts bash pour automatiser ces checks

Maillage série Linux Basics (P5)

← Précédent	Contrôler processus et services Linux avec ps, top et systemctl
→ Suivant	Écrire vos premiers scripts bash : variables, tests et boucles
Hub	Linux Basics
Aussi	AWS Security Groups / NACL · AWS VPC sous-réseaux · Services K8s (exposition de ports)

---

Meta publication (à remplir dans Rank Math / SEO)

• Title SEO : Réseau Linux : ip, ss, curl, DNS et ports (guide 2026)
• Meta description (≤ 155) : Vérifiez interfaces, routes, ports ouverts et HTTP avec ip, ss et curl. Remplacez ifconfig/netstat — lab junior DevOps.
• Focus keyphrase : ss linux
• KW secondaires : commande ip linux, curl, diagnostiquer réseau linux, ports ouverts, dig nslookup
• Schemas Rank Math : Article + HowTo (étapes lab) + FAQ (3 questions ci-dessus)
• Image mise en avant : assets/web/devopelastichayway/cover-linux-reseau-ip-ss-curl-1200x630.webp (Visuels Linux — WebP 1200×630)
• Catégorie : Linux · Niveau : Débutant
• Slug : linux-reseau-ip-ss-curl