Vérification par couches OSI

Définition

La vérification par couches OSI est une approche méthodique de dépannage réseau qui consiste à tester chaque couche du modèle OSI de manière séquentielle — généralement du bas vers le haut (bottom-up) — afin d'isoler précisément l'origine d'un problème de connectivité ou de performance.

Contexte

Le modèle OSI fournit un cadre universel de référence pour structurer le diagnostic. Plutôt que de tester au hasard, le technicien vérifie systématiquement chaque couche, ce qui accélère la résolution et évite de confondre symptômes et causes. Cette approche est attendue dans les certifications CCST, CCNA et CompTIA Network+ et constitue une compétence fondamentale en support réseau.

Détails techniques

Couche 1 — Physique

• Vérifier que le câble est branché, que les LEDs (link/activity) sont allumées sur le switch et le NIC.
• Tester le câble avec un testeur de continuité ou un cable tester.
• Vérifier que le port du switch n'est pas administrativement désactivé : show interfaces status.

Couche 2 — Liaison de données

• Confirmer qu'une adresse MAC est apprise sur le port du switch : show mac address-table.
• Vérifier l'état STP du port (forwarding vs blocking) : show spanning-tree interface <id>.
• S'assurer que le VLAN est correctement assigné et que le trunk autorise ce VLAN.

Couche 3 — Réseau

• Vérifier l'adresse IP, le masque et la passerelle par défaut sur l'hôte : ipconfig (Windows) ou ip addr (Linux).
• Tester la connectivité locale avec ping vers la passerelle.
• Vérifier la table de routage du routeur : show ip route.
• Confirmer qu'aucune ACL ne bloque le trafic : show access-lists.

Couche 4 — Transport

• Vérifier que le port TCP/UDP du service est en écoute : netstat -an ou ss -tuln.
• Tester l'ouverture du port avec telnet <ip> <port> ou Test-NetConnection (PowerShell).
• Vérifier qu'un pare-feu local ne bloque pas le flux.

Couches 5-7 — Session, Présentation, Application

• Tester le service applicatif directement (ex. : ouvrir une page web, tenter une connexion SSH).
• Vérifier les logs applicatifs pour des erreurs d'authentification, de certificat ou de configuration.
• Utiliser nslookup ou dig pour confirmer la résolution DNS si le service est accédé par nom.

Approches alternatives

• Top-down : partir de la couche application et descendre ; utile quand le symptôme est clairement applicatif.
• Divide-and-conquer : commencer par la couche 3 (ping) ; si ça fonctionne, monter ; sinon, descendre. Plus rapide dans de nombreux cas pratiques.

Exemple concret

Un utilisateur ne peut plus accéder à un serveur web interne. Démarche bottom-up :

1. Couche 1 : le câble est branché, LED active → OK.
2. Couche 2 : show mac address-table sur le switch montre l'adresse MAC de l'hôte → OK.
3. Couche 3 : ping 10.0.1.10 (serveur) depuis le poste → timeout. ping 10.0.1.1 (passerelle) → OK. On vérifie show ip route sur le routeur : la route vers 10.0.1.0/24 est présente. On vérifie show access-lists : une ACL bloque le trafic HTTP vers 10.0.1.10. Cause trouvée à la couche 3 (ACL).
4. Correction : modifier l'ACL, vérifier que ping et curl vers le serveur fonctionnent, documenter.