Accueil/Réseaux, Systèmes & Cybersécurité /Chapitre 15 /Projet · Mission 1

Projet TechShop

Tout le programme réseau de l'année, d'un coup, sur une seule maquette — et un client à qui il faut prouver que ça marche.

📌

Résumé flash

Un magasin, trois pôles métier, un entrepôt distant. On isole les pôles en VLAN, on les fait communiquer par Router-on-a-Stick, on adresse en DHCP centralisé (d'où l'ip helper-address), on rejoint l'entrepôt par routage statique sur un lien /30, on publie le serveur d'inventaire en NAT statique, et l'on referme les flux sensibles par une ACL. Puis on prouve chaque point par une capture.

🔑 #VLAN #802.1Q #trunk #native-vlan #pruning #router-on-a-stick #sous-interface #DHCP #ip-helper-address #route-statique #route-par-défaut #NAT-statique #ACL #recette

01Le cahier des charges

TECHSHOP est un magasin d'informatique qui ouvre. Il faut monter son réseau. Le sujet ne donne pas une liste de commandes à taper : il donne des besoins métier, et c'est à nous d'en déduire la technique. C'est exactement la démarche attendue en E5.

Pôle	Effectif	Enjeu métier	Risque annoncé
VENTE	8 postes	disponibilité pour les transactions clients	interruptions dues aux broadcasts excessifs
ADMIN	6 postes	confidentialité (paie, comptabilité)	fuite de données, non-conformité RGPD
TECH	20 postes	performance pour les tests et la maintenance	ralentissements, délais de service
ENTREPÔT	site distant	joindre le siège	—

🧭 Traduire un besoin métier en décision technique

Chaque risque du tableau désigne sa solution. C'est la lecture qu'attend le jury, et c'est elle qui doit ouvrir le rapport :

Le sujet dit…	…donc on fait
« broadcasts excessifs »	VLAN : découper le domaine de broadcast
« confidentialité », « RGPD »	VLAN + ACL : séparer, puis filtrer ce qui traverse
« accès contrôlé aux serveurs »	ACL — « contrôlé » ne veut pas dire « ouvert »
« site distant »	routage statique sur un lien WAN dédié
« publier le serveur inventaire »	NAT statique : une IP privée ↔ une IP publique
« adressage dynamique »	DHCP — et, si le serveur est dans un autre VLAN, `ip helper-address`

Les trois critères d'acceptation

Le sujet se termine par trois phrases courtes. Ce sont elles qui décident de la note :

🧰 Ce qui sera vérifié, mot pour mot

« IP DHCP cohérentes par VLAN » — chaque poste reçoit une adresse du bon réseau, avec la bonne passerelle et le bon DNS.
« Communication inter-VLAN / entrepôt » — les pings passent dans les deux sens, y compris vers le site distant.
« Accès Internet au serveur inventaire via NAT » — la traduction est active et visible dans show ip nat translation.

Un projet qui fait tout le reste magnifiquement mais rate l'un des trois est un projet incomplet. On commence par sécuriser ces trois points, on embellit après.

💡 Pourquoi ce projet arrive en fin d'année

Regardez les chapitres qu'il convoque : VLAN et trunks, routage statique, DHCP, NAT, configuration Cisco, adressage, dépannage. TechShop n'enseigne rien de neuf : il vérifie que les briques de l'année tiennent ensemble. C'est la différence entre savoir configurer un VLAN et savoir livrer un réseau.

02L'architecture

Deux sites. Au siège, une étoile autour d'un commutateur fédérateur ; à l'entrepôt, un seul commutateur d'accès. Entre les deux, une liaison série dédiée.

Le siège en étoile autour de SW-COEUR ; un seul lien physique porte les trois VLAN jusqu'à R-STICK. L'entrepôt est un réseau d'extrémité, joint par un lien série /30.

Pourquoi une étoile

Chaque équipement a son propre câble vers le commutateur central. Conséquence directe : une panne reste locale. Un câble arraché, un poste en panne, et le reste du magasin continue de vendre.

⚠️ Le défaut de l'étoile, à savoir énoncer à l'oral

Le commutateur central est un point de défaillance unique (SPOF, single point of failure) : s'il tombe, tout le siège tombe. Le jury pose la question — autant avoir la réponse.

Ce qu'on répond : le risque est connu et accepté au regard de la taille de l'entreprise, et se traite par redondance quand le budget le permet — un second commutateur cœur, des liens doublés en EtherChannel, et HSRP pour doubler la passerelle. « Je connais la limite et je sais ce qui la corrige » vaut bien mieux que de prétendre qu'il n'y en a pas.

🔗 Le magasin et ses rayons

Le commutateur cœur, c'est l'allée centrale du magasin ; les commutateurs d'accès sont les rayons. Les VLAN sont des portes entre les rayons : sans porte, personne ne passe d'un rayon à l'autre. Le routeur est le vigile posté à la seule porte existante — tout passage inter-rayon défile devant lui, donc tout passage est contrôlable. C'est précisément ce qui rend l'ACL du chapitre 9 possible.

03Le plan d'adressage

Premier livrable du projet, et le seul qu'on ne peut pas corriger après coup sans tout reconfigurer. On l'écrit avant de toucher au premier équipement.

Zone	Réseau	Masque	Passerelle	Broadcast	Mode
VLAN 10 VENTE	`192.168.10.0/24`	255.255.255.0	192.168.10.1	192.168.10.255	DHCP
VLAN 20 ADMIN	`192.168.20.0/24`	255.255.255.0	192.168.20.1	192.168.20.255	DHCP
VLAN 30 TECH	`192.168.30.0/24`	255.255.255.0	192.168.30.1	192.168.30.255	DHCP
Entrepôt	`192.168.50.0/24`	255.255.255.0	192.168.50.1	192.168.50.255	statique
Lien WAN	`10.0.0.0/30`	255.255.255.252	.1 siège ↔ .2 entrepôt	10.0.0.3	statique
Internet	`203.0.113.0/24`	255.255.255.0	203.0.113.10 (R-STICK)	203.0.113.255	statique

🧰 Le /30 des liaisons point à point

/30 = 255.255.255.252 → 2² − 2 = 2 adresses utilisables

