Mise en œuvre et dépannage

Le cours s'achève là où il devient un métier : devant une machine qui « ne marche pas ». Les huit chapitres précédents ont construit un modèle complet, du signal à l'application. Ce dernier chapitre en fait un outil de travail : configurer une machine, et surtout diagnostiquer une panne — non pas au hasard, mais méthodiquement, en s'appuyant sur la structure en couches qui a été le fil rouge de tout le cours.

C'est le chapitre le plus pratique, et celui où la théorie prouve sa valeur. Vous découvrirez que « je n'ai plus Internet » ne veut presque rien dire — et qu'une poignée de commandes, appliquées dans le bon ordre, transforment cette plainte vague en un diagnostic précis.

Configurer une machine

Pour communiquer sur un réseau IP, une machine a besoin de quatre paramètres, tous rencontrés dans le cours :

Ces quatre paramètres se règlent de deux façons. En automatique, via DHCP (chapitre 8) : c'est le cas par défaut, la machine reçoit tout à la connexion. En manuel (configuration statique), on les saisit à la main — indispensable pour un serveur ou un routeur, qui doit garder une adresse stable. Comprendre ces quatre champs, c'est comprendre ce qui peut manquer : une panne réseau est très souvent l'un d'eux, absent ou erroné.

Les commandes de diagnostic

Cinq commandes suffisent à couvrir l'essentiel du dépannage, et chacune interroge une couche précise :

Deux signaux à savoir lire tout de suite. Une adresse en 169.254.x.x (ou « APIPA ») signifie que la machine n'a pas reçu d'adresse par DHCP : elle s'est auto-attribué une adresse de secours, et le problème est à chercher côté DHCP ou lien. Et un ping 8.8.8.8 qui répond tandis qu'un ping exemple.fr échoue est la signature d'un problème de DNS — le réseau IP fonctionne, seule la résolution de noms est cassée.

Le dépannage couche par couche

Voici la méthode, et la synthèse de tout le cours. Face à une panne, on ne tâtonne pas : on teste les couches de bas en haut, parce que chaque couche dépend de celle du dessous. Le premier test qui échoue localise la panne, et rend inutiles tous les tests au-dessus.

11-2  Le lien est-il up ?              → ip link      (câble branché, Wi-Fi associé)23    Ai-je une IP valide ?            → ipconfig     (pas de 169.254.x.x)33    La passerelle répond-elle ?      → ping passerelle43    Internet répond-il par IP ?      → ping 8.8.8.857    Le DNS résout-il les noms ?      → nslookup exemple.fr67    Le service répond-il ?           → ping/navigateur sur le nom

La logique est implacable, et c'est pourquoi elle marche : inutile de soupçonner le DNS (couche 7) si la machine n'a même pas d'adresse IP (couche 3) ; inutile d'accuser le site distant si la passerelle ne répond pas. En remontant du bas, on élimine méthodiquement, et le premier échec pointe la couche fautive.

L'exemple le plus fréquent illustre toute la puissance de la méthode : ping 8.8.8.8 répond, mais ping exemple.fr échoue. Tout ce qui est en dessous du DNS fonctionne — le lien, l'adresse, la passerelle, le routage mondial. Seul le DNS est en cause. Le symptôme « je n'ai plus Internet » était trompeur : Internet marche parfaitement, c'est l'annuaire qui est en panne. Sans la grille des couches, on aurait redémarré la box, changé le câble, appelé l'opérateur — pour un problème que nslookup localise en une seconde.

Les outils de TP : Packet Tracer et Wireshark

Deux outils accompagnent la pratique, et chacun éclaire une facette du cours.

Cisco Packet Tracer est un simulateur de réseau : on y construit un réseau complet — machines, commutateurs, routeurs, serveurs — et on le configure, sans aucun matériel. Il suffit largement en L1 et évite la lourdeur d'un parc physique. Le TP recommandé est d'y bâtir un petit réseau d'entreprise complet : plusieurs sous-réseaux (chapitre 5), un routeur qui les relie (chapitre 6), un serveur DHCP et un serveur DNS (chapitre 8) — et de le voir fonctionner de bout en bout. Construire soi-même le réseau ancre les chapitres 5 et 6 comme aucun exercice sur papier.

Wireshark est un analyseur de trafic : il capture les paquets réels qui passent sur une interface et les affiche, en couches emboîtées. Le TP le plus formateur est d'y capturer le simple chargement d'une page web et de regarder défiler, dans l'ordre : la requête DHCP (si l'on vient de se connecter), la résolution DNS, la poignée de main TCP en trois temps (chapitre 7), puis la requête HTTP. On voit littéralement l'encapsulation du chapitre 2 — Ethernet contenant IP contenant TCP contenant HTTP — et toute la chorégraphie du chapitre 8. Voir les couches défiler pour de vrai ancre le modèle bien mieux qu'un schéma au tableau.

