Transporter les deux groupes sur la liaison

LinuxBeginner
Pratiquer maintenant

Introduction

Maple Hall utilise désormais deux commutateurs logiciels reliés par un câble partagé. Les groupes locaux visiteurs et personnel sont déjà corrects. Vous devez transporter les deux groupes sur cette liaison, puis placer un appareil réaffecté dans le groupe du personnel sans perturber les appareils existants.

Terminez le premier laboratoire ou maîtrisez son processus d’accès : lire le plan, supprimer une appartenance précise, ajouter le PVID prévu et la sortie sans étiquette, et observer de vrais services/ARP. Les bases MAC/IP et sous-réseaux sont nécessaires. Ce scénario indépendant ne dépend pas de la VM précédente.

Switch A et Switch B sont des consoles persistantes distinctes pour des espaces de noms séparés d’une instance au noyau partagé. Client Checks observe les terminaux ; LAN Groups affiche l’état et les requêtes réels. Seules les appartenances VLAN/PVID/propriétés d’étiquetage des deux ports uplink et du port ticket de Switch B sont modifiables. Préservez les adresses, autres ports, services, ponts et pare-feu. Les 45 minutes sont une estimation de l’auteur, sans essai auprès de débutants.

Terminer la liaison étiquetée

Dans cette étape, vous distinguerez un groupe local fonctionnel d’un chemin partagé incomplet, puis terminerez ses deux extrémités. Ouvrez LAN Groups, puis Open device plan. Les visiteurs utilisent le VLAN 10, le personnel le VLAN 20. Les serveurs locaux sont sur Switch A ; les serveurs distants et ticket, sur Switch B. L’adresse /24 préparée de chaque terminal correspond déjà à son groupe prévu.

Passez à Client Checks. Testez d’abord les deux chemins locaux fonctionnels avec l’outil du premier laboratoire :

python3 /opt/labex/lan-groups/checks.py request visitor local
python3 /opt/labex/lan-groups/checks.py request staff local

Lisez le programme et les consignes complets. Omettez maintenant local pour viser le serveur du même groupe au-delà de la liaison. Un délai de connexion dépassé est attendu, car aucun VLAN n’est autorisé sur la liaison. L’outil renvoie un état non nul et signale le délai dépassé. C’est prévu ici ; poursuivez avec la commande suivante :

python3 /opt/labex/lan-groups/checks.py request visitor

Passez à Switch A et lisez ses appartenances réelles :

bridge vlan show

Passez à Switch B et lisez cet autre commutateur :

bridge vlan show

Les consoles démarrent toutes deux dans /home/labex/project/lan-groups, mais agissent dans des espaces de noms différents. Vérifiez le nom de l’onglet avant chaque changement. Une ligne uplink vide ou absente signifie qu’aucun groupe n’est autorisé, et non qu’un terminal est débranché. Les deux groupes locaux peuvent fonctionner malgré le chemin partagé incomplet.

Le terminal ticket possède déjà l’adresse du personnel 10.60.20.31/24, mais son port affiche toujours le VLAN visiteur 10. Ce décalage délibéré sera traité après la liaison. Ne le corrigez pas en changeant l’adresse IP.

Autoriser les groupes aux deux extrémités

Vous allez faire passer deux groupes sur le même lien. Une liaison étiquetée ajoute un identifiant VLAN IEEE 802.1Q à chaque trame Ethernet pour que le commutateur suivant connaisse son groupe. Les terminaux ordinaires continuent de recevoir des trames sans étiquette. Les deux extrémités doivent autoriser les mêmes groupes.

Commencez dans Switch A. Ajoutez les appartenances visiteurs et personnel à uplink. Les commandes omettent volontairement pvid et untagged : le lien transporte des trames étiquetées, sans groupe natif non étiqueté :

bridge vlan add dev uplink vid 10
bridge vlan add dev uplink vid 20

Passez à Switch B et configurez son extrémité :

bridge vlan add dev uplink vid 10
bridge vlan add dev uplink vid 20
bridge vlan show dev uplink

Attendez les VLAN 10 et 20, sans indicateurs PVID ni Egress Untagged. Revenez dans Switch A pour lire aussi son extrémité :

bridge vlan show dev uplink

Passez à Client Checks et testez les deux chemins distants :

