TIP 3.6 – Vérifier la connectivité avec les outils de diagnostic

Lorsqu’un utilisateur indique :

"Je n'ai plus de réseau."

cela peut correspondre à de nombreuses situations différentes :

• absence de liaison physique ;
• mauvaise adresse IP ;
• DHCP indisponible ;
• passerelle inaccessible ;
• problème DNS ;
• filtrage réseau ;
• serveur indisponible ;
• service applicatif arrêté.

Le rôle du technicien n’est donc pas de lancer des commandes au hasard, mais de suivre une méthode de diagnostic progressive.

1. Commencer par définir le problème

Avant toute commande, il faut préciser le symptôme.

Par exemple :

"Je n'ai pas Internet."

"Je n'accède plus au serveur de fichiers."

"L'application métier ne démarre plus."

"Le Wi-Fi est connecté mais rien ne fonctionne."

"L'imprimante réseau est inaccessible."

Ces phrases ne décrivent pas forcément la même panne.

2. Une méthode de diagnostic progressive

Une démarche simple consiste à tester du plus proche vers le plus éloigné :

1. Interface réseau
        ↓
2. Configuration IP
        ↓
3. Pile TCP/IP locale
        ↓
4. Réseau local
        ↓
5. Passerelle
        ↓
6. Réseau distant
        ↓
7. DNS
        ↓
8. Port / service demandé

Cette méthode permet d’identifier plus rapidement à quel niveau apparaît la panne.

3. Vérifier l’état de la carte réseau

Avec PowerShell :

Get-NetAdapter

Exemple :

Name       Status          LinkSpeed

Ethernet   Up              1 Gbps
Wi-Fi      Disconnected    0 bps

Cette commande permet notamment de vérifier :

• le nom de l’interface ;
• son état ;
• sa vitesse de liaison ;
• son adresse MAC.

4. Lire la configuration IP

La commande classique est :

ipconfig /all

Elle permet de consulter notamment :

• l’adresse IPv4 ;
• le masque ;
• la passerelle ;
• les serveurs DNS ;
• le serveur DHCP ;
• l’adresse MAC ;
• les informations du bail DHCP.

Version PowerShell

Get-NetIPConfiguration

Elle offre une vue plus synthétique.

5. Vérifier l’adresse obtenue

Une configuration cohérente pourrait être :

IPv4       : 192.168.10.25
Masque     : 255.255.255.0
Passerelle : 192.168.10.1
DNS        : 192.168.10.10

Une adresse comme :

169.254.71.25

constitue en revanche un indice important si le poste est censé obtenir sa configuration par DHCP.

Il faut alors examiner notamment :

liaison
DHCP
VLAN
configuration réseau

6. Tester la pile TCP/IP locale

La première adresse que l’on peut tester est :

127.0.0.1

Commande :

ping 127.0.0.1

Cette adresse correspond à la boucle locale.

Elle permet de vérifier le fonctionnement de la pile TCP/IP locale.

7. Tester l’adresse du poste

Tu peux ensuite tester l’adresse IPv4 locale du poste.

Exemple :

ping 192.168.10.25

Ce test reste local à la machine.

Il ne garantit pas encore que la communication avec le réseau fonctionne.

8. Tester la passerelle

La passerelle constitue un test important.

Exemple :

ping 192.168.10.1

Si la passerelle répond, cela constitue un indice que :

• l’interface fonctionne ;
• la liaison locale fonctionne ;
• le poste communique avec au moins un équipement du LAN.

Mais une absence de réponse ne prouve pas automatiquement que la passerelle est hors service.

9. Limite importante de ping

ping utilise le protocole ICMP.

Certains équipements ou pare-feu peuvent volontairement ne pas répondre aux requêtes ICMP.

Par conséquent :

Ping réussi
→ communication ICMP fonctionnelle

Ping échoué
→ ne prouve pas à lui seul que la machine est indisponible

10. Tester une ressource distante par adresse IP

Supposons qu’un serveur possède :

192.168.20.15

Tu peux tester :

ping 192.168.20.15

Si le serveur est situé sur un autre réseau, la communication passe généralement par un équipement de routage.

PC
 │
 ▼
Switch
 │
 ▼
Passerelle
 │
 ▼
Réseau distant
 │
 ▼
Serveur

11. Tester par adresse IP puis par nom

Une technique particulièrement utile consiste à tester :

Adresse IP

puis

Nom DNS

Exemple :

ping 192.168.20.15

puis :

ping srv-fichiers.entreprise.local

