Dépannage réseau et Wireshark

Cinq commandes, une méthode — et l'outil qui montre ce qui circule vraiment sur le câble.

📌

Résumé flash

On dépanne du plus proche au plus lointain : câble, puis switch, puis routeur, puis Internet, puis DNS. ipconfig montre la configuration, ping teste la joignabilité, tracert montre où ça s'arrête. Le TTL du ping révèle le nombre de routeurs traversés. Et quand les commandes ne suffisent plus, Wireshark capture chaque PDU qui passe sur le fil.

🔑 #ipconfig #ping #ICMP #TTL #tracert #netstat #nslookup #flushdns #Wireshark #PDU #capture #latence

01La méthode

🧰 Le principe fondamental

On teste du plus proche au plus lointain. Le premier test qui échoue désigne l'endroit exact de la panne — et tous les tests suivants sont inutiles tant que celui-là n'est pas réparé.

Sauter directement au test le plus lointain (« ça ne marche pas, je ping Google ») ne renseigne sur rien : l'échec peut venir de n'importe où sur le trajet.

Cinq paliers, dans cet ordre. C'est la démarche attendue à l'oral comme en TP.

02ipconfig

La commande ipconfig /all a pour objectif d'afficher la configuration réseau de chaque interface de la machine. C'est l'occasion de vérifier si les paramètres sont corrects et, basiquement, de voir si la machine dispose bien d'une adresse IP sur la carte réseau connectée.

Elle retourne l'adresse IP, le masque de sous-réseau, la passerelle par défaut et le ou les serveurs DNS définis sur chaque carte.

Commande	Effet	Quand l'utiliser
`ipconfig /all`	Toute la configuration réseau	Toujours en premier
`ipconfig /release`	Libérer l'adresse IP obtenue par DHCP	Vérifier un serveur DHCP, résoudre un conflit d'adresses
`ipconfig /renew`	Renouveler l'adresse IP via DHCP	Après un `/release`
`ipconfig /flushdns`	Vider le cache DNS	Problème de résolution lié à un cache obsolète
`ipconfig /displaydns`	Afficher le contenu du cache DNS	Voir ce que la machine a mémorisé

🧰 Ce qu'il faut lire dans ipconfig /all

Windows

Adresse IPv4. . . . . . . . : 192.168.1.45     ← 169.254.x.x = pas de DHCP !
Masque de sous-réseau . . . : 255.255.255.0    ← cohérent avec le plan ?
Passerelle par défaut . . . : 192.168.1.1      ← VIDE = pas de sortie possible
Serveurs DNS. . . . . . . . : 192.168.1.1      ← vide = pas de résolution de noms
Serveur DHCP. . . . . . . . : 192.168.1.1      ← est-ce bien LE nôtre ?
Adresse physique. . . . . . : 00-1A-2B-3C-4D-5E

Quatre anomalies se lisent directement : une adresse en 169.254, une passerelle vide, un DNS vide, ou un serveur DHCP inattendu.

🌍 L'équivalent sous Linux

bash

ip a                     # ≈ ipconfig
ip route                 # la passerelle par défaut
cat /etc/resolv.conf     # les serveurs DNS
dhclient -r && dhclient  # ≈ release puis renew
resolvectl flush-caches  # ≈ flushdns

03ping et le TTL

ping teste la connectivité entre deux machines en envoyant des paquets ICMP (Internet Control Message Protocol). Il mesure également le temps de réponse — le temps nécessaire pour que le paquet émis par la machine A atteigne la machine B.

Ce qu'il permet

Tester la communication entre deux équipements ;
diagnostiquer les problèmes de latence, par la lecture du temps de réponse ;
mesurer la fiabilité d'un réseau à un instant donné ;
identifier la cause d'un ralentissement, s'il y a des pertes de paquets.

Interpréter le résultat

Windows

C:\> ping 1.1.1.1

Réponse de 1.1.1.1 : octets=32 temps=12 ms TTL=54
Réponse de 1.1.1.1 : octets=32 temps=11 ms TTL=54
                     └───┬───┘ └────┬───┘ └──┬──┘
                         │          │        └── durée de vie restante
                         │          └── LATENCE, en millisecondes
                         └── taille du paquet

