⚠️ Disclaimer

La méthode que je présente ici correspond à ma propre démarche d’apprentissage. Elle peut contenir des approximations ou des erreurs, car j’apprends et je progresse chaque jour un peu plus. Ne prenez donc pas ce que je fais comme une référence absolue, mais plutôt comme un retour d’expérience personnel.

Contexte et Enjeux

Une société du secteur communication et influence digitale nécessitait une refonte complète de son infrastructure réseau lors de son déménagement dans de nouveaux locaux répartis sur trois sites. Le cahier des charges imposait des contraintes fortes en matière de segmentation métier, de disponibilité et de sécurité des données.

Enjeux métier :

  • Isolation stricte des départements pour conformité réglementaire
  • Accessibilité contrôlée aux ressources partagées (serveurs, internet)
  • Résilience face aux pannes matérielles
  • Support dual-stack IPv4/IPv6 pour évolutivité

Périmètre technique :

  • 3 sites géographiquement distants
  • 6 départements métier nécessitant une isolation réseau
  • Services mutualisés (DNS, serveur web, passerelles internet)
  • Architecture redondante sur le site principal

Approche de Conception

Analyse des Besoins et Segmentation

La première phase a consisté à traduire les besoins métier en architecture réseau. Six départements devaient être isolés avec des politiques d’accès différenciées :

DépartementBesoins SpécifiquesNiveau de Privilège
Management ExécutifAccès total sauf Support TechniqueÉlevé
Gestion du PersonnelCommunication inter-départementsMoyen
Développement CommercialAccès serveur web + DNSMoyen
ComptabilitéIsolation renforcéeMoyen
Support TechniqueAccès administratif completAdministrateur
InfrastructureServeurs et services partagésCritique

Choix de conception : Une segmentation VLAN a été retenue plutôt qu’une segmentation physique pour sa flexibilité et son rapport coût/efficacité. Chaque département dispose de son propre VLAN (VLANs 100-150 pour les utilisateurs, VLAN 200 pour les serveurs, VLAN 300 pour le management réseau).

Architecture Hiérarchique vs Plate

Face au nombre de VLANs et aux exigences de disponibilité, le choix s’est porté sur une architecture hiérarchique trois niveaux pour le site principal :

Architecture retenue (3-tier) :

Core (L3) → Distribution (L3) → Access (L2)

Avantages de ce modèle :

  • Séparation claire des rôles (routage/distribution/accès)
  • Évolutivité : ajout de nouveaux départements sans reconfiguration globale
  • Résilience : redondance possible à chaque niveau
  • Performance : agrégation de liens entre Distribution et Core

Alternative écartée : Une architecture plate (collapsed core) aurait été plus simple mais insuffisante face aux besoins de redondance et d’évolutivité. L’ajout d’un sixième ou septième département aurait nécessité une refonte.

Plan d’Adressage : Anticipation et Évolutivité

Le plan d’adressage a été conçu pour supporter une croissance future sans ré-adressage majeur :

IPv4 - Schéma /24 par VLAN :

  • 10.50.100.0/24 → Management Exécutif
  • 10.50.110.0/24 → Gestion Personnel
  • 10.50.120.0/24 → Développement Commercial
  • 10.50.130.0/24 → Comptabilité
  • 10.50.140.0/24 → Support Technique
  • 10.50.200.0/24 → Infrastructure (Serveurs)
  • 10.50.250.0/30 → Transit Core-Routeur

Rationale du /24 : Même si certains départements comptent 2-3 personnes actuellement, l’utilisation systématique de /24 simplifie la gestion (masques uniformes) et anticipe la croissance (jusqu’à 250 hôtes par département). Le coût en adresses privées est négligeable.

IPv6 - Stratégie dual-stack : Allocation d’un /64 par VLAN à partir du préfixe 2001:db8:1000::/48, permettant une transition progressive sans rupture de service IPv4.

Défis d’Architecture et Solutions

Défi 1 : Routage Inter-VLAN en Environnement Hybride

Problématique : Comment implémenter le routage inter-VLAN pour 7 VLANs avec support dual-stack (IPv4 et IPv6) sachant que l’équipement switch L3 présentait des limitations en IPv6 ?

Solution architecturale : adoption d’une architecture hybride :

Pour IPv4 :

  • Routage centralisé sur le switch Core L3 via interfaces SVI (Switched Virtual Interfaces)
  • Avantage : routage au niveau 3 du modèle OSI, performances optimales
  • Configuration : une interface VLAN (SVI) par réseau avec l’IP de passerelle

