Dossier d’Architecture Technique : Projet Impact Influence

Table des Matières

1. Contexte et Enjeux du Projet
2. Architecture Globale et Plan d’Adressage
3. Ingénierie et Choix Techniques
   • 3.1. Infrastructure WAN et Routage Dynamique (OSPF)
   • 3.2. Cœur de Réseau LAN et Haute Disponibilité (HSRP, STP, LACP)
   • 3.3. Sécurité, Segmentation et Services (VLANs, ACLs, NAT, DHCP/DNS)
4. Cartographie et Matrice des Flux
5. Plan d’Assurance Qualité (QA) et Validation

1. Contexte et Enjeux du Projet

Dans le cadre de l’expansion de l’entreprise Impact Influence, j’ai conçu et déployé une nouvelle infrastructure réseau répartie sur trois sites géographiques distincts :

• Bâtiment RED : Siège opérationnel hébergeant 6 départements (Direction, RH, Commerciaux, Finance, IT, ainsi que le serveur DNS interne).
• Bâtiment GREEN : Site d’hébergement isolé pour le serveur Web public (impactinfluence.com).
• Bâtiment BLUE : Site d’hébergement isolé pour le serveur de Messagerie (smtp et pop.impactinfluence.com).

Les enjeux techniques majeurs :

• Haute Disponibilité (HA) : Éliminer tous les points de défaillance uniques (SPOF) sur le site principal RED (en doublant les routeurs de bordure et les switches de cœur de réseau) ainsi que sur la topologie WAN.
• Sécurité et Cloisonnement : Segmenter strictement les 6 départements dans des VLANs dédiés et filtrer finement les flux inter-VLAN et WAN avec des listes de contrôle d’accès (ACLs) étendues.
• Exposition contrôlée : Rendre les serveurs Web et Mail accessibles depuis le réseau interne comme depuis l’extérieur grâce à des mécanismes de translation d’adresses (NAT Statique et PAT/Overload).

2. Architecture Globale et Plan d’Adressage

J’ai bâti l’architecture sur un modèle hiérarchique à trois niveaux (Accès / Distribution / Cœur-Bordure) pour garantir à la fois l’évolutivité du réseau et l’isolation des domaines de diffusion.

Plan d’adressage IP (RFC 1918 & Public)

Pour répondre aux besoins de segmentation du bâtiment RED et des sites distants, j’ai structuré le plan d’adressage comme suit :

Bâtiment RED (LAN Utilisateurs & Serveurs locaux)

Sites Distants (Bâtiments BLUE & GREEN)

Stratégie d’allocations IP statiques et réservées

• Switches de distribution D1 (SVI) : 10.10.x.252 (pour tous les VLANs de 10 à 60).
• Switches de distribution D2 (SVI) : 10.10.x.253 (pour tous les VLANs de 10 à 60).
• Passerelles virtuelles HSRP (VIP) : 10.10.x.254 (distribuées comme default-gateway par le DHCP).
• Serveurs critiques : DNS (10.10.10.10), MAIL (172.16.10.10 / Public : 132.186.32.65), WEB (172.16.20.10 / Public : 132.186.32.97).

3. Ingénierie et Choix Techniques

3.1. Infrastructure WAN et Routage Dynamique (OSPF)

Le cœur WAN s’appuie sur 5 routeurs interconnectés en topologie maillée (fibre optique et cuivre). Pour ne pas gaspiller d’adresses IP publiques sur les interconnexions point-à-point, j’ai découpé le bloc public 132.186.32.64/26 en sous-réseaux /30 (255.255.255.252).

• Protocole OSPF (Single Area 0) : Je l’ai déployé sur les routeurs WAN1 à WAN5 pour garantir une convergence rapide et profiter du partage de charge (ECMP) en cas de coupure d’un lien.
• Sécurisation du plan de contrôle : J’ai passé toutes les interfaces orientées vers les routeurs clients (RED-1, RED-2, BLUE, GREEN) en passive-interface. Cela bloque toute tentative de monter une adjacence OSPF non autorisée depuis un site client et évite d’annoncer les réseaux privés sur le WAN.

• Routage de bordure et redondance (Bâtiment RED) : Plutôt que d’étendre OSPF sur les routeurs de bordure RED-1 et RED-2, j’ai mis en place des routes statiques flottantes (Floating Static Routes). RED-1 envoie son trafic par défaut vers WAN1 (Distance Administrative standard de 1) et garde une route de secours vers RED-2 avec une distance administrative relevée à 10. J’ai appliqué exactement la même logique symétrique pour le retour vers les VLANs internes en répartissant la charge entre D1 (prioritaire sur les VLANs 10, 20, 30) et D2 (prioritaire sur les VLANs 40, 50, 60).

3.2. Cœur de Réseau LAN et Haute Disponibilité (HSRP, STP, LACP)

Dans le bâtiment RED, ce sont les deux switches multicouches D1 et D2 qui assurent la résilience de niveau 2 et 3.

Répartition de charge Active/Active avec HSRP & Rapid-PVST+

Au lieu de laisser le second switch de distribution dormir en attendant une panne du premier, j’ai configuré un partage de charge actif/actif par groupe de VLANs :

