Le diagnostique d'un réseau

Introduction

On va apprendre à diagnostiquer un réseau comme un pro, en utilisant une méthode simple, logique, et surtout efficace : le modèle OSI, de la couche 1 à la couche 7.

Quand Internet ne fonctionne plus, on a tendance à redémarrer la box, débrancher les câbles, ou simplement attendre que ça revienne. Mais en réalité, il existe une méthode structurée qui permet de trouver la cause en quelques minutes. Dans cette vidéo, nous allons parcourir cette méthode ensemble, puis l’appliquer dans un cas pratique Packet Tracer.

Le modèle OSI

Pour diagnostiquer un réseau, il faut penser en couches. Le modèle OSI est composé de sept niveaux, du plus simple au plus complexe.

La couche 1, le physique. La couche 2, la liaison. La couche 3, le réseau. La couche 4, le transport. Les couches 5, 6 et 7, qui concernent la session, la présentation et l’application.

La règle d’or est simple : toujours partir du matériel, puis remonter progressivement jusqu’à l’application.

Un ticket, deux pannes cachées

Chez Enrico78, un ticket vient d'arriver : Sophie, du service commercial, n'a plus accès à Internet depuis ce matin. Le câble est branché, mais Windows signale un conflit d'adresse IP. Et une fois ce conflit réglé, le ping fonctionne… mais toujours pas de navigateur. Notre objectif aujourd'hui : remonter cette panne couche par couche, du câble jusqu'au navigateur, sans jamais deviner.

Le réseau Enrico78

Voici la topologie sur laquelle on travaille : un routeur en 192.168.10.1, un serveur DNS et web en 192.168.10.5, et trois postes sur le même réseau, dont celui de Sophie. C'est ce petit réseau qu'on va diagnostiquer ensemble.

Mise en place du TP

Lien vers le document de packet tracer : Diag-reseau, pour souivre et tester les diagnostiques proposer.

            ! ── Passer en mode privilégié ───────────
            Router> enable
            Router# 

            ! ── Entrer en mode de configuration globale ───────────
            Router# configure terminal
            Router(config)# 

            ! ── Configurer de l'interface gigabitEthernet 0/0 ───────────
            Router(config)# interface fastEthernet 0/0
            Router(config-if)# ip address 192.168.10.1 255.255.255.192
            Router(config-if)# no shutdown
            Router(config-if)# exit
          

Penser en couches, du bas vers le haut

Le principe est simple : chaque couche du modèle OSI dépend de celle du dessous. Si la couche 1, la couche physique, est cassée, inutile d'aller chercher un problème de DNS en couche 7. On avance dans l'ordre, du bas vers le haut, et on ne saute jamais d'étape.

Le signal arrive-t-il physiquement ?

On commence toujours par le plus basique : le signal arrive-t-il physiquement ? On vérifie que le câble est bien branché aux deux extrémités, que le voyant du switch est allumé ou clignote, et si le poste est en Wi-Fi, que la carte réseau est bien activée. Ici, tout est vert : on peut monter d'un étage.

L'interface est-elle bien montée sur le réseau ?

Ensuite, on vérifie que l'interface réseau est bien montée sur le réseau local. Avec la commande ipconfig /all, on regarde si l'interface indique bien « connectée », et on vérifie que l'adresse MAC est cohérente. Là encore, rien à signaler, on continue.

Le piège n°1 : le conflit d'adresse IP

Et voilà notre premier coupable : Sophie et un autre poste, PC-Marc, partagent la même adresse IP, 192.168.10.10. Le réseau ne sait plus à qui livrer les paquets, un peu comme deux maisons avec la même adresse postale. On le confirme avec ipconfig /all et arp -a, puis on corrige en réattribuant une adresse unique à chaque poste, avec ipconfig /release et ipconfig /renew.

Le bon port est-il ouvert ?

Une fois l'adressage réglé, on teste les ports et le pare-feu. Une IP correcte ne garantit pas que le bon port soit ouvert. Avec Test-NetConnection sur le port 80, on vérifie que rien ne bloque la communication. Ici, le port répond, on peut continuer à monter.

Le piège n°2 : « ça ping mais pas Internet »

Et voici le deuxième piège du jour, le plus classique de tous : Sophie arrive à ping son routeur, elle arrive même à ping une adresse comme 8.8.8.8. Mais son navigateur reste désespérément vide. Pourquoi ? Parce que le ping ne teste que la couche 3, la connectivité IP brute. Un navigateur, lui, a besoin de traduire un nom de domaine en adresse IP avant de contacter le site, et cette traduction, c'est le rôle du DNS, en couche 7. Avec nslookup, on découvre que le serveur DNS configuré chez Sophie ne répond pas. On corrige l'adresse DNS, et le site s'affiche enfin. Retenez cette règle : ping qui marche plus Internet qui ne marche pas, c'est neuf fois sur dix un problème de DNS.

Après avoir réglé les deux pièges, voici ce qui devrais être configurer

Un message d'erreur est un indice, pas un mur

Dernier réflexe à avoir : apprendre à lire un message d'erreur au lieu de le fermer par réflexe. Un délai d'attente dépassé pointe vers un problème de routage. Un hôte de destination injoignable pointe vers la passerelle. Un serveur DNS qui ne répond pas pointe vers la configuration DNS. Et une adresse IP en conflit pointe vers un problème d'adressage. Un message d'erreur, ce n'est pas un mur, c'est un indice : il vous dit littéralement à quelle couche chercher.

La check-list en 4 réflexes

Pour résumer toute la méthode en quatre réflexes : d'abord le physique et la liaison, ensuite l'adressage IP, puis les ports et le pare-feu, et enfin les services, en n'oubliant jamais que le ping ne suffit pas pour valider qu'un service fonctionne vraiment.

• 1^er réflexe : vérifer phusiquement câble et liaison
• 2^e réflexe : l'adresse IP des appareils
• 3^e réflexe : vérifier les ports et le par-feu
• 4^e réflexe : les services, exemple le DNS

L'outil de diagnostic interactif

Pour vous entraîner sur d'autres tickets fictifs, j'ai préparé un simulateur interactif sur enrico78.fr. Vous y retrouverez la même méthode par couches, avec d'autres pannes à identifier et à corriger vous-même.

Conclusion

Toujours partir du matériel, et remonter progressivement jusqu'à l'application : c'est le réflexe qui vous fera gagner un temps précieux sur chaque panne réseau.