Sur 10.0.0.0/30 : 10.0.0.0 est l'adresse réseau, 10.0.0.1 et 10.0.0.2 sont les deux extrémités, 10.0.0.3 est le broadcast. Exactement deux adresses pour exactement deux routeurs : zéro adresse gaspillée.

Employer un /24 sur ce lien fonctionnerait tout aussi bien — et gâcherait 252 adresses pour rien. Sur un lien entre deux routeurs, le /30 est la norme professionnelle. C'est le raisonnement du chapitre VLSM.

La réservation basse : de .1 à .20

Dans chaque VLAN, les vingt premières adresses sont retirées du DHCP et réservées à l'adressage fixe. Le serveur DHCP ne distribue qu'à partir de .21.

Plage	Usage	Attribution
`.1`	passerelle (sous-interface du routeur)	fixe
`.2` – `.20`	serveurs, imprimantes, matériel à adresse stable	fixe
`.21` – `.254`	postes de travail — 234 adresses	DHCP

⚠️ Un serveur ne prend jamais son adresse en DHCP

Un serveur se joint par son adresse : les clients, les partages, les enregistrements DNS en dépendent. Une adresse qui change au renouvellement du bail casse tout d'un coup. Deux précautions, et il faut les deux :

configurer l'adresse en fixe sur le serveur ;
l'exclure de la plage DHCP, sinon le serveur DHCP peut la proposer à un poste — et deux machines se retrouvent avec la même adresse.

L'oubli du second point donne un symptôme déroutant : tout marche pendant des semaines, puis un jour un portable branché au hasard « vole » l'adresse du serveur de fichiers.

🧠 Auto-évaluation

Le pôle VENTE compte 8 postes et reçoit un /24, soit 254 adresses utilisables. Est-ce un mauvais plan d'adressage ?

Non, c'est le plan imposé par le cahier des charges — et c'est un choix défendable. Mais il faut savoir dire pourquoi.

Au plus juste, avec du VLSM :

Pôle	Besoin	Masque au plus juste	Hôtes
VENTE	8 postes + passerelle	`/28`	2⁴ − 2 = 14
ADMIN	6 postes + 2 serveurs + passerelle	`/28`	2⁴ − 2 = 14
TECH	20 postes + 1 serveur + passerelle	`/27`	2⁵ − 2 = 30

Pourquoi on garde tout de même le /24 : en adressage privé, les adresses ne coûtent rien, et un plan lisible — « le troisième octet est le numéro de VLAN » — se retient, se documente et se dépanne sans table de conversion. Un technicien qui voit 192.168.30.47 sait immédiatement : pôle TECH.

L'économie d'adresses est un vrai sujet sur un plan public, ou sur un réseau qui compte ses sous-réseaux. En interne, la lisibilité gagne presque toujours. Savoir arbitrer entre les deux, c'est ce que le jury écoute.

04La segmentation VLAN

Un VLAN découpe un commutateur physique en plusieurs commutateurs logiques. Deux postes branchés sur le même équipement mais dans deux VLAN différents ne se voient pas — leurs broadcasts ne se croisent jamais. C'est la réponse directe aux deux risques du cahier des charges : les broadcasts du pôle VENTE et la confidentialité du pôle ADMIN.

Cisco IOS — SW-COEUR

configure terminal
 hostname SW-COEUR
 no ip domain-lookup              ← évite l'attente de 30 s sur une faute de frappe

vlan 10
 name VENTE
vlan 20
 name ADMIN
vlan 30
 name TECH
vlan 99
 name native                      ← VLAN natif dédié, sans aucun poste
vlan 999
 name PARKING                     ← où l'on range les ports inutilisés
 exit

Port d'accès ou port trunk

	Port d'accès	Port trunk
Ce qu'on y branche	un poste, un serveur, une imprimante	un autre commutateur, ou le routeur
VLAN transportés	un seul	plusieurs, étiquetés
Étiquette 802.1Q	aucune — l'équipement ignore tout des VLAN	ajoutée à chaque trame, sauf pour le VLAN natif
Commande	`switchport mode access`	`switchport mode trunk`

🔗 L'étiquette 802.1Q, c'est le colis et son bordereau

Sur un port d'accès, le poste envoie un colis nu : le commutateur sait de quel rayon il vient, puisqu'il connaît la prise. Sur un trunk, un seul camion transporte les colis de tous les rayons : il faut coller un bordereau sur chacun — c'est l'étiquette 802.1Q, quatre octets insérés dans la trame — pour que le commutateur d'en face sache où livrer. Le VLAN natif est le seul colis qui voyage sans bordereau.

Cisco IOS — les trunks de SW-COEUR

interface fa0/1                              ← vers R-STICK : il lui faut tout
 switchport mode trunk
 switchport trunk native vlan 99
 switchport trunk allowed vlan 10,20,30,99
 exit

interface fa0/2                              ← vers SW-1 (TECH) : rien d'autre à y passer
 switchport mode trunk
 switchport trunk native vlan 99
 switchport trunk allowed vlan 30,99
 exit

interface fa0/3                              ← vers SW-2 (VENTE + ADMIN)
 switchport mode trunk
 switchport trunk native vlan 99
 switchport trunk allowed vlan 10,20,99
 exit

🧰 Les trois mesures de sécurité du trunk

VLAN natif déplacé en 99. Par défaut, le VLAN natif d'un trunk Cisco est le VLAN 1 — celui où atterrissent tous les ports non configurés. Comme le trafic natif circule sans étiquette, un attaquant qui réussit à injecter une trame doublement étiquetée peut sauter d'un VLAN à l'autre : c'est le VLAN hopping par double tagging. Un VLAN natif dédié et vide ferme la manœuvre.
Filtrage explicite (pruning). allowed vlan 30,99 sur le lien vers SW-1 : le VLAN ADMIN ne descend jamais vers le commutateur du pôle TECH. Ce qui ne circule pas ne peut pas être capturé.
Ports inutilisés en VLAN 999 et éteints. Une prise libre dans un magasin ouvert au public est une porte d'entrée. On la place dans un VLAN « parking » qui ne mène nulle part, et on la coupe.

Cisco IOS

interface range fa0/4-24 , gig0/1-2
 switchport mode access
 switchport access vlan 999
 shutdown
 exit

