Dépannage réseau et Wireshark — QCM

1Pourquoi teste-t-on du plus proche au plus lointain plutôt que l'inverse ?

Câble → switch → routeur → Internet → DNS. Chaque palier suppose le précédent réparé, donc le premier échec localise la panne et tous les tests suivants deviennent inutiles. Commencer par « je ping Google » ne renseigne sur rien : l'échec peut venir de n'importe où sur le trajet.

2ipconfig /all affiche une adresse en 169.254.12.7. Qu'est-ce que cela indique ?

169.254.x.x est l'adresse que Windows s'attribue tout seul quand aucun serveur DHCP ne lui a répondu. La machine a donc une adresse — c'est pourquoi rien ne semble cassé — mais elle ne parle à personne. Les trois autres anomalies qui se lisent dans ipconfig /all : passerelle vide, DNS vide, serveur DHCP inattendu.

3Un ping vers un serveur revient avec TTL=54. Combien de routeurs le paquet a-t-il traversés ?

Le TTL part généralement de 64 (Linux) ou 128 (Windows) et perd 1 à chaque routeur traversé. 64 − 54 = 10 sauts. Au passage, le même calcul trahit le système distant : un TTL reçu de 118 vient d'un départ à 128, donc d'une machine Windows.

4Le poste A ne ping pas le poste B, mais B ping très bien A. Que cherche-t-on ?

Cette asymétrie ne peut venir d'aucun problème réseau : un câble coupé ou un mauvais masque casse la communication dans les deux sens. Seul un filtrage explique qu'un sens passe et pas l'autre — et le pare-feu Windows bloque l'ICMP entrant par défaut. Le test qui tranche est justement de pinguer dans l'autre sens.

5Un tracert affiche une ligne d'astérisques au saut 3, puis atteint la destination au saut 4. Que conclure ?

Beaucoup de routeurs sont configurés pour ne pas répondre aux sollicitations de tracert, et cela n'empêche pas la trace de poursuivre. Le vrai signal d'alarme, c'est la trace qui s'arrête définitivement à un saut et n'atteint jamais la destination. Un temps qui explose puis redevient normal n'est pas une panne non plus : c'est un routeur occupé qui achemine correctement.

6Quelle commande donne le PID du processus qui occupe déjà le port 80 ?

-a toutes les connexions, -n sans résolution de noms (bien plus rapide), -o le PID du processus responsable — que le gestionnaire des tâches traduit en nom d'application. Sous Linux, l'équivalent moderne est ss -tulpn. C'est aussi la commande qui révèle une connexion sortante inattendue, premier indice d'une machine compromise.

7nslookup répond « Réponse ne faisant pas autorité ». Est-ce une erreur ?

L'adresse a été fournie par un serveur qui l'avait mise en cache, pas par celui qui gère officiellement la zone. C'est le fonctionnement normal du DNS, et c'est ce qui le rend rapide. La mention signale seulement que l'information peut être légèrement datée.

8ping 8.8.8.8 répond, ping www.google.fr échoue. Où est le problème ?

Le réseau, le routage et la sortie Internet sont prouvés par le premier ping. Seule la traduction du nom échoue. Trois commandes suivent, dans cet ordre : ipconfig /all pour voir quel serveur DNS est configuré, nslookup pour tester sa réponse, ipconfig /flushdns pour vider un cache obsolète.

9Quelle est la différence entre un filtre de capture et un filtre d'affichage dans Wireshark ?

Le premier agit avant l'enregistrement et s'écrit en syntaxe BPF : host 192.168.1.10. Le second agit après, en syntaxe Wireshark : ip.addr == 192.168.1.10. Les deux syntaxes se ressemblent assez pour qu'on les confonde, et pas assez pour qu'elles s'échangent.

10Une capture lancée sur un poste relié à un commutateur ne montre pas le trafic des voisins. Pourquoi ?

On ne voit que son propre trafic, plus les diffusions. Pour capturer celui d'un autre poste, il faut un port miroir (SPAN) sur le commutateur, qui recopie le trafic d'un port vers celui de l'analyseur. C'est ce qui rend l'écoute passive difficile sur un réseau commuté, à la différence d'un hub où tout le monde voyait tout.