R10 - Méthode de dépannage réseau
Objectif
Ne plus jamais chercher « au hasard ». On remonte les couches de bas en haut, en testant du plus proche au plus loin.
1. L’arbre de décision
flowchart TD A["❌ « Je n'ai pas accès au service »"] --> B{"Lien physique ?<br/>voyant, câble, Wi-Fi"} B -- non --> B1["Câble, port switch shutdown,<br/>carte désactivée"] B -- oui --> C{"ip a / ipconfig :<br/>j'ai une IP correcte ?"} C -- "169.254.x.x / rien" --> C1["DHCP KO : port dans le bon VLAN ?<br/>serveur DHCP ? relais ip helper ?"] C -- "IP dans le mauvais réseau" --> C2["Erreur de config IP / masque"] C -- oui --> D{"ping 127.0.0.1 ?"} D -- non --> D1["Pile réseau de l'OS cassée"] D -- oui --> E{"ping de MA passerelle ?"} E -- non --> E1["VLAN / trunk / sous-interface /<br/>no shutdown / pare-feu local"] E -- oui --> F{"ping d'une IP distante<br/>(ex. 8.8.8.8) ?"} F -- non --> F1["Routage : route par défaut, route RETOUR,<br/>NAT, pare-feu intermédiaire<br/>→ traceroute pour voir où ça coince"] F -- oui --> G{"ping d'un NOM<br/>(ex. google.fr) ?"} G -- non --> G1["DNS : resolvectl / nslookup,<br/>serveur DNS donné par le DHCP"] G -- oui --> H{"Le service répond ?<br/>port ouvert ?"} H -- non --> H1["Service arrêté (systemctl status),<br/>écoute sur 127.0.0.1 seulement,<br/>pare-feu (iptables, pfSense, Windows)"] H -- oui --> I["✅ Problème applicatif :<br/>identifiants, config du logiciel, logs"]
2. La boîte à outils
Linux (Pop!_OS, Arch, Debian)
| Besoin | Commande |
|---|---|
| Mes IP / interfaces | ip -br a |
| Mes routes | ip r |
| Ma table ARP | ip neigh |
| Mon DNS | resolvectl status ou cat /etc/resolv.conf |
| Tester une IP | ping -c 4 192.168.1.1 |
| Chemin vers une destination | traceroute 8.8.8.8 / mtr 8.8.8.8 |
| Résoudre un nom | dig +short google.fr / nslookup google.fr |
| Ports en écoute chez moi | sudo ss -tulpn |
| Tester un port distant | nc -zv 192.168.1.20 22 |
| Tester un site web | curl -I https://exemple.fr |
| Scanner les ports d’une machine (de TON labo uniquement) | nmap -sV 192.168.1.20 |
| Capturer le trafic | sudo tcpdump -i eth0 port 53 |
| Journaux réseau | journalctl -u NetworkManager -e |
Windows
| Besoin | Commande |
|---|---|
| IP, MAC, DNS, passerelle | ipconfig /all |
| Routes | route print |
| Tester un port | Test-NetConnection 192.168.1.20 -Port 3389 |
| Chemin | tracert 8.8.8.8 |
| DNS | nslookup google.fr / Resolve-DnsName google.fr |
| Vider le cache DNS | ipconfig /flushdns |
| Ports en écoute | netstat -ano |
Cisco
show ip interface brief · show vlan brief · show interfaces trunk · show ip route · show standby brief · show spanning-tree · show mac address-table - détails dans R09 - Cisco IOS - aide-mémoire.
3. Bonnes pratiques
- Reproduire le problème et noter le message d’erreur exact.
- Une seule modification à la fois, puis retester.
- Comparer avec une machine qui fonctionne (même VLAN, même config).
- Regarder les journaux (
journalctl, Observateur d’événements, logs pfSense). - Documenter la cause et la solution (ticket GLPI → SV04 - GLPI et gestion de parc (ITIL)).
Dans Packet Tracer, passe en mode Simulation : tu vois exactement à quel équipement le paquet meurt.