Architecture Réseau Redondante et Sécurisée

1. Ports trunk

Dans ce lab, les trunks sont indispensables car ils permettent aux VLANs créés sur CD1 d'être accessibles sur CD2, Acc3 et Acc4, et de remonter jusqu'aux routeurs R1 et R2 pour le routage inter-VLAN. Chaque lien entre switch sont configuré en mode trunk.

Un VLAN natif (VLAN 99) est défini sur chaque trunk. C'est le VLAN qui circule sans tag sur le lien. J'utilise un VLAN dédié (99) plutôt que le VLAN 1 par défaut pour des raisons de sécurité.

Zoom

Liens trunk entre CD1, CD2, Acc3 et Acc4

B. Vérification des configuration trunks 802.1Q

CD1 et CD2

Lien inter-core Po1 : VLANs 10, 20, 30, 99, 100, 200.

Liens vers Acc3/Acc4 : VLANs 10, 20, 30, 99 uniquement — les VLANs serveurs et DMZ ne descendent pas à la couche accès.

Acc3

Deux trunks 802.1Q vers CD1 et CD2 — VLANs 10, 20, 30, 99 (natif).

Spanning Tree répartit les VLANs entre les deux liens pour éviter les boucles réseau : VLAN 20 → Fa0/21  |  VLANs 10, 30, 99 → Fa0/24.

Acc4

Deux trunks 802.1Q vers CD1 et CD2 — VLANs 10, 20, 30, 99 (natif).

STP inverse d'Acc3 : VLANs 10, 30, 99 → Fa0/21  |  VLAN 20 → Fa0/24.

2. EtherChannel

Le lien entre CD1 et CD2 est le lien le plus critique du lab — tout le trafic inter-VLAN entre les deux switches de distribution passe par là. Il est donc logique de le rendre redondant et plus performant avec un EtherChannel plutôt qu'un simple lien trunk.

Le choix de LACP plutôt que PAgP est une bonne pratique car LACP est compatible avec tous les constructeurs, pas uniquement Cisco.

Zoom

EtherChannel LACP entre CD1 et CD2 (G1/0/2 + G1/0/3)

B. Vérification des configuration EtherChannel LACP

Les interfaces Gi1/0/2 et Gi1/0/3 sont agrégées dans le Port-Channel et toutes les deux actives (P) dans le bundle.

Le statut SU indique que le Port-Channel fonctionne correctement en couche 2 (S) et est en utilisation (U).

Cette configuration permet d'augmenter la bande passante entre les switches tout en assurant la redondance en cas de panne d'un lien physique.

3. VTP + VLANs

Dans ce lab, CD1 est configuré en tant que serveur VTP. Il centralise et gère la base de données des VLANs du réseau. Les switches CD2, Acc3 et Acc4 sont configurés en clients VTP et récupèrent automatiquement les VLANs via les liens trunk, ce qui facilite l'administration et évite de devoir créer manuellement les VLANs sur chaque switch.

Plusieurs VLANs ont été créés afin de segmenter le réseau en différents départements. Cette segmentation améliore l'organisation du réseau, réduit les domaines de broadcast et renforce la sécurité en isolant notamment les serveurs et certains équipements sensibles du reste des utilisateurs.

B. Vérification des configuration VLAN

Tous les VLANs créés sur CD1 apparaissent automatiquement sur CD2, Acc3 et Acc4 grâce à la propagation VTP via les trunks.

4. Ports access + Port Security

Les ports des switches Acc3 et Acc4 connectés aux PC ont été configurés en mode access et assignés à leur VLAN respectif. Les ports des switches CD1 et CD2 connectés aux serveurs ont également été configurés en access sur les VLANs 100 et 200.

Le Port Security a été activé sur chaque port access pour limiter à 1 seule adresse MAC par port. En cas de violation, le port se met en shutdown pour les PC et en restrict pour les serveurs. Le mode sticky permet d'apprendre automatiquement la MAC de l'équipement connecté et de la mémoriser donc pas besoin de la saisir manuellement.

Zoom

Ports access sur Acc3, Acc4, CD1 et CD2

B. Vérification des configuration ports security

Acc3

Port Security activé sur Fa0/1 — max 1 adresse MAC. Mode violation : Shutdown.

Une adresse MAC a été apprise via le mode sticky — le port se désactive automatiquement si un équipement non autorisé est connecté.

CD2

Mode violation : Restrict — les adresses MAC non autorisées sont bloquées sans désactiver le port.