🔧 Corrigé — le VLAN natif absent d'un côté du trunk

Sur le lien SW-COEUR (fa0/2) ↔ SW-1 (fa0/1), les deux extrémités ne déclarent pas la même liste :

Cisco IOS — l'asymétrie

SW-COEUR, fa0/2 :  switchport trunk allowed vlan 30,99
SW-1,     fa0/1 :  switchport trunk allowed vlan 30        ← le 99 manque

Le VLAN natif reste le 99 des deux côtés : il n'y a donc pas de NATIVE_VLAN_MISMATCH, et aucun message d'erreur n'apparaît. Le lien monte, les postes TECH communiquent, tous les tests passent — l'impact immédiat est nul, précisément parce que le VLAN 99 a été choisi vide.

Pourquoi corriger, alors ? Parce que le jour où le VLAN 99 sert à quelque chose — une adresse d'administration sur les commutateurs, un poste de supervision — le trafic s'arrête sur ce lien, et la cause est à chercher dans une ligne écrite six mois plus tôt. Les deux extrémités d'un trunk doivent déclarer exactement la même liste :

Cisco IOS — corrigé

SW-1(config)# interface fa0/1
SW-1(config-if)# switchport trunk allowed vlan 30,99

Règle générale : un trunk se configure par paire. On ne termine jamais un côté sans faire l'autre dans la foulée.

⚠️ Piège d'examen — allowed n'est pas not pruned

La commande show interfaces trunk affiche trois blocs successifs, et la plupart des étudiants n'en lisent que le premier :

Cisco IOS — sortie réelle du projet

SW-COEUR#show interfaces trunk

Port    Mode  Encapsulation  Status     Native vlan
Fa0/1   on    802.1q         trunking   99
Fa0/2   on    802.1q         trunking   99
Fa0/3   on    802.1q         trunking   99

Port    Vlans allowed on trunk                   ← ce que J'AI CONFIGURÉ
Fa0/1   10,20,30,99
Fa0/2   30,99
Fa0/3   10,20,99

Port    Vlans in spanning tree forwarding state and not pruned
Fa0/1   10,20,30,99                              ← ce qui CIRCULE VRAIMENT
Fa0/2   30
Fa0/3   10,20

Le premier bloc dit que le lien est monté. Le deuxième dit ce qu'on a demandé. Seul le troisième dit ce qui passe. Ici, le VLAN 99 est autorisé sur Fa0/2 et Fa0/3 mais n'apparaît pas dans le troisième bloc : il est effectivement élagué sur ces liens, faute d'être actif des deux côtés.

En dépannage, c'est toujours le troisième bloc qu'il faut regarder. Un VLAN « autorisé » mais élagué se comporte exactement comme un VLAN interdit — et l'on peut relire sa configuration pendant une heure sans rien y voir d'anormal.

05Le Router-on-a-Stick

Les VLAN ont isolé les pôles. Trop bien isolés : plus personne ne se parle. Or le pôle VENTE doit atteindre le serveur de fichiers, et le pôle TECH le serveur d'inventaire. Il faut rouvrir — de manière contrôlée.

Un commutateur travaille en couche 2 : il ne sait pas faire passer une trame d'un réseau IP à un autre. Il faut un routeur. La méthode Router-on-a-Stick découpe une interface physique du routeur en autant de sous-interfaces logiques qu'il y a de VLAN : le routeur tient sur un seul câble — d'où le « stick ».

Une interface physique, trois sous-interfaces logiques : chacune porte la passerelle d'un VLAN et reconnaît son étiquette 802.1Q.

Cisco IOS — R-STICK

interface g0/0
 description LAN_Siege
 no shutdown                      ← l'interface PHYSIQUE doit être allumée
 exit

interface g0/0.10
 encapsulation dot1q 10           ← « je réponds aux trames étiquetées 10 »
 ip address 192.168.10.1 255.255.255.0
 exit

interface g0/0.20
 encapsulation dot1q 20
 ip address 192.168.20.1 255.255.255.0
 exit

interface g0/0.30
 encapsulation dot1q 30
 ip address 192.168.30.1 255.255.255.0
 exit

⚠️ Les trois erreurs qui tuent un Router-on-a-Stick

L'interface physique reste éteinte. Les sous-interfaces peuvent être parfaitement configurées : si g0/0 est en administratively down, rien ne passe. no shutdown se met sur le physique, les sous-interfaces suivent.
Le numéro de sous-interface ne fait pas foi. Ce qui compte est encapsulation dot1q 10, pas le .10 du nom. Appeler la sous-interface g0/0.7 et y mettre dot1q 10 fonctionne parfaitement. On les aligne quand même — pour se relire dans six mois.
Le port du commutateur en face n'est pas en trunk. C'est l'erreur la plus fréquente. Un port d'accès ne livre qu'un seul VLAN, sans étiquette : les sous-interfaces ne reconnaissent rien et un seul VLAN semble marcher — ce qui rend le diagnostic déroutant.

Symptôme : un seul VLAN fonctionne
→ regarder le mode du port en face

🧠 Auto-évaluation

Cinq VLAN au lieu de trois : le routeur a-t-il besoin de cinq câbles ?

Non — c'est tout l'intérêt de la méthode. On ajoute deux sous-interfaces sur la même interface physique, et les deux VLAN à la liste allowed du trunk. Zéro câble supplémentaire.

La limite n'est pas le nombre de VLAN mais le débit : tout le trafic inter-VLAN — dans les deux sens — transite par ce seul lien. Un Gigabit partagé entre trente VLAN très bavards devient un goulot d'étranglement, et le routeur traite chaque paquet par logiciel.

La solution industrielle s'appelle le commutateur de niveau 3 : il route entre VLAN directement en matériel, via des interfaces virtuelles (SVI), sans passer par un lien externe. Le Router-on-a-Stick reste la bonne réponse pour une PME comme TechShop — et c'est ce qu'il faut savoir dire.

06DHCP centralisé et relais

Le sujet laisse le choix : le routeur peut faire office de serveur DHCP, ou l'on déploie un serveur dédié à 192.168.20.11, dans le VLAN ADMIN. Le projet livré retient la seconde solution — celle de l'entreprise réelle.

	DHCP sur le routeur	Serveur DHCP dédié