Pour IPv6 :

  • Router-on-a-Stick : routage délégué au routeur principal
  • Sous-interfaces 802.1Q taggées, une par VLAN
  • Rationale : contournement des bugs Packet Tracer sur le routage IPv6 des switches 3560/3650

Compromis assumé : Cette architecture implique que le trafic IPv6 traverse deux équipements (switch puis routeur) contre un seul pour IPv4. Acceptable car :

  1. Le trafic IPv6 reste marginal dans cette phase de transition
  2. La stabilité prime sur l’optimisation absolue
  3. Migration possible vers routage IPv6 sur Core lors d’un changement d’équipement

Défi 2 : Conception d’une Politique de Sécurité Granulaire

Problématique : Chaque département a des besoins d’accès différents. Comment implémenter une matrice de sécurité sans complexité excessive ?

Approche de conception :

  1. Principe du moindre privilège : tout est interdit par défaut, autorisation explicite uniquement

  2. Logique par “profils” :

    • Profil Administrateur (Support Technique) : accès complet
    • Profil Standard (Management, Gestion, Dev Commercial, Compta) : accès inter-départements + ressources partagées
    • Profil Serveur : accepte connexions du LAN uniquement, bloque initiations externes
  3. Définition de zones de confiance :

    • Zone Haute Confiance : Support Technique
    • Zone Confiance Moyenne : Départements utilisateurs
    • Zone Ressources : Serveurs (accepte mais n’initie pas)
    • Zone Non Fiable : Sites secondaires et internet

Implémentation via ACL Extended : Plutôt que des ACL monolithiques, création d’une ACL par VLAN appliquée en entrée (in) sur chaque interface SVI. Cette approche facilite le troubleshooting et la maintenance.

Exemple de logique (Management Exécutif) :

Autoriser → Gestion Personnel, Dev Commercial, Comptabilité, Infrastructure
Refuser   → Support Technique (sauf réponses à des requêtes initiées)
Autoriser → Internet et sites secondaires

Défi conceptuel : L’ordre des règles dans une ACL est crucial. Une règle deny ip any any placée trop tôt bloquerait tout, y compris les flux autorisés. La logique doit être : permits spécifiques → deny spécifique → permit générique (ou deny implicite).

Défi 3 : Haute Disponibilité avec Équipements Limités

Problématique : Assurer la continuité de service en cas de panne d’un switch de distribution, sans budget pour des équipements haut de gamme supportant des protocoles de redondance avancés (HSRP, VRRP).

Solutions déployées :

1. Agrégation de liens LACP entre les deux switches de distribution

Plutôt qu’un seul lien, quatre liens Gigabit agrégés via LACP (Link Aggregation Control Protocol) :

  • Bande passante agrégée : 4 Gbps vs 1 Gbps
  • Tolérance aux pannes : perte d’un lien → débit réduit mais service maintenu
  • Load-balancing automatique : répartition du trafic selon algorithme (généralement src-dst-ip)

Avantage architectural : Le port-channel est vu comme une interface unique logique par Spanning Tree, simplifiant la topologie.

2. Dual-homing des switches d’accès

Chaque switch Access dispose de deux uplinks :

  • Un vers Distribution-1
  • Un vers Distribution-2

Mécanisme de basculement : Spanning Tree Protocol (STP) maintient un lien en forwarding, l’autre en blocking. En cas de panne du lien actif ou du switch de distribution associé, STP converge et active le lien de secours (quelques secondes d’interruption).

Limitation acceptée : Pas de load-balancing actif/actif sur les uplinks Access (contrainte STP). Pour l’obtenir, il faudrait des technologies comme VSS (Virtual Switching System) ou StackWise, hors budget.

Défi 4 : Gestion du NAT avec Plusieurs Réseaux Internes

Problématique : Sept VLANs doivent accéder à internet via une seule IP publique. Comment router correctement le trafic et gérer les traductions d’adresses ?

Architecture retenue :

  1. VLAN de transit dédié (VLAN 250) entre switch Core et routeur

    • Raison : séparer le trafic de routage WAN du trafic utilisateur
    • Réseau /30 (2 adresses utiles suffisent pour un lien point-à-point)
  2. Route par défaut sur le Core pointant vers le routeur via ce VLAN de transit

    • Tout trafic non destiné aux réseaux internes → routeur → internet
  3. NAT Overload (PAT) sur le routeur

    • ACL identifiant tous les réseaux internes (10.50.0.0/16)
    • Traduction sur l’interface WAN du routeur
    • Port-based translation : plusieurs milliers de connexions simultanées possibles

