Mon premier vrai projet réseau : infrastructure sécurisée d’une PME avec Cisco Packet Tracer

Abdessamad Cyber FR septembre 30, 2026


Mon premier vrai projet réseau : infrastructure sécurisée d’une PME avec Cisco Packet Tracer

Depuis le début de mes études en Gestion des Réseaux et Sécurité, j’ai travaillé sur plusieurs notions comme l’adressage IP, les VLAN, le routage, les ACL et la sécurité des équipements Cisco.

Après avoir réalisé plusieurs exercices séparés, j’ai voulu créer quelque chose de plus complet.

J’ai donc réalisé mon premier vrai projet réseau avec Cisco Packet Tracer : une infrastructure réseau sécurisée pour une PME fictive.

L’objectif était de construire un réseau organisé, fonctionnel et sécurisé, avec plusieurs services, plusieurs VLAN, des serveurs, un réseau Wi-Fi Guest et un accès Internet simulé.

Le projet complet est disponible sur mon GitHub :

GitHub :
https://github.com/AbdessamadAitbenali/Infrastructure-PME-NETSEC

L’objectif du projet

L’idée principale était de créer une infrastructure qui ressemble davantage à un réseau d’entreprise qu’à un simple exercice.

J’ai séparé l’entreprise en plusieurs services :

  1. Direction
  2. Ressources Humaines
  3. Finance
  4. IT
  5. Employés
  6. Serveurs
  7. Guest
  8. Management

Chaque service possède son propre VLAN afin de séparer les utilisateurs et de mieux contrôler les communications entre les différentes parties du réseau.

Architecture du réseau

L’infrastructure utilise plusieurs switches d’accès connectés à un switch central appelé SW-CORE.

SW-CORE est ensuite connecté au routeur R1-EDGE grâce à un trunk 802.1Q.

L’architecture finale ressemble à ceci :

PC / Serveurs / Wi-Fi Guest
          |
   Switches d'accès
          |
       SW-CORE
          |
      Trunk 802.1Q
          |
       R1-EDGE
          |
          ISP
          |
   Serveur Internet

Dans la version finale du projet, SW-CORE fonctionne principalement comme un switch Layer 2.

Le routeur R1-EDGE assure plusieurs fonctions importantes :

  1. Routage inter-VLAN
  2. Passerelles des VLAN
  3. DHCP Relay
  4. ACL
  5. NAT/PAT
  6. Connexion vers l’ISP

Les VLAN utilisés

J’ai créé huit VLAN dans le réseau.

VLANServiceRéseau
10Direction192.168.10.0/24
20RH192.168.20.0/24
30Finance192.168.30.0/24
40IT192.168.40.0/24
50Employés192.168.50.0/24
60Serveurs192.168.60.0/24
70Guest192.168.70.0/24
99Management192.168.99.0/24

Chaque VLAN utilise une passerelle située sur R1-EDGE.

Par exemple :

VLAN 10 → 192.168.10.1
VLAN 20 → 192.168.20.1
VLAN 30 → 192.168.30.1
VLAN 40 → 192.168.40.1
VLAN 50 → 192.168.50.1
VLAN 60 → 192.168.60.1
VLAN 70 → 192.168.70.1
VLAN 99 → 192.168.99.1

Cette segmentation permet de séparer les différents services de l’entreprise.

Router-on-a-Stick

Pour permettre la communication entre les différents VLAN, j’ai utilisé une architecture Router-on-a-Stick.

Le lien entre SW-CORE et R1-EDGE transporte les VLAN suivants :

  1. VLAN 10
  2. VLAN 20
  3. VLAN 30
  4. VLAN 40
  5. VLAN 50
  6. VLAN 60
  7. VLAN 70
  8. VLAN 99

Sur R1-EDGE, j’ai créé une sous-interface pour chaque VLAN.

Par exemple, pour le VLAN IT :

