Einführung
Die lokalen Dienste des Lantern Festival funktionieren, aber das Personal kann das Programm des anderen Bereichs noch nicht abrufen. Du stellst einen begrenzten Weg zwischen getrennten Netzen her und erhältst den Zugang zum Senderaum.
Du solltest IPv4-Adressen, einen einfachen /24-Bereich, Client-/Serverrollen und Ports erkennen, Terminalbefehle eingeben und Adressen mit ip addr ansehen können. Die vorbereiteten Linux-Knoten teilen einen Kernel; sie sind Netzwerk-Namespaces und keine getrennten physischen Rechner. Programmierung, Firewalls, dynamisches Routing und Subnetzrechnung sind nicht erforderlich.
Nutze Area Plan für echte Programmanfragen, Area A und Area B für ihre Clients sowie West Router und East Router für Routingänderungen. Jedes Terminal behält sein Verzeichnis und seinen Netzwerkzustand. Ein neuer Tab setzt den Fortschritt nicht zurück. Dieses Lab beginnt unabhängig. Die Zeiten sind Autorenschätzungen einschließlich Lesen und gewöhnlicher Fehler, ohne Zeitstudie mit Anfängern.
Den Weg zu Workshop wiederherstellen
In diesem Schritt prüfst du zuerst ein funktionierendes lokales Beispiel, bevor du ein entferntes Ziel untersuchst. Beginne in Area Plan. Wähle auf der Karte Main Stage Request from Area A. Du erwartest die Eröffnungsaufführung und den Laternenumzug, am Ende Request received from: 10.71.0.10. Gehe mit der Zurück-Schaltfläche des Browsers zurück. Wähle bei Broadcast Room Request from Area A: Auch dessen Sendesignal ist erreichbar. Diese funktionierenden Dienste müssen erhalten bleiben.
Wechsle zu Area A. Das Terminal befindet sich bereits in /home/labex/project/festival-routes/a. pwd zeigt dieses Verzeichnis. ip -4 addr show zeigt IPv4-Adressen; dev eth0 wählt die Kursschnittstelle.
pwd
ip -4 addr show dev eth0
Erwarte 10.71.0.10/24. In diesem Plan bedeutet /24, dass Adressen mit dem Anfang 10.71.0 lokal sind. Workshop nutzt ein anderes Subnetz, 10.72.0.0/24. Ein Router leitet Pakete zwischen Netzen weiter und ändert dabei ihre ursprünglichen Adressen nicht.
HTTP ist das Anfrage-/Antwortprotokoll des vorbereiteten Programmdienstes. curl fordert eine HTTP-Ressource an. --noproxy '*' umgeht Proxyeinstellungen für alle Ziele; die Anführungszeichen erhalten * als wörtliches Zeichen. -f behandelt HTTP-Fehler als Fehlschlag, -s blendet die Fortschrittsanzeige aus, und -S zeigt Fehler weiterhin an. --max-time 3 begrenzt den gesamten Versuch auf drei Sekunden. Port 8080 gehört zum vorbereiteten Programmdienst.
curl --noproxy '*' -fsS --max-time 3 http://10.71.0.10:8080/programme.txt
Lies das vollständige lokale Programm einschließlich seiner Quelladresse. Versuche jetzt Workshop. Die nächste Anfrage soll fehlschlagen; sie beschädigt das Netz nicht.
curl --noproxy '*' -fsS --max-time 3 http://10.72.0.10:8080/programme.txt
Erwarte einen Verbindungsfehler statt eines Programms. Lies sofort den nativen Exitstatus: $? enthält den Status des letzten Befehls, echo gibt ihn aus.
echo $?
Ein Status ungleich null bedeutet, dass dieser Versuch scheiterte. Verbindungsfehler (häufig 7), Zeitüberschreitung (28) und HTTP-Ablehnung (22 mit -f) beschreiben unterschiedliche Beobachtungen; keine erklärt allein jede mögliche Ursache. Ein abgewiesener Port kann bedeuten, dass der Host erreicht wurde, aber kein Dienst die Verbindung annahm. Prüfe bei Tippfehlern zuerst den richtigen Tab, die genaue Adresse und den Port und wiederhole dann die Anfrage. Setze die VM nicht zurück.
Der lokale Dienst und das dritte Netz funktionieren. Als Nächstes ist zu klären, welchen Weg West Router für Workshop wählen würde.
Die Routerentscheidung lesen
Hier unterscheidest du das Standard-Gateway eines Clients vom Zielpfad eines Routers. Beginne in Area A. ip route liest die aktive Routingtabelle; ip route get fragt den Kernel nach seiner Wegwahl, ohne eine Programmanfrage zu senden.
ip route
ip route get 10.72.0.10
Erwarte via 10.71.0.1 dev eth0: Der nächste Hop ist der benachbarte West Router. via benennt diesen Nachbarn; dev benennt die Ausgangsschnittstelle. Das beweist noch nicht, dass West Router den restlichen Weg kennt.
Wechsle zu West Router, dessen Kursverzeichnis auf /west endet. Lies Schnittstellen und Routen:
ip -4 addr show
ip route
ip route get 10.72.0.10
Die letzte Abfrage liefert voraussichtlich RTNETLINK answers: No route to host. Die LAN-Schnittstelle hat 10.71.0.1/24; transit hat 172.22.0.1/24. Der benachbarte East Router nutzt 172.22.0.2/24 und bindet Workshop mit 10.72.0.1/24 an. Broadcast Room liegt hinter der Schnittstelle broadcast von West Router, 10.73.0.1/24.
Die vorbereitete Route unreachable default metric 32760 ist beabsichtigt: Ziele ohne andere passende Route werden in dieser isolierten Übung abgewiesen. Eine normale Standardroute kann stattdessen ein Gateway nutzen. Erhalte hier die bestehende Route. metric 32760 bezeichnet ihre Präferenz gegenüber Routen mit demselben Präfix; dabei wird eine kleinere Metrik bevorzugt. Eine Route für 10.72.0.0/24 ist genauer als die Standardroute und ändert nur den Weg dieses Bereichs. Ersetze die Standardroute nicht und leere die Tabelle nicht.
Klappe in Area Plan West Router · live routing table auf, um dieselbe native Tabelle zu vergleichen. Die Karte zeigt Struktur; Programmanfragen prüfen echte Kommunikation. In diesem ersten Lab ist die Rückroute von East Router bereits vorbereitet. Nur die Zielroute von West Router fehlt.
Den begrenzten Weg ergänzen
Hier ergänzt du eine Zielroute und rufst die vollständige entfernte Ressource ab. Beginne in West Router. Dieses Terminal hat bereits administrative Rechte im Kurs-Namespace. ip route add ergänzt eine aktive Route; 10.72.0.0/24 ist der Zielbereich, via 172.22.0.2 der benachbarte Router und dev transit die Verbindung zu diesem Nachbarn.
ip route add 10.72.0.0/24 via 172.22.0.2 dev transit
Erfolg erzeugt normalerweise keine Ausgabe. Lies die Entscheidung erneut:
ip route get 10.72.0.10
Erwarte via 172.22.0.2 dev transit. Das angezeigte src gehört zu einer auf diesem Router gestarteten Anfrage; weitergeleiteter Verkehr von Area A behält seine eigene Adresse. Wechsle zu Area A und sende die echte Clientanfrage:
curl --noproxy '*' -fsS --max-time 3 http://10.72.0.10:8080/programme.txt
Erwarte Workshop, den Papierlaternen-Workshop, den Rhythmuskreis und Request received from: 10.71.0.10.
Das Programm speichern und andere Wege erhalten
In diesem Schritt speicherst du die entfernte Ressource und erhältst den lokalen Weg sowie den Senderaum. Beginne in Area A. -o remote-programme.txt speichert die empfangenen Bytes im Verzeichnis dieses Terminals. cat liest die gespeicherte Datei.
curl --noproxy '*' -fsS --max-time 3 -o remote-programme.txt http://10.72.0.10:8080/programme.txt
cat remote-programme.txt
Prüfe auch den geschützten Weg zum Senderaum:
curl --noproxy '*' -fsS --max-time 3 http://10.73.0.10:8080/programme.txt
Gehe in Area Plan zur Startseite zurück und wähle bei Workshop Request from Area A. Lies dasselbe Programm und die ursprüngliche Quelladresse. Fordere mit der Browser-Zurückfunktion erneut Main Stage und Broadcast Room an. Die aufgeklappte Routingtabelle muss die ursprünglichen Standard- und verbundenen Routen weiterhin zeigen.
Meldet add den Fehler File exists, lies ip route in West Router. replace ergänzt oder aktualisiert nur das genannte Präfix:
ip route replace 10.72.0.0/24 via 172.22.0.2 dev transit
Falls du versehentlich 10.72.1.0/24 ergänzt hast, passt es nicht zu diesem Ziel. Entferne nur diesen falschen Eintrag mit ip route del 10.72.1.0/24 und nutze dann die gezeigte richtige Route. Lies bei anderen Tippfehlern ebenfalls die Tabelle und entferne nur das zusätzlich eingetragene Präfix. Verwende niemals flush. Erhalte Adressen, ursprüngliche Routen, Verbindungen und Dienste. Wiederhole denselben Download, wenn ein Fehlschlag keine vollständige Datei hinterlassen hat. Diese Routen gelten live für die Sitzung; Neustartpersistenz ist nicht Teil des Labs.
Finde auf der Karte die beiden Transitnachbarn und vergleiche die Zielzeilen mit den erhaltenen Standardrouten. Die aufgeklappten Tabellen zeigen echte Kernelrouten im funktionierenden Lab.
Zusammenfassung
Du hast echte Zielabfragen und begrenzte Routen genutzt, um Festivalprogramme auszuliefern und ursprüngliche Adressen sowie andere Wege zu erhalten. Das Client-Gateway ist nur der erste Hop; jeder Router braucht eine nutzbare nächste Entscheidung.
