Chapitre 6.4 — Diagnostic réseau

⏱️ TL;DR — Quand « le site ne marche pas », la panique ne sert à rien : une trousse à outils et une méthode suffisent. Ce chapitre te donne les deux. Côté DNS : dig, dig +short, dig @1.1.1.1 (interroger un resolver précis), nslookup, host. Côté machine : ss -tulpn pour voir qui écoute quoi (le remplaçant de netstat). Côté HTTP : curl -I et curl -v pour tester une réponse, ses en-têtes et suivre la chaîne. Côté réseau brut : ping, traceroute / mtr, et nc -zv pour tester si un port est ouvert. Avec ça, tu réponds à la seule question qui compte — « ça bloque où ? » — et tu isoles le maillon fautif : DNS, pare-feu, app pas démarrée, ou service qui n’écoute pas au bon endroit.

🎯 Objectifs

• Interroger le DNS avec dig, dig +short et dig @<resolver>, et connaître nslookup / host.
• Lister qui écoute quoi sur la machine avec ss -tulpn.
• Tester une réponse HTTP et ses en-têtes avec curl -I et curl -v.
• Tester la joignabilité et le chemin réseau avec ping, traceroute / mtr.
• Vérifier qu’un port est ouvert de bout en bout avec nc -zv.
• Inspecter les interfaces et le routage local avec ip a et ip route.
• Appliquer une méthode : remonter la chaîne pour isoler DNS vs pare-feu vs app.

La méthode avant les outils

Reprends la carte de dépannage de la Partie 1 (chapitre 1.5) : une requête traverse une chaîne — DNS → connexion/réseau → pare-feu → TLS → Nginx → app → base. Diagnostiquer, ce n’est pas deviner : c’est remonter la chaîne de l’extérieur vers l’intérieur et tester chaque maillon avec l’outil adapté. Chaque section ci-dessous couvre un maillon.

Interroger le DNS : dig

dig (Domain Information Groper) est l’outil de référence pour interroger le DNS. Sa sortie brute est verbeuse, mais l’option +short la réduit à l’essentiel.

dig formacampus.fr                 # sortie complete : question, reponse, TTL, serveur interroge
dig formacampus.fr +short          # juste la reponse : 203.0.113.10
dig formacampus.fr AAAA +short     # la reponse IPv6
dig formacampus.fr MX +short       # les serveurs de mail
dig www.formacampus.fr CNAME +short  # la cible d'un CNAME

L’option +short est celle que tu utiliseras 90 % du temps : elle répond directement « quelle IP ? ». Dans la sortie complète, la section ANSWER contient la réponse avec son TTL (le nombre en secondes) — pratique pour voir combien de temps un cache la gardera.

Le point le plus utile : dig @<resolver> interroge un resolver précis au lieu de celui de ta machine. Le @ en début d’argument désigne le serveur à questionner.

dig @1.1.1.1 formacampus.fr +short   # demande au resolver de Cloudflare
dig @8.8.8.8 formacampus.fr +short   # demande a celui de Google

C’est l’ outil pour contourner ton cache local (chapitre 6.3) : si @1.1.1.1 renvoie déjà ta nouvelle IP mais que ta machine sert encore l’ancienne, tu sais que le DNS public est correct et que c’est ton cache qui traîne.

🐚 Au terminal — Le triangle de vérification DNS, à garder sous la main :

dig formacampus.fr +short        # ce que MA machine voit (peut etre en cache)
dig @1.1.1.1 formacampus.fr +short   # ce qu'un resolver public frais voit
dig +trace formacampus.fr        # tout le chemin depuis la racine, etage par etage

dig +trace déroule la hiérarchie complète (racine → TLD → autoritaire) : précieux quand tu soupçonnes une délégation cassée (mauvais NS).

nslookup et host : les alternatives

dig n’est pas toujours installé (paquet dnsutils / bind-utils). Deux alternatives quasi partout :

nslookup formacampus.fr            # resolution simple
nslookup formacampus.fr 1.1.1.1    # via un resolver precis (sans @)
host formacampus.fr                # encore plus concis
host formacampus.fr 1.1.1.1        # via un resolver precis

nslookup désigne le resolver sans le @ (on met juste l’IP en second argument). host est le plus court pour un coup d’œil rapide. Pour un diagnostic sérieux, préfère dig : il montre le TTL et la structure de la réponse.

💡 Réflexe — Si un nom ne résout pas du tout (dig ... +short ne renvoie rien) mais que dig @1.1.1.1 répond, le problème est local (ton resolver, ton /etc/resolv.conf, ton cache). Si aucun resolver ne répond, le problème est dans la zone (enregistrement manquant, délégation cassée) — vérifie avec dig +trace.

