⚠️ 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épartement | Besoins Spécifiques | Niveau de Privilège |
|---|---|---|
| Management Exécutif | Accès total sauf Support Technique | Élevé |
| Gestion du Personnel | Communication inter-départements | Moyen |
| Développement Commercial | Accès serveur web + DNS | Moyen |
| Comptabilité | Isolation renforcée | Moyen |
| Support Technique | Accès administratif complet | Administrateur |
| Infrastructure | Serveurs et services partagés | Critique |
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 :
- Le trafic IPv6 reste marginal dans cette phase de transition
- La stabilité prime sur l’optimisation absolue
- 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 :
Principe du moindre privilège : tout est interdit par défaut, autorisation explicite uniquement
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
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 :
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)
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
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 :
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
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
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