Les services réseau restent disponibles tout en sécurisant les ports connectés aux serveurs.

5. Spanning Tree

Le Spanning Tree Protocol (STP) en mode PVST+ a été configuré pour éviter les boucles réseau au niveau couche 2. Puisque chaque PC et serveur est connecté à la fois à CD1 et CD2 via Acc3/Acc4, il existe plusieurs chemins possibles donc sans STP, cela créerait des boucles infinies et paralyserait le réseau.

Pour optimiser le trafic, les rôles de root bridge ont été répartis entre CD1 et CD2 en fonction des VLANs, en cohérence avec la configuration HSRP — CD1 est root sur les VLANs où il est actif HSRP, CD2 pareil. Cela garantit que le trafic L2 et L3 prend toujours le même chemin optimal.

PortFast et BPDU Guard ont été activés sur les ports access vers les PC — PortFast permet au port de passer immédiatement en état forwarding sans attendre la convergence STP, et BPDU Guard bloque le port si un switch y est connecté par erreur.

Zoom

Topologie STP PVST+ — CD1, CD2, Acc3, Acc4

B. Vérification des configuration Spanning Tree (PVST+)

CD1 pour le VLAN 10

CD1 est le Root Bridge pour le VLAN 10.

Les interfaces Gi1/0/21, Gi1/0/24 et Po1 sont en état Designated Forwarding — aucun port bloqué car le Root Bridge possède uniquement des ports désignés.

CD2 pour le VLAN 20

CD2 est le Root Bridge pour le VLAN 20.

Les interfaces Gi1/0/21, Gi1/0/24 et Po1 sont également en état Designated Forwarding.

Acc3 pour le VLAN 10

Chemin vers le Root Bridge (CD1) via Fa0/24 — état Root Forwarding (Root FWD).

Fa0/21 en état Alternate Blocking (Altn BLK) pour éviter une boucle L2.

Acc4 pour le VLAN 20

Chemin vers le Root Bridge (CD2) via Fa0/24 — état Root Forwarding (Root FWD).

Comme Acc3, Fa0/21 en état Alternate Blocking pour éviter une boucle L2.

1. ip routing + SVIs

La commande ip routing a été activée sur CD1 et CD2 pour transformer ces switches de distribution en équipements Layer 3 capables de router le trafic entre les VLANs. Une interface SVI (Switch Virtual Interface) a été créée pour chaque VLAN sur CD1 et CD2 — chaque SVI possède une adresse IP qui servira de passerelle pour les équipements de ce VLAN.

Ce choix est plus performant que le router-on-a-stick car le routage inter-VLAN se fait directement dans les switches sans remonter jusqu'aux routeurs R1/R2, qui eux ne gèrent que le trafic WAN.

B. Vérification des SVIs

Sur CD1

Les interfaces VLAN 10, 20, 30, 99, 100 et 200 sont toutes en état up/up, confirmant que les VLANs sont actifs et opérationnels.

CD1 peut ainsi assurer le routage inter-VLAN directement au niveau distribution.

Sur CD2

Les interfaces VLAN 10, 20, 30, 99, 100 et 200 sont toutes en état up/up, confirmant que les VLANs sont actifs et opérationnels.

CD2 peut ainsi assurer le routage entre les différents réseaux en cas de bascule HSRP.

2. Hot Standby Router Protocol

HSRP (Hot Standby Router Protocol) a été configuré sur les SVIs de CD1 et CD2 pour assurer la redondance de la passerelle par défaut. Chaque VLAN possède une adresse IP virtuelle (VIP) qui est la passerelle utilisée par les PC et serveurs. Si CD1 tombe, CD2 prend automatiquement le relais sans aucune interruption visible pour les utilisateurs.

Les rôles actif/standby ont été répartis entre CD1 et CD2 selon les VLANs, en parfaite cohérence avec le Spanning Tree — CD1 est actif HSRP sur les VLANs où il est root bridge STP, et CD2 pareil. Cette cohérence évite le trafic asymétrique et garantit le chemin le plus court à chaque instant.

Le preempt a été activé sur le switch actif — si CD1 tombe puis revient, il reprend automatiquement son rôle actif sans intervention manuelle.

B. Vérification du routed ports

Sur CD1

Le test ICMP effectué depuis CD1 vers l'adresse 10.10.1.2 confirme le bon fonctionnement du lien Layer 3 point à point entre CD1 et R1.

Les cinq paquets ont été transmis avec succès, validant la connectivité IP sur le réseau /30.

