Accueil/Réseaux & Systèmes /Chapitre 13 /Exercices corrigés

Dépannage réseau — exercices

Lire une sortie de commande, localiser une panne, et l'étude de cas de sous-réseaux entièrement déroulée.

🎯

Ce qui est évalué

Pas la connaissance des commandes — tout le monde sait taper ping. Ce qui rapporte des points, c'est d'interpréter la sortie et de dire ce qu'on en déduit. Une réponse qui commence par « donc le problème est forcément… » vaut toujours mieux qu'une liste de commandes.

01Interpréter ipconfig

1Quatre sorties, quatre diagnostics Facile

Pour chaque sortie, dites ce qui ne va pas et ce que vous vérifiez ensuite.

A)  Adresse IPv4. . . . : 169.254.72.13
    Masque . . . . . . : 255.255.0.0
    Passerelle . . . . : (vide)

B)  Adresse IPv4. . . . : 192.168.1.45
    Masque . . . . . . : 255.255.255.0
    Passerelle . . . . : (vide)
    Serveurs DNS . . . : 192.168.1.1

C)  Adresse IPv4. . . . : 192.168.1.45
    Masque . . . . . . : 255.255.255.0
    Passerelle . . . . : 192.168.1.1
    Serveurs DNS . . . : (vide)

D)  Adresse IPv4. . . . : 192.168.1.45
    Masque . . . . . . : 255.255.0.0
    Passerelle . . . . : 192.168.1.1
    Serveurs DNS . . . : 192.168.1.1

✅ Correction

	Diagnostic	Vérification suivante
A	APIPA — la machine n'a joint aucun serveur DHCP et s'est auto-attribué une adresse en `169.254.x.x`	Câble et LED, VLAN du port, service DHCP, `ip helper-address` si le serveur est distant
B	Passerelle absente : la machine communique dans son LAN mais ne peut pas en sortir	Ping d'un poste voisin (doit marcher), puis ping de `8.8.8.8` (doit échouer). Vérifier la configuration DHCP ou la saisie manuelle
C	DNS absent : l'accès par adresse IP fonctionne, aucun nom ne se résout	`ping 8.8.8.8` réussit, `ping www.google.fr` échoue. Renseigner un DNS
D	Masque incohérent : `/16` sur un réseau prévu en `/24`	Comparer au plan d'adressage. La machine croira que tout `192.168.x.x` est local et n'utilisera jamais la passerelle

⚠️ Le cas D est le plus vicieux

Tout est renseigné, rien n'est vide : au premier coup d'œil, la configuration semble correcte. Mais avec un masque 255.255.0.0 au lieu de 255.255.255.0, la machine considère que 192.168.2.10 est sur son propre réseau. Elle tentera donc de le joindre directement, par ARP, au lieu de passer par la passerelle — et n'obtiendra jamais de réponse.

Symptôme caractéristique : certaines destinations marchent, d'autres non, sans logique apparente. Vérifiez toujours le masque contre le plan d'adressage, pas seulement sa présence.

02Le TTL et le ping

2Que révèle le TTL Moyen

Un ping vers un serveur du même VLAN revient avec TTL=64. Combien de routeurs ont été traversés ?
Un ping vers 1.1.1.1 revient avec TTL=54. Combien de routeurs, et comment le calculez-vous ?
Un ping revient avec TTL=118. Que pouvez-vous en déduire sur la machine distante ?
Un ping vers un poste voisin ne répond pas, alors que ce poste vous ping très bien. Que se passe-t-il ?
Citez cinq raisons pour lesquelles un hôte peut ne pas répondre au ping.

✅ Correction

1. Aucun routeur. Le TTL est intact à sa valeur initiale de 64 : le paquet n'a traversé aucun routeur. C'est logique, les deux machines sont sur le même segment.

2. Dix routeurs.

64 − 54 = 10

La valeur initiale du TTL est généralement 64. Chaque routeur traversé la décrémente de 1. Rien d'étonnant : 1.1.1.1 est un serveur DNS public situé sur Internet.

3. C'est probablement une machine Windows. 118 est proche de 128, la valeur initiale de Windows — 10 routeurs traversés. Un départ à 64 (Linux/Unix) n'aurait pas pu donner 118.

4. Le pare-feu du poste voisin. Cette asymétrie — A ne ping pas B, mais B ping A — ne peut venir d'aucun problème réseau : le chemin est forcément bon dans les deux sens. Windows bloque l'ICMP entrant par défaut.

5. Les cinq raisons du cours :

L'hôte distant est injoignable à cause d'un problème de routage ;
un pare-feu entre les deux machines bloque le ping ;
le pare-feu local de l'hôte distant ne répond pas au ping ;
le pare-feu réseau entre les deux hôtes bloque le ping ;
le ping porte sur un nom de domaine que le DNS ne résout pas.