Mise en place	immédiate, tout est sur l'équipement	une machine à installer et à maintenir
Réservations par adresse MAC	limitées	complètes
Suivi des baux	`show ip dhcp binding`	console graphique, journal, alertes
Couplage DNS	aucun	naturel — même machine, mêmes enregistrements
Le routeur tombe…	plus de DHCP	le DHCP survit
Prérequis	aucun	`ip helper-address` sur les autres VLAN

Le problème : un routeur ne relaie pas les broadcasts

Un poste qui démarre n'a pas d'adresse IP. Il ne peut donc pas s'adresser à un serveur précis : il crie. Il émet un DHCPDISCOVER en broadcast, vers 255.255.255.255.

Or un routeur bloque les broadcasts — c'est même sa raison d'être : sans cela, chaque diffusion inonderait toute l'entreprise. Le serveur DHCP est dans le VLAN 20 ; l'appel d'un poste du VLAN 10 meurt donc sur la sous-interface g0/0.10 et n'arrive jamais.

Le relais DHCP transforme un appel diffusé en un appel nominatif — et signe cet appel avec l'adresse de la sous-interface d'entrée.

🧰 ip helper-address — deux lignes, tout le mécanisme

Cisco IOS — R-STICK

R-STICK(config)# interface g0/0.10
R-STICK(config-subif)# ip helper-address 192.168.20.11
R-STICK(config-subif)# exit
R-STICK(config)# interface g0/0.30
R-STICK(config-subif)# ip helper-address 192.168.20.11
R-STICK(config-subif)# exit

La commande se place sur la sous-interface où arrive le broadcast, jamais du côté du serveur. Le routeur y fait deux choses :

il transforme le broadcast en unicast vers 192.168.20.11 ;
il inscrit l'adresse de la sous-interface d'entrée (192.168.10.1) dans le champ giaddr du paquet. C'est ce champ qui dit au serveur dans quelle plage puiser. Sans lui, le serveur ne saurait pas si la demande vient de VENTE ou de TECH.

⚠️ Pourquoi le VLAN 20 n'a pas besoin de la commande

Dans la configuration livrée, ip helper-address est posé sur g0/0.10 et g0/0.30 — pas sur g0/0.20. Ce n'est pas un oubli : le serveur DHCP est dans le VLAN 20. Les postes ADMIN et lui partagent le même domaine de broadcast, l'appel lui parvient directement, sans routeur.

Poser le relais sur g0/0.20 serait inutile — et ferait arriver la demande deux fois au serveur : une par broadcast, une par le relais.

Le relais se pose sur les VLAN sans serveur DHCP

Côté serveur, un pool par VLAN, avec la passerelle correspondante — et le même DNS pour tous :

Pool	Passerelle	Serveur DNS	Début	Nombre d'adresses
`VLAN10_VENTE`	192.168.10.1	192.168.20.11	192.168.10.21	234
`VLAN20_ADMIN`	192.168.20.1	192.168.20.11	192.168.20.21	234
`VLAN30_TECH`	192.168.30.1	192.168.20.11	192.168.30.21	234

🔧 Corrigé — un serveur DNS par VLAN, qui n'existe pas

Une version intermédiaire du projet — celle que décrit le compte rendu remis en juin — faisait le DHCP sur le routeur, et annonçait à chaque VLAN un DNS de son propre réseau :

Cisco IOS — ce qui était écrit

ip dhcp pool VLAN10_VENTE
 dns-server 192.168.10.11        ← ✘ aucune machine ne porte cette adresse
ip dhcp pool VLAN20_ADMIN
 dns-server 192.168.20.11        ← ✔ le vrai serveur
ip dhcp pool VLAN30_TECH
 dns-server 192.168.30.11        ← ✘ n'existe pas non plus

Le plan d'adressage du projet ne déclare qu'un seul serveur DNS : 192.168.20.11. Les postes VENTE et TECH recevaient donc l'adresse d'une machine inexistante — et perdaient toute résolution de noms.

Le piège est que les tests passent quand même : les pings du compte rendu sont faits vers des adresses IP, jamais vers des noms. Un ping serveurfichiers.techshop.local aurait échoué immédiatement.

Cisco IOS — corrigé

ip dhcp pool VLAN10_VENTE
 dns-server 192.168.20.11        ← le serveur DNS est unique, il est dans le VLAN 20
ip dhcp pool VLAN30_TECH
 dns-server 192.168.20.11

La version finale du projet corrige le problème d'elle-même : le serveur dédié annonce 192.168.20.11 aux trois pools, et l'ipconfig /all d'un poste TECH le confirme — DNS Servers : 192.168.20.11.

🔧 Corrigé — le no qui annule l'exclusion

Dans le même fichier intermédiaire, la première des trois exclusions portait un no :

Cisco IOS — ce qui était écrit

no ip dhcp excluded-address 192.168.10.1 192.168.10.11   ← ✘ SUPPRIME l'exclusion
   ip dhcp excluded-address 192.168.20.1 192.168.20.11   ← ✔
   ip dhcp excluded-address 192.168.30.1 192.168.30.11   ← ✔

En IOS, no devant une commande la retire. Le VLAN 10 n'avait donc aucune adresse protégée : le pool pouvait distribuer 192.168.10.1 — l'adresse de la passerelle. Le premier poste à obtenir ce bail rendait le VLAN VENTE inutilisable, et le suivant démarrait normalement : une panne intermittente, la pire à diagnostiquer.

Ce type de faute vient presque toujours d'un copier-coller depuis une session où l'on avait défait une configuration. Elle est invisible à la relecture rapide — l'œil lit la commande, pas le préfixe.

Après toute exclusion : show running-config | include excluded

🧠 Auto-évaluation

Un poste VENTE reçoit 169.254.13.87. Que s'est-il passé, et par où commence-t-on ?

Le poste n'a reçu aucune réponse DHCP. 169.254.0.0/16 est la plage APIPA : le système se l'attribue tout seul quand le DHCP n'a rien renvoyé. Elle ne permet de joindre personne — c'est un constat d'échec, pas une configuration.

Les causes, dans l'ordre où on les teste :