Statistiques : envoyés = 4, reçus = 4, perdus = 0 (perte 0%)
                                                   └── 0 % = aucune interruption

🧰 Le TTL — l'information qu'on n'exploite jamais assez

TTL signifie Time To Live : la durée de vie du paquet avant sa destruction. Sa valeur initiale est généralement 64 (Linux) ou 128 (Windows), et elle est réduite de 1 à chaque routeur traversé.

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

Exemple : un TTL=54 avec un départ à 64 signifie que le paquet a traversé 10 routeurs. Ce n'est pas étonnant pour 1.1.1.1, un serveur DNS public sur Internet.

À l'inverse, un ping vers un hôte du même segment — deux serveurs du même VLAN — revient avec le TTL intact, puisqu'aucun routeur n'a été traversé.

⚠️ Le TTL trahit le système d'exploitation distant

Un TTL reçu de 54 vient probablement d'un départ à 64 → machine Linux/Unix. Un TTL de 118 vient d'un départ à 128 → machine Windows.

C'est une information de reconnaissance réseau — utile en diagnostic, et c'est aussi la raison pour laquelle certains administrateurs modifient le TTL par défaut de leurs serveurs.

Le ping continu

Par défaut, Windows réalise 4 pings puis s'arrête. Pour un ping continu, utile pour tester une connexion pendant plusieurs minutes :

commandes

ping -t 192.168.1.1        # Windows : continu, Ctrl+C pour arrêter
ping 192.168.1.1           # Linux : continu PAR DÉFAUT
ping -c 4 192.168.1.1      # Linux : limiter à 4
ping -l 1400 8.8.8.8       # Windows : forcer une taille de paquet (test MTU)

Quand l'hôte ne répond pas

Un ping sans réponse ne signifie pas que la machine est éteinte. Cinq causes possibles :

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 est configuré pour ne pas répondre ;
le pare-feu réseau situé entre les deux hôtes bloque le ping ;
le ping porte sur un nom de domaine et le DNS ne parvient pas à le résoudre.

⚠️ Le pare-feu Windows bloque l'ICMP entrant par défaut

Symptôme caractéristique : A ne ping pas B, mais B ping très bien A. Cette asymétrie ne peut venir d'aucun problème réseau — seulement d'un pare-feu.

Le test qui tranche : pinguer dans l'autre sens. Si ça marche, cherchez le pare-feu, pas le câble.

04tracert

tracert — traceroute sous Linux et macOS — détermine le chemin emprunté par les paquets pour atteindre une destination, en listant tous les routeurs intermédiaires.

On l'utilise à la suite d'un ping pour en savoir plus sur un problème de connexion, et pour vérifier des règles de routage — s'assurer que le trafic est bien acheminé par le bon chemin.

Windows

C:\> tracert 8.8.8.8

  1     1 ms     1 ms     1 ms  192.168.1.1          ← la passerelle locale
  2    12 ms    11 ms    12 ms  10.20.30.1           ← le routeur de l'opérateur
  3     *        *        *     Délai d'attente…     ← aucune réponse à ce saut
  4    18 ms    17 ms    18 ms  8.8.8.8              ← la destination

Chaque ligne = un SAUT vers un routeur intermédiaire, avec son temps de réponse.

🧰 Lire un tracert

Les astérisques apparaissent lorsqu'aucune réponse n'est reçue pour l'un des paquets. Cela dépend de la configuration du routeur — beaucoup ne répondent pas volontairement — et n'empêche pas tracert de poursuivre. Une ligne d'astérisques n'est donc pas forcément une panne.
Un temps qui explose à un saut donné, puis redevient normal, signale un routeur occupé qui répond lentement — mais qui achemine correctement. Ce n'est pas non plus une panne.
Le vrai signal d'alarme : la trace s'arrête définitivement à un saut et n'atteint jamais la destination. C'est là que le chemin est coupé.

Par défaut, tracert tente de traduire les adresses IP en noms, ce qui prend du temps. Pour désactiver :

commandes

tracert -d www.microsoft.com     # Windows, sans résolution de noms
traceroute -n 8.8.8.8            # Linux, équivalent
tracert -h 10 8.8.8.8            # limiter à 10 sauts

🧰 Localiser la coupure grâce à tracert