Choix technique : Le NAT est volontairement placé sur le routeur, pas sur le switch Core, pour respecter la séparation des rôles (Core = routage interne, Routeur = passerelle WAN).

Défi 5 : Limitations du Simulateur et Contournements

Problématique majeure : Packet Tracer 9, bien qu’amélioré pour l’IPv6, présente des bugs critiques impactant la production :

Bug 1 : Routage IPv6 instable sur switches L3

  • Symptôme : Connectivité IPv6 fonctionnelle, puis perte aléatoire de paquets
  • Cause identifiée : Gestion défaillante des tables de voisinage IPv6 (NDP)
  • Solution : Abandon du routage IPv6 sur le Core, migration vers Router-on-a-Stick
  • Impact : Augmentation de la latence IPv6 (~5ms) mais stabilité retrouvée

Bug 2 : Non-persistance des ACL après redémarrage

  • Symptôme : Les ACL configurées disparaissent au redémarrage du simulateur
  • Cause : Gestion défaillante de la NVRAM simulée pour les ACL Extended
  • Solution de contournement :
    • Script de re-déploiement rapide des ACL (copy-paste préparé)
    • Sauvegarde externe du fichier .pkt après chaque configuration stable
    • Documentation exhaustive des ACL pour reconstruction rapide

Apprentissage clé : En environnement de production réel, ces bugs seraient inacceptables. Cependant, ils ont forcé une réflexion approfondie sur :

  • La documentation rigoureuse (essentielle même sans bugs)
  • Les plans de reprise d’activité
  • La validation systématique post-déploiement

Défi 6 : Services Réseau Centralisés et Accessibilité

Problématique : Le serveur DNS doit être accessible depuis tous les VLANs du site principal, mais pas depuis les sites secondaires (exigence sécurité).

Solution architecturale :

  1. Placement du DNS dans un VLAN dédié Infrastructure (200)

    • Isolation des serveurs des VLANs utilisateurs
    • Facilite l’application de politiques de sécurité strictes
  2. ACL sur l’interface SVI du VLAN Infrastructure :

    • Accepter connexions depuis 10.50.0.0/16 (tous les VLANs site principal)
    • Refuser connexions depuis 10.60.0.0/16 et 10.70.0.0/16 (sites secondaires)
    • Refuser toute initiation de connexion depuis le serveur vers les VLANs utilisateurs
  3. Configuration DHCP : Tous les pools DHCP fournissent l’IP du DNS (10.50.200.10) comme serveur DNS primaire

Bénéfice : Cette approche permet un contrôle fin. Le DNS est joignable pour résolution, mais ne peut pas être utilisé comme vecteur d’attaque (impossibilité d’initier des connexions sortantes).

Choix Technologiques et Justifications

Routage Statique vs Routage Dynamique

Choix retenu : Routage statique sur les liaisons WAN entre les trois sites.

Justification :

  • Topologie simple et stable (3 routeurs, maillage complet)
  • Pas de besoin de convergence rapide (pas de liens redondants inter-sites)
  • Consommation ressources CPU/RAM minimale
  • Sécurité : pas de risque de propagation de routes malveillantes

Alternative écartée (OSPF) :

  • Pertinent si >3 sites ou ajouts fréquents de sites
  • Overhead inutile pour cette topologie

IPv6 : Router-on-a-Stick vs Routage Distribué

Choix retenu : Router-on-a-Stick pour IPv6 (sous-interfaces 802.1Q sur le routeur principal).

Justification technique :

  • Contournement des limitations Packet Tracer
  • Centralisation du routage IPv6 simplifie le troubleshooting
  • Préparation à une migration future : toutes les routes IPv6 sont déjà sur le routeur

Inconvénient assumé :

  • Tous les flux IPv6 inter-VLANs transitent par le routeur (goulot d’étranglement théorique)
  • Acceptable car trafic IPv6 <5% du trafic total dans cette phase

En production réelle : Migration vers routage IPv6 distribué sur le Core dès que les équipements le supportent correctement.

Résultats et Enseignements

Validation Fonctionnelle

L’infrastructure déployée répond aux objectifs :

  • Segmentation : 6 VLANs utilisateurs isolés avec contrôle d’accès granulaire
  • Services centralisés : DHCP et DNS opérationnels pour tous les utilisateurs
  • Connectivité WAN : Routage inter-sites fonctionnel en IPv4 et IPv6
  • NAT : Accès internet depuis tous les VLANs avec traduction d’adresse
  • Haute disponibilité : Résilience face à la panne d’un lien ou d’un switch de distribution

