Einführung
Riverlight Gathering besitzt bereits einen funktionierenden IPv4-Veranstaltungsführer. Besucher benötigen denselben vollständigen Inhalt über IPv6, einschließlich Anreiseinformationen und herunterladbarem Programm. Die Netzwerkadressen sind vorbereitet, doch der Webdienst lauscht noch nicht auf IPv6 und der AAAA-Eintrag zeigt auf die falsche Adresse.
Du trennst diese Probleme: Zuerst ermöglichst du direkten IPv6-Zugriff auf die Anwendung, danach korrigierst du den Namen. IPv4, der Empfang, andere DNS-Einträge und sämtliche Originalbytes der Seiten und Downloads bleiben erhalten. Voraussetzungen sind grundlegende Terminal-, Pfad- und Tab-Bedienung sowie das Erkennen von Adressen, Namen und Ports; Nginx- oder IPv6-Administration wird nicht vorausgesetzt. Die 70 Minuten sind eine Schätzung des Autors.
Guide Server und Guide Client sind isolierte Netzwerkknoten mit gemeinsamem Kernel dieser Trainingsinstanz, keine getrennten VMs. Ändere nur die Listener-Anweisungen in guide.conf und den Ziel-AAAA/SOA-Serienwert in guide.zone; speichere Downloads im Client-Arbeitsbereich. Ändere keine Routen, Adressen, IPv6-Schalter, anderen Sites, Quellseiten oder Plattformparameter. Dieses vorbereitete lokale Netz umfasst kein öffentliches IPv6, RA, DHCPv6, Tunnel oder NAT64.
Die Adressfamilien vergleichen
In diesem Schritt liest du den funktionierenden IPv4-Führer und unterscheidest eine erreichbare IPv6-Adresse von einer lauschenden Anwendung. Beginne in Guide Client. Das Terminal startet in /home/labex/project/ipv6-guide/client; seine Shell und sein Verzeichnis bleiben unabhängig von Guide Server bestehen. pwd zeigt das aktuelle Verzeichnis:
pwd
IPv4-Adressen haben vier Dezimalteile, etwa 10.77.0.10. IPv6 verwendet acht Gruppen hexadezimaler Ziffern. Führende Nullen einer Gruppe dürfen entfallen; ein einziges :: ersetzt eine Folge vollständig aus Nullen bestehender Gruppen. Hier bedeutet fd77:7::10 die Adresse fd77:0007:0000:0000:0000:0000:0000:0010. Die letzte 10 ist hexadezimal, nicht der dezimale Endteil der IPv4-Adresse. Diese privaten Trainingsadressen bedeuten keine Erreichbarkeit im öffentlichen Internet.
curl ruft eine HTTP-Ressource ab. -4 erzwingt IPv4, -f behandelt HTTP-Fehlerantworten als Fehler, -s verbirgt den Fortschritt und -S zeigt trotzdem Fehler an. --noproxy '*' umgeht Proxys für alle Hosts; die Anführungszeichen halten * wörtlich, statt Dateinamen zu expandieren. Port 8080 wählt die Führer-Anwendung. -o speichert empfangene Bytes in einer Datei; v4 ist ein vorbereitetes Ausgabeverzeichnis:
curl --noproxy '*' -4 -fsS http://guide.riverlight.test:8080/index.html -o v4/index.html
Erfolgreiches Speichern gibt normalerweise nichts aus. head -c 180 liest die ersten 180 Bytes, ohne die Datei zu ändern:
head -c 180 v4/index.html
Erwarte HTML mit Riverlight Gathering. Dies ist die funktionierende Referenz, die du erhalten sollst. Für die vollständige Browserdarstellung brauchst du zusätzlich das Stylesheet, das du später speicherst.
Teste nun die vorbereitete IPv6-Adresse. ping -6 sendet IPv6-Echoanfragen; -c 1 beendet den Vorgang nach einer Anfrage. Dies prüft Netzwerkerreichbarkeit und nicht HTTP:
ping -6 -c 1 fd77:7::10
Eine Antwort wird erwartet. Eine wörtliche IPv6-Adresse in einer URL benötigt eckige Klammern, um ihre Doppelpunkte vom Porttrenner zu unterscheiden. Setze die gesamte URL in Anführungszeichen. -6 erzwingt IPv6; --max-time 3 begrenzt die Anfrage auf drei Sekunden:
curl --noproxy '*' -6 -fsS --max-time 3 'http://[fd77:7::10]:8080/'
Diese Anfrage soll erwartungsgemäß fehlschlagen, mit curl: (7) und abgelehnter Verbindung. Die IPv6-Adresse existiert und beantwortet Echoanfragen, aber die Anwendung hat diesen IPv6-Endpunkt nicht geöffnet. Ein Timeout bedeutet hingegen, dass innerhalb der Frist keine nutzbare Antwort ankam; das unterscheidet sich von sofortiger Ablehnung. Deaktiviere IPv6 nicht als Lösung. Ein normaler Dual-Stack-Browser kann über IPv4 erneut versuchen; eine dort sichtbare Seite beweist daher keinen IPv6-Erfolg.
Ein falsch geschriebener Name kann curl-Fehler 6 auslösen: Die Namensauflösung ist fehlgeschlagen. Vergleiche die Schreibweise und wiederhole den ersten Befehl. Ein falscher Speicherpfad erzeugt einen lokalen Schreibfehler; prüfe pwd und den angegebenen Pfad v4/index.html. Beide unterscheiden sich von HTTP 404, bei dem ein erreichbarer Server eine fehlende Ressource meldet.
Den Webdienst auf IPv6 lauschen lassen
In diesem Schritt erhältst du den funktionierenden IPv4-Listener und ergänzt einen getrennten IPv6-Listener. Wechsle zu Guide Server. Das Terminal beginnt in /home/labex/project/ipv6-guide/config. cat liest die vorbereitete Endpunkttabelle und die kurze Zielkonfiguration:
cat endpoints.tsv
cat guide.conf
Der Führer gehört auf 10.77.0.10 und fd77:7::10, Port 8080. Der Empfang verwendet Port 8081; er bleibt erhalten. server_name wählt den Namen dieser Site, root den Ort ihrer Originalseiten und index die Startseite. Geschweifte Klammern gruppieren einen Server; jede Direktive endet mit einem Semikolon.
ss liest die Sockets des Kernels. -l wählt Listener, -t TCP, -n numerische Adressen und Ports und -p die zugehörigen Prozesse:
ss -ltnp
Finde Nginx auf IPv4 10.77.0.10:8080; für den Führer gibt es noch keinen IPv6-Listener. Der IPv6-Socket :8081 des Empfangs bedient nicht den Führer-Port.
Du ersetzt die gesamte kurze Datei durch eine vollständige Vorlage. cat > guide.conf schreibt in diese Datei und ersetzt ihren bisherigen Inhalt. <<'NGINX' startet ein Here-Dokument: Die Shell übernimmt alle folgenden Zeilen wörtlich bis zur Zeile, die nur NGINX enthält. Füge den ganzen Block einschließlich Endmarker ein. Zunächst legt cp eine lokale Sicherung an; der zweite Dateiname bezeichnet die Kopie:
cp guide.conf guide.conf.before
cat > guide.conf <<'NGINX'
server {
listen 10.77.0.10:8080;
listen [fd77:7::10]:8080 ipv6only=on;
server_name guide.riverlight.test;
root /opt/labex/ipv6-guide/www;
index index.html;
error_page 404 /404.html;
}
NGINX
listen öffnet einen Anwendungsendpunkt. Die neue Adresse in eckigen Klammern ist IPv6; ipv6only=on beschränkt diesen Listener auf IPv6. Die erhaltene IPv4-Zeile bedient IPv4 unabhängig. Eine Adresskonfiguration allein könnte diesen lauschenden Socket nicht erzeugen.
Der vorbereitete Befehl guide-control prüft oder lädt nur den unabhängigen Dienst dieses Kurses. web-check führt den Nginx-Konfigurationstest aus, ohne Änderungen zu übernehmen:
guide-control web-check
Erwarte syntax is ok und test is successful. Bei einem falsch eingegebenen Semikolon, einer Klammer oder Adresse nennt der Fehler Datei und Zeile. Es wurde nichts geladen. Wiederhole die vollständige Vorlage und prüfe erneut. Mit cp guide.conf.before guide.conf kannst du die ursprüngliche funktionierende IPv4-Konfiguration wiederherstellen; prüfe sie vor dem Laden. Starte weder Plattform-Nginx noch das Netzwerk neu.
web-load prüft erneut und fordert dann ein Neuladen an. Dabei bleibt der Kurs-Masterprozess erhalten, während die gespeicherte Konfiguration wirksam wird. Eine gespeicherte Datei allein verändert den Dienst nicht:
guide-control web-load
ss -ltnp
Nginx sollte sowohl 10.77.0.10:8080 als auch [fd77:7::10]:8080 besitzen. Meldet das Log einen belegten Endpunkt, vergleiche die Datei mit der vollständigen Vorlage und lies ss; stoppe keinen fremden Dienst.
Wechsle zu Guide Client. -w gibt nach dem Antwortinhalt Verbindungsfakten aus. Das zitierte Format enthält \n für einen Zeilenumbruch; curl ersetzt %{remote_ip} durch die tatsächliche Gegenstellenadresse und %{http_code} durch den Antwortstatus:
curl --noproxy '*' -6 -fsS --max-time 3 -w '\npeer=%{remote_ip} status=%{http_code}\n' 'http://[fd77:7::10]:8080/'
Erwarte Riverlight-HTML und anschließend peer=fd77:7::10 status=200. Lies den Inhalt ebenso wie den Status: Eine fremde Standardseite mit 200 wäre falsch. Die erfolgreiche direkte Anfrage grenzt die Anwendungsschicht ein; den Namen des Führers hast du noch nicht korrigiert.
Den Namen auf den funktionierenden IPv6-Dienst zeigen lassen
In diesem Schritt korrigierst du nur den Ziel-AAAA und lässt einen echten Cache natürlich aktualisieren. Beginne in Guide Client. DNS, das Domain Name System, ordnet Namen Daten zu. Ein A-Eintrag liefert IPv4, AAAA liefert IPv6. Die DNS-Abfrage selbst kann über IPv4 laufen und trotzdem eine IPv6-Adresse liefern.
dig fragt DNS ab. @10.77.0.2 wählt den vorbereiteten autoritativen Server, der diese Zone verwaltet. +noall +answer blendet andere Abschnitte aus und zeigt Antwortzeilen:
dig @10.77.0.2 guide.riverlight.test A +noall +answer
dig @10.77.0.2 guide.riverlight.test AAAA +noall +answer
Der A-Eintrag ist mit 10.77.0.10 korrekt. Der AAAA zeigt derzeit auf fd77:7::99, was nicht zum funktionierenden Dienst passt. Frage jetzt den unabhängigen Caching-Resolver des Clients unter Loopback 127.0.0.1 ab:
dig @127.0.0.1 guide.riverlight.test AAAA +noall +answer
Eine Zeile enthält Name, TTL, IN, Typ und Wert. TTL bedeutet Time To Live: die verbleibenden Sekunden, während derer eine zwischengespeicherte Antwort wiederverwendet werden darf. Die vorbereitete Zone verwendet 30 Sekunden. Diese Abfrage kann die alte Adresse zwischenspeichern; das ist normal.
Wechsle zu Guide Server und lies die gesamte Zone:
cat guide.zone
$TTL 30 setzt die Standardlebensdauer. @ steht für die Wurzel dieser Zone. SOA (Start of Authority) enthält als erste Zahl in Klammern die Zonenversion, die Seriennummer. NS identifiziert die zuständige Autorität. Namen mit abschließendem Punkt sind vollständig; kurze Namen wie guide beziehen sich auf riverlight.test. Erhalte alle Einträge außer dem Führer-AAAA und erhöhe die Seriennummer für diese Änderung von 1 auf 2. Sie dokumentiert eine Zonenversion, leert aber keine vorhandenen Client-Caches.
Sichere die Datei und ersetze die ganze kurze Zone mit dem bereits erklärten Here-Dokument. Die einfachen Anführungszeichen um ZONE schützen auch $TTL vor Shell-Variablenexpansion:
cp guide.zone guide.zone.before
cat > guide.zone <<'ZONE'
$TTL 30
@ IN SOA ns.riverlight.test. admin.riverlight.test. (2 60 30 3600 30)
@ IN NS ns.riverlight.test.
ns IN A 10.77.0.2
guide IN A 10.77.0.10
guide IN AAAA fd77:7::10
desk IN A 10.77.0.10
desk IN AAAA fd77:7::10
contact IN TXT "Welcome desk opens at 10:00"
ZONE
dns-check führt die native BIND-Zonenprüfung aus und ändert kein laufendes DNS:
guide-control dns-check
Erwarte loaded serial 2 und OK. Hier beschreibt loaded das Einlesen der Datei durch den Prüfer, nicht eine Änderung des laufenden autoritativen Servers. Bei einem Syntaxfehler lies die Zeilennummer, wiederhole die vollständige Vorlage und prüfe erneut. cp guide.zone.before guide.zone stellt bei Bedarf die ursprüngliche Datei wieder her, aber auch den alten falschen AAAA. Dies ist ein Wiederherstellungsbeginn und noch keine fertige Lösung.
dns-load prüft und lädt dann ausschließlich die Kurszone über einen privaten Steuerkanal neu:
guide-control dns-load
Wechsle zu Guide Client und frage Autorität und Cache getrennt ab:
dig @10.77.0.2 guide.riverlight.test AAAA +noall +answer
dig @127.0.0.1 guide.riverlight.test AAAA +noall +answer
Die Autorität sollte nun fd77:7::10 liefern. Der Cache darf bis zum Ablauf seiner restlichen TTL noch die alte Adresse zeigen. sleep 31 wartet 31 Sekunden, ohne einen Cache zu verändern:
sleep 31
dig @127.0.0.1 guide.riverlight.test AAAA +noall +answer
Nun erwartest du die richtige IPv6-Adresse. Globales Cache-Leeren oder Resolver-Änderungen sind unnötig. Ist die Autorität noch falsch, kehre zur gespeicherten Zone und zu dns-load zurück. Ist sie korrekt und nur der Cache abweichend, lies die TTL und wiederhole die begrenzte Wartezeit. Das Löschen von AAAA würde den IPv6-Namenszugriff entfernen statt reparieren.
Erzwinge abschließend eine IPv6-Anfrage per Namen:
curl --noproxy '*' -6 -fsS --max-time 3 -w '\npeer=%{remote_ip} status=%{http_code}\n' http://guide.riverlight.test:8080/
Erwarte Riverlight-HTML und peer=fd77:7::10 status=200. Funktioniert direkter IPv6-Zugriff, aber der Name nicht, deutet das auf DNS statt auf einen neu aufzubauenden Listener.
Den vollständigen Führer über beide Familien lesen und laden
In diesem Schritt nutzt du den vollständigen Führer über beide Adressfamilien und erhältst den geschützten Empfang sowie seine Einträge. Beginne in Guide Client. Eine richtige Startseite allein beweist weder den Detaillink noch Styles oder den vollständigen Download.
Speichere alle vier Originalressourcen über den echten Führernamen mit IPv4. Der vorbereitete Ordner v4 enthält nur deine heruntergeladenen Bytes; jeder -o-Pfad benennt die gespeicherte Ressource:
curl --noproxy '*' -4 -fsS http://guide.riverlight.test:8080/index.html -o v4/index.html
curl --noproxy '*' -4 -fsS http://guide.riverlight.test:8080/visit.html -o v4/visit.html
curl --noproxy '*' -4 -fsS http://guide.riverlight.test:8080/style.css -o v4/style.css
curl --noproxy '*' -4 -fsS http://guide.riverlight.test:8080/programme.txt -o v4/programme.txt
Wiederhole den Abruf über IPv6 mit getrennten Dateien, damit der Erfolg die IPv4-Ergebnisse nicht überschreibt:
curl --noproxy '*' -6 -fsS http://guide.riverlight.test:8080/index.html -o v6/index.html
curl --noproxy '*' -6 -fsS http://guide.riverlight.test:8080/visit.html -o v6/visit.html
curl --noproxy '*' -6 -fsS http://guide.riverlight.test:8080/style.css -o v6/style.css
curl --noproxy '*' -6 -fsS http://guide.riverlight.test:8080/programme.txt -o v6/programme.txt
cmp vergleicht zwei Dateien Byte für Byte. Keine Ausgabe und die Rückkehr zur Eingabeaufforderung bedeuten Gleichheit; eine gemeldete Abweichung bedeutet unterschiedliche Ressourcen. Vergleiche jede Datei und lies dann das ganze Programm:
cmp v4/index.html v6/index.html
cmp v4/visit.html v6/visit.html
cmp v4/style.css v6/style.css
cmp v4/programme.txt v6/programme.txt
cat v6/programme.txt
Lies bis WET WEATHER und zur letzten Anmerkung über die synthetische Veranstaltung. Existenz oder Größe einer Datei beweisen nicht, dass der gesamte Zeitplan und die Zugangsinformationen richtig ankamen. Sind zwei falsche Dateien gleich, beweist auch cmp allein keine Originalinhalte; die Prüfungen vergleichen die vorbereiteten Originale und den echten Dienst.
Wechsle zu Saved Guide. Wähle Open IPv4 saved guide, lies die Programmkarten und öffne mit Make a day of it die Anreise- und Zugangsinformationen. Wähle dort Save the programme, um das Programm herunterzuladen. Mit Back des Browsers kehrst du von der Detailseite zur Startseite zurück und mit einem weiteren Back zur Auswahl des Betrachters. Wähle Open IPv6 saved guide und wiederhole dieselben Links und den Download. Beide sollten denselben vollständigen Riverlight-Führer zeigen.
Lies die drei Programmkarten und verwende Besuchs- und Downloadlinks: Dies ist dein tatsächlich gespeicherter Führer.
Der Betrachter liest ausschließlich die Dateien v4 und v6 aus Guide Client und lädt fehlende Dateien niemals nach. Fehlt eine Seite oder das Styling, kehre zu Guide Client zurück, wiederhole den Abruf der exakten Familie und Ressource und lade die Browserseite neu. Die Verbindung zum Betrachter dient der Darstellung; die erzwungene Adressfamilie und tatsächliche Gegenstelle im Terminal belegen IPv6, nicht die URL des Betrachters.
Wechsle zu Guide Client. Erhalte den unabhängigen Empfang über beide Adressfamilien:
curl --noproxy '*' -4 -fsS http://desk.riverlight.test:8081/
curl --noproxy '*' -6 -fsS http://desk.riverlight.test:8081/
Beide liefern Welcome desk: open 10:00–20:00. Keep this site available.. Prüfe die erhaltenen A- und TXT-Einträge:
dig @10.77.0.2 guide.riverlight.test A +short
dig @10.77.0.2 contact.riverlight.test TXT +short
Erwarte 10.77.0.10 und "Welcome desk opens at 10:00". Weicht ein geschützter Wert ab, stelle ihn anhand der vollständigen Originalvorlage wieder her und behalte den korrigierten AAAA. Prüfe und lade neu. Kopiere keine Quellseiten, ergänze keinen Proxy, ersetze keinen Dienstprozess und ändere keine Adressen, nur um eine grüne Prüfung zu erhalten. Prüfungen beobachten laufende Dienste und gespeicherte Ergebnisse; normale GET- und DNS-Anfragen dürfen native Logs ergänzen, laden oder reparieren aber deine Arbeit nicht.
Zusammenfassung
Du hast einen funktionierenden IPv4-Führer um einen echten IPv6-Listener erweitert, seinen AAAA korrigiert und einen getrennten DNS-Cache natürlich aktualisieren lassen. Anfragen mit vorgegebener Familie lieferten dieselben Originale für Startseite, Anreise, Stylesheet und vollständiges Programm. IPv4, Empfang, andere Einträge und das vorbereitete Netz blieben erhalten. Erreichbarkeit, Namensauflösung, Listener und korrekter Anwendungsinhalt sind getrennte Tatsachen.