Où ça s'arrête	Ce que cela signifie
Avant la passerelle locale	Problème interne : LAN, sous-réseau, configuration du poste
Juste après la passerelle	Problème de routage sur le routeur, ou de lien opérateur
Plus loin, dans Internet	Coupure chez le fournisseur d'accès ou filtrage extérieur — hors de votre contrôle

C'est tout l'intérêt de la commande : elle transforme un « ça ne marche pas » en « ça s'arrête ici ».

05netstat et nslookup

netstat

netstat fournit une vue de toutes les connexions réseau actives et des ports d'écoute du système. Il aide à identifier les applications qui communiquent, à détecter les connexions indésirables et à surveiller les schémas de trafic.

commandes

netstat -a          # toutes les connexions actives et les ports en écoute
netstat -an         # idem, sans résolution de noms — beaucoup plus rapide
netstat -ano        # Windows : ajoute le PID du processus responsable
netstat -r          # la table de routage

# Linux, l'équivalent moderne
ss -tulpn           # sockets TCP/UDP en écoute, avec le processus

🧰 L'usage qui rend service

« Le port 80 est déjà utilisé, mon serveur web ne démarre pas. » — netstat -ano donne le PID du coupable, que le gestionnaire des tâches traduit en nom d'application.

C'est aussi l'outil qui révèle une connexion sortante inattendue vers une adresse inconnue — le premier indice d'une machine compromise.

nslookup

nslookup interroge les serveurs DNS pour obtenir des informations sur les noms de domaine et les adresses IP. Lorsque des sites deviennent inaccessibles, les problèmes de résolution DNS en sont souvent la cause.

commandes

nslookup www.google.fr             # nom → adresse IP
nslookup 8.8.8.8                   # adresse IP → nom (résolution inverse)
nslookup www.google.fr 1.1.1.1     # interroger UN serveur DNS précis

# Linux, plus détaillé
dig www.google.fr
host www.google.fr

🌍 « Réponse ne faisant pas autorité »

Ce message signifie que l'adresse IP obtenue n'a pas été fournie directement par le serveur DNS qui gère officiellement la zone du domaine demandé, mais par un autre serveur qui a récupéré et mis en cache la réponse.

Ce n'est pas une erreur — c'est le fonctionnement normal du DNS, et c'est ce qui le rend rapide. La mention n'apparaît que pour signaler que l'information peut être légèrement datée.

⚠️ Le test qui isole le DNS en dix secondes

diagnostic

ping 8.8.8.8            répond   → le réseau et le routage fonctionnent
ping www.google.fr      échoue   → le problème est FORCÉMENT le DNS

Dans ce cas : ipconfig /all pour vérifier le serveur DNS configuré, nslookup pour tester la résolution, et ipconfig /flushdns si le cache est en cause.

06Wireshark

Wireshark est un analyseur de protocoles — un analyseur de paquets — utilisé pour dépanner les réseaux, effectuer des analyses, développer des logiciels et des protocoles, et s'informer.

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

C'est devenu le programme standard d'analyse de paquets pour les ingénieurs réseau. Ce logiciel open source est disponible pour Windows, macOS et Linux, et se télécharge sur www.wireshark.org.

💡 Analogie

ping vous dit si la lettre est arrivée. tracert vous dit par quels bureaux de poste elle est passée. Wireshark ouvre l'enveloppe et vous montre ce qui est écrit à l'intérieur — en-tête par en-tête, couche par couche.

C'est pourquoi on ne le sort qu'en dernier : c'est l'outil le plus puissant, mais aussi celui qui demande le plus de travail d'interprétation.

Le vocabulaire de la capture

Terme	Signification
Capture	L'enregistrement du trafic passant par une interface
Filtre de capture	Ce qu'on enregistre — avant l'enregistrement. Syntaxe BPF : `host 192.168.1.10`
Filtre d'affichage	Ce qu'on affiche — après. Syntaxe Wireshark : `ip.addr == 192.168.1.10`
Mode promiscuité	La carte réseau accepte toutes les trames, pas seulement celles qui lui sont destinées

🧰 Les filtres d'affichage à connaître

Wireshark