Le port du commutateur est-il dans le bon VLAN ? show vlan brief — la cause numéro un.
Le relais est-il posé ? show running-config interface g0/0.10 doit montrer ip helper-address.
Le serveur répond-il ? Depuis un poste du VLAN 20 — qui n'a pas besoin du relais — un bail arrive-t-il ? Si oui, le serveur va bien et le problème est le relais ou le VLAN.
La plage est-elle épuisée ? 234 adresses pour 8 postes : improbable ici, fréquent sur un réseau Wi-Fi invité.

Cette progression est celle du chapitre dépannage : on remonte les couches une par une, de la plus basse à la plus haute, au lieu de deviner.

07Le routage entre les sites

Le siège et l'entrepôt sont deux réseaux distincts reliés par une liaison série. Chaque routeur connaît ses propres réseaux — il ignore tout de ceux d'en face. Il faut le lui dire.

Cisco IOS — R-STICK (siège)

interface Serial0/0/0
 ip address 10.0.0.1 255.255.255.252
 no shutdown
 exit

! pour joindre le réseau de l'entrepôt, sortir par 10.0.0.2
ip route 192.168.50.0 255.255.255.0 10.0.0.2

Cisco IOS — R-ENTREPOT

interface Serial0/0/0
 ip address 10.0.0.2 255.255.255.252
 no shutdown
 exit

interface g0/0
 ip address 192.168.50.1 255.255.255.0
 no shutdown
 exit

! tout ce que je ne connais pas part vers le siège
ip route 0.0.0.0 0.0.0.0 10.0.0.1

🧭 Pourquoi les deux routes ne se ressemblent pas

C'est le point que le jury interroge le plus souvent, et l'asymétrie est voulue :

	R-STICK (siège)	R-ENTREPOT
Route	`ip route 192.168.50.0 …`	`ip route 0.0.0.0 0.0.0.0 …`
Type	statique précise	route par défaut
Position	plusieurs directions possibles	réseau d'extrémité : une seule sortie
Lecture	« pour aller à l'entrepôt, par là »	« pour aller ailleurs, par là »

L'entrepôt n'a qu'un seul câble vers le monde : énumérer les destinations n'aurait aucun sens — il faudrait ajouter une ligne à chaque nouveau VLAN créé au siège. Une route par défaut couvre tout, définitivement.

Le siège, lui, a deux sorties : le lien WAN et le lien Internet. Une route par défaut vers l'entrepôt y enverrait aussi le trafic Internet. Il faut donc désigner précisément le réseau concerné.

Un réseau d'extrémité (stub) → route par défaut
Un nœud à plusieurs sorties → routes précises

⚠️ Une route ne fonctionne que si l'autre existe

Un aller sans retour ne donne aucun ping. Le paquet part, arrive — et la réponse se perd faute de route de retour. Le symptôme est trompeur : on soupçonne l'émetteur, alors que la configuration manquante est à l'autre bout.

Le réflexe : après chaque route ajoutée, se demander « et pour revenir ? », puis vérifier des deux côtés avec show ip route.

🧰 Lire show ip route

Cisco IOS — R-STICK, sortie réelle

R-STICK#show ip route
Gateway of last resort is not set

     10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C       10.0.0.0/30 is directly connected, Serial0/0/0
L       10.0.0.1/32 is directly connected, Serial0/0/0
     192.168.10.0/24 is variably subnetted, 2 subnets, 2 masks
C       192.168.10.0/24 is directly connected, GigabitEthernet0/0.10
L       192.168.10.1/32 is directly connected, GigabitEthernet0/0.10
C       192.168.20.0/24 is directly connected, GigabitEthernet0/0.20
C       192.168.30.0/24 is directly connected, GigabitEthernet0/0.30
S       192.168.50.0/24 [1/0] via 10.0.0.2

`C`	Connected — réseau directement branché sur une interface active
`L`	Local — l'adresse du routeur lui-même, en /32. Automatique, c'est normal
`S`	Static — la route qu'on a écrite
`[1/0]`	distance administrative 1, métrique 0. 1 = une route statique, la plus crédible après le direct (0)
`S*`	route par défaut — l'étoile la distingue

Les trois sous-interfaces apparaissent bien comme trois réseaux connectés distincts : c'est la preuve que le Router-on-a-Stick est monté.

💡 « Gateway of last resort is not set »

Cette ligne signale que R-STICK n'a aucune route par défaut. Dans la maquette cela ne gêne pas : le réseau « Internet » (203.0.113.0/24) est directement branché sur g0/1, donc connu.

Sur une vraie sortie Internet, il en faudrait une — sans quoi le routeur jette tout ce qui ne figure pas dans sa table :

Cisco IOS — pour aller plus loin

ip route 0.0.0.0 0.0.0.0 203.0.113.1     ← l'adresse du routeur du FAI

Le projet ne l'exige pas : le seul flux Internet demandé est entrant, vers le serveur d'inventaire. Mais le savoir vous met à l'abri de la question « et si un poste voulait sortir sur Internet ? » — à laquelle il manquerait aussi une règle de NAT dynamique, voir la section suivante.

08Publier un serveur en NAT

Le serveur d'inventaire porte 192.168.30.10 — une adresse privée, qui n'existe pas sur Internet et que personne ne peut router de l'extérieur. Pour le rendre joignable, on lui affecte une adresse publique de façade : 203.0.113.20. C'est le NAT statique.

Cisco IOS — R-STICK

! la traduction : une privée ↔ une publique, en permanence
ip nat inside source static 192.168.30.10 203.0.113.20

! l'interface tournée vers l'extérieur
interface g0/1
 ip address 203.0.113.10 255.255.255.0
 ip nat outside
 no shutdown
 exit

! les interfaces tournées vers l'intérieur — toutes les sous-interfaces
interface g0/0.10
 ip nat inside
interface g0/0.20
 ip nat inside
interface g0/0.30
 ip nat inside
 end

⚠️ L'erreur numéro un : oublier inside / outside

La règle de traduction seule ne fait rien. Le routeur doit savoir de quel côté est le dedans et de quel côté le dehors — sans quoi il ne sait pas dans quel sens traduire, et laisse passer les paquets tels quels.

C'est une panne silencieuse : show running-config montre bien la ligne ip nat inside source static, tout paraît configuré, et rien ne fonctionne. La commande qui tranche :

Cisco IOS