Qui écoute quoi : ss -tulpn

Une fois sur le serveur, la question centrale est : quels services écoutent, sur quels ports, sur quelle interface ? L’outil moderne est ss (le remplaçant de l’ancien netstat).

ss -tulpn
# -t : sockets TCP
# -u : sockets UDP
# -l : uniquement ceux en ecoute (LISTEN)
# -p : le processus (nom + PID) qui ecoute
# -n : adresses et ports en numerique (pas de resolution en noms)

La sortie ressemble à ceci (colonnes simplifiées) :

Netid  State   Local Address:Port   Process
tcp    LISTEN  0.0.0.0:22           sshd
tcp    LISTEN  0.0.0.0:443          nginx
tcp    LISTEN  0.0.0.0:80           nginx
tcp    LISTEN  127.0.0.1:3000       node
tcp    LISTEN  127.0.0.1:5432       postgres

Tu lis d’un coup d’œil deux choses cruciales :

• Le service tourne-t-il ? S’il n’est pas dans la liste, il n’écoute pas — l’app est probablement arrêtée (c’est la cause n°1 d’un 502 Bad Gateway : Nginx tourne, mais l’app derrière est absente).
• Sur quelle interface écoute-t-il ? 0.0.0.0:443 = exposé (normal pour Nginx). 127.0.0.1:5432 = local (bien, pour Postgres). Un 0.0.0.0:5432 sauterait aux yeux comme une faille (chapitre 6.1).

⚠️ Piège — Un 502 te fait souvent triturer la config de Nginx pendant une heure… alors que ss -tulpn t’aurait montré en une seconde que le port 3000 n’écoute pas : l’app est tombée. Réflexe : ss -tulpn AVANT de toucher à Nginx. Si l’app n’est pas dans la liste, le problème est l’app (systemctl status, journalctl), pas le proxy.

Tester la réponse HTTP : curl -I et curl -v

curl fait une vraie requête HTTP et te montre la réponse. Deux usages clés :

curl -I https://formacampus.fr
# -I (i majuscule) : requete HEAD -> seulement les en-tetes de reponse, pas le corps

Tu obtiens le code de statut et les en-têtes :

HTTP/2 200
server: nginx
content-type: text/html; charset=utf-8
strict-transport-security: max-age=63072000

Le code 200 dit « tout va bien ». Un 301 / 302 est une redirection (typiquement HTTP → HTTPS, ou apex vers www). Un 502 / 504 vient de Nginx qui ne joint pas l’app. Un 404 est applicatif. Les en-têtes te renseignent : server: nginx confirme qui répond, strict-transport-security confirme le HSTS (Partie 8).

Pour suivre toute la chaîne, curl -v (verbeux) montre la résolution DNS, la connexion TCP, la poignée de main TLS (certificat) et les en-têtes envoyés/reçus :

curl -v https://formacampus.fr
# affiche : IP resolue, connexion sur le port 443, details du certificat TLS, en-tetes

Options utiles à combiner :

curl -IL https://formacampus.fr        # -L suit les redirections jusqu'a la page finale
curl -I --resolve formacampus.fr:443:203.0.113.10 https://formacampus.fr
# force la resolution vers une IP precise : teste TON serveur sans dependre du DNS

Le --resolve est un bijou : il te laisse tester le serveur directement, court-circuitant le DNS — parfait pour vérifier qu’un VPS répond avant même d’avoir pointé le domaine dessus.

💡 Réflexe — Face à un site « cassé », enchaîne : curl -I https://le-site d’abord. Le code de statut oriente immédiatement : pas de réponse du tout → DNS ou réseau ou pare-feu ; 502/504 → l’app derrière Nginx ; 200 mais mauvais contenu → l’app elle-même. Le code te dit quel maillon creuser.

Joignabilité et chemin : ping, traceroute, mtr

ping envoie de petits paquets et mesure si la machine répond et en combien de temps.

ping formacampus.fr        # Ctrl+C pour arreter ; montre le temps aller-retour (ms)
ping -c 4 formacampus.fr   # limite a 4 paquets

Attention : beaucoup de serveurs bloquent le ping (ICMP filtré) par choix de sécurité. Un ping sans réponse ne veut donc pas forcément dire « serveur down » — le web (443) peut très bien répondre alors que le ping est ignoré. C’est un indice, pas une preuve.

traceroute (ou mtr, sa version temps réel) montre le chemin des paquets, routeur par routeur, du poste jusqu’au serveur.

traceroute formacampus.fr   # liste les sauts (hops) et leur latence
mtr formacampus.fr          # meme idee, en continu et interactif : ideal pour voir OU ca coince

Utile quand la latence est mauvaise ou qu’une connexion « meurt en route » : tu vois à quel saut le chemin se dégrade ou s’arrête.