interface GigabitEthernet0/0.40
 encapsulation dot1Q 40
 ip address 192.168.40.1 255.255.255.0
 ip helper-address 192.168.60.40
 ip nat inside

Cette sous-interface sert notamment de passerelle pour les machines du VLAN IT.

Le même principe est utilisé pour les autres VLAN.

DHCP centralisé

Je ne voulais pas configurer manuellement une adresse IP sur chaque ordinateur.

J’ai donc ajouté un serveur DHCP centralisé.

Son adresse est :

192.168.60.40

Comme les clients se trouvent dans différents VLAN, les requêtes DHCP doivent traverser le routeur.

J’ai donc utilisé :

ip helper-address 192.168.60.40

sur les sous-interfaces concernées.

Grâce à cela, les postes peuvent recevoir automatiquement :

  1. Une adresse IP
  2. Un masque de sous-réseau
  3. Une passerelle
  4. Une adresse DNS

DNS et serveur Web

J’ai également ajouté un serveur DNS avec l’adresse :

192.168.60.10

Le serveur Web utilise :

192.168.60.20

J’ai ensuite créé l’enregistrement DNS suivant :

www.netsec.local

qui pointe vers :

192.168.60.20

Les utilisateurs peuvent donc accéder au serveur Web avec :

http://www.netsec.local

au lieu d’utiliser directement son adresse IP.

Sécurisation avec les ACL

La sécurité entre les différents VLAN représente une partie importante du projet.

Je ne voulais pas que tous les services puissent communiquer librement entre eux.

J’ai donc configuré plusieurs ACL sur les sous-interfaces de R1-EDGE.

EMPLOYES_FILTER

Le VLAN Employés ne peut pas accéder directement aux réseaux suivants :

  1. Finance
  2. RH
  3. Management

Le reste du trafic est autorisé, notamment l’accès au DNS, au serveur Web et au réseau Internet simulé.

RH_FILTER

Le VLAN RH ne peut pas accéder directement aux réseaux suivants :

  1. Finance
  2. Management

Les autres communications autorisées peuvent continuer à fonctionner.

FINANCE_FILTER

Le VLAN Finance ne peut pas accéder directement aux réseaux suivants :

  1. RH
  2. Management

Les autres communications nécessaires restent autorisées.

Réseau Wi-Fi Guest

J’ai également ajouté un réseau Wi-Fi destiné aux visiteurs.

Il utilise le VLAN 70 :

192.168.70.0/24

L’objectif était simple :

un visiteur doit pouvoir accéder à Internet sans pouvoir accéder au réseau interne de l’entreprise.

J’ai donc créé une ACL appelée :

GUEST_FILTER

Cette ACL permet notamment :

  1. DHCP
  2. DNS
  3. L’accès à la passerelle Guest
  4. L’accès à Internet

Elle bloque ensuite l’accès aux réseaux internes de l’entreprise.

Pendant mes tests, j’ai obtenu :

Guest → Passerelle        ✅ Autorisé
Guest → Serveur interne   ❌ Bloqué
Guest → Internet          ✅ Autorisé

Le laptop Guest reçoit automatiquement une adresse IP via DHCP.

Pendant mes tests, il utilisait par exemple :

IP : 192.168.70.101
Gateway : 192.168.70.1

Administration sécurisée avec SSH

J’ai également configuré SSH afin de pouvoir administrer les switches à distance.

Mais je ne voulais pas que tous les utilisateurs puissent accéder aux équipements réseau.

J’ai donc créé l’ACL suivante :

ip access-list standard SSH_JUSTE_IT
 permit 192.168.40.0 0.0.0.255
 deny any

Cela signifie que seul le VLAN IT :

192.168.40.0/24

peut administrer les switches avec SSH.

Les utilisateurs des autres VLAN ne peuvent pas se connecter aux équipements réseau.

VLAN Management

J’ai créé le VLAN 99 spécialement pour l’administration des équipements.

Les adresses utilisées sont :

