Introduction
Les services locaux du Lantern Festival fonctionnent, mais le personnel ne peut pas encore récupérer le programme de l’autre zone. Vous rétablirez un chemin ciblé entre réseaux séparés en préservant la salle de diffusion.
Vous devez reconnaître les adresses IPv4, une plage /24 simple, les rôles client/serveur et les ports, savoir saisir des commandes et afficher les adresses avec ip addr. Les nœuds Linux préparés partagent un noyau : ce sont des espaces de noms réseau, pas des machines physiques distinctes. Programmation, pare-feu, routage dynamique et calcul de sous-réseaux ne sont pas requis.
Utilisez Area Plan pour les vraies requêtes de programmes, Area A et Area B pour leurs clients, et West Router et East Router pour les modifications de routage. Chaque terminal conserve son répertoire et son état réseau. Ouvrir un onglet ne réinitialise pas la progression. Ce laboratoire démarre indépendamment. Les durées sont des estimations de l’auteur incluant lecture et erreurs courantes, sans chronométrage auprès de débutants.
Rétablir le chemin vers Workshop
Dans cette étape, vous établirez un exemple local fonctionnel avant d’étudier une destination distante. Commencez dans Area Plan. Sur la carte Main Stage, sélectionnez Request from Area A. Vous devez voir le spectacle d’ouverture et le défilé de lanternes, avec Request received from: 10.71.0.10 à la fin. Revenez avec le bouton Précédent du navigateur. Sur Broadcast Room, sélectionnez Request from Area A : sa consigne est également accessible. Ce sont des services fonctionnels à préserver.
Passez dans Area A. Son terminal se trouve déjà dans /home/labex/project/festival-routes/a. pwd affiche ce répertoire. ip -4 addr show affiche les adresses IPv4 ; dev eth0 sélectionne l’interface du cours.
pwd
ip -4 addr show dev eth0
Vous devez voir 10.71.0.10/24. Dans ce plan, /24 signifie que les adresses commençant par 10.71.0 sont locales. Workshop utilise un autre sous-réseau, 10.72.0.0/24. Un routeur transmet les paquets entre réseaux sans changer leurs adresses d’origine.
HTTP est le protocole requête/réponse du service de programmes préparé. curl demande une ressource HTTP. --noproxy '*' évite les paramètres de proxy pour toutes les destinations ; les guillemets gardent * littéral. -f considère les erreurs HTTP comme des échecs, -s masque la progression et -S affiche encore les erreurs. --max-time 3 limite toute la tentative à trois secondes. Le port 8080 correspond au service de programmes préparé.
curl --noproxy '*' -fsS --max-time 3 http://10.71.0.10:8080/programme.txt
Lisez le programme local complet et son adresse source. Essayez maintenant Workshop. La prochaine requête doit échouer ; elle n’endommage pas le réseau.
curl --noproxy '*' -fsS --max-time 3 http://10.72.0.10:8080/programme.txt
Vous devez obtenir un échec de connexion plutôt qu’un programme. Lisez immédiatement le code de sortie natif : $? contient le code de la dernière commande et echo l’affiche.
echo $?
Un code non nul indique l’échec de cette tentative. Échec de connexion (souvent 7), expiration (28) et refus HTTP (22 avec -f) sont des observations différentes ; aucune ne suffit à identifier toutes les causes. Un port refusé peut signifier que l’hôte a été atteint mais qu’aucun service n’a accepté la connexion. En cas de faute de saisie, vérifiez l’onglet, l’adresse et le port exacts, puis recommencez. Ne réinitialisez pas la VM.
Le service local et le troisième réseau fonctionnent. Il faut maintenant déterminer le chemin choisi par West Router pour Workshop.
Lire la décision du routeur
Vous distinguerez ici la passerelle par défaut du client du chemin spécifique d’un routeur. Commencez dans Area A. ip route lit la table active ; ip route get demande au noyau le chemin qu’il choisirait sans envoyer de requête de programme.
ip route
ip route get 10.72.0.10
Vous devez voir via 10.71.0.1 dev eth0 : le prochain saut est le West Router voisin. via désigne ce voisin ; dev désigne l’interface de sortie. Cela ne prouve pas que West Router connaît la suite du chemin.
Passez dans West Router, dont le répertoire de travail se termine par /west. Lisez ses interfaces et routes :
ip -4 addr show
ip route
ip route get 10.72.0.10
La dernière consultation doit produire RTNETLINK answers: No route to host. L’interface LAN vaut 10.71.0.1/24 ; transit vaut 172.22.0.1/24. Le routeur East Router voisin utilise 172.22.0.2/24 et rejoint Workshop par 10.72.0.1/24. Broadcast Room est derrière l’interface broadcast de West Router, 10.73.0.1/24.
La route préparée unreachable default metric 32760 est volontaire : les destinations sans autre correspondance sont refusées dans cet exercice isolé. Une route par défaut ordinaire peut utiliser une passerelle. Préservez celle-ci. metric 32760 indique sa préférence entre routes de même préfixe ; la métrique la plus basse est alors préférée. Une route vers 10.72.0.0/24 est plus spécifique que la route par défaut et ne change que le chemin de cette zone. Ne remplacez pas la route par défaut et ne videz pas la table.
Dans Area Plan, dépliez West Router · live routing table pour comparer la même table native. Le plan représente la structure ; les requêtes testent la communication réelle. Dans ce premier laboratoire, le retour d’East Router est déjà préparé. Seule la route de destination de West Router manque.
Ajouter le chemin ciblé
Vous ajouterez ici une route de destination et récupérerez la ressource distante complète. Commencez dans West Router. Ce terminal dispose déjà des droits administratifs dans l’espace de noms du cours. ip route add ajoute une route active ; 10.72.0.0/24 est la plage cible, via 172.22.0.2 désigne le routeur voisin et dev transit choisit le lien vers ce voisin.
ip route add 10.72.0.0/24 via 172.22.0.2 dev transit
Une réussite n’affiche normalement rien. Relisez la décision :
ip route get 10.72.0.10
Vous devez voir via 172.22.0.2 dev transit. Le src affiché concerne une requête émise par ce routeur ; le trafic transféré d’Area A garde sa propre adresse. Passez dans Area A et faites une vraie requête cliente :
curl --noproxy '*' -fsS --max-time 3 http://10.72.0.10:8080/programme.txt
Vous devez voir Workshop, l’atelier de lanternes en papier, le cercle rythmique et Request received from: 10.71.0.10.
Enregistrer le programme et préserver les autres chemins
Dans cette étape, vous enregistrerez la ressource distante et préserverez les chemins local et de diffusion. Commencez dans Area A. -o remote-programme.txt enregistre les octets reçus dans le répertoire de ce terminal. cat lit le fichier enregistré.
curl --noproxy '*' -fsS --max-time 3 -o remote-programme.txt http://10.72.0.10:8080/programme.txt
cat remote-programme.txt
Testez également le chemin de diffusion protégé :
curl --noproxy '*' -fsS --max-time 3 http://10.73.0.10:8080/programme.txt
Dans Area Plan, revenez à l’accueil et sélectionnez Request from Area A sur Workshop. Lisez le même programme et l’adresse source d’origine. Utilisez Précédent pour redemander Main Stage et Broadcast Room. La table dépliable doit toujours afficher les routes par défaut et connectées d’origine.
Si add indique File exists, lisez ip route dans West Router. replace ajoute ou met à jour uniquement le préfixe nommé :
ip route replace 10.72.0.0/24 via 172.22.0.2 dev transit
Si vous avez ajouté 10.72.1.0/24 par erreur, il ne correspond pas à cette destination. Supprimez uniquement cette entrée avec ip route del 10.72.1.0/24, puis utilisez la bonne route montrée. Pour toute autre faute de saisie, lisez la table et retirez seulement le préfixe supplémentaire ajouté. N’utilisez jamais flush. Préservez adresses, routes d’origine, liens et services. Répétez le même téléchargement si l’échec n’a pas laissé de fichier complet. Ces routes sont actives pour cette session ; leur persistance après redémarrage est hors périmètre.
Localisez les deux voisins de transit sur le plan, puis comparez les lignes de destination aux routes par défaut conservées. Les tables dépliées montrent les vraies routes du noyau dans le laboratoire fonctionnel.
Résumé
Vous avez utilisé des consultations réelles de destination et des routes ciblées pour livrer les programmes du festival, en préservant adresses et chemins indépendants. La passerelle du client n’est que le premier saut ; chaque routeur a besoin d’une prochaine décision utilisable.