ip.addr == 192.168.1.10          tout le trafic d'une machine
ip.src == 192.168.1.10           seulement ce qu'elle ÉMET
tcp.port == 80                   le trafic HTTP
icmp                             les ping
arp                              les résolutions d'adresses MAC
dhcp                             le dialogue DORA
dns                              les requêtes de résolution de noms
tcp.flags.syn == 1               les débuts de connexion TCP
http.request                     les requêtes web uniquement

! combiner
ip.addr == 192.168.1.10 && tcp.port == 443

Attention à ne pas confondre : le filtre de capture et le filtre d'affichage n'ont pas la même syntaxe. Le premier utilise host et port, le second ip.addr et tcp.port.

⚠️ Sur un switch, on ne voit que son propre trafic

Un commutateur envoie chaque trame uniquement sur le port concerné. Une capture faite sur un poste ne montre donc que son trafic, plus les diffusions — et non celui des voisins.

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

Ce que Wireshark permet de voir

L'encapsulation en direct : les couches Ethernet, IP, TCP et applicative d'une même trame, dépliées ;
le dialogue DORA complet d'une attribution DHCP ;
une connexion Telnet — mot de passe compris, en clair. La démonstration la plus convaincante de la dangerosité du protocole ;
les retransmissions TCP, signe d'une perte de paquets ;
les requêtes ARP, pour vérifier l'étanchéité des VLAN.

07Les 5 étapes en pratique

Contexte : un réseau local d'entreprise comporte plusieurs postes 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.

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é.

2 — Test de connectivité locale : ping du switch

Depuis un poste client, exécuter ping <adresse_IP_du_commutateur>.

Réponse négative → le client n'arrive pas à joindre le switch au niveau IP. Trois hypothèses :

mauvaise configuration IP de l'un des deux équipements ;
défaut physique ou panne du port switch ou du port PC ;
problème de câblage, ou port désactivé sur le switch.

3 — Test de connectivité interne : ping du routeur et d'un autre poste

Résultat	Interprétation
Ping du switch OK, ping du routeur KO	Problème de configuration ou lien défectueux entre switch et routeur, ou configuration VLAN / sous-réseau incorrecte
Ping d'un autre poste KO	Souci d'isolation, de configuration VLAN, de pare-feu, ou de câble
Ping local OK	Le LAN est fonctionnel
Ping du routeur OK	La sortie vers d'autres réseaux est possible
Ping du poste distant OK	La communication LAN est établie

4 — Test de connectivité externe : ping vers 8.8.8.8

Réussi → la connexion Internet fonctionne.
Échec → effectuer un tracert 8.8.8.8 pour voir où le chemin s'interrompt, et interpréter selon le tableau de la section 4.

5 — Vérification des configurations

Sur le poste client, afficher la configuration IP avec ipconfig ou ip a. Vérifier la cohérence des adresses IP, du masque et de la passerelle avec le plan d'adressage prévu.

❓ Auto-évaluation

Un utilisateur ne peut plus accéder à aucun site web. Vous constatez : ipconfig affiche une adresse correcte, ping 192.168.1.1 (passerelle) répond, ping 8.8.8.8 répond, ping www.google.fr échoue avec « hôte introuvable ». Où est le problème, et quelles trois commandes utilisez-vous ?

Le problème est le DNS, sans aucune ambiguïté possible.

Le raisonnement : la configuration IP est bonne, la passerelle répond (LAN correct), 8.8.8.8 répond (routage et sortie Internet corrects). Seule la résolution de noms échoue — et le message « hôte introuvable », par opposition à « délai d'attente dépassé », le confirme.

Les trois commandes :

diagnostic

1.  ipconfig /all
    → quel serveur DNS est configuré ? Le champ est-il vide ? Est-ce le bon ?

2.  nslookup www.google.fr
    → le serveur DNS répond-il ? Si « timeout », il est injoignable ou en panne.
      nslookup www.google.fr 1.1.1.1   → tester avec un autre serveur pour comparer

3.  ipconfig /flushdns
    → vider le cache DNS local, souvent en cause après un changement d'adresse

Les trois causes les plus fréquentes, dans cet ordre : le cache DNS local est obsolète (résolu par /flushdns), le serveur DNS configuré est en panne (basculer temporairement sur 8.8.8.8 ou 1.1.1.1), ou le DHCP distribue une mauvaise adresse de serveur DNS — auquel cas tous les postes sont touchés, ce qui se vérifie en une question à un collègue.