R1-EDGE        → 192.168.99.1
SW-CORE        → 192.168.99.10
SW-DIRECTION   → 192.168.99.11
SW-FINANCE     → 192.168.99.12
SW-EMPLOYES    → 192.168.99.13
SW-SERVERS     → 192.168.99.14

Cela permet de séparer le trafic de management du trafic utilisateur.

Port Security

Sur les ports utilisateurs, j’ai configuré Port Security.

Par exemple :

switchport port-security
switchport port-security maximum 1
switchport port-security mac-address sticky
switchport port-security violation shutdown

Cette configuration limite le port à une seule adresse MAC.

L’adresse MAC peut être apprise automatiquement grâce au mode sticky.

Si une violation se produit, le port peut être désactivé.

PortFast et BPDU Guard

J’ai également activé PortFast et BPDU Guard sur les ports connectés aux utilisateurs.

spanning-tree portfast
spanning-tree bpduguard enable

PortFast permet au port d’entrer rapidement en état de fonctionnement.

BPDU Guard permet de protéger le réseau contre la connexion accidentelle ou non autorisée d’un autre switch sur un port utilisateur.

NAT/PAT et Internet simulé

Pour simuler une connexion Internet, j’ai ajouté un routeur ISP et un serveur externe.

R1-EDGE utilise l’adresse externe :

203.0.113.2

Le routeur ISP utilise :

203.0.113.1

Le serveur Internet simulé utilise :

198.51.100.10

R1-EDGE utilise PAT avec la commande :

ip nat inside source list 1 interface GigabitEthernet0/1 overload

Les VLAN suivants peuvent utiliser cette traduction :

  1. VLAN 10
  2. VLAN 20
  3. VLAN 30
  4. VLAN 40
  5. VLAN 50
  6. VLAN 60
  7. VLAN 70

Le VLAN Management 99 n’est pas inclus dans l’ACL NAT.

Grâce à PAT, plusieurs machines privées peuvent utiliser l’adresse externe 203.0.113.2.

J’ai vérifié les traductions avec :

show ip nat translations

Le problème le plus intéressant du projet

Au début du projet, mon architecture était différente.

Le routage inter-VLAN était réalisé directement sur SW-CORE.

SW-CORE fonctionnait donc comme un switch Layer 3.

J’avais également configuré les ACL sur ses interfaces VLAN.

Pendant les tests, certaines ACL fonctionnaient correctement.

Mais dans Packet Tracer, certaines associations entre les ACL et les interfaces VLAN ne restaient pas correctement après la sauvegarde et la réouverture du projet.

J’ai donc décidé de modifier l’architecture.

Ancienne architecture

SW-CORE
→ Routage inter-VLAN
→ ACL

Nouvelle architecture

SW-CORE
→ Commutation Layer 2
→ Trunk 802.1Q

R1-EDGE
→ Router-on-a-Stick
→ Routage inter-VLAN
→ ACL
→ DHCP Relay
→ NAT/PAT

J’ai déplacé les passerelles et les ACL vers R1-EDGE.

Après la modification, j’ai réalisé plusieurs tests.

J’ai ensuite sauvegardé le projet, fermé Packet Tracer, rouvert le fichier et refait les tests.

Cette fois, les ACL étaient toujours présentes et le réseau fonctionnait correctement.

Cette partie m’a beaucoup appris parce que je n’ai pas simplement changé une commande.

J’ai dû comprendre le problème et modifier l’architecture du réseau.

Un problème avec ARP

Après avoir déplacé les passerelles de SW-CORE vers R1-EDGE, certains PC ne pouvaient temporairement plus communiquer avec leur passerelle.

Par exemple, un PC pouvait avoir comme passerelle :

192.168.30.1

mais ne recevait aucune réponse.

Le problème venait du cache ARP.

Le PC avait encore associé l’adresse IP de la passerelle à l’ancienne adresse MAC du switch.

Après le rafraîchissement des communications ARP, les machines ont recommencé à communiquer normalement avec R1-EDGE.