Sur CD2

Le test ICMP effectué depuis CD2 vers l'adresse 10.10.1.6 confirme le bon fonctionnement du lien Layer 3 entre CD2 et R2.

Cette vérification valide la configuration des interfaces routées et la communication entre les équipements Layer 3 du réseau.

3. Routed ports

Les ports G1/0/1 de CD1 et CD2 ont été convertis en interfaces Layer 3 pures avec la commande no switchport. Ces ports ne sont plus des ports switching — ils deviennent des interfaces routées avec leur propre adresse IP, exactement comme un port de routeur.

Ce choix est plus propre et plus réaliste qu'un trunk avec un VLAN dédié. Le lien entre CD1↔R1 et CD2↔R2 est un lien point à point /30 — seules deux adresses IP sont nécessaires, pas besoin d'un VLAN supplémentaire.

B. Vérification du routed ports

Sur CD1

Le test ICMP effectué depuis CD1 vers l'adresse 10.10.1.2 confirme le bon fonctionnement du lien Layer 3 point à point entre CD1 et R1.

Les cinq paquets ont été transmis avec succès, validant la connectivité IP sur le réseau /30.

Sur CD2

Le test ICMP effectué depuis CD2 vers l'adresse 10.10.1.6 confirme le bon fonctionnement du lien Layer 3 entre CD2 et R2.

Cette vérification valide la configuration des interfaces routées et la communication entre les équipements Layer 3 du réseau.

4. Adressage IP routeurs

Toutes les interfaces des routeurs R1, R2, SP1 et SP2 ont été configurées avec leurs adresses IP. R1 et R2 ont trois interfaces chacun dont une vers l'ISP, une vers les switches de distribution et une pour le lien point à point entre eux (utilisé pour la redondance et les routes flottantes).

SP1 et SP2 ont deux interfaces chacun — une vers R1/R2 et une pour le lien entre les deux ISP.

B. Vérification adressage IP

Sur R1

Les interfaces G0/0 (203.0.113.2), G0/1 (10.10.1.2) et G0/2 (10.10.20.1) sont toutes en état up/up.

R1 est correctement adressé vers SP1, CD1 et R2.

Sur R2

Les interfaces G0/0 (203.0.113.6), G0/1 (10.10.1.6) et G0/2 (10.10.20.2) sont toutes en état up/up.

R2 est correctement adressé vers SP2, CD2 et R1.

Sur SP1

Les interfaces G0/0 (203.0.113.1) et G0/1 (203.0.113.9) sont en état up/up.

SP1 est correctement adressé vers R1 et SP2.

Sur SP2

Les interfaces G0/0 (203.0.113.5) et G0/1 (203.0.113.10) sont en état up/up.

SP2 est correctement adressé vers R2 et SP1.

5. Open Shortest Path First

OSPF a été configuré sur tous les équipements : CD1, CD2, R1, R2, SP1 et SP2 en zone 0 (backbone).

CD1 et CD2 annoncent les réseaux VLAN dans OSPF pour que R1 et R2 les connaissent. R1 et R2 annoncent leurs liens WAN et redistribuent leur route statique par défaut dans OSPF pour que CD1 et CD2 sachent comment atteindre Internet.

SP1 et SP2 propagent la route par défaut vers R1/R2 via default-information originate.

La commande passive-interface a été appliquée sur toutes les SVIs de CD1 et CD2 — OSPF annonce ces réseaux mais n'envoie pas de paquets hello vers les PC et serveurs, ce qui est inutile et légèrement risqué.

B. Vérification des voisins OSPF

Sur CD1

CD1 affiche R1 (1.1.1.1) comme voisin OSPF en état FULL — l'adjacence est bien établie via le routed port G1/0/1.

L'état FULL confirme que les deux équipements ont échangé leurs bases de données de routage complètes.

Sur CD2

CD2 affiche R2 (2.2.2.2) comme voisin OSPF en état FULL via G1/0/1 — même logique que CD1.

La redondance est bien en place des deux côtés.

Sur R1

R1 affiche trois voisins OSPF en état FULL — CD1 (11.11.11.11) via G0/1, R2 (2.2.2.2) via G0/2 et SP1 (3.3.3.3) via G0/0.

R1 est bien au centre de la topologie et connecté à tous les équipements adjacents.

Sur R2

R2 affiche trois voisins OSPF en état FULL — CD2 (22.22.22.22) via G0/1, R1 (1.1.1.1) via G0/2 et SP2 (4.4.4.4) via G0/0.