🧰 La formule et ses deux points de départ

routeurs traversés = TTL initial − TTL reçu

TTL initial	Système	TTL reçu typique
64	Linux, Unix, macOS, équipements réseau	50 à 64
128	Windows	110 à 128
255	Certains équipements Cisco	240 à 255

On identifie le point de départ en arrondissant à la valeur supérieure la plus proche.

⚠️ « Ça ne ping pas » ne veut pas dire « c'est en panne »

C'est l'erreur de raisonnement la plus fréquente. Le ping utilise ICMP, un protocole que beaucoup d'équipements et de pare-feux bloquent volontairement, pour ne pas se signaler.

Un serveur web qui ne répond pas au ping peut très bien servir des pages sans le moindre problème. Avant de conclure à une panne, testez le service lui-même — un navigateur, un telnet sur le port concerné.

03Localiser une coupure

3Trois traces à interpréter Moyen

La passerelle locale est 192.168.1.1. Interprétez chaque trace.

A)  1   *   *   *   Délai d'attente de la demande dépassé.
    2   *   *   *   Délai d'attente de la demande dépassé.
    (arrêt)

B)  1   1 ms   1 ms   1 ms   192.168.1.1
    2   *      *      *      Délai d'attente de la demande dépassé.
    3   *      *      *      Délai d'attente de la demande dépassé.
    (arrêt)

C)  1   1 ms    1 ms    1 ms   192.168.1.1
    2   12 ms   11 ms   12 ms  10.20.30.1
    3   *       *       *      Délai d'attente de la demande dépassé.
    4   18 ms   17 ms   18 ms  8.8.8.8

✅ Correction

	Interprétation	Où chercher
A	Le poste ne joint même pas sa propre passerelle. Le problème est interne et très proche	Câble, port du switch, configuration IP du poste, masque, VLAN
B	La passerelle répond, rien au-delà. La coupure est juste après	Routage sur le routeur, route par défaut absente, ou lien opérateur coupé
C	Tout va bien. La destination est atteinte	Rien à chercher — un routeur intermédiaire refuse simplement de répondre

⚠️ Le cas C piège tout le monde

Les astérisques au saut 3 ne sont pas une panne. Le cours le dit : « ceci dépend de la configuration du routeur et n'empêchera pas tracert de poursuivre l'opération ».

Beaucoup de routeurs sont configurés pour ne pas répondre aux sondes de traceroute — par choix de sécurité ou pour économiser leurs ressources. Ils acheminent pourtant parfaitement le trafic, comme le prouve le saut 4 qui aboutit.

La règle : ce qui compte, c'est de savoir si la trace atteint sa destination. Des astérisques au milieu sont normaux ; des astérisques jusqu'à la fin sont le symptôme.

🧰 Le tableau de lecture du cours

Où le blocage se produit	Responsabilité
Entre le poste et la passerelle locale	Problème interne — LAN, sous-réseau, routeur
Juste après la passerelle	Routage sur le routeur, ou liens opérateur
Plus loin, dans le nuage Internet	Coupure chez le fournisseur d'accès ou filtrage extérieur — hors de votre contrôle

C'est ce tableau qui transforme un « ça ne marche pas » en « le problème est chez l'opérateur, voici la preuve ».

04Étude de cas — 172.177.0.0

4Découpage en quatre sous-réseaux Exigeant

Une entreprise a demandé et reçu l'adresse réseau 172.177.0.0.

Déterminer la classe de ce réseau.
Quel(s) octet(s) représentent la portion réseau ?
Quel(s) octet(s) représentent la portion hôte ?
Quel est le masque par défaut ?
Nombre maximal de machines dans ce réseau ?

Vous souhaitez diviser ce réseau physique en quatre sous-réseaux.

Combien de bits faut-il emprunter à la portion hôte ?
Remplir le tableau des sous-réseaux.
Quel masque de sous-réseau utiliser, en décimal et en binaire ?
Combien de bits reste-t-il pour les hôtes ?
L'hôte A est en 172.177.7.15, l'hôte B en 172.177.222.97. Font-ils partie du même sous-réseau ? Pourquoi ?

✅ Correction

Questions 1 à 5 — le réseau de départ

1. Classe	Classe B — le premier octet vaut 172, donc entre 128 et 191
2. Portion réseau	Les deux premiers octets : `172.177`
3. Portion hôte	Les deux derniers octets
4. Masque par défaut	`255.255.0.0` — soit `/16`
5. Machines maximum	16 bits d'hôte → 2¹⁶ − 2 = 65 534

Question 6 — les bits à emprunter

calcul

on cherche 2ⁿ ≥ 4 sous-réseaux

2¹ = 2   → insuffisant
2² = 4   → EXACTEMENT ce qu'il faut

→ il faut emprunter 2 BITS à la portion hôte