Cette étape m’a permis de mieux comprendre le rôle d’ARP dans un réseau local.

Tests réalisés

Après avoir terminé la configuration, j’ai réalisé plusieurs tests.

DHCP                      ✅ Fonctionnel
DNS                       ✅ Fonctionnel
Serveur Web               ✅ Fonctionnel
SSH depuis IT             ✅ Autorisé
SSH depuis autres VLAN    ❌ Bloqué
Employés → Finance        ❌ Bloqué
Employés → RH             ❌ Bloqué
Employés → Internet       ✅ Autorisé
RH → Finance              ❌ Bloqué
RH → Internet             ✅ Autorisé
Finance → RH              ❌ Bloqué
Finance → Internet        ✅ Autorisé
Guest → Réseau interne    ❌ Bloqué
Guest → Internet          ✅ Autorisé
NAT/PAT                   ✅ Fonctionnel

J’ai également sauvegardé le projet puis fermé et rouvert Packet Tracer afin de vérifier que les configurations restaient fonctionnelles.

Les commandes de vérification utilisées

Pendant le projet, j’ai utilisé plusieurs commandes Cisco pour comprendre et vérifier le fonctionnement du réseau.

  1. show vlan brief
  2. show interfaces trunk
  3. show ip interface brief
  4. show ip route
  5. show access-lists
  6. show ip nat translations
  7. show ip nat statistics
  8. show port-security
  9. show arp
  10. show running-config

Sur les PC, j’ai principalement utilisé :

  1. ipconfig
  2. ping
  3. ssh

Ce que ce projet m’a appris

Avant ce projet, j’étudiais souvent les différentes technologies séparément.

Par exemple :

  1. VLAN
  2. DHCP
  3. ACL
  4. SSH
  5. NAT
  6. DNS
  7. Routage

Avec ce projet, j’ai compris comment toutes ces technologies peuvent fonctionner ensemble dans une même infrastructure.

J’ai également compris qu’en réseau, connaître uniquement les commandes ne suffit pas.

Il faut savoir :

  1. Tester la connectivité
  2. Lire les résultats des commandes
  3. Vérifier les routes
  4. Vérifier les VLAN
  5. Vérifier les trunks
  6. Analyser les compteurs des ACL
  7. Comprendre ARP
  8. Vérifier NAT/PAT
  9. Identifier l’origine d’un problème
  10. Modifier l’architecture lorsque cela devient nécessaire

Le dépannage a probablement été la partie la plus intéressante de ce projet.

Le projet est disponible sur GitHub

J’ai publié le projet complet sur GitHub.

Le dépôt contient :

  1. Le fichier Cisco Packet Tracer
  2. Les configurations des équipements
  3. Les captures des tests
  4. Le README complet
  5. La documentation du projet

Vous pouvez consulter le projet ici :

Infrastructure-PME-NETSEC

https://github.com/AbdessamadAitbenali/Infrastructure-PME-NETSEC

Conclusion

Ce projet représente mon premier vrai projet réseau complet.

Il m’a permis de passer de petits exercices séparés à une infrastructure dans laquelle plusieurs technologies doivent fonctionner ensemble.

J’ai pu travailler sur :

  1. VLAN
  2. Trunks 802.1Q
  3. Router-on-a-Stick
  4. DHCP
  5. DNS
  6. SSH
  7. ACL
  8. NAT/PAT
  9. Port Security
  10. PortFast
  11. BPDU Guard
  12. Wi-Fi Guest
  13. Dépannage réseau

Ce projet représente seulement une première étape.

Mon objectif est maintenant de continuer à développer mes compétences avec de nouveaux projets autour de Python, Linux, réseaux et cybersécurité, puis de les documenter également sur NetSec FR et sur mon GitHub.

Abdessamad Cyber FR

Publié par Abdessamad Cyber FR

Enregistrer un commentaire

0 Commentaires