Construire une infrastructure GNS3 avec routage multi-sauts et DHCP relaye

Contexte et objectif

Cette version web reprend davantage le deroule du projet source. L enjeu n est pas seulement de montrer quelques commandes Cisco ou Linux, mais de suivre la topologie complete, d expliquer le role de chaque machine et de prouver que le DHCP traverse bien plusieurs sauts jusqu aux clients les plus eloignes.

Preparation

Guides et ressources

Revoir la base avec la passerelle Debian

Avant d executer

Une maquette GNS3 ou VirtualBox avec plusieurs segments reseau
Un routeur Cisco IOS ou une simulation equivalente dans GNS3
Deux machines Linux au minimum pour les roles de passerelle et serveur DHCP

Etape 1 Etape cle

Poser la topologie et les sous-reseaux

8 min

Nommer les segments et les roles avant toute commande.

La maquette s appuie sur un reseau physique 20.0, un domaine GNS3 intermediaire 17.0, un segment DHCP 18.0, un reseau client 19.0 et un domaine Cisco 21 a 23.

Vue d ensemble

Le routeur GNS3 relie les reseaux 17, 18 et 19. VM20 sert de passerelle Linux entre le domaine virtuel et le reseau physique. VM21 fait la liaison entre le domaine Cisco et le reseau physique. R1 transporte ensuite les requetes DHCP et le trafic vers les segments 21 et 22.

Sous-reseaux a garder en tete

192.168.17.0/24 pour la liaison VM20 vers le routeur GNS3
192.168.18.0/24 pour les serveurs DHCP
192.168.19.0/24 pour un client DHCP local GNS3
192.168.20.0/24 pour le reseau physique
192.168.21.0 a 23.0/24 pour le domaine Cisco

Routeur Cisco R1 avec helper-address — La configuration de R1 porte les helper-address qui permettront au DHCP de traverser la topologie.

Etape 2 Etape cle

Valider la passerelle Linux intermediaire VM20

10 min

Verifier que le domaine virtuel peut sortir vers le reseau physique.

VM20 porte une interface sur le reseau physique et une autre vers GNS3. Sa table de routage prouve la sortie Internet et l acces aux reseaux internes via le routeur GNS3.

Ce qu il faut verifier

La route par defaut doit sortir vers 192.168.20.254 via l interface physique, tandis que les reseaux 18 et 19 doivent passer par 192.168.17.1. Sans cette separation claire, la suite du lab est brouillee.

Commandes utiles

ip route
ip -4 -o addr show
sysctl net.ipv4.ip_forward
cat /etc/sysctl.conf | grep ip_forward

Table de routage sur VM20 — La table de routage de VM20 montre a la fois la sortie physique vers 20.254 et la delegation des reseaux 18 et 19 vers 17.1.

Test de connectivite depuis VM20 — Premier test de connectivite depuis VM20 vers le domaine virtuel relie au routeur GNS3.

Test de ping depuis VM20 vers un reseau interne — Ce second test illustre le passage de VM20 vers un equipement place plus loin dans la maquette.

Validation complementaire depuis VM20 — La validation complementaire confirme que VM20 reste correctement relie au domaine physique tout en servant de passerelle pour le domaine virtuel.

Point d attention

Si ip_forward n est pas actif, VM20 restera une machine classique et non une passerelle. La topologie semblera partiellement correcte alors que les flux ne traverseront pas les interfaces.

Etape 3 Etape cle

Valider la liaison Cisco via VM21

10 min

Confirmer que le domaine Cisco peut atteindre les reseaux plus lointains.

VM21 relie le reseau physique 20.0 au segment 23.0 ou se trouve R1. On y controle les interfaces, le forwarding et la table de routage vers 21 et 22.

Lecture de la table de routage

La route par defaut sort vers 192.168.20.254, tandis que les sous-reseaux 21 et 22 partent vers 192.168.23.1. VM21 est donc le point de jonction entre le reseau reel et le domaine Cisco simule.

Verification VM21

ip -4 -o addr show
sysctl net.ipv4.ip_forward
ip route
traceroute 192.168.18.101

Interfaces reseau de VM21 — La carte d identite reseau de VM21 montre clairement l interface cote Cisco et l interface cote reseau physique.

Activation du forwarding sur VM21 — L activation du forwarding sur VM21 est indispensable pour transformer la machine en vrai routeur Linux.

Table de routage de VM21 — La table de routage montre les reseaux 21 et 22 derriere R1, avec le reseau 23 en liaison directe.

Premier test de connectivite depuis VM21 vers le domaine Cisco.

Ping vers le reseau 21 depuis VM21 — Le ping du reseau 21 confirme l acces a un sous-reseau situe derriere R1.

Ping vers le reseau 22 depuis VM21 — Le ping du reseau 22 valide un second sous-reseau plus profond dans la topologie.

Tests complementaires sur VM21 — Les tests complementaires confirment que VM21 joint a la fois son voisin Cisco et le reseau physique.

Etape 4 Etape cle

Configurer R1 comme routeur et relais DHCP

12 min

Transporter les requetes DHCP depuis les reseaux clients jusqu aux serveurs du reseau 18.

R1 gere les reseaux 21, 22 et 23 et porte les ip helper-address sur les interfaces clientes. Il connait egalement une route par defaut vers VM21.

Role exact de R1

Le routeur Cisco ne se contente pas de router. Il transforme les broadcasts DHCP des reseaux 21 et 22 en requetes unicast grace a ip helper-address, ce qui permet a un serveur situe sur le reseau 18 de repondre.

Commandes Cisco a verifier