Tester un port précis : nc -zv

ping teste la machine ; nc (netcat) teste un port précis — donc un service. C’est la différence entre « l’immeuble est là » et « l’appartement répond ».

nc -zv formacampus.fr 443    # le port 443 est-il ouvert et joignable ?
# -z : mode scan (n'envoie pas de donnees, teste juste l'ouverture)
# -v : verbeux (dit "succeeded" ou "refused"/"timed out")
nc -zv formacampus.fr 22     # et le port SSH ?

Trois réponses possibles, trois diagnostics :

• « succeeded » / « open » : le port est ouvert et un service écoute derrière. Bon signe.
• « Connection refused » : la machine est joignable, mais rien n’écoute sur ce port (service arrêté, ou il écoute ailleurs comme 127.0.0.1).
• « timed out » : aucune réponse — typiquement un pare-feu qui bloque silencieusement le paquet (il drop au lieu de reject).

C’est le test pour distinguer « service pas démarré » (refused) de « pare-feu qui bloque » (timeout) — deux pannes aux corrections opposées.

🔒 Sécurité — Un pare-feu bien réglé drop (ignore silencieusement) les paquets vers un port fermé plutôt que de les reject (refuser explicitement) : le timed out de nc en est la signature. C’est voulu — ça rend les scans de ports plus lents et moins informatifs pour un attaquant. Côté UFW (Partie 5), c’est le comportement par défaut de deny.

Interfaces et routage : ip a, ip route

Deux dernières commandes, sur la machine elle-même :

ip a          # les interfaces et leurs IP (voir chapitre 6.1)
ip route      # la table de routage : notamment la route "default" (la passerelle)

ip route montre la route par défaut (default via ...) : la passerelle par laquelle sort tout le trafic vers l’extérieur. Si elle manque ou est fausse, la machine ne joint rien hors de son réseau local — cause possible d’un « le serveur n’a pas Internet ».

« Ça bloque où ? » : l’arbre de décision

Mets tout ensemble. Face à « le site ne répond pas », descends cet arbre :

1. dig le-site +short — le nom résout-il, vers la bonne IP ? Non → problème DNS (enregistrement, TTL, délégation). Oui → continue.
2. nc -zv le-site 443 — le port répond-il ? timed out → pare-feu (ou machine down). refused → rien n’écoute sur 443. succeeded → continue.
3. curl -I https://le-site — quel code ? 502/504 → l’app derrière Nginx (vérifie ss -tulpn puis systemctl status). 200 → le serveur répond ; si le contenu est faux, c’est applicatif.
4. Sur le serveur, ss -tulpn — l’app écoute-t-elle, sur le bon port et la bonne interface ? Absente → app arrêtée (journalctl). Sur 127.0.0.1 alors qu’il faut du public, ou l’inverse → mauvaise configuration d’écoute.

Chaque test isole un maillon. Tu ne devines plus : tu élimines.

🧭 Sur FormaCampus — Le jour du rapatriement, formacampus.fr renvoyait un 502. L’équipe n’a pas touché à Nginx : dig @1.1.1.1 formacampus.fr +short confirmait la bonne IP (DNS OK), curl -I https://formacampus.fr renvoyait bien un 502 de Nginx (donc Nginx tourne et le TLS répond), et ss -tulpn sur le VPS montrait que le port 3000 n’écoutait pas : le service Next.js n’avait pas démarré après le déploiement. Un journalctl -u formacampus-web a révélé une variable d’environnement manquante ; service relancé, port 3000 à l’écoute, curl -I repassé à 200. Dépannage en cinq minutes parce que chaque maillon a été testé dans l’ordre, de l’extérieur vers l’intérieur — exactement la carte de la Partie 1. Les runbooks complets sont en Partie 16.

📚 La doc — Chaque outil a son man (man dig, man ss, man curl, man nc) : c’est la référence qui fait autorité pour les options exactes de ta version. curl --help et dig -h donnent un rappel rapide. En cas de doute sur une option, le man avant de supposer.

✏️ Exercices

Exercice 1 — refused vs timed out. Tu testes nc -zv monsite.fr 443. Dans un cas tu obtiens « Connection refused », dans l’autre « timed out ». Quel diagnostic pour chacun, et quelle est la correction typique ?

Exercice 2 — Le 502. curl -I https://monsite.fr renvoie HTTP/2 502. Le DNS résout bien, le certificat est valide. Où est le problème, et quels deux commandes lances-tu sur le serveur ?

🧠 Quiz de révision

Fin de la Partie 6. Ton domaine pointe vers ton VPS et tu sais diagnostiquer le trajet. Le trafic arrive à la porte : on l’accueille avec Partie 7 — Nginx : le reverse proxy.