Appliquer la méthode couche par couche (physique → application)
Maîtriser les commandes de diagnostic : ping, traceroute, nslookup, netstat, tcpdump
Résoudre 3 scénarios de panne progressifs en appliquant la démarche
1
La méthode couche par couche
Face à une panne réseau, l'erreur classique est de sauter directement à la couche applicative. La démarche correcte part toujours de la couche la plus basse. Cliquez sur chaque nœud de décision pour explorer les chemins de diagnostic.
Symptôme : je n'arrive pas à accéder à un site web
↓
① ping 8.8.8.8 répond ?
Cliquez pour voir les deux chemins →
✗ NON
Couche 1/2/3 : Physique / IP
Vérifier le câble ou le Wi-Fi. Lancer ipconfig (Windows) / ifconfig (Linux) pour confirmer qu'une IP valide est attribuée. Vérifier la passerelle par défaut. En DHCP : ipconfig /release && ipconfig /renew.
✓ OUI
Couche 3 OK : La connectivité IP vers Internet fonctionne. Le problème est au-dessus. Continuer l'investigation vers DNS ou TCP.
↓ Si OUI
② ping www.example.com répond ?
Cliquez pour voir les deux chemins →
✗ NON
Couche 7 : DNS
La résolution de nom échoue. Confirmer avec nslookup www.example.com. Tester avec un autre résolveur : nslookup www.example.com 8.8.8.8. Si ça marche, c'est votre DNS configuré qui est en faute.
✓ OUI
DNS OK : La résolution de nom fonctionne correctement. L'IP du serveur est atteinte par ping. Le problème est plus haut : TCP ou applicatif.
↓ Si OUI
③ curl -I https://www.example.com répond ?
Cliquez pour voir les trois cas →
✗ TIMEOUT
TCP port 443 bloqué
Firewall local ou réseau ? Tester : telnet www.example.com 443 ou nc -zv www.example.com 443. Peut aussi indiquer que le serveur est down.
✗ ERREUR TLS
Certificat / TLS
Le TCP fonctionne mais la négociation TLS échoue. Certificat expiré ? Mauvais hostname ? Vérifier avec openssl s_client -connect host:443.
✓ 200 OK
Couche applicative
Le serveur répond correctement. Le problème est dans le navigateur : proxy, extension, cache. Tester en navigation privée ou un autre navigateur.
2
Référence des commandes de diagnostic
Chaque outil cible une couche précise du modèle OSI. Naviguer entre les onglets pour voir des exemples de sortie commentés.
ping : Test ICMP couche 3
Couche 3 : IP
$ping 8.8.8.8PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.64 bytes from 8.8.8.8: icmp_seq=1 ttl=118 time=12.3 ms64 bytes from 8.8.8.8: icmp_seq=2 ttl=118 time=11.8 ms--- ping statistics ---2 packets transmitted, 2 received, 0% packet loss
Points clés
Le TTL (Time To Live) est décrémenté de 1 à chaque routeur traversé (hop). TTL=118 ≈ 10 hops depuis un TTL initial de 128 (Windows) : 128 − 118 = 10 routeurs traversés.
Latence élevée (>200 ms pour un serveur proche) indique un problème sur le chemin réseau.
Sur Windows : ping -t 8.8.8.8 pour un ping continu (Ctrl+C pour arrêter).
traceroute / tracert : Chemin réseau hop par hop
Couche 3 : Routage
$traceroute 8.8.8.8 1 192.168.1.1 1.234 ms (votre box) 2 10.200.0.1 8.567 ms (FAI niveau 1) 3 * * *(routeur qui ne répond pas à ICMP) 4 72.14.215.90 11.123 ms 5 8.8.8.8 12.456 ms
Points clés
* * * = timeout ICMP : ce routeur ne répond pas aux sondes ICMP TTL Exceeded, mais laisse probablement passer le trafic TCP/UDP normalement. Ce n'est pas forcément une panne.
Si la latence saute brutalement entre deux hops (ex : 15ms → 200ms), c'est sur ce segment que le problème se situe.
Sur Windows : commande tracert. Outil avancé : mtr (Linux/Mac) : combine ping + traceroute en temps réel.
"Non-authoritative answer" = réponse servie depuis le cache d'un résolveur intermédiaire (normal). Une réponse authoritative viendrait directement des serveurs NS du domaine.
Pour forcer une résolution fraîche sans cache : dig www.google.com @8.8.8.8 +nocache
dig (Linux/Mac) est plus puissant que nslookup : dig www.google.com +short pour un résultat concis. Affiche aussi le TTL restant en cache.
netstat / ss : État des connexions TCP locales
Couche 4 : TCP
$netstat -tulpnProto Local Address Foreign Address Statetcp 0.0.0.0:443 0.0.0.0:* LISTENtcp 192.168.1.10:443 93.184.216.34:52341 ESTABLISHEDtcp 192.168.1.10:22 10.0.0.5:49821 ESTABLISHED
Points clés
LISTEN = le service est démarré et attend des connexions entrantes sur ce port.
ESTABLISHED = connexion TCP active bidirectionnelle en cours.
TIME_WAIT = fermeture en cours (l'OS attend pour s'assurer que tous les paquets sont bien arrivés). Normal après fermeture d'une connexion. Trop de TIME_WAIT peut indiquer un problème de charge.
Remplaçant moderne (Linux) : ss -tulpn : plus rapide, même syntaxe.
tcpdump / Wireshark : Capture de paquets
Couches 2–7 : Analyse complète
$tcpdump -i eth0 host 8.8.8.8 -n14:32:01 IP 192.168.1.10.52341 > 8.8.8.8.443: Flags [S]← SYN14:32:01 IP 8.8.8.8.443 > 192.168.1.10.52341: Flags [S.]← SYN-ACK14:32:01 IP 192.168.1.10.52341 > 8.8.8.8.443: Flags [.]← ACK
Points clés
[S]=SYN, [S.]=SYN-ACK, [.]=ACK, c'est le 3-Way Handshake TCP visible en capture !
Si on voit [S] partir mais jamais de [S.] revenir = le SYN est envoyé mais le serveur ou un firewall intermédiaire bloque la réponse.
Wireshark : interface graphique de tcpdump, indispensable pour analyser du trafic complexe. Filtre utile : tcp.flags.syn == 1 && tcp.flags.ack == 0 pour ne voir que les initiations de connexion.
3
Scénario 1 : Site web inaccessible
Application guidée de la méthode. Choisissez la bonne action à chaque étape.
🔴 Symptôme
"Le navigateur affiche Impossible d'atteindre ce site."
💡 Conseil : commencez par tester la couche la plus basse (IP) avant les couches supérieures (DNS, TCP).
1
Quelle est la première commande à lancer ?
A
ping www.example.com
B
ping 8.8.8.8
C
traceroute www.example.com
D
nslookup www.example.com
2
ping 8.8.8.8 répond normalement, mais ping www.example.com échoue. Cause probable ?
A
La carte réseau est défaillante
B
Problème DNS : la résolution de nom échoue
C
Port 80 bloqué par le firewall
D
Le serveur web est down
3
nslookup www.example.com échoue. Quelle commande pour tester avec un DNS alternatif ?
A
nslookup www.example.com 8.8.8.8
B
ping 8.8.8.8
C
traceroute www.example.com
D
ipconfig /flushdns
4
Scénario 2 : Connexion lente
Les symptômes de lenteur sont plus subtils à diagnostiquer. Identifiez la cause et la bonne commande à chaque étape.
🟡 Symptôme
"Les pages chargent très lentement, parfois timeout. Tout le reste semble fonctionner."
1
ping 8.8.8.8 répond avec une latence de 350 ms (normale : 15 ms). Quelle est la prochaine action ?
A
Redémarrer la box
B
Lancer traceroute 8.8.8.8 pour identifier le hop lent
C
nslookup pour tester la latence DNS
D
Appeler le FAI directement
2
traceroute montre 3 lignes consécutives * * *, puis le trafic reprend normalement. Diagnostic ?
A
La connexion est coupée à ce hop
B
Ces routeurs refusent ICMP mais laissent passer TCP : comportement normal
C
Il y a une boucle de routage
D
Le câble réseau est défectueux
3
La latence vers 8.8.8.8 est normale (12 ms), mais YouTube et les services Google buffèrent. Cause la plus probable ?
A
Problème DNS
B
Congestion sur le lien vers les CDN Google : problème de peering / QoS
C
Adresse APIPA détectée sur la machine
D
UDP 443 (QUIC/HTTP3) bloqué par le FAI
5
Scénario 3 : Emails refusés
Un cas plus avancé qui mobilise DNS, réputation IP et protocoles SMTP. Appliquez la démarche méthodique.
🔴 Symptôme
"Les emails envoyés depuis notre serveur sont rejetés ou systématiquement marqués spam par les destinataires."
1
Le serveur SMTP distant refuse la connexion avec "550 5.7.1 Message rejected due to policy". Première vérification ?
A
Redémarrer le serveur mail
B
Vérifier si l'IP publique sortante est en liste noire (RBL/blacklist)
C
Changer le port SMTP
D
Désactiver le firewall local
2
L'IP n'est dans aucune blacklist. Les emails continuent d'être rejetés ou marqués spam. Que vérifier ensuite ?
A
Vérifier les enregistrements SPF, DKIM et DMARC dans le DNS
B
Mesurer la vitesse du réseau
C
Vérifier la taille des emails envoyés
D
Vérifier le certificat TLS du serveur SMTP
3
Le SPF existe et est correct, mais DKIM est absent. Quel est l'impact concret ?
A
Les emails sont chiffrés : leur contenu est protégé
B
Les emails peuvent passer en spam car leur intégrité ne peut pas être vérifiée
C
Le port 25 sera bloqué automatiquement
D
Les emails seront perdus en transit
6
Arbre de décision rapide
Référence synthétique : quelle commande pour quel symptôme ? À mémoriser ou conserver sous la main.
🔴 Réseau inaccessible
↓
ping 8.8.8.8
Test IP pur sans DNS : valide la couche 3
🔴 Nom de domaine non résolu
↓
nslookup / dig
Test DNS : force un résolveur alternatif si besoin
🟡 Lenteur / timeout inexpliqué
↓
traceroute / mtr
Localise le hop problématique sur le chemin
🔴 Service applicatif inaccessible
↓
telnet / nc IP port
Teste la connexion TCP sur un port précis
🔵 Quels ports sont ouverts ?
↓
netstat -tulpn / ss
Liste les sockets TCP/UDP actifs et en écoute
🟣 Analyser un problème complexe
↓
tcpdump / Wireshark
Capture complète : voit tout, couches 2 à 7
La méthode gagnante : toujours partir de la couche la plus basse. Si la couche 3 (IP) ne fonctionne pas, inutile de déboguer DNS ou TCP. Chaque test doit isoler UNE variable : ne testez pas www.example.com quand vous voulez tester la connectivité IP : utilisez une adresse IP directement.