10 - Le réseau : comprendre ce qui passe par le fil

Ce que tu vas apprendre

• Inspecter la configuration réseau avec ip et ss
• Faire des requêtes HTTP avec curl et wget
• Diagnostiquer avec ping, traceroute et dig
• Comprendre les ports et savoir ce qui écoûte sur ta machine

Prerequisites

Etre a l'aise avec le terminal Linux et les commandes de base. Avoir une connexion réseau (ca aide).

Je me souviens d'un bug qui m'a pris une demi-journee. Mon app tournait, les logs etaient propres, mais impossible d'y acceder depuis l'extérieur. Le problème ? Le serveur ecoutait sur 127.0.0.1 au lieu de 0.0.0.0. Ce genre de galere, ca se resout en cinq minutes quand tu connais les bons outils.

Voir ta configuration réseau

bash# Toutes les interfaces et leurs adresses IP
ip addr

# Version courte
ip a

# Uniquement les interfaces actives
ip link show up

# Voir la table de routage
ip route

# L'ancienne commande (depreciee mais encore partout)
ifconfig

La sortie de ip addr te donne pour chaque interface : son nom (eth0, ens3, wlp2s0...), son état (UP/DOWN), son adresse MAC, et ses adresses IP (IPv4 et IPv6).

ss : qui écoûte quoi

ss remplace netstat (déprécié). C'est la commande que j'utilise le plus en debug réseau :

bash# Tous les ports TCP en ecoute, avec les PID
ss -tlnp

# Decomposition :
# -t : TCP uniquement
# -l : en ecoute (listening)
# -n : numeros de ports (pas de resolution DNS)
# -p : affiche le processus

# Meme chose en UDP
ss -ulnp

# Toutes les connexions etablies
ss -tnp

# Filtrer par port
ss -tlnp | grep :3000

# Connexions vers un port precis
ss -tnp dst :443

Quand ton app ne démarré pas parce que "le port est deja utilise", ss -tlnp | grep :PORT te dit immédiatement quel processus occupe le port.

curl : le couteau suisse HTTP

curl est un outil que tu utiliseras tous les jours. Pour tester une API, debugger un problème, ou automatiser des requêtes :

bash# GET simple
curl https://api.example.com/users

# Voir les headers de requete et de reponse
curl -v https://api.example.com/users

# Uniquement les headers de reponse
curl -I https://api.example.com/users

# POST avec JSON
curl -X POST https://api.example.com/users \
  -H "Content-Type: application/json" \
  -d '{"name": "Nicolas", "email": "nico@example.com"}'

# Avec un token d'auth
curl -H "Authorization: Bearer mon-token-jwt" \
  https://api.example.com/protected

# Suivre les redirections
curl -L https://example.com

# Telecharger un fichier
curl -O https://example.com/archive.tar.gz

# Timeout de 5 secondes
curl --connect-timeout 5 https://api.example.com/health

Sur paltemps.fr, je teste toujours mes endpoints avec curl -v avant de toucher au frontend. Ca elimine toute une categorie de bugs.

wget : telecharger des fichiers

wget est plus simple que curl pour le telechargement :

bash# Telecharger un fichier
wget https://example.com/fichier.tar.gz

# Telecharger en renommant
wget -O backup.sql.gz https://example.com/dump.sql.gz

# Telecharger en arriere-plan
wget -b https://example.com/gros-fichier.iso

Diagnostiquer avec ping et traceroute

bash# Verifier qu'un hote est joignable
ping example.com

# Limiter a 4 paquets
ping -c 4 example.com

# Voir le chemin reseau jusqu'a un hote
traceroute example.com

# Version plus rapide (utilise ICMP)
traceroute -I example.com

ping te dit si la machine répond et en combien de temps. traceroute te montre chaque routeur sur le chemin. Utile quand "ca marche pas" et que tu veux savoir ou ca coince.

DNS : dig et nslookup

Le DNS traduit les noms de domaine en adresses IP. Quand ta résolution DNS deconne, rien ne marche :

bash# Voir les enregistrements DNS d'un domaine
dig example.com

# Juste la reponse, sans le bruit
dig +short example.com

# Un type precis
dig MX example.com
dig CNAME www.example.com
dig TXT example.com

# Interroger un serveur DNS specifique
dig @8.8.8.8 example.com

# L'ancienne commande (plus simple mais moins detaillee)
nslookup example.com

Les ports : c'est quoi, a quoi ca sert

Un port, c'est un numero (de 0 a 65535) qui identifié un service sur une machine. Quand tu te connectes a example.com:443, tu parles au port 443 de cette machine.

Les ports "bien connus" (0-1023) sont reserves aux services standards :

Les ports au-dessus de 1024 sont libres. C'est la que tu mets tes apps (3000, 8080, etc.).

/etc/hosts : le DNS local

Le fichier /etc/hosts est consulte avant le DNS. Tu peux y ajouter des correspondances nom/IP :

bash# Voir le contenu
cat /etc/hosts

# Ajouter une entree (en root)
echo "192.168.1.50 mon-serveur.local" | sudo tee -a /etc/hosts

C'est pratique pour le dev local : tu peux faire pointer api.monapp.local vers 127.0.0.1 et tester avec un vrai nom de domaine.

Verifier ce qui écoûte : le reflexe a avoir

Quand tu deploies une app, vérifié toujours qu'elle écoûte sur la bonne adresse et le bon port :

bash# Qu'est-ce qui ecoute ?
ss -tlnp

# Mon app ecoute-t-elle ?
ss -tlnp | grep :3000

# Depuis l'exterieur, le port est-il accessible ?
curl -v telnet://mon-serveur:3000

Si ss montre que ton app écoûte sur 127.0.0.1:3000, elle n'est accessible que localement. Pour qu'elle soit joignable depuis l'extérieur, elle doit écoûter sur 0.0.0.0:3000.

Résumé

• ip addr pour voir tes interfaces, ip route pour le routage
• ss -tlnp est ton meilleur ami pour savoir ce qui écoûte
• curl -v pour debugger les requêtes HTTP en détail
• dig +short pour vérifier le DNS rapidement
• Attention a 127.0.0.1 vs 0.0.0.0 quand tu deploies

Article précédent : systemd Article suivant : Le firewall

Sources

• ss - Linux manual page
• curl documentation
• dig - DNS lookup utility