Si l’adresse IP fonctionne mais pas le nom, il faut examiner la résolution DNS.

12. nslookup

La commande :

nslookup srv-fichiers.entreprise.local

permet d’interroger le DNS.

Elle peut afficher :

Serveur : dns01.entreprise.local
Address : 192.168.10.10

Nom : srv-fichiers.entreprise.local
Address : 192.168.20.15

Tu peux ainsi contrôler que le nom est bien résolu.

13. Resolve-DnsName

PowerShell propose :

Resolve-DnsName srv-fichiers.entreprise.local

Cette commande permet d’obtenir des informations détaillées sur la résolution DNS.

Exemple :

Name       : srv-fichiers.entreprise.local
Type       : A
IPAddress  : 192.168.20.15

14. Tester un site Internet par IP et par nom

Si un utilisateur indique qu’Internet ne fonctionne pas, tu peux chercher à distinguer :

problème de routage

ou

problème DNS

La logique est :

Accès IP impossible
→ problème potentiel de connectivité

Accès IP possible
mais résolution de noms impossible
→ examiner DNS

Il faut toutefois rester prudent avec les tests vers des services publics, car certains peuvent bloquer certaines formes de diagnostic.

15. tracert

La commande :

tracert destination

permet d’observer le chemin emprunté vers une destination IP.

Exemple :

tracert 192.168.20.15

ou :

tracert www.microsoft.com

Résultat simplifié :

1    192.168.10.1
2    10.20.0.1
3    192.168.20.15

Chaque ligne représente un saut réseau identifié lorsque l’équipement répond aux requêtes utilisées par l’outil.

16. Pourquoi utiliser tracert ?

tracert peut aider à déterminer jusqu’où les paquets progressent.

Par exemple :

PC
 │
 ▼
Passerelle       OK
 │
 ▼
Routeur site     OK
 │
 ▼
Routeur distant  ?
 │
 ▼
Serveur

Si le chemin s’interrompt, cela peut orienter le diagnostic.

* * *

17. pathping

Windows fournit également :

pathping destination

Cette commande combine des informations proches de :

ping
+
tracert

Elle peut aider à observer :

• le chemin ;
• certains délais ;
• des statistiques de perte de paquets.

Elle demande plus de temps pour produire son résultat.

18. Test-NetConnection

PowerShell propose un outil particulièrement utile :

Test-NetConnection

Exemple :

Test-NetConnection srv-fichiers

Mais son intérêt principal est de pouvoir tester un port TCP.

19. Tester un port TCP

Supposons qu’une application utilise HTTPS sur le port 443.

Test-NetConnection srv-app -Port 443

Le résultat peut indiquer :

TcpTestSucceeded : True

ou :

TcpTestSucceeded : False

Ce test permet de vérifier si une connexion TCP vers ce port peut être établie.

20. Pourquoi le test de port est-il important ?

Un serveur peut être accessible sur le réseau mais un service particulier peut ne pas l’être.

Exemple :

Serveur joignable
       │
       ├── HTTPS 443      OK
       ├── SMB 445        BLOQUÉ
       └── RDP 3389       BLOQUÉ

La connectivité IP seule ne suffit donc pas pour conclure qu’une application fonctionne.

21. Quelques ports courants

Le fait de connaître les principaux ports aide à réaliser des tests ciblés.

22. arp

La commande :

arp -a

affiche la table ARP connue par le poste.

Exemple :

192.168.10.1     00-11-22-33-44-55
192.168.10.20    34-7d-f6-8a-21-c4

ARP permet notamment d’associer sur un réseau IPv4 local :

adresse IPv4
      ↕
adresse MAC

23. À quoi sert la table ARP en diagnostic ?

Elle peut aider à vérifier si le poste a appris l’adresse MAC d’un équipement local.

Par exemple, après une tentative de communication avec la passerelle, on peut rechercher son entrée dans :

arp -a

Mais l’absence d’une entrée ARP n’est qu’un indice et doit être interprétée avec le reste du diagnostic.

24. La table de routage

Un poste Windows dispose lui aussi d’une table de routage.

Commande classique :

route print

Avec PowerShell :

Get-NetRoute

Cette table indique comment le système doit envoyer les paquets selon leur destination.

25. La route par défaut

Une ligne importante est la route par défaut.

Elle correspond à :

0.0.0.0/0

et indique généralement la passerelle utilisée lorsqu’aucune route plus précise n’existe.

Exemple simplifié :

Destination     Passerelle

0.0.0.0/0       192.168.10.1

26. netstat

La commande :

netstat -ano

permet d’afficher notamment :