• Switch D1 : Je l’ai défini comme passerelle HSRP Active (Priorité 110 avec preempt) et Root Bridge Spanning-Tree (Priorité 24576) pour les VLANs 10 (DNS), 20 (IT) et 30 (FINANCE). En parallèle, il reste en Standby (Priorité HSRP 90 / STP 28672) pour les VLANs 40, 50 et 60.
• Switch D2 : Je l’ai configuré à l’exact opposé : il prend le rôle Actif et Root Bridge pour les VLANs 40 (COMMERCIAL), 50 (RH) et 60 (DIRECTION).

Le fait d’aligner systématiquement le Root Bridge Spanning-Tree avec la passerelle active HSRP est un point clé : les trames de niveau 2 montent directement vers le switch qui s’occupe du routage de niveau 3, ce qui évite de faire transiter du trafic inutilement sur le lien inter-cœur.

Agrégation de liens (EtherChannel LACP) et durcissement Trunk

Pour encaisser le trafic entre D1 et D2 et tolérer la perte d’un câble physique, j’ai agrégé 4 liens FastEthernet dans un canal logique (Port-channel 1) via le protocole LACP.

• Tous les liens Trunks (entre les cœurs et vers les switches d’accès) tournent avec l’encapsulation 802.1Q.
• Sécurité L2 : J’ai désactivé (shutdown) le VLAN 1 par défaut et je l’ai retiré des Trunks. J’ai déplacé le VLAN natif sur le VLAN 99 (non routé), et j’ai filtré les Trunks (switchport trunk allowed vlan) pour ne laisser passer que les VLANs strictement nécessaires sur chaque lien. Enfin, côté switches d’accès, j’ai forcé tous les ports utilisateurs en mode access avec spanning-tree portfast.

3.3. Sécurité, Segmentation et Services (VLANs, ACLs, NAT, DHCP/DNS)

Services d’infrastructure (DNS & DHCP redondé)

• DNS : Isolé dans le VLAN 10 (10.10.10.10), il résout les noms de domaine vers les IP publiques des serveurs (impactinfluence.com vers 132.186.32.97 et pop/smtp vers 132.186.32.65).
• DHCP : J’ai doublé le service directement sur D1 et D2. Chaque switch distribue la configuration réseau à tous les VLANs en excluant les plages réservées (.1 à .20 et .252 à .254) et pousse l’IP virtuelle HSRP (.254) comme passerelle par défaut.

/Capture%20d’écran%202026-10-22%20164326.png>

Exposition et Translation d’adresses (NAT)

• NAT Statique (Bâtiments GREEN et BLUE) : Sur les routeurs GREEN et BLUE, j’ai mis en place du NAT statique bi-directionnel (1-to-1) pour mapper les adresses privées des serveurs Web (172.16.20.10) et Mail (172.16.10.10) sur leurs adresses publiques respectives.
• NAT Overload / PAT (Bâtiment RED) : Sur les routeurs RED-1 et RED-2, j’ai combiné une ACL standard (permit 10.0.0.0 0.255.255.255) avec du PAT (overload) sur leur interface externe afin que les postes internes puissent sortir sur le WAN.

Filtrage granulaire par ACLs Étendues

J’ai posé des ACLs étendues en entrée (in) sur chaque interface SVI des switches D1 et D2. L’idée était d’appliquer un filtrage au moindre privilège (deny ip any any en fin de liste), mais sans casser les protocoles de contrôle du réseau :

1. Flux d’infrastructure autorisés : Lors de mes premiers tests d’ACLs strictes, le basculement HSRP et l’attribution IP tombaient en échec. J’ai donc explicitement ouvert en tête d’ACL les requêtes DHCP (bootpc/bootps) ainsi que les paquets Hello HSRP entre D1 et D2 (UDP 1985 vers le multicast 224.0.0.2).
2. Flux métiers autorisés : Résolution DNS (UDP 53 vers 10.10.10.10), navigation Web (TCP 80/443 vers 132.186.32.97) et messagerie (TCP 25/110 vers 132.186.32.65).
3. Asymétrie ICMP (Droits d’administration IT) : Le cahier des charges exigeait que seule l’équipe IT puisse pinguer le reste de l’infrastructure. J’ai joué sur les types ICMP : seul le VLAN 20 (IT) possède la règle permit icmp 10.10.20.0 0.0.0.255 any echo qui autorise l’envoi de requêtes Echo Request. Les autres VLANs (10, 30, 40, 50, 60) n’ont droit qu’au echo-reply : ils peuvent répondre aux pings de l’équipe IT, mais s’ils tentent d’initier un ping eux-mêmes, le paquet est immédiatement jeté par leur passerelle SVI.

4. Cartographie et Matrice des Flux

Avant d’écrire les règles d’ACLs sur les switches, j’ai cartographié l’ensemble des flux applicatifs et réseau de bout en bout.

Matrice récapitulative des flux autorisés

5. Plan d’Assurance Qualité (QA) et Validation

Une fois le déploiement terminé, j’ai déroulé un cahier de recette complet pour mettre l’architecture à l’épreuve (coupures de liens, extinction de switches et tentatives d’accès non autorisés) et valider son Maintien en Condition Opérationnelle (MCO).

5.1. Tests de Haute Disponibilité (Résilience)

5.2. Tests des Services Réseau

5.3. Tests de Sécurité et Filtrage

5.4. Tests Applicatifs de bout en bout