Tests de Validation Effectués

Connectivité :

  • Ping inter-VLANs selon matrice d’autorisation → OK
  • Résolution DNS depuis tous les VLANs → OK
  • Accès au serveur web site secondaire → OK
  • Accès internet (ping 8.8.8.8) → OK

Sécurité :

  • Tentative connexion Comptabilité → Support Technique → Bloquée ✓
  • Tentative connexion Site Secondaire → DNS → Bloquée ✓
  • Vérification compteurs ACL (show access-lists) → Règles triggées ✓

Haute disponibilité :

  • Déconnexion d’un lien LACP → Bande passante réduite, service maintenu ✓
  • Arrêt d’un switch de distribution → Convergence STP, basculement OK ✓

Enseignements Techniques

1. L’architecture doit être résiliente aux limitations des outils

Face aux bugs Packet Tracer, l’adoption d’architectures alternatives (Router-on-a-Stick, scripts de redéploiement) a permis de maintenir les objectifs métier. En production, cette adaptabilité face aux contraintes matérielles ou logicielles est essentielle.

2. La documentation vaut autant que la configuration

Les procédures de reconstruction rapide ont été tout aussi importantes que la configuration initiale. Une infrastructure non documentée est fragile.

3. La sécurité par couches (defense in depth)

Plutôt qu’une seule ligne de défense, l’approche multicouche combinant :

  • Segmentation VLAN (isolation L2)
  • ACL (filtrage L3)
  • NAT (masquage adresses internes)
  • Services centralisés avec ACL (protection des ressources critiques)

…offre une résilience supérieure face aux menaces.

4. Les choix d’architecture ont des conséquences long-terme

Le choix initial d’une architecture hiérarchique trois niveaux facilite grandement les évolutions futures (ajout de VLANs, de sites, d’équipements). Une architecture plate aurait nécessité des refontes majeures.

5. Le routage inter-VLAN n’est pas une commodité, c’est un enjeu de conception

Le placement du routage (switch Core vs routeur) impacte :

  • Les performances (latence, débit)
  • La complexité opérationnelle
  • Les possibilités d’évolution

Le dual-stack amplifie ces enjeux en nécessitant deux architectures de routage potentiellement distinctes.

Évolutions et Perspectives

Court terme

  • Monitoring centralisé : Implémentation SNMP pour supervision des équipements
  • Optimisation STP : Configuration manuelle des priorities pour contrôler les chemins actifs
  • Logging centralisé : Serveur Syslog pour journalisation des événements réseau

Moyen terme

  • Migration IPv6 native : Basculement du routage IPv6 sur le Core lors du remplacement matériel
  • Routage dynamique WAN : OSPF si extension à plus de 5 sites
  • Redondance de passerelle : HSRP sur le Core si budget alloué pour un second switch Core

Long terme

  • SD-WAN : Pour interconnexion de multiples sites avec optimisation automatique des chemins
  • Micro-segmentation : Passage à une segmentation plus fine avec firewalls L7 entre VLANs
  • Automatisation : Scripts Ansible pour déploiement automatisé des configurations sur nouveaux équipements

Conclusion

Ce déploiement illustre que la conception d’une infrastructure réseau moderne nécessite de jongler entre contraintes techniques, exigences métier, limitations matérielles et objectifs de sécurité. Les défis rencontrés (routage dual-stack, politique de sécurité granulaire, haute disponibilité, bugs simulateur) ont nécessité des choix d’architecture pragmatiques plutôt que des solutions “parfaites” théoriques.

Les principaux apprentissages portent sur :

  • L’importance de l’adaptabilité face aux contraintes réelles
  • La valeur de la documentation et des procédures de reprise
  • La conception en couches pour la résilience
  • L’équilibre entre complexité et maintenabilité

Cette infrastructure démontre qu’une architecture bien conçue, même avec des équipements non haut-de-gamme et un simulateur imparfait, peut répondre à des exigences professionnelles strictes en matière de segmentation, de disponibilité et de sécurité.


Compétences mobilisées : Conception réseau, Architecture hiérarchique, Segmentation VLAN, Politique de sécurité, Haute disponibilité, Dual-stack IPv4/IPv6, Troubleshooting, Adaptabilité technique

Environnement : Simulation Cisco Packet Tracer 9