À vous

Le dernier exercice du cours est sa synthèse. Vous implémentez le diagnostic couche par couche : une machine « n'a plus Internet », vous testez les couches de bas en haut, et le premier échec localise la panne. Vous découvrirez que le problème n'était pas « le réseau » mais le DNS — le réseau IP, lui, fonctionne parfaitement.

C'est l'aboutissement de toute l'année : le modèle en couches, introduit au chapitre 2 comme une idée abstraite, devient ici une méthode de travail qui localise une panne en quelques secondes là où le tâtonnement prendrait des heures.

// Une machine « n'a plus Internet ». Plutôt que de tâtonner, on teste les
// couches DE BAS EN HAUT : chaque test valide une couche, et le PREMIER test
// qui échoue localise la panne. C'est la méthode de dépannage du cours.
//
// On simule l'état (inconnu) d'une machine à diagnostiquer.
const machine = {
  cableConnecte: true,          // couche 1-2 : lien physique/liaison
  adresseIP: "192.168.1.50",   // couche 3 : a-t-on une IP valide (pas 169.254.x) ?
  passerelle: "192.168.1.1",   // couche 3 : passerelle joignable ?
  passerelleRepond: true,
  dnsRepond: false,            // couche 7 : le DNS résout-il les noms ?  <-- panne
  serveurWebRepond: true,      // couche 7 : le serveur distant répond-il ?
};

// Les tests, du plus bas au plus haut. Chacun rend true si SA couche va bien.
const TESTS = [
  { nom: "1-2  lien (câble/Wi-Fi)",  cmd: "ip link",           ok: (m) => m.cableConnecte },
  { nom: "3    adresse IP locale",   cmd: "ipconfig/ifconfig", ok: (m) => m.adresseIP && !m.adresseIP.startsWith("169.254") },
  { nom: "3    passerelle (ping)",   cmd: "ping passerelle",   ok: (m) => m.passerelleRepond },
  { nom: "3    Internet par IP",     cmd: "ping 8.8.8.8",      ok: (m) => m.passerelleRepond },
  { nom: "7    résolution DNS",      cmd: "nslookup exemple.fr", ok: (m) => m.dnsRepond },
  { nom: "7    service web",         cmd: "ping exemple.fr",   ok: (m) => m.dnsRepond && m.serveurWebRepond },
];

// ── À VOUS : le diagnostic couche par couche ────────────────────────────────
// Parcourir les tests DE BAS EN HAUT. S'arrêter au PREMIER qui échoue : c'est
// lui qui localise la panne. Si tout passe, le réseau est sain.
function diagnostiquer(m) {
  for (const t of TESTS) {
    const ok = t.ok(m);
    console.log((ok ? "  OK  " : " ÉCHEC") + " [" + t.nom + "]  (" + t.cmd + ")");
    // à compléter : si un test échoue, afficher le diagnostic et ARRÊTER
    // (return), car les couches du dessus dépendent de celle-ci.
  }
  console.log(">> Tout fonctionne : réseau sain.");
}

diagnostiquer(machine);

Ce que ce cours vous laisse

Vous avez remonté la pile réseau de bout en bout : le signal sur le support (chapitre 3), la trame sur le lien local (chapitre 4), l'adresse et le sous-réseau (chapitre 5), le routage mondial (chapitre 6), le transport fiable ou rapide (chapitre 7), les applications du quotidien (chapitre 8), et enfin la mise en œuvre (ce chapitre).

Trois idées survivront à l'oubli des détails :

• Le découpage en couches (chapitre 2) est l'idée maîtresse : chaque couche offre un service à celle du dessus et ignore le reste. C'est ce qui rend les réseaux évolutifs, interopérables — et diagnosticables.
• L'intelligence est aux extrémités, le réseau reste simple. IP achemine « au mieux » ; c'est TCP, sur les machines aux bouts, qui rétablit la fiabilité. Ce principe de bout en bout est ce qui a permis à Internet de croître sans se réinventer.
• Une panne se localise par couches. Savoir où est un problème, c'est l'avoir à moitié résolu.

Ces réseaux que vous savez maintenant lire sont aussi des surfaces d'attaque — l'ARP qu'on usurpe, le Wi-Fi qu'on écoute, le mot de passe qui voyage en clair. Le cours de cybersécurité de L3 reprendra cette pile du point de vue de l'attaquant et du défenseur ; vous y arriverez en sachant déjà comment chaque couche fonctionne, ce qui est la moitié du chemin.

À retenir