La redondance est symétrique avec R1.

C. Vérification des Table de routage

R1

La table de routage de R1 montre toutes les routes OSPF apprises dynamiquement — les réseaux VLANs appris via CD1, les réseaux ISP appris via SP1.

La route S* 0.0.0.0/0 via 203.0.113.1 est la route statique par défaut vers Internet.

CD1

CD1 affiche les routes O apprises via OSPF — notamment les réseaux distants 203.0.113.x et 10.10.1.4/30 (lien CD2↔R2).

La route par défaut S* 0.0.0.0/0 via 10.10.1.2 (R1) est redistribuée dans OSPF et permet à CD1 d'atteindre Internet.

6. Routes statiques + flottantes

Des routes statiques par défaut ont été configurées sur R1, R2, CD1 et CD2 pour définir le chemin vers Internet. Sur R1 et R2, une route flottante a été ajoutée en backup — elle a une distance administrative (AD) de 10, plus élevée que la route principale (AD 1), donc elle reste inactive tant que la route principale fonctionne. Si le lien ISP tombe, la route flottante s'active automatiquement et le trafic bascule vers l'autre routeur.

CD1 et CD2 ont également une route par défaut vers R1/R2 respectivement — cette route est redistribuée dans OSPF pour que tous les équipements du réseau sachent comment atteindre Internet.

7. Network Address Translation (PAT)

Le NAT PAT (Port Address Translation) a été configuré sur R1 et R2 pour permettre aux équipements du réseau interne (10.10.0.0/16) d'accéder à Internet en utilisant l'adresse IP publique du routeur. Tous les équipements internes partagent une seule IP publique — R1 utilise 203.0.113.2 et R2 utilise 203.0.113.6. La différenciation entre les sessions se fait grâce aux numéros de ports.

L'interface G0/1 (vers CD1/CD2) est définie comme inside et G0/0 (vers SP1/SP2) comme outside. Une ACL standard autorise uniquement le trafic du réseau 10.10.0.0/16 à être traduit.

B. Vérification du NAT

Vérification des traductions NAT

Les adresses privées du réseau interne 10.10.10.0/24 sont traduites en adresse publique 203.0.113.2, permettant aux équipements internes d'accéder au réseau externe tout en masquant leurs adresses IP privées.

Statistiques NAT

On observe que plusieurs traductions dynamiques ont été créées et que les interfaces inside et outside sont correctement définies.

8. Access Control List

Une ACL a été configurée pour filtrer le trafic au niveau des SVIs.

ACL 110 simule le comportement d'une DMZ pour le VLAN 200. Elle bloque d'abord toute tentative des serveurs DMZ d'accéder au réseau interne, puis autorise uniquement le trafic sur les ports spécifiques à chaque serveur — HTTP/HTTPS pour SRV-WEB, SMTP/POP3/IMAP pour SRV-MAIL et FTP pour SRV-FTP. Seuls les services exposés sont autorisés, tout le reste est bloqué. Elle est appliquée sur la SVI VLAN 200 de CD1 et CD2.

L'ordre des règles est critique — la règle de blocage des serveurs DMZ vers le réseau interne est placée en premier, avant les permit, pour qu'elle soit évaluée en priorité.

B. Vérification des configurations ACL

L'ACL est correctement configurée sur les switchs CD1 et CD2.

9. DHCP + ip helper

Le service DHCP a été configuré sur le serveur dédié SRV-DHCP (10.10.100.10) avec un pool par VLAN utilisateur. Plutôt que de configurer le DHCP directement sur les routeurs, un serveur centralisé a été choisi — c'est la bonne pratique en entreprise car cela centralise la gestion des adresses IP.

Comme le SRV-DHCP est dans le VLAN 100 et que les PC sont dans les VLANs 10 et 20, les requêtes DHCP ne peuvent pas traverser les VLANs seules. La commande ip helper-address a été configurée sur les SVIs VLAN 10 et VLAN 20 de CD1 et CD2 — elle relaie les requêtes DHCP broadcast des PC vers l'adresse unicast du SRV-DHCP.

C. Vérification des configuration DHCP

Les pools POOL_VLAN10 et POOL_VLAN20 sont correctement configurés avec leurs passerelles et leur serveur DNS.

Les adresses sont distribuées dans les plages définies et le SRV-DHCP est joignable depuis les deux VLANs via l'ip helper-address.

1. Tests couche 2

