Introduction
Le Lantern Festival dispose déjà du chemin aller de Main Stage à Workshop, mais la réponse ne peut pas revenir. Vous observerez de vrais paquets de connexion et réparerez le retour manquant en préservant les services existants.
Terminez d’abord « Atteindre l’autre zone du festival », ou maîtrisez ses consultations de destination, ajouts/remplacements de routes ciblées et procédures de récupération. 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 retour et préserver le réseau du festival
Dans cette étape, vous observerez les deux sens d’une connexion avant de changer une route. Ce scénario indépendant possède déjà la route de West Router vers Workshop. Commencez dans Area Plan : demandez Main Stage depuis Area A et Workshop depuis Area B. Les deux programmes locaux fonctionnent. Demandez aussi Broadcast Room depuis Area A. Workshop depuis Area A échoue toujours.
TCP (protocole de contrôle de transmission) établit une connexion avant cet échange HTTP. Le client choisit un port source temporaire, dit éphémère ; la réponse inverse adresses et ports source et destination. Une connexion commence par un SYN du client ; le serveur répond par SYN-ACK avant l’envoi d’HTTP. Voir un SYN sur le réseau du serveur ne prouve pas que la requête HTTP a atteint le service. Vous observerez du trafic réel et borné sur les deux routeurs.
Passez dans West Router. tcpdump observe les paquets ; -n garde les adresses numériques, -i any observe les interfaces de ce nœud et -c 8 arrête après huit paquets correspondants au maximum. Le filtre entre guillemets sélectionne TCP 8080. timeout 120 arrête aussi après deux minutes si huit paquets n’arrivent pas. Cela limite la collecte sans créer de trafic. Les lignes peuvent n’apparaître qu’à l’arrêt. Attendez le message de démarrage avant de changer d’onglet, puis lisez les lignes après l’arrêt.
timeout 120 tcpdump -ni any -c 8 'tcp port 8080'
Attendez listening on any, passez dans East Router et démarrez le même observateur borné :
timeout 120 tcpdump -ni any -c 8 'tcp port 8080'
Après listening on any, passez dans Area A et faites une requête. L’expiration à trois secondes est prévue :
curl --noproxy '*' -fsS --max-time 3 http://10.72.0.10:8080/programme.txt
echo $?
Vous devez voir 28. Passez dans East Router après l’échec. Si l’observateur fonctionne encore, appuyez sur Ctrl+C pour l’arrêter et afficher les lignes en mémoire. Si l’invite est déjà revenue, laissez-le arrêté. Dans les deux cas, affichez immédiatement son code avant toute autre commande :
echo $?
124 indique que la limite volontaire de deux minutes a arrêté la collecte. 0 peut indiquer que tcpdump a atteint son nombre de paquets ou traité Ctrl+C normalement ; un programme enveloppant interrompu peut afficher 130. Les lignes de paquets sont la preuve, pas le seul code de l’observateur. Recommencez les deux captures et la requête si le délai s’est écoulé avant celle-ci ou si aucun paquet n’a été capturé. Les deux minutes laissent le temps de changer d’onglet ; ce n’est pas une garantie mesurée auprès de débutants.
Cherchez la source 10.71.0.10 vers 10.72.0.10.8080, avec Flags [S], entrant par transit et sortant par lan. La réponse inverse les adresses : 10.72.0.10.8080 vers 10.71.0.10, avec Flags [S.], entrant par lan. Elle n’a pas de route utilisable pour continuer. Passez dans West Router, appuyez sur Ctrl+C si son observateur fonctionne encore, puis lisez aussi son code :
echo $?
West voit les SYN partant vers Workshop mais aucun SYN-ACK revenir. Heures exactes, ports éphémères et retransmissions varient. Ces éléments situent le défaut sur le retour ; ce n’est pas un échange HTTP terminé capturé.
Ajouter la route de retour
Vous donnerez ici une route à la destination de la réponse. Commencez dans East Router. Lisez sa table et interrogez l’adresse du client d’origine :
ip route
ip route get 10.71.0.10
Vous devez voir RTNETLINK answers: No route to host. East Router est relié à 10.72.0.0/24 et au transit 172.22.0.0/24, mais la réponse vise 10.71.0.0/24. Le prochain saut doit être West Router, son voisin 172.22.0.1, pas le client distant lui-même.
Utilisez la même syntaxe de route ciblée que précédemment :
ip route add 10.71.0.0/24 via 172.22.0.1 dev transit
ip route get 10.71.0.10
Vous devez voir via 172.22.0.1 dev transit. Passez dans Area A et recommencez la requête métier :
curl --noproxy '*' -fsS --max-time 3 http://10.72.0.10:8080/programme.txt
Lisez le programme complet de Workshop et Request received from: 10.71.0.10. La réussite comprend maintenant la négociation TCP, la requête HTTP et sa réponse. La source reste Area A ; traduction d’adresses ou proxy masqueraient le retour manquant au lieu d’en enseigner la réparation.
Si la route existe déjà, lisez la table et utilisez ip route replace 10.71.0.0/24 via 172.22.0.1 dev transit. Si l’échec persiste, comparez destination et prochain saut sur les deux routeurs, puis recommencez depuis le bon onglet client. Ne redémarrez pas tous les services et ne changez pas les adresses des extrémités.
Conserver les autres chemins
Vous testerez ici les deux sens et le troisième réseau protégé. Commencez dans Area B et demandez Main Stage :
curl --noproxy '*' -fsS --max-time 3 http://10.71.0.10:8080/programme.txt
Vous devez voir le spectacle d’ouverture, le défilé et Request received from: 10.72.0.10. Demandez aussi le programme local et la consigne de diffusion :
curl --noproxy '*' -fsS --max-time 3 http://10.72.0.10:8080/programme.txt
curl --noproxy '*' -fsS --max-time 3 http://10.73.0.10:8080/programme.txt
Passez dans Area A et préservez ses accès local et de diffusion d’origine :
ip -4 addr show dev eth0
ip route show default
curl --noproxy '*' -fsS --max-time 3 http://10.71.0.10:8080/programme.txt
curl --noproxy '*' -fsS --max-time 3 http://10.73.0.10:8080/programme.txt
L’adresse reste 10.71.0.10/24 et la route par défaut du client reste via 10.71.0.1. Passez dans Area B et lisez les valeurs correspondantes :
ip -4 addr show dev eth0
ip route show default
Son adresse reste 10.72.0.10/24, avec la route par défaut via 10.72.0.1. Dans Area Plan, demandez les trois ressources depuis Area A et Area B. Lisez contenu et source d’origine, puis dépliez chaque table. Les deux routes initiales unreachable default metric 32760 subsistent. Les routes ciblées prennent priorité sans remplacer les routes par défaut.
Si vous supprimez par erreur la route protégée du troisième réseau sur East Router, restaurez uniquement cette entrée avec la forme de remplacement déjà enseignée :
ip route replace 10.73.0.0/24 via 172.22.0.1 dev transit
Les routes par défaut initiales des extrémités figurent ci-dessus. Celles des routeurs se restaurent dans leurs propres onglets avec ip route replace unreachable default metric 32760 ; n’exécutez pas ces commandes sur le réseau de la plateforme. Relisez la table après chaque correction et recommencez toutes les requêtes concernées. Préservez routes connectées, adresses, liens et processus d’origine. Les contrôles font des observations en lecture seule et des GET ordinaires ; ils n’ajoutent jamais de route et ne réparent rien. Des routes précises équivalentes dans la plage distante indiquée sont acceptées.
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. Vous avez aussi distingué demandes de connexion et réponses grâce à des captures réelles bornées.