python3 /opt/labex/lan-groups/checks.py request visitor
python3 /opt/labex/lan-groups/checks.py request staff

Capturez chaque groupe sur les terminaux réels et les deux extrémités de la liaison :

python3 /opt/labex/lan-groups/checks.py broadcast visitor
python3 /opt/labex/lan-groups/checks.py broadcast staff

Lisez uplink-a et uplink-b : les lignes visiteurs contiennent 802.1Q et vlan 10 ; celles du personnel, vlan 20. Le serveur distant du même groupe reçoit ARP sans étiquette VLAN ; l’autre groupe reçoit zéro trame correspondante. Cela démontre un étiquetage réel sur le lien partagé et une remise sans étiquette aux terminaux.

À ce stade, ticket reçoit encore les diffusions visiteurs et manque celles du personnel, car son port garde l’ancienne appartenance. C’est prévu jusqu’à l’étape suivante. Si un serveur distant manque son propre groupe, comparez les deux tables de liaison avant de réessayer ; un seul côté correct ne suffit pas. Si vous ajoutez un mauvais VLAN, supprimez uniquement cette ligne avec la forme déjà enseignée bridge vlan del dev uplink vid ... dans le bon onglet, puis ajoutez l’appartenance prévue.

Placer l’appareil réaffecté dans son groupe prévu

Dans cette étape, vous terminerez la réaffectation de ticket en préservant les deux groupes distants. Commencez dans Switch B. Lisez d’abord le port actuel exact :

bridge vlan show dev ticket

Son ancien VLAN visiteur est 10, bien que son adresse et son rôle appartiennent déjà au personnel. Supprimez cette appartenance, puis installez le PVID du personnel et la sortie sans étiquette :

bridge vlan del dev ticket vid 10
bridge vlan add dev ticket vid 20 pvid untagged
bridge vlan show dev ticket

Attendez uniquement 20 PVID Egress Untagged. Adresse IP et appartenance VLAN relèvent de couches distinctes ; aucun changement d’adresse n’est nécessaire.

Passez à Client Checks et utilisez le vrai service du personnel depuis l’appareil réaffecté :

python3 /opt/labex/lan-groups/checks.py request ticket

Répétez les deux requêtes distantes d’origine :

python3 /opt/labex/lan-groups/checks.py request visitor
python3 /opt/labex/lan-groups/checks.py request staff

Capturez à nouveau les deux groupes :

python3 /opt/labex/lan-groups/checks.py broadcast visitor
python3 /opt/labex/lan-groups/checks.py broadcast staff

Désormais ticket reçoit les diffusions du personnel et zéro de visiteurs. Les deux copies étiquetées du lien et tous les terminaux du même groupe doivent rester visibles. Un service arrêté ne passe pas les tests positifs ; des sous-réseaux différents ne masquent pas une fuite ARP.

Ouvrez LAN Groups, rechargez et demandez le service sur toutes les cartes, y compris les deux références et ticket. Lisez les ressources complètes. Ouvrez l’appartenance actuelle pour comparer les deux extrémités et ticket au plan. Si vous avez modifié un autre port d’accès, restaurez uniquement son appartenance d’origine selon le plan, avec le modèle suppression/ajout enseigné ; ne réinitialisez pas la VM et ne supprimez pas le pont.

L’évaluation lit la configuration et envoie des sondes de lecture bornées sans la réparer. L’apprentissage des voisins et des correspondances MAC-port de la FDB (Forwarding Database), ainsi que les journaux ordinaires, peuvent évoluer naturellement. Ce sont des groupes filaires temporaires d’une instance au noyau partagé, sans routage entre VLAN ni persistance après redémarrage.

Requêtes réelles terminées dans LAN Groups

Lisez la réponse complète sous chaque bouton. Les étiquettes décrivent le plan ; les requêtes réussies et les tables actuelles montrent le résultat réel.

Résumé

Vous avez distingué réussite locale et chemin complet entre commutateurs, autorisé les deux VLAN étiquetés aux deux extrémités et corrigé un port réaffecté. Les vraies captures 802.1Q, les captures non étiquetées des terminaux, les réponses complètes et les références préservées démontrent le résultat. Le défi change les ID VLAN et combine les mêmes opérations.