• les connexions actives ;
• les ports en écoute ;
• les adresses locales ;
• les adresses distantes ;
• les PID associés.

Exemple :

TCP  192.168.10.25:52144  192.168.20.15:443  ESTABLISHED

27. Get-NetTCPConnection

PowerShell propose une alternative :

Get-NetTCPConnection

Exemple pour filtrer les connexions établies :

Get-NetTCPConnection -State Established

Cette commande peut être utile pour vérifier les connexions TCP ouvertes par une machine.

28. Résoudre un nom ne signifie pas que le service fonctionne

Supposons :

Resolve-DnsName srv-app

retourne correctement :

192.168.20.30

mais :

Test-NetConnection srv-app -Port 443

retourne :

TcpTestSucceeded : False

DNS fonctionne donc, mais le service HTTPS n’est pas accessible depuis ce poste.

Les pistes peuvent être :

• service arrêté ;
• pare-feu ;
• routage ;
• filtrage réseau ;
• port incorrect ;
• application indisponible.

29. Différence entre réseau et application

Il faut distinguer :

Connectivité réseau
        ↓
Accès à la machine
        ↓
Accès au port
        ↓
Fonctionnement de l'application

Un port TCP accessible ne garantit pas non plus que l’application fonctionne correctement sur le plan fonctionnel.

Il confirme seulement que la connexion réseau vers ce port peut être établie.

30. Diagnostiquer un partage réseau

Un utilisateur n’accède plus à :

\\SRV-FICHIERS\COMMUN

Une démarche possible :

1. Résoudre SRV-FICHIERS
        ↓
2. Tester sa connectivité
        ↓
3. Tester TCP 445
        ↓
4. Vérifier le partage
        ↓
5. Vérifier les droits

Par exemple :

Resolve-DnsName SRV-FICHIERS

Test-NetConnection SRV-FICHIERS -Port 445

31. Diagnostiquer une application HTTPS

Une application métier utilise :

https://srv-app.entreprise.local

La démarche peut être :

Resolve-DnsName srv-app.entreprise.local

Test-NetConnection srv-app.entreprise.local -Port 443

Si DNS fonctionne mais que TCP 443 échoue, le problème n’est probablement pas lié à la résolution du nom.

32. Vérifier la configuration complète

Les commandes suivantes donnent une bonne vue initiale :

Get-NetAdapter

Get-NetIPConfiguration

ipconfig /all

Avant d’aller plus loin, vérifie :

interface
IP
masque
passerelle
DNS
DHCP

33. Ne pas vider les caches au hasard

En diagnostic réseau, il est courant de voir des commandes utilisées immédiatement comme :

ipconfig /flushdns

Cette commande vide le cache DNS local.

Elle peut être utile dans certaines situations, mais elle ne doit pas être utilisée comme réflexe systématique sans diagnostic.

34. Cas pratique – Pas de réseau

Un poste affiche :

Get-NetAdapter

Ethernet   Disconnected

35. Cas pratique – APIPA

Un poste affiche :

IPv4 : 169.254.45.10

36. Cas pratique – IP OK mais nom KO

Le test suivant fonctionne :

ping 192.168.20.15

mais :

ping srv-fichiers

échoue.

Resolve-DnsName srv-fichiers

nslookup srv-fichiers

37. Cas pratique – Serveur accessible mais application indisponible

Le serveur répond au ping.

Mais :

Test-NetConnection srv-app -Port 443

retourne :

TcpTestSucceeded : False

38. Cas pratique – tracert incomplet

La commande :

tracert srv-distant

affiche :

1   192.168.10.1
2   * * *
3   192.168.30.1
4   192.168.40.15

39. TP 1 – Diagnostic progressif

"Je n'accède plus au serveur de fichiers."

IP         : 192.168.10.25
Masque     : 255.255.255.0
Passerelle : 192.168.10.1
DNS        : 192.168.10.10

Serveur :
SRV-FICHIERS
192.168.20.15

Get-NetAdapter

Get-NetIPConfiguration

ping 192.168.10.1

ping 192.168.20.15

Resolve-DnsName SRV-FICHIERS

Test-NetConnection SRV-FICHIERS -Port 445

40. TP 2 – Identifier le niveau de panne

Ethernet : Disconnected

IPv4 : 169.254.70.20

ping 192.168.20.15 → OK

Resolve-DnsName srv-app → échec

Resolve-DnsName srv-app → OK

Test-NetConnection srv-app -Port 443
TcpTestSucceeded : False

Quiz – Vérifie tes connaissances