R-STICK#show ip nat statistics
Total translations: 1 (1 static, 0 dynamic, 0 extended)
Outside Interfaces: GigabitEthernet0/1
Inside Interfaces: GigabitEthernet0/0.10 , GigabitEthernet0/0.20 , GigabitEthernet0/0.30

Si l'une des deux lignes Interfaces est vide, la cause est trouvée.

🔗 L'adresse publique, c'est la boîte aux lettres de la rue

Le serveur habite au fond de l'immeuble, appartement 192.168.30.10 — une adresse qui n'a de sens qu'à l'intérieur. Le NAT statique lui attribue une boîte aux lettres nominative sur la rue, 203.0.113.20. Le facteur y dépose le courrier, le concierge — le routeur — le monte à l'appartement.

Et cela ne révèle rien des autres appartements : le reste du réseau interne n'a pas de boîte, donc pas d'existence vue de la rue. C'est ce que demande le cahier des charges — « publier le serveur sans exposer le réseau interne ».

🧰 La preuve : show ip nat translation

Avant tout trafic, la traduction statique est déjà là, seule et permanente :

Cisco IOS — avant

Pro  Inside global     Inside local       Outside local    Outside global
---  203.0.113.20      192.168.30.10      ---              ---

Après un ping depuis l'hôte Internet (203.0.113.30), les sessions ICMP apparaissent :

Cisco IOS — après

Pro   Inside global      Inside local        Outside local      Outside global
icmp  203.0.113.20:18    192.168.30.10:18    203.0.113.30:18    203.0.113.30:18
icmp  203.0.113.20:19    192.168.30.10:19    203.0.113.30:19    203.0.113.30:19
---   203.0.113.20       192.168.30.10       ---                ---

Inside local	l'adresse privée réelle du serveur
Inside global	la façade publique, vue de l'extérieur
Outside local / global	le correspondant — identiques ici, faute d'un second NAT en face

Cette capture, prise avant et après, est la meilleure preuve possible du troisième critère d'acceptation. Une seule des deux ne démontrerait rien.

🧠 Auto-évaluation

Le serveur d'inventaire est publié. Un poste du pôle VENTE peut-il, lui, aller sur Internet ?

Non. La seule règle configurée est une traduction statique, réservée à 192.168.30.10. Un poste VENTE en 192.168.10.x n'a aucune façade publique : ses paquets sortent avec une adresse privée, et aucun serveur sur Internet ne saurait lui répondre.

Il faudrait ajouter du NAT dynamique avec surcharge (PAT) — tous les postes derrière la même adresse publique, distingués par le numéro de port :

Cisco IOS — pour aller plus loin

access-list 1 permit 192.168.0.0 0.0.255.255
ip nat inside source list 1 interface g0/1 overload

Le cahier des charges ne le demande pas — il ne réclame qu'un flux entrant vers le serveur d'inventaire. Savoir énoncer cette limite, et la commande qui la lèverait, vaut mieux que de laisser croire que tout sort déjà. Le détail est au chapitre NAT & PAT.

09Contrôler les flux par ACL

Le Router-on-a-Stick a rouvert la communication entre les pôles — totalement. Un poste du pôle VENTE peut aujourd'hui joindre n'importe quel poste du pôle ADMIN, donc les postes de la comptabilité et de la direction. Le cahier des charges demandait un « accès contrôlé ». Il reste à refermer.

🧭 Le VLAN sépare, l'ACL filtre

Deux outils, deux couches, deux rôles complémentaires — et c'est une question d'oral classique :

	VLAN	ACL
Couche	2 — commutation	3/4 — routage
Effet	isole les domaines de broadcast	autorise ou refuse des flux précis
Granularité	tout le VLAN	une adresse, un protocole, un port
Sans l'autre	l'inter-VLAN ouvre tout	rien à filtrer si rien n'est séparé

Les règles retenues

VENTE doit atteindre les serveurs d'ADMIN — pas ses postes.

Cisco IOS — R-STICK

ip access-list extended PROTECT_ADMIN
 permit ip 192.168.10.0 0.0.0.255 host 192.168.20.10      ← 1. serveur de fichiers : OUI
 permit ip 192.168.10.0 0.0.0.255 host 192.168.20.11      ← 2. serveur DHCP/DNS : OUI
 deny   ip 192.168.10.0 0.0.0.255 192.168.20.0 0.0.0.255  ← 3. le reste d'ADMIN : NON
 permit ip any any                                        ← 4. tout le reste : OUI
 exit

interface g0/0.20
 ip access-group PROTECT_ADMIN out
 exit

⚠️ L'ordre des règles décide de tout

Une ACL se lit de haut en bas et s'arrête à la première règle qui correspond. Les autres ne sont jamais évaluées.

Intervertissez les lignes 2 et 3 : le deny vers tout 192.168.20.0/24 englobe 192.168.20.10. Le paquet vers le serveur de fichiers est refusé avant d'avoir rencontré son autorisation — et VENTE perd l'accès au partage, alors que la règle qui l'autorise est bien présente, juste en dessous.

Les exceptions d'abord (host),
les refus larges ensuite

Le principe est général : du plus précis au plus général.

🧰 Le masque générique, c'est le masque à l'envers

Portée	Masque réseau	Masque générique	Écriture ACL
Un réseau /24	255.255.255.0	`0.0.0.255`	`192.168.10.0 0.0.0.255`
Une seule machine	255.255.255.255	`0.0.0.0`	`host 192.168.20.10`
N'importe qui	0.0.0.0	`255.255.255.255`	`any`

0 = « ce bit doit correspondre » · 1 = « ce bit est libre »

Le calcul : 255.255.255.255 − masque réseau. Un /26 (255.255.255.192) donne 0.0.0.63. Les raccourcis host et any évitent la faute d'inattention — préférez-les.

⚠️ Le deny any any invisible

Toute ACL se termine par un refus implicite que l'on ne voit nulle part dans la configuration. Sans la quatrième ligne, permit ip any any, l'ACL posée en sortie de g0/0.20 bloquerait tout ce qui entre dans le VLAN ADMIN : le pôle TECH, l'entrepôt, les réponses du serveur DHCP. Le réseau paraîtrait cassé au hasard.