Les tests couche 2 valident le bon fonctionnement de la commutation, de la segmentation réseau et des mécanismes de sécurité et de redondance au niveau switching.

A. EtherChannel

Scénario : Un des deux liens physiques entre CD1 et CD2 est coupé volontairement. Le trafic doit continuer à passer sur le lien restant sans interruption, prouvant que l'agrégation de liens assure bien la redondance.

1

Vérification de la communication avant la coupure

Le Port-Channel fonctionne correctement avec LACP : les interfaces Gi1/0/2 et Gi1/0/3 sont bien agrégées dans Po1.

Le ping vers 10.10.20.100 réussit, ce qui montre que la connectivité réseau passe bien par l'EtherChannel et que les SVIs sont opérationnelles pour l'intervlan.

2

Couper G1/0/2 sur CD1 et verification

L'interface Gi1/0/2 est passée en Down, donc un des liens de l'EtherChannel est tombé.

Mais Gi1/0/3 reste actif dans le Port-Channel, donc le ping fonctionne toujours : l'EtherChannel assure la redondance et évite une coupure réseau.

Test Validé : La perte d'un lien physique n'entraîne pas d'interruption du service. Le Port-channel reste actif grâce au lien G1/0/3 qui prend le relais automatiquement.

B. Spanning Tree

Scénario : CD1 est hors service. CD2 doit automatiquement devenir root bridge pour le VLAN 10, 30 et 100 et recalculer les chemins pour maintenir la connectivité L2 dans tout le réseau.

1

Vérifier l'état initial

CD1 est bien root bridge sur les VLANs 10 et 30.

2

Éteindre CD1

On simule une panne complète de CD1 en l'éteignant.

3

Vérifier que CD2 devient root bridge VLAN 10 et 30

Après extinction de CD1, CD2 détecte l'absence de root bridge et se proclame automatiquement root sur tous les VLANs.

CD2 affiche bien "This bridge is the root" sur tous les VLANs.

4

Vérifier la connectivité entre VLAN 10 et 20

Les PC peuvent toujours communiquer malgré la panne de CD1. Le trafic passe uniquement par CD2.

Test Validé : Le Spanning Tree Protocol prouve son efficacité en cas de panne d'un switch de distribution. CD2 détecte automatiquement l'absence de CD1 et recalcule la topologie pour maintenir la connectivité L2. Aucune intervention manuelle n'est nécessaire — la convergence STP garantit la continuité du service.

C. Port Security

Scénario : Un employé branche un hub sur le port access Fa0/1 afin de connecter plusieurs pc au réseau. Le port doit immédiatement passer en shutdown, prouvant que la politique de sécurité MAC est bien appliquée.

1

Vérifier l'état initial

Avant de simuler la violation, on vérifie l'état du port security sur Acc3 F0/1. Le port est en Secure-up avec une MAC autorisée et le mode violation en Shutdown.

2

Brancher un deuxième PC via hub

On branche un deuxième PC sur le port Fa0/1 de Acc3, déjà occupé par PC COMPTA. Ce port n'accepte qu'une seule adresse MAC — le branchement d'un second équipement déclenche la violation.

3

Vérification de l'état du port Fa0/1

Dès que le deuxième PC envoie du trafic, le port passe en err-disabled et toute communication est coupée. On vérifie l'état du port après la violation.

4

Remettre le port en service

Pour remettre le port en service après une violation shutdown, il faut manuellement le désactiver puis le réactiver.

Test validé : Le Port Security prouve son efficacité contre les connexions non autorisées. Dès qu'un équipement inconnu tente de se connecter sur un port protégé, le port est immédiatement désactivé.

2. Tests Couche 3

Les tests couche 3 valident le routage, la redondance des passerelles, la sécurité du trafic et l'accès à Internet.

A. HSRP

CD1 est éteint. Les PC doivent continuer à communiquer sans interruption car CD2 prend automatiquement le rôle de passerelle active via HSRP.

1

Vérifier l'état initial

On vérifie que CD1 est bien actif HSRP sur les VLANs 10, 30 et 100 et CD2 sur les VLANs 20 et 200.

2

Éteindre CD1 et vérifier que CD2 devient actif sur tous les VLANs

Après extinction de CD1, on vérifie que CD2 est maintenant actif sur tous les VLANs — y compris VLAN 10, 30 et 100 sur lesquels il était standby.

5

Rallumer CD1 et vérifier le preempt

On rallume CD1 et on vérifie qu'il reprend automatiquement son rôle actif sur les VLANs 10, 30 et 100 grâce au preempt configuré.

