Einführung
Maple Hall verwendet jetzt zwei Software-Switches mit einem gemeinsamen Verbindungskabel. Die lokalen Besucher- und Mitarbeitergruppen sind bereits korrekt. Du führst beide Gruppen über diesen Uplink und ordnest danach ein versetztes Gerät der Mitarbeitergruppe zu, ohne vorhandene Geräte zu beeinträchtigen.
Schließe das erste Lab ab oder kenne dessen Zugangsport-Ablauf: Portplan lesen, eine genaue Mitgliedschaft entfernen, vorgesehene PVID und ungetaggte Ausgabe hinzufügen und echte Dienste/ARP beobachten. MAC/IP- und Subnetzgrundlagen werden vorausgesetzt. Diese unabhängige Szene benötigt die vorherige VM nicht.
Switch A und Switch B sind getrennte persistente Konsolen für verschiedene Netzwerk-Namespaces derselben Instanz mit gemeinsamem Kernel. Client Checks beobachtet Endgeräte; LAN Groups zeigt echten Zustand und Anfragen. Nur VLAN-Mitgliedschaft/PVID/Tag-Eigenschaften der zwei uplink-Ports und des ticket-Ports an Switch B sind änderbar. Erhalte alle Adressen, anderen Ports, Dienste, Bridges und Firewalls. Die 45 Minuten sind eine Autorenschätzung, kein gemessener Anfängertest.
Vervollständige den getaggten Uplink
In diesem Schritt unterscheidest du eine funktionierende lokale Gruppe von einem unvollständigen gemeinsamen Weg und vervollständigst beide Uplink-Enden. Öffne LAN Groups, dann Open device plan. Besucher verwenden VLAN 10, Mitarbeiter VLAN 20. Lokale Server stehen an Switch A; entfernte Server und ticket an Switch B. Die vorbereitete /24-Adresse jedes Endgeräts passt bereits zu seiner Zielgruppe.
Wechsle zu Client Checks. Nutze zuerst beide bekannten lokalen Wege mit dem Helfer aus dem ersten Lab:
python3 /opt/labex/lan-groups/checks.py request visitor local
python3 /opt/labex/lan-groups/checks.py request staff local
Lies das vollständige Programm und die Mitarbeiteranweisungen. Lasse jetzt local weg, um den Gruppenserver jenseits des Uplinks zu erreichen. Eine Zeitüberschreitung ist zu erwarten, weil der Uplink keine VLANs erlaubt. Der Helfer meldet einen Status ungleich null und die Zeitüberschreitung. Das ist hier beabsichtigt; fahre mit dem nächsten Befehl fort:
python3 /opt/labex/lan-groups/checks.py request visitor
Wechsle zu Switch A und lies seine aktuellen Portmitgliedschaften:
bridge vlan show
Wechsle zu Switch B und lies diesen anderen Switch:
bridge vlan show
Beide Konsolen beginnen in /home/labex/project/lan-groups, wirken aber in verschiedenen Switch-Namespaces. Prüfe vor jeder Änderung den Tab-Namen. Eine leere oder fehlende uplink-Zeile bedeutet, dass keine Gruppen erlaubt sind, nicht dass ein Endgerät ausgesteckt ist. Beide lokalen Gruppen können trotz unvollständigem gemeinsamen Weg funktionieren.
Das Endgerät ticket hat bereits die Mitarbeiteradresse 10.60.20.31/24, sein Port zeigt jedoch noch Besucher-VLAN 10. Diese absichtliche Abweichung wird nach dem Uplink gesondert bearbeitet. Repariere sie nicht durch Änderung der IP-Adresse.
Erlaube die Gruppen an beiden Uplink-Enden
Nun führst du zwei Gruppen über dieselbe Verbindung. Ein getaggter Uplink fügt jedem Ethernet-Frame eine IEEE-802.1Q-VLAN-Kennung hinzu, damit der nächste Switch die Gruppe kennt. Gewöhnliche Zugangsgeräte empfangen weiterhin ungetaggte Frames. Beide Enden müssen dieselben Gruppen erlauben.
Beginne in Switch A. Ergänze Besucher- und Mitarbeitermitgliedschaften für uplink. Die Befehle lassen pvid und untagged absichtlich weg: Die Verbindung führt getaggte Frames ohne native ungetaggte Gruppe:
bridge vlan add dev uplink vid 10
bridge vlan add dev uplink vid 20
Wechsle zu Switch B und konfiguriere sein Ende:
bridge vlan add dev uplink vid 10
bridge vlan add dev uplink vid 20
bridge vlan show dev uplink
Erwartet werden VLAN 10 und 20 ohne PVID- oder Egress-Untagged-Flags. Kehre zu Switch A zurück und lies auch sein Ende:
bridge vlan show dev uplink
Wechsle zu Client Checks und teste beide entfernten Wege:
python3 /opt/labex/lan-groups/checks.py request visitor
python3 /opt/labex/lan-groups/checks.py request staff
Erfasse jede Gruppe an den echten Endgeräten und beiden Uplink-Enden:
python3 /opt/labex/lan-groups/checks.py broadcast visitor
python3 /opt/labex/lan-groups/checks.py broadcast staff
Lies uplink-a und uplink-b: Besucherzeilen enthalten 802.1Q und vlan 10, Mitarbeiterzeilen vlan 20. Der entfernte Gruppenserver empfängt ARP ohne VLAN-Tag, der Server der anderen Gruppe null passende Frames. Das belegt echtes Tagging auf dem gemeinsamen Weg und ungetaggte Endgerätezustellung.
Zu diesem Zeitpunkt empfängt ticket noch Besucher-Broadcasts und keine Mitarbeiter-Broadcasts, weil sein Port die alte Mitgliedschaft behält. Das ist bis zum nächsten Schritt korrekt. Fehlt einem entfernten Server seine Gruppe, vergleiche vor dem Wiederholen beide Uplink-Tabellen; ein korrektes Ende reicht nicht. Hast du ein falsches VLAN ergänzt, entferne nur diese Zeile mit der bekannten Form bridge vlan del dev uplink vid ... im betroffenen Switch-Tab und ergänze die richtige Mitgliedschaft.
Ordne das versetzte Gerät seiner Zielgruppe zu
In diesem Schritt beendest du die Zuordnung des Ticketschalters und erhältst beide entfernten Gruppen. Beginne in Switch B. Lies zuerst den genauen aktuellen Port:
bridge vlan show dev ticket
Sein altes Besucher-VLAN ist 10, obwohl vorbereitete Adresse und Aufgabe bereits zum Personal gehören. Entferne diese Mitgliedschaft und richte Mitarbeiter-PVID sowie ungetaggte Ausgabe ein:
bridge vlan del dev ticket vid 10
bridge vlan add dev ticket vid 20 pvid untagged
bridge vlan show dev ticket
Erwartet wird nur 20 PVID Egress Untagged. IP-Adresse und VLAN-Mitgliedschaft gehören zu unterschiedlichen Schichten; eine Neuadressierung ist hier unnötig.
Wechsle zu Client Checks und nutze den echten Mitarbeiterdienst vom neu zugeordneten Endgerät:
python3 /opt/labex/lan-groups/checks.py request ticket
Wiederhole beide ursprünglichen entfernten Dienstanfragen:
python3 /opt/labex/lan-groups/checks.py request visitor
python3 /opt/labex/lan-groups/checks.py request staff
Erfasse beide Gruppen erneut:
python3 /opt/labex/lan-groups/checks.py broadcast visitor
python3 /opt/labex/lan-groups/checks.py broadcast staff
Jetzt empfängt ticket Mitarbeiter-Broadcasts und null Besucher-Broadcasts. Beide getaggten Uplink-Kopien und sämtliche Endgeräte derselben Gruppe müssen sichtbar bleiben. Ein gestoppter Dienst besteht die positiven Geschäftstests nicht; unterschiedliche Subnetze verbergen kein ARP-Leck.
Öffne LAN Groups, lade neu und fordere den Dienst auf jeder Clientkarte an, einschließlich beider Referenzen und ticket. Lies alle Ressourcen vollständig. Vergleiche über die aktuelle Mitgliedschaft beide Enden und ticket mit dem Plan. Hast du den falschen Zugangsport geändert, stelle nur dessen ursprüngliche Mitgliedschaft anhand des Plans mit dem bekannten Lösch-/Hinzufügemuster wieder her; setze die VM nicht zurück und lösche keine Bridge.
Die Bewertung liest die Konfiguration und sendet begrenzte Leseproben, ohne etwas zu reparieren. Nachbarlernen und MAC-Port-Lernen der FDB (Forwarding Database) sowie gewöhnliche Zugriffslogs können sich natürlich verändern. Dies sind temporäre kabelgebundene Gruppen einer Trainingsinstanz mit gemeinsamem Kernel, ohne Inter-VLAN-Routing oder Neustartpersistenz.
Lies die vollständige Antwort unter jedem Geräteknopf. Gruppenbeschriftungen beschreiben den Plan; erfolgreiche Anfragen und aktuelle Porttabellen zeigen das wirkliche Ergebnis.
Zusammenfassung
Du hast lokalen Erfolg von einem vollständigen Switch-übergreifenden Weg unterschieden, beide getaggten VLANs an beiden Enden erlaubt und einen neu zugeordneten Zugangsport korrigiert. Echte 802.1Q-Mitschnitte, ungetaggte Endgerätemitschnitte, vollständige Dienstantworten und erhaltene Referenzen belegen das Ergebnis. Die Challenge ändert VLAN-IDs und kombiniert dieselben Schritte.