Une ACL qui n'autorise rien à la fin interdit tout. On l'oublie une fois — jamais deux.

💡 in ou out, et sur quelle interface ?

Le sens s'entend du point de vue du routeur : in = le paquet entre dans l'interface, out = il en sort.

Ici l'ACL est posée out sur g0/0.20 : elle inspecte tout ce qui part vers le VLAN ADMIN, quelle qu'en soit la provenance. C'est le bon choix quand on protège une destination.

On aurait pu la poser in sur g0/0.10 — filtrer à la source. Plus efficace, car le paquet est jeté avant d'être routé ; mais il faudrait répéter l'ACL sur chaque VLAN d'origine le jour où d'autres pôles sont concernés. Protéger la destination se maintient mieux.

Protéger une ressource → out côté ressource
Brider un émetteur → in côté émetteur

🧰 La preuve que l'ACL fonctionne

Depuis un poste VENTE, vers un poste ADMIN :

Invite de commandes — PC VENTE

C:\>ping 192.168.20.21

Pinging 192.168.20.21 with 32 bytes of data:
Reply from 192.168.10.1: Destination host unreachable.
Reply from 192.168.10.1: Destination host unreachable.

Packets: Sent = 4, Received = 0, Lost = 4 (100% loss)

Détail capital : la réponse vient de 192.168.10.1, la passerelle, et non de la destination. C'est la signature d'un refus par ACL : le routeur a reçu le paquet, l'a refusé, et l'annonce par un ICMP unreachable.

Message	Qui répond	Diagnostic
`Destination host unreachable`	la passerelle	un routeur refuse ou ne sait pas router
`Request timed out`	personne	le paquet se perd, ou la réponse ne revient pas
`Reply from …`	la destination	le chemin fonctionne dans les deux sens

Et la contre-épreuve, tout aussi indispensable : depuis le même poste VENTE, le ping vers 192.168.20.10 — le serveur de fichiers — doit réussir. Elle prouve que l'ACL filtre avec discernement au lieu de tout couper.

10La recette : prouver

La configuration est finie. Le projet, non. Le cahier des charges réclame un « compte rendu de validation » : une série de tests qui prouvent. Configurer est un travail de technicien ; prouver est un travail d'ingénieur, et c'est ce qui est noté.

🧭 Une preuve par critère, dans l'ordre des couches

Couche	Ce qu'on vérifie	Commande	Ce qui doit apparaître
2	les VLAN existent, les ports sont bien affectés	`show vlan brief`	chaque port d'accès en face de son VLAN
2	les trunks sont montés	`show interfaces trunk`	`trunking`, natif 99, et le 3ᵉ bloc
3	le DHCP distribue correctement	`ipconfig /all`	IP, masque, passerelle, DNS — les quatre
3	les routes sont là	`show ip route`	les `C` des VLAN + le `S` vers l'entrepôt
3	l'inter-VLAN et le site distant	`ping`	`0% loss`, dans les deux sens
3/4	le NAT traduit	`show ip nat translation`	la ligne statique, avant et après trafic
3/4	l'ACL filtre — et n'exagère pas	`ping` ×2	un refus et un succès

🧰 Lire un ipconfig /all : les quatre lignes qui comptent

Invite de commandes — PC du VLAN 30

C:\>ipconfig /all

   IPv4 Address. . . . . . : 192.168.30.22      ← 1. dans le bon réseau, ≥ .21
   Subnet Mask . . . . . . : 255.255.255.0      ← 2. le bon masque
   Default Gateway . . . . : 192.168.30.1       ← 3. la passerelle de SON VLAN
   DHCP Server . . . . . . : 192.168.20.11      ← 4. le serveur dédié : le relais a marché
   DNS Servers . . . . . . : 192.168.20.11      ← 5. le serveur DNS unique

La ligne 4 est la plus parlante du projet entier : le poste est dans le VLAN 30, le serveur DHCP dans le VLAN 20. Le fait qu'il ait obtenu un bail prouve à lui seul que l'ip helper-address fonctionne. Une seule capture, deux critères validés.

Une adresse en 169.254.x.x signifie l'inverse : aucune réponse DHCP.

💡 Le TTL raconte le chemin parcouru

Invite de commandes — poste entrepôt vers le siège

C:\>ping 192.168.20.13
Reply from 192.168.20.13: bytes=32 time=21ms TTL=126
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss)

Le TTL (Time To Live) part d'une valeur ronde — 128 sous Windows — et chaque routeur traversé le décrémente de 1. Un TTL de 126 signifie donc deux routeurs franchis : R-ENTREPOT puis R-STICK. Le chiffre confirme le trajet à lui seul.

Un ping à l'intérieur du même VLAN reviendrait avec 128 : aucun routeur, rien que de la commutation. Mentionner cette lecture dans un compte rendu montre qu'on ne s'est pas contenté de voir « Reply ».

⚠️ Piège — le test qui ne teste rien

Tous les pings du compte rendu visaient des adresses IP. Aucun ne visait un nom. Or un serveur DNS a été déployé, avec trois enregistrements. Rien ne prouve qu'il fonctionne — et une erreur de DNS distribué par DHCP serait passée inaperçue (voir la section 6).

Invite de commandes — le test manquant

C:\>ping serveurfichiers.techshop.local
Pinging serveurfichiers.techshop.local [192.168.20.10] with 32 bytes of data:
Reply from 192.168.20.10: bytes=32 time<1ms TTL=127

La ligne [192.168.20.10] entre crochets est la preuve : le nom a été résolu. Un seul test, et le service DNS est validé.

Un test qui réussit toujours ne prouve rien.
Un bon test peut échouer.

🧠 Auto-évaluation

Combien de captures faut-il, au minimum, pour démontrer les trois critères d'acceptation ? Lesquelles ?

Cinq. Et les choisir montre qu'on a compris ce que chacune démontre :

ipconfig /all d'un poste VLAN 30 — critère 1. Il vaut mieux que celui du VLAN 20 : il prouve en plus le relais DHCP.
ping VLAN 10 → VLAN 30 — critère 2, l'inter-VLAN.
ping poste entrepôt → poste siège — critère 2, le site distant. Le TTL à 126 confirme les deux routeurs.
show ip nat translation après un ping venu d'Internet — critère 3.
show ip route sur R-STICK — l'ossature : sous-interfaces montées et route statique posée. Elle explique pourquoi les captures 2 et 3 réussissent.

