Einführung
Beim Lantern Festival ist die Hinroute von Main Stage zu Workshop bereits vorbereitet, doch die Antwort findet nicht zurück. Du beobachtest echte Verbindungspakete und ergänzt den fehlenden Rückweg, während bestehende Dienste erhalten bleiben.
Schließe zuerst „Den anderen Festivalbereich erreichen“ ab oder beherrsche dessen Zielabfragen sowie das Hinzufügen, Ersetzen und Wiederherstellen begrenzter Routen. 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 Rückweg reparieren und das Festivalnetz erhalten
In diesem Schritt beobachtest du beide Richtungen einer Verbindung, bevor du eine Route änderst. Diese unabhängige Umgebung enthält bereits die Route von West Router zu Workshop. Beginne in Area Plan: Fordere Main Stage aus Area A und Workshop aus Area B an. Beide lokalen Programme funktionieren. Fordere auch Broadcast Room aus Area A an. Workshop aus Area A scheitert weiterhin.
TCP (Transmission Control Protocol) baut vor diesem HTTP-Austausch eine Verbindung auf. Der Client wählt einen temporären Quellport, auch ephemerer Port genannt; die Antwort vertauscht Quell- und Zieladressen sowie Ports. Eine TCP-Verbindung beginnt mit einem SYN des Clients; der Server antwortet vor dem HTTP-Versand mit SYN-ACK. Ein SYN im Servernetz beweist nicht, dass die HTTP-Anfrage den Dienst erreicht hat. Du beobachtest echte, begrenzte Pakete auf beiden Routern.
Wechsle zu West Router. tcpdump beobachtet Pakete; -n behält numerische Adressen, -i any überwacht die Schnittstellen dieses Knotens, und -c 8 beendet nach höchstens acht passenden Paketen. Der Filter in Anführungszeichen wählt TCP-Port 8080. timeout 120 beendet zusätzlich nach zwei Minuten, falls acht Pakete ausbleiben. Das begrenzt die Sammlung und erzeugt keinen Verkehr. Paketzeilen können erst beim Beenden erscheinen. Warte vor dem Tabwechsel auf die Startmeldung und lies die gesammelten Zeilen nach dem Stoppen.
timeout 120 tcpdump -ni any -c 8 'tcp port 8080'
Warte auf listening on any, wechsle dann zu East Router und starte denselben begrenzten Beobachter:
timeout 120 tcpdump -ni any -c 8 'tcp port 8080'
Wechsle nach listening on any zu Area A und sende eine Anfrage. Die Zeitüberschreitung nach drei Sekunden ist erwartet:
curl --noproxy '*' -fsS --max-time 3 http://10.72.0.10:8080/programme.txt
echo $?
Erwarte 28. Wechsle nach dem Fehlschlag zu East Router. Läuft der Beobachter noch, drücke Ctrl+C, um ihn anzuhalten und gepufferte Paketzeilen auszugeben. Ist die Eingabeaufforderung schon zurück, lass ihn beendet. Gib in beiden Fällen sofort, vor jedem anderen Befehl, seinen Status aus:
echo $?
124 bedeutet, dass die beabsichtigte Zweiminutengrenze die Sammlung beendete. 0 kann heißen, dass tcpdump die Paketanzahl erreichte oder Ctrl+C regulär behandelte; ein unterbrochenes Wrapperprogramm kann stattdessen 130 melden. Nutze die Paketzeilen als Beleg, nicht allein den Status. Wiederhole beide Mitschnitte und die Anfrage, wenn das Fenster vor der Anfrage ablief oder nichts erfasst wurde. Die zwei Minuten bieten Zeit zum Tabwechsel; sie sind keine mit Anfängern gemessene Zusicherung.
Suche die Quelle 10.71.0.10 zum Ziel 10.72.0.10.8080, mit Flags [S], eingehend auf transit und ausgehend auf lan. Die Antwort kehrt die Adressen um: 10.72.0.10.8080 nach 10.71.0.10, mit Flags [S.], eingehend auf lan. Für sie fehlt ein funktionierender weiterer Weg. Wechsle zu West Router, stoppe dessen Beobachter bei Bedarf mit Ctrl+C und lies ebenfalls den Status:
echo $?
West sieht SYNs in Richtung Workshop, aber keine zurückkehrenden SYN-ACKs. Genaue Zeiten, ephemere Clientports und Wiederholungszahlen variieren. Die Belege grenzen den Fehler auf den Rückweg ein; sie zeigen keinen abgeschlossenen HTTP-Austausch.
Die Rückroute ergänzen
Hier gibst du dem Antwortziel eine eigene Route. Beginne in East Router. Lies die Tabelle und frage die Adresse des ursprünglichen Clients ab:
ip route
ip route get 10.71.0.10
Erwarte RTNETLINK answers: No route to host. East Router ist an 10.72.0.0/24 und das Transitnetz 172.22.0.0/24 angeschlossen, aber die Antwort ist für 10.71.0.0/24 bestimmt. Der nächste Hop muss der benachbarte West Router, 172.22.0.1, sein, nicht der entfernte Client selbst.
Nutze dieselbe begrenzte Routensyntax wie im vorherigen Lab:
ip route add 10.71.0.0/24 via 172.22.0.1 dev transit
ip route get 10.71.0.10
Erwarte via 172.22.0.1 dev transit. Wechsle zu Area A und wiederhole die Geschäftsanfrage:
curl --noproxy '*' -fsS --max-time 3 http://10.72.0.10:8080/programme.txt
Lies das vollständige Workshop-Programm und Request received from: 10.71.0.10. Erfolg umfasst jetzt Verbindungsaufbau, HTTP-Anfrage und HTTP-Antwort. Die Quelle bleibt die Adresse von Area A; Adressumsetzung oder Proxy würden den fehlenden Rückweg verdecken statt ihn zu reparieren.
Existiert die Route schon, lies die Tabelle und nutze ip route replace 10.71.0.0/24 via 172.22.0.1 dev transit. Scheitert die Anfrage weiter, vergleiche Ziel und nächsten Hop auf beiden Routern und versuche es im richtigen Clienttab erneut. Starte nicht alle Dienste neu und ändere keine Endpunktadressen.
Die anderen Wege funktionsfähig halten
Hier prüfst du beide Richtungen und das geschützte dritte Netz. Beginne in Area B und fordere Main Stage an:
curl --noproxy '*' -fsS --max-time 3 http://10.71.0.10:8080/programme.txt
Erwarte Eröffnungsaufführung, Laternenumzug und Request received from: 10.72.0.10. Fordere auch das lokale Programm und die Sendeanweisung an:
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
Wechsle zu Area A und erhalte dessen ursprüngliche lokale Verbindung und den Senderaumzugang:
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
Die Adresse ist weiterhin 10.71.0.10/24, die Client-Standardroute weiterhin via 10.71.0.1. Wechsle zu Area B und lies die entsprechenden Werte:
ip -4 addr show dev eth0
ip route show default
Seine Adresse bleibt 10.72.0.10/24, mit Standardroute via 10.72.0.1. Fordere in Area Plan alle drei Ressourcen aus Area A und Area B an. Lies Inhalt und ursprüngliche Quellidentität und klappe beide Routingtabellen auf. Die beiden ursprünglichen Routen unreachable default metric 32760 bleiben bestehen. Genauere Zielrouten erhalten Vorrang, ohne Standardrouten zu ersetzen.
Wenn du die geschützte Drittnetzroute auf East Router versehentlich löschst, stelle nur sie mit der gelehrten Ersetzungsform wieder her:
ip route replace 10.73.0.0/24 via 172.22.0.1 dev transit
Die ursprünglichen Standardrouten der Endpunkte stehen oben. Die Router-Standardrouten kannst du in deren eigenen Tabs mit ip route replace unreachable default metric 32760 wiederherstellen; wende diese Kursbefehle nicht auf das Plattformnetz an. Lies nach jeder Korrektur die Tabelle und wiederhole alle betroffenen Anfragen. Erhalte ursprüngliche verbundene Routen, Adressen, Links und Dienstprozesse. Die Prüfungen beobachten nur lesend und senden gewöhnliche GET-Anfragen; sie ergänzen keine Routen und reparieren die Umgebung nicht. Gleichwertige genaue Routen im angegebenen entfernten Bereich sind zulässig.
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. Außerdem hast du Verbindungsanfragen und Antworten mit begrenzten Live-Mitschnitten unterschieden.
