Diagnostique un service de bout en bout

L’idée reçue

« Quand un site ne s’ouvre pas, il faut redémarrer le réseau. »

Un redémarrage peut masquer temporairement un symptôme et détruire des preuves. Un diagnostic professionnel avance du plus fondamental au plus spécifique et valide chaque hypothèse.

Incident déclaré : « l’intranet ne s’ouvre pas ». Le laboratoire contient volontairement plusieurs défauts successifs. Ne cherche pas à tout corriger d’un coup.

1Lien et adressageinterface, IP, route, voisin

2Résolutionnom, type, réponse, serveur

3Transportécoute, port, refus, timeout

4Application et TLSHTTP, logs, certificat, nom

01Construire l’incident

sudo apt update
sudo apt install -y dnsmasq-base dnsutils curl netcat-openbsd tcpdump openssl python3

chmod +x module3-services-lab.sh
sudo ./module3-services-lab.sh up
sudo ip -n soria-cli addr add 10.30.0.100/24 dev eth0

Crée volontairement un enregistrement DNS incorrect :

cat >/tmp/soria-dnsmasq.conf <<'EOF'
interface=eth0
bind-interfaces
no-resolv
no-hosts
local=/soria.test/
host-record=intranet.soria.test,10.30.0.21
log-queries
log-facility=-
EOF

sudo ip netns exec soria-svc dnsmasq --no-daemon --conf-file=/tmp/soria-dnsmasq.conf

Dans un autre terminal, lance le service au mauvais endroit :

sudo ip netns exec soria-web python3 -m http.server 8080 --bind 127.0.0.1

02Valider le socle réseau

sudo ip -n soria-cli -brief link
sudo ip -n soria-cli -brief address
sudo ip -n soria-cli route
sudo ip netns exec soria-cli ping -c 2 10.30.0.1
sudo ip netns exec soria-cli ping -c 2 10.30.0.20

Les deux adresses répondent. Tu possèdes maintenant une preuve que le lien, l’adressage local et la communication IP vers les deux serveurs fonctionnent.

03Contrôler la résolution

sudo ip netns exec soria-cli dig @10.30.0.1 intranet.soria.test A +short

10.30.0.21

La réponse DNS est techniquement réussie mais fonctionnellement fausse. Corrige la ligne vers 10.30.0.20, redémarre dnsmasq, puis vérifie à nouveau.

Comprends succès de protocole ≠ donnée correcte

Le serveur répond rapidement, sans timeout et sans NXDOMAIN. Pourtant l’enregistrement pointe vers la mauvaise destination. Le diagnostic doit donc vérifier la valeur, pas seulement le fait qu’une réponse existe.

04Contrôler le transport

Après correction DNS, teste le port :

sudo ip netns exec soria-cli nc -vz 10.30.0.20 8080
sudo ip netns exec soria-web ss -lntp

La sortie serveur révèle 127.0.0.1:8080. Le processus existe, mais aucun socket n’écoute sur 10.30.0.20:8080.

Arrête le serveur et relance-le correctement :

sudo ip netns exec soria-web python3 -m http.server 8080 --bind 10.30.0.20

Valide :

sudo ip netns exec soria-cli nc -vz 10.30.0.20 8080
sudo ip netns exec soria-cli curl -v http://10.30.0.20:8080/

05Ajouter puis diagnostiquer TLS

Crée volontairement un certificat pour le mauvais nom :

openssl req -x509 -newkey rsa:2048 -nodes -days 7 -keyout /tmp/soria-lab.key -out /tmp/soria-lab.crt -subj '/CN=api.soria.test' -addext 'subjectAltName=DNS:api.soria.test'

sudo ip netns exec soria-web openssl s_server -accept 8443 -cert /tmp/soria-lab.crt -key /tmp/soria-lab.key -WWW

Depuis le client :

sudo ip netns exec soria-cli curl -v --cacert /tmp/soria-lab.crt --resolve intranet.soria.test:8443:10.30.0.20 https://intranet.soria.test:8443/

Inspecte le certificat :

openssl x509 -in /tmp/soria-lab.crt -noout -subject -issuer -ext subjectAltName

Le transport TCP et la session TLS peuvent démarrer, mais la validation échoue car le certificat ne couvre pas intranet.soria.test.

Régénère le certificat avec le SAN correct, redémarre s_server et valide avec curl –cacert.

06Utiliser les captures et les journaux au bon moment

Question	Outil	Preuve recherchée
Le paquet quitte-t-il le client ?	`tcpdump`	ARP, SYN, DNS query ou absence de trafic
Le nom pointe-t-il au bon endroit ?	`dig`	serveur interrogé, statut et valeur A
Le processus écoute-t-il ?	`ss`	transport, bind address et port
Le port répond-il ?	`nc`	connexion, refus ou timeout
L’application répond-elle ?	`curl -v`	requête, code HTTP et erreur précise
Le certificat convient-il ?	`openssl`	SAN, émetteur, dates et chaîne

07Rédiger le compte rendu

Symptôme :
Impact :
Chronologie :
Preuves collectées :
Cause 1 :
Correction 1 :
Cause 2 :
Correction 2 :
Cause 3 :
Correction 3 :
Validation finale :
Mesure préventive :

Livrable BookStack

Documente l’incident comme un technicien

décris le symptôme sans proposer immédiatement une cause ;
copie les commandes et les sorties décisives ;
sépare les trois causes : DNS, bind et certificat ;
associe une validation à chaque correction ;
propose une mesure préventive : test de santé, revue DNS ou contrôle de certificat.

Quand BookStack sera relié par SSO, ce format deviendra une page de journal de laboratoire et un élément du portfolio technique.

08Nettoyer

sudo ./module3-services-lab.sh down

✓Ce que tu retiens

Un même symptôme peut cacher plusieurs causes. Le diagnostic progresse par preuves : adressage, résolution, transport, application puis TLS. Chaque correction doit être suivie d’une validation explicite et d’une documentation reproductible.