À quoi l'on ajoute, puisque le projet va au-delà du minimum : les deux pings de l'ACL — un refus et un succès — et un ping par nom pour le DNS.

11Le compte rendu

Le dernier livrable est un document. Il sera lu par quelqu'un qui n'a pas assisté au travail et qui, en E5 comme en E6, aura la maquette ouverte à côté.

🔧 Corrigé — le rapport décrit une version, le fichier en livre une autre

C'est le défaut le plus coûteux du projet, et il ne se voit qu'en comparant les deux livrables. Le compte rendu remis en juin décrit une version intermédiaire de la maquette ; le fichier Packet Tracer livré est plus récent. Les captures d'écran de la copie A, elles, correspondent au fichier :

Point	Ce que dit le rapport	Ce que montrent les captures
Service DHCP	assuré par le routeur, trois `ip dhcp pool`	serveur dédié `192.168.20.11` + `ip helper-address`
DNS annoncé	`192.168.10.11` / `.20.11` / `.30.11`	`192.168.20.11` pour les trois VLAN
Début de plage	« à partir de `.12` »	`.21` (`ipconfig` : `192.168.10.21`)
Noms des équipements	`S1-Coeur`, `S2`, `S3`	`SW-COEUR`, `SW-1`, `SW-2`, `R-STICK`
Interface WAN	`Serial0/0/1`	`Serial0/0/0` (`show ip route`)
ACL	absente du rapport	présente et testée

Aucune de ces différences n'est une faute de configuration : le projet livré est le meilleur des deux. Mais un jury qui tape show running-config et lit R-STICK là où le rapport annonce S1-Coeur se pose une question gênante — et la pose à voix haute.

La règle : le rapport se met à jour en dernier, après le dernier changement de la maquette. Une passe de relecture finale, maquette ouverte à côté du document, ligne par ligne. Le travail supplémentaire réel se compte en minutes ; le risque évité se compte en points.

🔧 Corrigé — deux mesures annoncées mais non appliquées

La partie « Sécurité » annonce que les ports inutilisés sont placés dans un VLAN 999 « parking » et éteints. Sur SW-1, show vlan brief raconte autre chose :

Cisco IOS — SW-1, sortie réelle

SW-1#show vlan brief

VLAN Name      Status    Ports
---- --------- --------- ----------------------------------------
1    default   active    Fa0/2, Fa0/3, Gig0/1, Gig0/2   ← restés en VLAN 1
30   TECH      active    Fa0/6 … Fa0/24
99   native    active
                                                        ← aucun VLAN 999

Le VLAN 999 n'a jamais été créé sur ce commutateur, et quatre ports dorment dans le VLAN 1 par défaut — exactement la situation que la mesure était censée éviter.

Second écart, en sens inverse : le rapport contient une ligne interface range fa0/9-24 suivie de shutdown, qui éteindrait 16 des 19 ports du pôle TECH et ne laisserait que trois prises pour vingt techniciens. La capture ci-dessus prouve qu'elle n'a pas été appliquée — c'est un copier-coller resté dans le document.

Les deux erreurs ont la même origine : le rapport et la maquette ont été écrits séparément. Annoncer une mesure absente, c'est se déclarer protégé quand on ne l'est pas — le plus grave des deux.

Cisco IOS — à appliquer sur SW-1

vlan 999
 name PARKING
 exit
interface range fa0/2-5 , gig0/1-2
 switchport mode access
 switchport access vlan 999
 shutdown
 exit

🧰 Le plan d'un compte rendu réseau

Contexte et besoins — l'entreprise, les pôles, les enjeux. Reformulés, pas recopiés.
Objectifs — ce qu'on va livrer, en cinq lignes.
Architecture — schéma physique et schéma logique, avec les ports et les adresses. Les deux sont demandés et ne disent pas la même chose.
Plan d'adressage — le tableau : réseau, passerelle, broadcast, plage.
Configurations — équipement par équipement, chaque bloc précédé d'une phrase qui dit pourquoi.
Sécurité — regroupée : mots de passe, VLAN natif, pruning, ports inutilisés, ACL. Uniquement ce qui est réellement appliqué.
Validation — les tests, avec captures et lecture de chaque capture.
Conclusion et limites — ce qui marche, et ce qui manquerait en production.

💡 Ce qui distingue un bon rapport

Ce n'est ni la longueur ni la mise en page : c'est le pourquoi à côté de chaque comment. « J'ai mis le VLAN natif en 99 » est un constat. « J'ai déplacé le VLAN natif en 99 parce que le trafic natif circule sans étiquette et qu'un VLAN 1 par défaut ouvre la porte au VLAN hopping » est une compétence.

Même chose pour les limites. Écrire « le commutateur cœur est un point de défaillance unique ; en production je doublerais le lien en EtherChannel et la passerelle en HSRP » ne vous affaiblit pas : cela prouve que vous savez où regarde un professionnel.

🧠 Auto-évaluation

À l'oral, le jury demande : « Pourquoi avoir choisi le Router-on-a-Stick plutôt qu'un commutateur de niveau 3 ? » Que répondez-vous ?

Une réponse complète tient en trois temps :

1. Le besoin. TechShop compte 34 postes répartis en trois VLAN. Le trafic inter-VLAN se limite à quelques accès aux serveurs de fichiers et d'inventaire — un lien Gigabit y suffit largement.

2. Le coût. Le routeur est déjà présent, il est de toute façon nécessaire pour le lien WAN et pour le NAT. Le Router-on-a-Stick n'ajoute aucun matériel ; un commutateur de niveau 3 serait un achat.

3. La limite, énoncée d'avance. Tout le trafic inter-VLAN transite par ce seul lien, et le routeur commute par logiciel. Si l'entreprise grandit — davantage de VLAN, du transfert de fichiers massif entre pôles —, le lien devient un goulot d'étranglement et l'on passe à un commutateur de niveau 3, qui route en matériel via des interfaces virtuelles (SVI).

Ce qu'écoute le jury : non pas « connaît-il la commande », mais « sait-il pourquoi il l'a choisie, et quand elle cesserait de convenir ».