Guide d’utilisation des outils de diagnostic réseau

Vue d’ensemble

Cet article présente une approche systématique pour identifier les causes des problèmes de communication dans un environnement Windows Server, à l’aide de commandes standard et d’outils PowerShell. Les sujets abordés incluent la vérification ICMP, les tests de ports TCP, la résolution DNS et l’analyse des journaux.

Notation des variables

Les valeurs dépendantes de l’environnement sont indiquées ci-dessous. Remplacez-les selon votre configuration réelle.

Variable Exemple Description
<<TARGET_HOST>> 192.168.10.1 Nom d’hôte ou adresse IP de la cible
<<PORT_NUMBER>> 443 Numéro de port TCP utilisé par l’application
<<LOG_PATH>> C:\Logs\netdiag.txt Emplacement du fichier journal de sortie

Étape 1 : Vérification de la connectivité ICMP (ping)

Vérifie l’accessibilité du réseau au niveau de la couche IP.

ping <<TARGET_HOST>>

Si aucune réponse n’est reçue, vérifiez :

  • Si Windows Defender Firewall bloque ICMP
  • Si l’hôte cible est en ligne
  • Si la table de routage (route print) est correcte

Remarque : Si les réponses ICMP sont désactivées, effectuez un test de connectivité TCP.


Étape 2 : Vérification du chemin (tracert)

Permet de déterminer à quel saut le trafic est interrompu.

tracert <<TARGET_HOST>>

Étape 3 : Test de connectivité TCP (Test-NetConnection)

Vérifie si la communication au niveau de l’application peut être établie.

Test-NetConnection -ComputerName <<TARGET_HOST>> -Port <<PORT_NUMBER>>

Principaux champs de sortie :

Champ Description
TcpTestSucceeded Indique si la connexion TCP a réussi
PingSucceeded Indique si la vérification ICMP a réussi
RemoteAddress Adresse IP résolue de la cible
SourceAddress Adresse IP source utilisée

Astuce : Si le DNS est instable, utilisez directement l’adresse IP.


Étape 4 : Vérification de l’état des sessions TCP (netstat / Get-NetTCPConnection)

Affiche les connexions TCP actives et les ports en écoute.

Avec netstat

netstat -ano | findstr "<<PORT_NUMBER>>"

Options :

  • -a : affiche toutes les connexions et ports d’écoute
  • -n : affiche les adresses et ports sous forme numérique
  • -o : affiche l’ID du processus

Identifier le processus correspondant :

tasklist /FI "PID eq <<PID_NUMBER>>"

Avec PowerShell

Get-NetTCPConnection -State Established |
  Select-Object LocalAddress, LocalPort, RemoteAddress, RemotePort, State, OwningProcess
Get-NetTCPConnection | Where-Object { $_.LocalPort -eq <<PORT_NUMBER>> }

Un grand nombre d’états SYN_SENT ou TIME_WAIT peut indiquer des connexions interrompues ou trop fréquentes.


Étape 5 : Vérification de la résolution DNS (nslookup / Resolve-DnsName)

Vérifie si la résolution de noms fonctionne correctement.

nslookup <<TARGET_HOST>>

Analyse détaillée avec PowerShell :

Resolve-DnsName <<TARGET_HOST>> -Type A

Interroger un serveur DNS spécifique :

Resolve-DnsName <<TARGET_HOST>> -Type A -Server 8.8.8.8

Remarque : En environnement IPv6, utilisez -Type AAAA.


Étape 6 : Dépannage avancé

Activer le journal du pare-feu

Si la communication est bloquée, activez la journalisation du pare-feu pour analyse.

Set-NetFirewallProfile -Profile Domain,Public,Private `
  -LogAllowed True -LogBlocked True `
  -LogFileName "C:\Windows\System32\LogFiles\Firewall\pfirewall.log" `
  -LogMaxSizeKilobytes 32767

Par défaut, la taille maximale du journal est de 1 Mo ; l’augmenter facilite l’analyse.

Vérification de la table ARP (problèmes de couche 2)

arp -a

Des doublons ou incohérences d’adresses MAC peuvent indiquer un cache de commutateur ou de carte réseau virtuelle corrompu.


Conclusion

La plupart des pannes réseau peuvent être diagnostiquées en cinq étapes :
ICMP → Route → TCP → DNS → Journalisation

En combinant les outils intégrés ping, tracert, netstat et les cmdlets PowerShell Get-NetTCPConnection, Resolve-DnsName et Test-NetConnection, vous pouvez effectuer un dépannage réseau efficace, structuré et reproductible sous Windows Server.