Einführung
Das Check-in-Gerät von Maple Yard benötigt eine bekannte Adresse, damit das Veranstaltungsteam es erkennen kann. Ein dynamischer Bereich ist vorbereitet, aber die Check-in-Reservierung fehlt und die Gateway- und DNS-Optionen für neue Geräte verweisen auf unbenutzte Adressen. Der geschützte Referenzplatz bleibt verfügbar.
Du ordnest die echte Geräteidentität ihrer Reservierung zu, korrigierst die Serveroptionen und gibst die Check-in-Lease tatsächlich frei, um sie erneut zu beziehen. Diese frische Umgebung enthält alles Nötige; sie verwendet keine Dateien oder Leases aus dem ersten Lab. Schließe das erste geführte Lab ab oder beherrsche dessen Ablauf für Bereich, Lease und Tabwechsel.
Nutze Network Desk für die Serverdatei, Check-In und Guest A für ihre eigenen Clientbefehle und Network Map für reine Beobachtung. Wie zuvor sind dies isolierte Linux-Knoten mit gemeinsamem Kernel.
Die Adresse für das richtige Gerät reservieren
In diesem Schritt gibst du dem Check-in-Gerät eine echte Lease für seine geplante Adresse. Beginne in Network Map und fordere das Referenzprogramm an, um das funktionierende Beispiel zu bestätigen. Seine Adresse muss 10.77.0.10 bleiben.
Wechsle zu Network Desk, in /home/labex/project/event-network:
cat devices.tsv
cat dhcp.conf
Das Check-in-Gerät hat MAC 02:77:00:00:00:28 und benötigt 10.77.0.20. Der Gästebereich bleibt 10.77.0.100–10.77.0.109; die Reservierung liegt außerhalb. Nur ein lesbarer Name würde das Gerät nicht identifizieren. Diese vorbereitete Übung verwendet die stabile MAC-Adresse.
Eine Zeile dhcp-host ordnet einem Gerät eine Adresse und optional einen Hostnamen zu. Hier hängt >> Inhalt an die vorhandene Datei an und erhält Bereich und Optionen. Kopiere den vollständigen wörtlichen Block:
cat >> dhcp.conf <<'CONF'
dhcp-host=02:77:00:00:00:28,10.77.0.20,check-in
CONF
Prüfe und übernimm ihn mit demselben Kursdienst wie im ersten Lab:
dnsmasq --test --conf-file=dhcp.conf
sudo systemctl restart event-dhcp
Bei einem Syntaxfehler liest du die Datei und korrigierst nur die fehlerhafte Zeile vor dem Neustart. Entferne die geschützte Einbindung nicht.
Wechsle zu Check-In. Es beginnt in seinem eigenen Clientverzeichnis und seiner Administratorshell. Fordere die echte Lease an:
dhclient -4 -v -1 -cf client.conf -pf client.pid -lf client.leases eth0
ip -4 addr show dev eth0
Erwartet wird 10.77.0.20/24. Lade Network Map neu und vergleiche die Check-in-Karte mit der geplanten Identität. Dieser Schritt prüft nur die reservierte Adresse. Gateway und DNS neuer Geräte sind absichtlich noch falsch; eine Programmanfrage von Check-In wird bis zum nächsten Schritt erwartungsgemäß scheitern. Setze die VM wegen dieses bekannten Fehlers nicht zurück.
Wirklich nutzbare Einstellungen senden
In diesem Schritt reparierst du Gateway- und DNS-Optionen und lässt die Clients diese empfangen. Beginne in Check-In:
ip route show default
cat /etc/resolv.conf
Die vorbereiteten falschen Werte sind 10.77.0.254 für das Gateway und 10.77.0.253 für DNS. An diesen Adressen gibt es keine solchen Dienste. Tatsächlicher Kursrouter und DNS sind beide 10.77.0.1. Der erste Wert steuert Verkehr außerhalb des Subnetzes, der zweite die Namensauflösung.
Wechsle zu Network Desk. dhcp-option=option:router liefert ein Gateway, dhcp-option=option:dns-server liefert DNS. Ersetze die vollständige Datei durch die richtige Einbindung, den unveränderten Bereich, die Reservierung und diese beiden Optionen. Das erste Lab hat > und das zitierte Here-Dokument erklärt:
cat > dhcp.conf <<'CONF'
conf-file=/opt/labex/event-network/server-base.conf
dhcp-range=10.77.0.100,10.77.0.109,255.255.255.0,2h
dhcp-host=02:77:00:00:00:28,10.77.0.20,check-in
dhcp-option=option:router,10.77.0.1
dhcp-option=option:dns-server,10.77.0.1
CONF
dnsmasq --test --conf-file=dhcp.conf
sudo systemctl restart event-dhcp
Eine Serveränderung überschreibt keine bereits angewendete Client-Lease. Wechsle zu Check-In. Gib die alte Lease mit -r frei; betroffen sind nur Prozess und Schnittstelle dieses Clients:
dhclient -4 -v -r -cf client.conf -pf client.pid -lf client.leases eth0
Fordere sie erneut an:
dhclient -4 -v -1 -cf client.conf -pf client.pid -lf client.leases eth0
ip route show default
cat /etc/resolv.conf
Beide Einstellungen sollten jetzt 10.77.0.1 verwenden. Die Adresse bleibt 10.77.0.20, weil die Reservierung dasselbe Gerät erkennt.
Wechsle zu Guest A und beziehe seine erste Lease in dieser Umgebung:
dhclient -4 -v -1 -cf client.conf -pf client.pid -lf client.leases eth0
ip -4 addr show dev eth0
ip route show default
cat /etc/resolv.conf
Erwartet wird eine dynamische Adresse im Gästebereich mit richtigem Gateway und DNS. Fordere das Programm an:
curl --noproxy '*' -fsS --max-time 5 http://programme.event.test:8080/programme.txt
Alle fünf Maple-Yard-Programmzeilen aus dem ersten Lab sollten erscheinen. Falls ein alter falscher Wert bleibt, prüfe, ob der Server nach der Dateiänderung tatsächlich neu gestartet und auf dem betroffenen Client freigegeben und erneut angefordert wurde. Überschreibe /etc/resolv.conf nicht manuell; das würde das Problem der Serveroption verdecken.
Neu verbinden und den Check-in bereit halten
In diesem Schritt belegst du die Reservierung durch eine echte neue Lease und speicherst die Platzressource. Wechsle zu Check-In. Lies die aktuelle Adresse vor der Freigabe:
ip -4 addr show dev eth0
Sie sollte 10.77.0.20/24 sein. Gib die Lease frei und beziehe sie erneut:
dhclient -4 -v -r -cf client.conf -pf client.pid -lf client.leases eth0
dhclient -4 -v -1 -cf client.conf -pf client.pid -lf client.leases eth0
ip -4 addr show dev eth0
Erwartet wird dieselbe reservierte Adresse. Dies war eine echte DHCP-Freigabe und ein neuer Bezug, keine manuell wiederhergestellte statische Adresse. Eine dynamische Gästezuweisung muss nicht immer dieselbe Adresse behalten.
Lade mit der empfangenen Konfiguration die Platzanweisungen herunter. Das erste Lab hat die curl-Optionen und -o erklärt:
curl --noproxy '*' -fsS --max-time 5 -o desk.txt http://desk.event.test:8080/desk.txt
cat desk.txt
Erwarteter Inhalt:
MAPLE YARD | Registration desk
Desk: North entrance
Session: Community workshop
Status: Ready for arrivals
Ist die Adresse falsch, kehre zu Network Desk zurück und vergleiche die genaue MAC-Adressbeziehung mit devices.tsv. Prüfe die korrigierte Datei, starte nur den Kurs-DHCP-Dienst neu und gib anschließend auf Check-In frei und fordere erneut an. Ein Dienstneustart oder erneutes Verbinden des Tabs allein ist keine neue Client-Lease.
Lade Network Map neu und fordere das Programm von Check-In, Guest A und reference an. Alle müssen funktionieren. Feste Check-in-Adresse, nutzbare Optionen, echter erneuter Bezug und erhaltene Dienste ergeben zusammen das fertige Netzwerk.
Vergleiche IPv4-Adresse, Gateway und DNS jeder Karte und lies danach die Programmantwort unter ihrem Button. Die zugewiesenen Gästeadressen können von diesem Beispiel abweichen.
Zusammenfassung
Du hast eine echte Geräteidentität mit einer reservierten Adresse verknüpft, Gateway- und DNS-Optionen an ihrer Quelle repariert und neue Leases auf den Clients angewendet. Anschließend hast du die Check-in-Lease freigegeben und erneut bezogen, ohne Adresse oder normalen Gästedienst zu verlieren.
Die unabhängige Challenge ändert Adressplan und Gerätebestand der Veranstaltung. Sie verwendet dieselben Werkzeuge und Mechanismen. Der Kurs hat weder DHCP-Relay, WLAN-Funkeinstellungen, Hochverfügbarkeit noch Neustartbeständigkeit konfiguriert.
