Diagnostic réseau : méthode et commandes Windows et Linux

Diagnostiquer une panne réseau, c'est vérifier les couches dans l'ordre, du câble jusqu'à l'application, avec une commande par étape : ipconfig ou ip a pour la configuration, ping pour la connectivité, tracert pour le chemin, nslookup pour le DNS, Test-NetConnection ou nc pour le port du service. Ce chapitre donne la méthode, les commandes Windows et Linux, la lecture de leurs messages et les pannes classiques avec leur solution.

La méthode avant les commandes

Au support, le réflexe de taper des commandes au hasard fait perdre du temps. La méthode tient en cinq temps.

1. Préciser le symptôme. « Internet ne marche pas » ne veut rien dire. Qui est touché (un poste, un service, tout le monde) ? Quoi exactement (un site, tous les sites, les partages, l'imprimante) ? Depuis quand ? Qu'est-ce qui a changé (une mise à jour, un déménagement de bureau, un nouveau matériel) ?
2. Reproduire la panne toi-même, et noter le message d'erreur exact.
3. Tester couche par couche, en partant du bas. Chaque test réussi élimine une famille de causes ; le premier test qui échoue indique où chercher.
4. Changer une seule chose à la fois, puis retester. Sinon tu ne sauras pas ce qui a réparé, ni ce que tu as cassé.
5. Documenter : symptôme, cause, solution, dans le ticket. La prochaine fois, toi ou un collègue gagnerez une heure. C'est aussi ce qu'on attend de toi pour l'E5. Le cours ITIL et gestion des incidents montre comment rédiger ce compte rendu, et le cours GLPI et gestion de parc comment tenir les tickets.

Les commandes essentielles

Les commandes Linux ifconfig, route, arp et netstat appartiennent au paquet net-tools, obsolète et absent des installations récentes de Debian : prends l'habitude de ip et ss. Le cours Linux : administration détaille la configuration réseau de Linux, le cours Scripts PowerShell et Bash montre comment automatiser ces tests.

Lire ipconfig /all

Carte Ethernet Ethernet :
   Suffixe DNS propre à la connexion. . . : sorbier.example
   Adresse physique . . . . . . . . . . . : 3C-52-82-4A-10-7E
   DHCP activé. . . . . . . . . . . . . . : Oui
   Adresse IPv4. . . . . . . . . . . . . .: 192.168.10.70(préféré)
   Masque de sous-réseau. . . . . . . . . : 255.255.255.192
   Bail obtenu. . . . . . . . . . . . . . : lundi 26 octobre 2026 08:02:11
   Bail expirant. . . . . . . . . . . . . : mardi 3 novembre 2026 08:02:11
   Passerelle par défaut. . . . . . . . . : 192.168.10.126
   Serveur DHCP . . . . . . . . . . . . . : 192.168.10.177
   Serveurs DNS. . . . . . . . . . . . .  : 192.168.10.177

À vérifier, dans l'ordre : une adresse dans le bon réseau (pas de 169.254), un masque cohérent avec le plan d'adressage, une passerelle dans le réseau de l'adresse, le bon serveur DHCP (pas un serveur pirate) et le DNS interne. « (préféré) » signifie que l'adresse est valide ; « (dupliqué) » signale un conflit d'adresse.

Lire les réponses de ping

ping envoie des requêtes ICMP Echo et affiche les réponses. Les messages d'échec ne disent pas tous la même chose.

Options utiles : ping -t (Windows, en continu, Ctrl+C pour arrêter), ping -n 10 (Windows) ou -c 10 (Linux) pour le nombre de requêtes, ping -4 ou -6 pour forcer la version d'IP.

Lire un traceroute

C:\> tracert -d 8.8.8.8
Détermination de l'itinéraire vers 8.8.8.8 avec un maximum de 30 sauts.
  1    <1 ms    <1 ms    <1 ms  192.168.10.126
  2     1 ms    <1 ms    <1 ms  192.168.10.193
  3     3 ms     2 ms     3 ms  203.0.113.1
  4     *        *        *     Délai d'attente de la demande dépassé.
  5     9 ms     8 ms     9 ms  192.0.2.45
  …
 11    11 ms    10 ms    11 ms  8.8.8.8
Itinéraire déterminé.

Chaque ligne est un routeur, avec trois mesures de temps. Ici : le switch de cœur (saut 1), le pare-feu (2), le routeur de l'opérateur (3), puis Internet. Une ligne d'étoiles au milieu d'un trajet qui aboutit n'est pas une panne : ce routeur ne répond simplement pas aux paquets dont le TTL expire. Une suite d'étoiles jusqu'au bout montre où le trafic s'arrête. L'option -d (Windows) ou -n (Linux) évite de résoudre chaque adresse en nom, ce qui accélère beaucoup la commande. pathping (Windows) et mtr (Linux) combinent traceroute et statistiques de perte sur chaque saut.

Tester le service lui-même

Le ping passe, le nom se résout, mais l'application ne répond pas : teste le port.

PS C:\> Test-NetConnection srv-gestion -Port 443

ComputerName     : srv-gestion
RemoteAddress    : 192.168.10.179
RemotePort       : 443
InterfaceAlias   : Ethernet
SourceAddress    : 192.168.10.70
TcpTestSucceeded : True

TcpTestSucceeded : False signifie que la connexion TCP n'aboutit pas : le service est arrêté ou n'écoute pas sur cette interface (vérifie avec ss -tlnp sur le serveur), ou un filtrage bloque le port : le pare-feu du serveur, ou l'équipement qui route entre les VLAN (ACL d'un switch de niveau 3, règles d'un pare-feu). Si le port répond mais que l'application renvoie une erreur, la couche réseau est hors de cause : regarde les journaux de l'application, le certificat, les identifiants. curl -v montre tout l'échange, de la connexion TCP à la réponse HTTP.

Tester le MTU

Quand de petites requêtes passent mais que de gros transferts se bloquent, souvent à travers un VPN, teste la taille maximale d'un paquet qui passe sans fragmentation. On envoie un ping avec le drapeau « ne pas fragmenter » et une taille de données donnée ; 1 472 octets de données + 8 d'en-tête ICMP + 20 d'en-tête IP = 1 500 octets, le MTU d'Ethernet.

Windows :  ping -f -l 1472 10.30.1.161
Linux   :  ping -M do -s 1472 10.30.1.161

Si la réponse est une erreur indiquant que le paquet devrait être fragmenté, procède par dichotomie : essaie 1 400 ; si ça passe, remonte (1 450, 1 430…), sinon descends (1 350…), jusqu'à trouver la plus grande taille qui passe : le MTU du chemin est cette taille + 28. Un MTU de chemin inférieur à 1 500 est normal à travers un tunnel ; ce qui ne l'est pas, c'est qu'un pare-feu bloque les messages ICMP qui permettent aux machines de le découvrir seules.

Les pannes classiques

Le ticket n° 13 de la base de Sorbier, « Lenteurs réseau à l'entrepôt », dont la seule intervention note « Commutateur de l'entrepôt redémarré » alors que le ticket reste en cours, entre dans la dernière ligne : un redémarrage vide la table MAC et soulage le switch, mais si la cause est une boucle ou une inondation, la panne reviendra. Un bon technicien ne s'arrête pas au redémarrage ; il cherche la cause et la note dans le ticket.

Exercices

  1    <1 ms    <1 ms    <1 ms  192.168.10.126
  2     1 ms     1 ms     1 ms  192.168.10.193
  3     *        *        *     Délai d'attente de la demande dépassé.
  4     *        *        *     Délai d'attente de la demande dépassé.
  …
 30     *        *        *     Délai d'attente de la demande dépassé.

Adresse IPv4. . . . . . . . . . . . . .: 192.168.10.140
Masque de sous-réseau. . . . . . . . . : 255.255.255.0
Passerelle par défaut. . . . . . . . . : 192.168.10.158
Serveurs DNS. . . . . . . . . . . . .  : 192.168.10.177