TP – Diagnostiquer des pannes injectées
BTS SIO SISR 2e année – Bloc 2 – S13 – binôme : un tape, l'autre lit ; on échange les rôles à chaque panne
Note
But. Tu appliques la méthode de diagnostic à des symptômes réels, tu trouves la cause de trois pannes injectées par l'enseignant sans en connaître la nature, tu corriges, tu vérifies et tu rédiges une fiche d'incident.
Durée : 2 h 35 (parties A à D), plus le bilan. Prérequis : cours S13 lu ; S11.
Note
Comment ce TP fonctionne. Pour chaque panne, tu écris tes hypothèses avant de tester, puis tes tests et leurs résultats. Un bilan de compétences clôt la séance.
Binôme : ____________ / ____________
Le laboratoire
| Machine | Rôle | Adresse |
|---|---|---|
| SRV | Serveur web (Apache) | 192.168.10.10/24 |
| CLI | Poste client | 192.168.10.20/24 |
Sur CLI, le nom `srv.lab.local` désigne SRV (fichier `/etc/hosts`). Le point de départ de chaque panne est la même plainte :
« Le site http://srv.lab.local/ ne s'affiche plus depuis le poste CLI. »
Avant de commencer : vérifie que tout fonctionne (`curl -I http://srv.lab.local/` répond `200 OK`).
Partie A – Lire des symptômes (≈ 30 min)
Pour chaque message obtenu depuis CLI, indique ce qu'il signifie, deux hypothèses, et le premier test que tu ferais.
| # | Message | Sens | Deux hypothèses | Premier test |
|---|---|---|---|---|
| 1 | `curl: (6) Could not resolve host: srv.lab.local` | |||
| 2 | `ping: connect: Network is unreachable` | |||
| 3 | `curl: (28) Connection timed out after 5001 milliseconds` (le ping de l'adresse répond) | |||
| 4 | `curl: (7) Failed to connect … Connection refused` (ou `Couldn't connect to server`) | |||
| 5 | `HTTP/1.1 403 Forbidden` |
Éléments de réponse
| # | Sens | Hypothèses | Premier test |
|---|---|---|---|
| 1 | Le nom n'est pas résolu | Ligne absente de `/etc/hosts`, DNS injoignable | `getent hosts srv.lab.local` |
| 2 | Aucune route vers ce réseau | Adresse ou masque de CLI faux, passerelle absente | `ip -br a`, `ip route` |
| 3 | Les paquets partent, rien ne revient | Pare-feu qui jette le trafic, nom résolu vers une mauvaise adresse | `getent hosts`, puis `curl` sur l'adresse IP ; `tcpdump` côté serveur |
| 4 | La machine répond, le port est fermé | Apache arrêté, Apache écoute sur un autre port | `ss -tlnp` sur SRV |
| 5 | Le service répond mais refuse | Droits du fichier, configuration d'accès | `ls -l` / `namei -l` sur SRV, journal d'erreurs |
Partie B – Diagnostiquer trois pannes (≈ 80 min)
L'enseignant injecte successivement trois pannes, qu'il te communique par le symptôme seulement. Pour chacune, remplis le journal ci-dessous au fur et à mesure. L'ordre des étapes est celui de la méthode.
Journal de diagnostic – panne n° ____
| Étape | Ce que j'écris |
|---|---|
| 1. Symptôme observé (message exact, commande) | |
| 2. Ce qui marche encore (ping, autre accès, autre poste…) | |
| 3. Hypothèses (au moins deux, avant de tester) | |
| 4. Tests effectués (commande → résultat), un à la fois | |
| 5. Cause identifiée (et la preuve) | |
| 6. Correction appliquée | |
| 7. Vérification (commande qui prouve le retour à la normale ; autre chose cassé ?) | |
| Durée du diagnostic |
Reproduis ce tableau pour chaque panne (trois fois).
Règles du jeu.
- Tu ne demandes pas quelle panne c'est ; tu peux demander un indice (noté dans ton journal et décompté).
- Tu n'as le droit de modifier qu'après avoir une hypothèse testée.
- À la fin, tu rends le laboratoire comme tu l'as trouvé (hors panne corrigée).
J'anticipe. Avant la première panne : ordre dans lequel tu comptes tester (liste de trois commandes) : ______________________
Éléments de réponse
Un ordre raisonnable : `curl -v http://srv.lab.local/` (lire le message), `getent hosts srv.lab.local` et `ip -br a` (nom et adresse), puis côté serveur `systemctl is-active apache2` et `ss -tlnp | grep apache`. L'essentiel est d'aller du symptôme vers la cause, pas de relancer des services au hasard.
Partie C – Rédiger la fiche d'incident (≈ 25 min)
Choisis la panne la plus difficile pour toi et rédige sa fiche, avec les rubriques du cours : identification, symptôme, impact, chronologie, cause, correction, vérification, prévention.
| Rubrique | Contenu |
|---|---|
| Identification | |
| Symptôme | |
| Impact | |
| Chronologie (heures) | |
| Cause racine | |
| Correction | |
| Vérification | |
| Prévention (alerte, procédure, changement) |
Je comprends. Quelle différence y a-t-il entre la correction et la prévention ? Donne un exemple. ______________________
Éléments de réponse
La correction rétablit le service (relancer Apache). La prévention vise à ne pas revoir l'incident, ou à le détecter plus tôt : alerte sur le port 80 (S11), vérification après chaque redémarrage, changement revu avant application (S08). Corriger sans prévenir, c'est attendre la prochaine panne.
Partie D – Diagnostic croisé (≈ 20 min)
Échange avec un autre binôme : donne-lui ton journal le plus complet sans la cause. Il doit retrouver la cause à partir du symptôme et de tes tests. Note les informations qui lui ont manqué.
| Ce qui manquait dans mon journal | Ce que j'ajouterai la prochaine fois |
|---|---|
Pour aller plus loin
- Écris une procédure de diagnostic d'une page (« le site ne répond pas ») sous forme d'arbre de décision.
- Dresse la liste des dix commandes que tu veux toujours avoir sous la main.
- Ajoute à la supervision (S11) une alerte qui aurait détecté chacune des pannes.
Retour en entreprise (si ta situation le permet)
- Observer : comment l'entreprise gère-t-elle les incidents ? Existe-t-il des tickets, une base de connaissances ?
- Documenter : un incident réel récent, avec la méthode en sept étapes.
Rendu
Compte rendu PDF, nommé `RENDU-B2A2-S13-NOM.pdf`, contenant : le tableau de la partie A, les trois journaux de diagnostic, la fiche d'incident, le bilan du diagnostic croisé.
Prolongement dans InfraLab (facultatif)
Remonter du symptôme à la cause, puis prioriser quand plusieurs pannes arrivent en même temps.
Le simulateur InfraLab propose des TP guidés sur ce thème : vue TP, choisis le TP. Ils s'ajoutent à la séance (en classe si le temps le permet, sinon en autonomie) ; ils ne remplacent pas la manipulation sur machine réelle ci-dessus.
| TP | Titre | Durée |
|---|---|---|
| 16 | PC déconnecté | 50 min |
| 18 | Switch en panne | 25 min |
| 17 | Serveur arrêté | 40 min |
| 19 | Plusieurs utilisateurs impactés | 60 min |
| 20 | Incident majeur | 50 min |
Note
InfraLab simule : le score ne valide aucune compétence. Exporte le rapport du TP (HTML) et joins-le à ton compte rendu.
Bilan de la séance
Niveau : Non maîtrisé, Maîtrise partielle, Bonne maîtrise ou Excellente maîtrise, ou Non évalué.
| Compétence du référentiel | Ce que j'ai fait dans cette séance | Niveau |
|---|---|---|
| B2.3 – Exploiter, dépanner et superviser une solution d'infrastructure réseau |
Note
Les codes sont ceux du référentiel.
Je sais faire, sans aide :
- Appliquer la méthode : symptôme, hypothèses, test, cause, correction, vérification ;
- Distinguer « refusé », « délai dépassé », « 403 » et « nom non résolu » ;
- Utiliser `ip`, `ss`, `curl -v`, `journalctl`, `tcpdump` à bon escient ;
- Ne faire qu'un changement à la fois et vérifier ;
- Rédiger une fiche d'incident avec prévention.
Ce que je dois reprendre : ______________________
Ma question à poser à l'enseignant : ______________________