Questions 8 et 9 — le masque et les bits restants

calcul

masque de départ  /16  = 11111111.11111111.00000000.00000000
+ 2 bits empruntés     = 11111111.11111111.11000000.00000000
                                            └┬┘
                                    les 2 bits pris à l'hôte

NOUVEAU MASQUE
  binaire  : 11111111.11111111.11000000.00000000
  décimal  : 255.255.192.0
  CIDR     : /18

BITS RESTANTS POUR LES HÔTES
  32 − 18 = 14 bits  →  2¹⁴ − 2 = 16 382 hôtes par sous-réseau

Question 7 — le tableau des quatre sous-réseaux

Le pas vaut 256 − 192 = 64, et il s'applique au 3^e octet — c'est là que le masque coupe.

N°	Adresse de sous-réseau	Premier hôte	Dernier hôte	Diffusion
1	`172.177.0.0`	`172.177.0.1`	`172.177.63.254`	`172.177.63.255`
2	`172.177.64.0`	`172.177.64.1`	`172.177.127.254`	`172.177.127.255`
3	`172.177.128.0`	`172.177.128.1`	`172.177.191.254`	`172.177.191.255`
4	`172.177.192.0`	`172.177.192.1`	`172.177.255.254`	`172.177.255.255`

Question 10 — A et B sont-ils dans le même sous-réseau ?

Non. Il suffit de regarder le 3^e octet, le seul qui soit coupé par le masque :

vérification

Hôte A : 172.177.  7.15    →  3ᵉ octet = 7    →  7 ∈ [0 ; 63]     → sous-réseau 172.177.0.0
Hôte B : 172.177.222.97    →  3ᵉ octet = 222  →  222 ∈ [192 ; 255] → sous-réseau 172.177.192.0

→ SOUS-RÉSEAUX DIFFÉRENTS : le 1ᵉʳ et le 4ᵉ

Conséquence pratique : A et B ne peuvent pas communiquer directement. Il faut un routeur — ou un commutateur de couche 3 — pour acheminer le trafic entre les deux sous-réseaux.

🧰 La vérification par le ET logique

calcul

Hôte A            172.177.7.15
  3ᵉ octet          7  = 00000111
  masque          192  = 11000000
  ET logique           = 00000000 = 0     →  172.177.0.0

Hôte B            172.177.222.97
  3ᵉ octet        222  = 11011110
  masque          192  = 11000000
  ET logique           = 11000000 = 192   →  172.177.192.0

Le raccourci du pas donne le même résultat en dix secondes, mais le ET logique reste la méthode à montrer si l'énoncé demande de « justifier ».

⚠️ Le piège du 3^e octet

Sur un réseau de classe B, le découpage ne touche pas le dernier octet mais le troisième. Beaucoup appliquent machinalement le pas au 4^e octet — réflexe pris sur les classes C — et obtiennent des sous-réseaux qui n'existent pas.

La règle : le pas s'applique toujours à l'octet coupé, celui du masque qui n'est ni 255 ni 0. Ici 255.255.192.0 : c'est le troisième.

05TP Wireshark

5Capturer et filtrer Moyen

Qu'est-ce que Wireshark capture exactement, et selon quelles spécifications décode-t-il ?
Écrivez le filtre d'affichage pour ne voir que : les pings · le dialogue DHCP · le trafic HTTPS d'une machine précise.
Vous capturez depuis votre poste sur un réseau commuté. Verrez-vous le trafic de votre voisin ? Pourquoi ?
Quelle démonstration faire avec Wireshark pour prouver que Telnet est dangereux ?

✅ Correction

1. Wireshark capture chaque unité de données de protocole (PDU) des flux circulant sur le réseau, et permet de décoder et d'analyser leur contenu conformément aux spécifications RFC ou autres appropriées.

C'est un analyseur de protocoles, open source, disponible pour Windows, macOS et Linux — devenu le standard des ingénieurs réseau.

2. Les filtres d'affichage :

Wireshark

icmp                                     les pings
dhcp                                     le dialogue DORA complet
ip.addr == 192.168.1.10 && tcp.port == 443    le HTTPS d'une machine

3. Non, sauf configuration particulière. Un commutateur envoie chaque trame uniquement sur le port du destinataire. Votre carte réseau ne reçoit donc que :

le trafic qui vous est destiné ;
les diffusions — ARP, DHCP — qui partent sur tous les ports.

Pour voir le trafic d'un autre poste, il faut configurer un port miroir (SPAN) sur le commutateur.

4. La démonstration Telnet :

démonstration

1.  Lancer la capture sur l'interface concernée
2.  Ouvrir une session Telnet vers un équipement, et s'authentifier
3.  Filtre d'affichage :  telnet
4.  Clic droit sur un paquet → « Suivre » → « Flux TCP »