Test validé : HSRP prouve son efficacité en garantissant la continuité de service en cas de panne d'un switch de distribution. CD2 prend automatiquement le relais sans aucune intervention manuelle et les PC ne perdent pas leur connectivité. Lorsque CD1 revient, le preempt lui permet de reprendre immédiatement son rôle actif.

B. Routes flottantes

Le lien entre R1 et SP1 est coupé. R1 doit automatiquement basculer sur la route flottante via R2 pour maintenir l'accès à Internet, prouvant que la redondance WAN fonctionne.

1

Vérifier l'état initial

Avant la panne, on vérifie la table de routage de R1. La route par défaut principale via SP1 (203.0.113.1) doit être active avec une AD de 1. La route flottante via R2 (10.10.20.2) avec AD 10 n'apparaît pas car elle est inactive tant que la route principale fonctionne.

2

Couper le lien R1↔SP1

Après la coupure, R1 doit automatiquement activer la route flottante via R2 (10.10.20.2). On vérifie que la table de routage affiche maintenant la route flottante comme route active.

3

Communication R1 vers SP1

Le trafic passe par R2 via 10.10.20.1.

4

Réactiver le lien R1↔SP1

On réactive l'interface G0/0 de R1 et on vérifie que la route principale reprend automatiquement sa place avec AD 1, remplaçant la route flottante.

Test validé : Les routes flottantes prouvent leur utilité en assurant la redondance WAN. Lorsque le lien principal vers SP1 tombe, R1 bascule automatiquement sur le chemin de secours via R2 sans aucune intervention manuelle.

C. Network Address Translation

Un ping est lancé depuis PC COMPTA vers Internet (SP1). La table NAT de R1 est affichée pour montrer la traduction de l'IP privée en IP publique.

1

Générer du trafic vers Internet

Immédiatement après le ping, on vérifie la table NAT de R1. On doit voir la traduction entre l'IP privée du PC et l'IP publique de R1.

2

Vérifier les statistiques NAT

Les statistiques nous montrent le nombre de traductions actives et le nombre de hits sur les règles NAT.

Test validé : La table NAT de R1 affiche correctement la traduction de l'adresse IP privée du PC COMPTA vers l'adresse IP publique de R1, confirmant le bon fonctionnement du NAT/PAT et l'accès à Internet.

D. Access Control List

ACL 110 : Isolation DMZ

Un ping est lancé depuis SRV-WEB (10.10.200.10) vers PC COMPTA (10.10.10.100). La communication doit être bloquée par l'ACL 110, prouvant que les serveurs DMZ sont bien isolés du réseau interne et ne peuvent pas initier de connexions vers les utilisateurs.

1

Vérifier l'ACL 110 en place

L'ACL 110 est bien présente sur CD1 et appliquée en entrée sur la SVI VLAN 200. La séquence 10 bloque tout trafic initié depuis le sous-réseau 10.10.200.0 vers le réseau interne 10.10.10.0.

2

Lancer un ping depuis SRV-WEB vers PC COMPTA

Aucun paquet n'atteint PC COMPTA. Le trafic initié depuis la DMZ est bien bloqué dès la SVI VLAN 200.

3

Vérifier les compteurs ACL après le ping

Le compteur de la séquence 10 est passé de 4 à 8 matches — les 4 paquets ICMP ont bien été interceptés et bloqués par la règle deny.

Test validé : L'ACL 110 bloque efficacement tout trafic initié depuis la DMZ vers le réseau interne. Les 4 paquets ICMP ont été interceptés et bloqués dès la SVI VLAN 200, confirmant l'isolation de la DMZ.

ACL 110 : Accès aux serveurs DMZ depuis l'extérieur

Depuis un PC client externe, un navigateur accède à l'adresse IP du SRV-WEB en HTTP. La page web doit s'afficher, prouvant que le serveur est accessible depuis l'extérieur via le port 80.

1

Vérification de la page Web

La page index a été codée côté serveur Web.

2

Tester l'accès depuis l'extérieur

La page Web est accessible depuis l'extérieur. L'ACE permit tcp any host 10.10.200.10 eq www de l'ACL 110 fonctionne correctement.

Test validé : Les serveurs DMZ sont accessibles depuis l'extérieur sur les ports autorisés. L'ACL 110 permet le trafic HTTP entrant vers SRV-WEB (port 80), confirmant que les règles permit fonctionnent correctement en complément des règles deny.