infra / linux-bash
Réseaux depuis le terminal (ip, ss, curl, wget)
Explication
Sur un serveur distant, il n'y a pas de fenêtre de paramètres réseau à ouvrir : tout se fait en ligne de commande. Cette leçon regroupe les outils qui répondent à trois questions essentielles : quelle est ma configuration réseau actuelle, quelles connexions sont actives, et est-ce que je peux joindre une ressource distante.
Ce que vous allez apprendre
- Consulter la configuration réseau d'une machine avec
ip addretip route - Lister les connexions et ports en écoute avec
ss, le remplaçant moderne denetstat - Utiliser
curlcomme un vrai client HTTP pour tester une API (GET, POST, headers, JSON) - Diagnostiquer un problème de résolution de nom avec
digethost - Tester rapidement si un port distant est ouvert sans installer d'outil supplémentaire
Dans quel contexte ?
Un développeur backend vient de déployer une nouvelle API sur un serveur, mais l'application frontend n'arrive pas à la joindre sur https://api.exemple.com/health. Avant de soupçonner le code, il doit vérifier méthodiquement chaque étape depuis le terminal : est-ce que api.exemple.com se résout bien en IP (dig), est-ce que le port 443 est ouvert (nc -zv ou ss), et est-ce que le serveur répond correctement à une requête HTTP (curl -v).
Une nuance à connaître : des outils modernes remplacent les anciens
| Ancien outil | Outil moderne | Rôle |
|---|---|---|
ifconfig | ip addr / ip a | Configuration des interfaces réseau |
route | ip route | Table de routage |
netstat | ss | Connexions et sockets actives |
arp | ip neigh | Table ARP (voisins réseau) |
Des commandes historiques comme ifconfig ou netstat sont aujourd'hui dépréciées, au profit de ip et ss, plus complètes et mieux maintenues. De nombreux systèmes plus anciens ou des tutoriels utilisent encore les anciennes commandes, mais dans tes propres scripts, privilégie toujours les nouvelles.
Prérequis
Aucune connaissance réseau avancée n'est nécessaire, mais être à l'aise avec les pipes et les redirections (leçon 10) aide pour combiner ces outils entre eux.
Une fois la base réseau comprise, voyons curl d'un peu plus près
Beaucoup de gens pensent à curl uniquement pour télécharger un fichier. C'est en réalité bien plus : un client HTTP complet, capable d'envoyer n'importe quelle méthode (GET, POST...), des en-têtes personnalisés, ou un corps de requête JSON — l'outil de référence pour tester une API depuis un terminal ou un script, sans avoir besoin d'ouvrir un navigateur.
Il reste une dernière étape avant de joindre un serveur par son nom
Avant de pouvoir contacter un serveur via un nom comme exemple.com, la machine doit d'abord traduire ce nom en adresse IP, grâce au DNS. dig et host permettent de voir explicitement ce que répond le serveur DNS.
Bonne pratique
Face à une erreur de connexion, isole d'abord le problème avec dig +short exemple.com : si aucune IP ne s'affiche, le problème est la résolution DNS, pas le serveur cible lui-même. C'est le premier réflexe à avoir avant de chercher plus loin.
Une fois ces bases réseau posées, la suite logique est d'apprendre à se connecter de façon sécurisée à un serveur distant avec SSH.
Commandes & code
Réseaux depuis le terminal
# ip : outil moderne (remplace ifconfig/route/arp, désormais dépréciés)
ip addr show # ou "ip a" : interfaces et adresses IP
ip -4 addr show eth0 # filtre IPv4 sur une interface précise
ip link show # état des interfaces (UP/DOWN, MAC)
ip link set eth0 up # active une interface
sudo ip addr add 192.168.1.50/24 dev eth0 # ajoute une IP à une interface (temporaire)
ip route show # table de routage
ip route get 8.8.8.8 # quelle route serait utilisée pour cette destination
ip neigh show # table ARP (voisins découverts)
# ss : état des sockets/connexions (remplace netstat)
ss -tulpn # tcp+udp, listening, process, numérique (pas de résolution DNS)
ss -t state established # connexions TCP établies uniquement
ss -s # statistiques résumées
# curl : requêtes HTTP/HTTPS en ligne de commande
curl https://api.exemple.com/health
curl -I https://exemple.com # HEAD uniquement (headers de réponse)
curl -X POST -H "Content-Type: application/json" \
-d '{"email":"test@exemple.com"}' \
https://api.exemple.com/users
curl -o fichier.zip https://exemple.com/fichier.zip # sauvegarde vers un fichier
curl -L https://exemple.com/redirige # suit les redirections
curl -w "%{http_code} %{time_total}s\n" -o /dev/null -s https://exemple.com # code + latence
curl -v https://exemple.com # verbose : voir le TLS handshake, headers
# wget : téléchargement, plus adapté aux gros fichiers / miroirs
wget https://exemple.com/fichier.tar.gz
wget -c https://exemple.com/gros_fichier.iso # -c reprend un téléchargement interrompu
wget -r -np -k https://exemple.com/docs/ # mirror récursif d'un site
# Résolution DNS depuis le shell
dig exemple.com # requête DNS complète
dig +short exemple.com # juste l'IP résultante
host exemple.com # équivalent simplifié
nslookup exemple.com # historique mais encore courant
# Test de connectivité et de port
ping -c 4 exemple.com # 4 paquets ICMP
nc -zv exemple.com 443 # teste si le port 443 est ouvert (netcat)
timeout 3 bash -c "</dev/tcp/exemple.com/443" && echo "port ouvert" # sans netcatRésumé
ipremplaceifconfig/route;ssremplacenetstatsur les distributions modernes.curlpour scripter des appels API,wgetpour du téléchargement récursif/résumable.dig +shortest le réflexe rapide pour vérifier une résolution DNS.
Exercices pratiques
Mission : diagnostiquer une API injoignable depuis le terminal
Objectif : Isoler méthodiquement une panne réseau couche par couche (DNS, port, HTTP) sans jamais soupçonner le code en premier.
Contexte
L'application frontend n'arrive plus à joindre https://api.exemple.com/health. Avant de soupçonner le code de l'API, tu dois vérifier depuis le terminal, dans l'ordre, chaque couche réseau qui pourrait être en cause.