→ le NOM D'UTILISATEUR et le MOT DE PASSE apparaissent EN CLAIR
  (caractère par caractère : Telnet envoie chaque frappe séparément)

5.  Refaire la même chose en SSH  →  filtre :  ssh
→ tout est CHIFFRÉ, illisible

🌍 Pourquoi cette démonstration marque

C'est le moment où l'on comprend pourquoi le cours répète que Telnet envoie « les informations d'authentification, les mots de passe et les commandes en clair ». Lire soi-même son propre mot de passe dans une capture est beaucoup plus convaincant qu'une phrase de diaporama.

C'est aussi la meilleure façon de justifier, à l'oral, pourquoi on configure SSH plutôt que Telnet sur un équipement Cisco.

⚠️ Capture ≠ affichage

Deux filtres différents, deux syntaxes différentes :

	Filtre de capture	Filtre d'affichage
Quand	Avant l'enregistrement	Après
Syntaxe	`host 192.168.1.10`	`ip.addr == 192.168.1.10`
Effet	Ce qui n'est pas capturé est perdu	Tout reste, on ne fait que masquer

En TP, capturez large et filtrez à l'affichage : vous pourrez revenir en arrière si vous vous êtes trompé de piste.

06Dépanner un réseau d'entreprise

6L'exercice d'application du cours Exigeant

Contexte : un réseau local d'entreprise comporte plusieurs postes clients reliés à un commutateur, lui-même connecté à un routeur pour accéder à Internet. Certains utilisateurs rencontrent des problèmes de connexion intermittente ou une perte totale d'accès.

Question : donner les étapes à suivre pour dépanner ce réseau.

✅ Correction

Étape 1 — Vérification physique

Contrôler l'état des câbles (section, usure, mauvaise connexion), des connecteurs et des LED d'activité sur les commutateurs. Remplacer tout câble suspect.

But : s'assurer que le problème ne provient pas d'un défaut matériel facilement observable — câble coupé, débranché, port endommagé.

Étape 2 — Connectivité locale : ping du switch

ping <adresse_IP_du_commutateur>

Réponse négative → le client ne joint pas le switch au niveau IP. Trois hypothèses : mauvaise configuration IP de l'un des deux, défaut physique du port switch ou PC, problème de câblage ou port désactivé.

Étape 3 — Connectivité interne : ping du routeur, puis d'un autre poste

Résultat	Ce qu'on en déduit
Switch OK, routeur KO	Configuration ou lien défectueux entre switch et routeur, ou VLAN / sous-réseau incorrect
Autre poste KO	Isolation, configuration VLAN, pare-feu, ou câble
Ping local OK	Le LAN est fonctionnel
Ping routeur OK	La sortie vers d'autres réseaux est possible
Ping poste distant OK	La communication LAN est établie

Étape 4 — Connectivité externe : ping vers 8.8.8.8

Réussi → la connexion Internet fonctionne.
Échec → tracert 8.8.8.8 pour voir où le chemin s'interrompt, puis interpréter : avant la passerelle (interne), juste après (routeur ou opérateur), plus loin (fournisseur d'accès).

Étape 5 — Vérification des configurations

ipconfig /all sur le poste. Vérifier la cohérence des adresses IP, du masque et de la passerelle avec le plan d'adressage.

🧰 Le cas particulier : « intermittent »

L'énoncé mentionne des problèmes intermittents — c'est le cas le plus difficile, parce que tout fonctionne au moment où l'on teste. Quatre causes classiques, qu'aucune des cinq étapes ne révèle directement :

Conflit d'adresses IP — deux machines partagent la même adresse, et celle qui répond varie. Symptôme typiquement intermittent, souvent dû à une adresse statique non exclue du pool DHCP.
Câble en limite — il fonctionne, puis lâche sous l'effet de la chaleur ou d'une vibration. Un ping -t laissé plusieurs minutes fait apparaître les pertes.
Bail DHCP qui expire sans renouvellement possible — la machine perd son adresse à intervalles réguliers.
Serveur DHCP pirate — une box branchée par un utilisateur répond parfois avant le vrai serveur : certains postes reçoivent alors une mauvaise configuration, d'autres non.

diagnostic de l'intermittent

ping -t 192.168.1.1          laisser tourner 10 minutes, observer les pertes
ipconfig /all                le serveur DHCP est-il bien LE nôtre ?
arp -a                       deux entrées pour la même IP = conflit

Une panne intermittente se diagnostique dans la durée : un test ponctuel qui réussit ne prouve rien.

⚠️ Ce que le correcteur attend vraiment

Pas une liste de commandes, mais une progression justifiée. La phrase qui rapporte des points : « je teste du plus proche au plus lointain, car le premier test qui échoue localise la panne ».

Et pour chaque étape, dire ce qu'on en déduit — pas seulement ce qu'on tape.