show ip interface brief
show ip route
show running-config | section interface
show ip dhcp relay statistics
ping 192.168.18.101 source 192.168.21.1

Interfaces de R1 dans GNS3 — L etat des interfaces confirme que R1 porte bien les trois segments 21, 22 et 23.

Table de routage de R1 — La table de routage presente les reseaux connectes du domaine Cisco.

Route par defaut de R1 — La route par defaut vers VM21 relie le routeur Cisco au reste de l infrastructure.

Configuration helper-address sur R1 — Les interfaces clientes de R1 portent les helper-address pointant vers les deux serveurs DHCP en failover.

Detail du relais DHCP sur R1 — Une seconde vue permet de confirmer la configuration du relais DHCP sur les bons segments seulement.

Test de connectivite depuis R1 vers VM21 — Le test de connectivite vers VM21 valide la jonction entre le domaine Cisco et le routeur Linux intermediaire.

Helper-address

Les interfaces clientes portent deux helper-address, un par serveur DHCP du binome de failover. L interface vers VM21 n en a pas besoin puisqu elle ne recoit pas de broadcasts DHCP clients.

Etape 5 Etape cle

Verifier les serveurs DHCP puis prouver le bout en bout cote clients

15 min

Montrer que les baux sont attribues depuis le reseau 18 jusqu aux clients distants.

Les serveurs DHCP doivent etre lisibles comme un service complet : adressage statique, service actif, relation de failover, puis preuves cote VM19 et VM22.

Ce qui prouve que le lab tient

Le signal le plus fort n est pas seulement l adresse attribuee. C est la coherence complete : baux dynamiques visibles, passerelle correcte, journaux DHCPACK, ping vers le serveur, puis sortie vers les reseaux plus lointains.

Commandes serveur et client

dhcpd -t -cf /etc/dhcp/dhcpd.conf
systemctl status isc-dhcp-server
journalctl -u isc-dhcp-server --since "1 hour ago"
ip -4 -o addr show
cat /var/lib/dhcp/dhclient.leases

Ordre de lecture conseille

Serveurs DHCP
Verifier l adressage, la configuration des sous-reseaux et le statut du service.
VM19
Controler un premier client proche pour valider le service sans le domaine Cisco.
VM22
Terminer par le client le plus eloigne pour prouver le relais DHCP sur toute la chaine.

Configuration IP statique du serveur DHCP — La configuration IP statique pose clairement les adresses de travail sur le reseau 18.

Configuration complementaire sur le serveur DHCP — Cette vue complete la configuration de base cote serveur DHCP.

Parametres du serveur DHCP — Le second ecran de configuration confirme la coherence des parametres du serveur sur le reseau 18.

Configuration DHCP des sous-reseaux — La configuration DHCP couvre les sous-reseaux distribues aux clients du lab.

Definitions de sous-reseaux DHCP — Une autre vue des definitions de sous-reseaux complete la lecture de la configuration DHCP.

Flux de service du DHCP relaye — Le flux de service rappelle que le serveur du reseau 18 distribue des baux a des clients situes beaucoup plus loin dans la chaine.

Service isc-dhcp-server actif — Le statut du service DHCP et les DHCPACK dans les journaux constituent une preuve forte de fonctionnement.

Ping du partenaire de failover — Le test vers le partenaire de failover valide la relation entre les deux serveurs DHCP.

Ping de la passerelle depuis le serveur DHCP — Le test vers la passerelle du reseau 18 confirme que le serveur rejoint correctement le routeur GNS3.

Adresse DHCP recue par VM19 — VM19 obtient bien une adresse dynamique sur le reseau 19 via le service DHCP distant.

Informations de bail DHCP sur VM19 — La seconde vue complete la lecture du bail et des informations remontees au client.

Preuve de failover DHCP sur VM19 — Le bail met en evidence la logique de failover et le fait que les deux serveurs sont bien vus par le client.

Ping de la passerelle depuis VM19 — Le ping vers la passerelle 19.1 valide le premier saut cote client.

Ping du serveur DHCP depuis VM19 — Le ping vers le serveur DHCP du reseau 18 prouve que le routage entre 19 et 18 fonctionne.

Configuration finale de VM19 — La derniere vue consolide la preuve cote client en montrant la configuration obtenue et sa stabilite.

Configuration DHCP sur VM22 — Le client distant est bien place en mode DHCP avant la demande de bail.

Adresse DHCP obtenue par VM22 — VM22 obtient une adresse IP malgre sa position tres eloignee des serveurs DHCP.

Details du bail DHCP sur VM22 — Les informations detaillees du bail completent la preuve d attribution cote client.

Fichier de leases de VM22 — Le fichier de leases constitue une preuve formelle du serveur ayant attribue le bail.

Premier test de connectivite depuis VM22 — Le premier test de connectivite valide la chaine reseau depuis le client le plus lointain.

Test complementaire depuis VM22 — Le test complementaire souligne le nombre de sauts necessaires pour rejoindre le service DHCP.

Chemin complet du DHCP depuis VM22 — La vue finale illustre le chemin complet et rend la preuve de bout en bout beaucoup plus solide.

Conclusion

Le projet devient beaucoup plus lisible quand on le suit comme une chaine complete. VM20 ouvre le domaine GNS3, VM21 raccorde le domaine Cisco, R1 relaie les broadcasts DHCP, les serveurs du reseau 18 distribuent les baux et les clients VM19 puis VM22 servent de preuves progressives.

Publier une variante plus courte centree uniquement sur ip helper-address
Isoler le failover DHCP dans un guide dedie
Completer avec une vue traceroute commentee de chaque saut du client VM22