Servir le même guide aux clients IPv4 et IPv6

LinuxBeginner
Pratiquer maintenant

Introduction

Riverlight Gathering possède déjà un guide événementiel fonctionnel en IPv4. Les visiteurs ont besoin du même guide complet en IPv6, avec les informations d'arrivée et le programme téléchargeable. Les adresses réseau sont préparées, mais le service web n'écoute pas encore en IPv6 et l'AAAA du guide pointe vers une mauvaise adresse.

Vous séparerez ces deux problèmes : faire fonctionner l'accès IPv6 direct à l'application, puis corriger le nom. Vous préserverez IPv4, le point d'accueil, les autres enregistrements DNS et tous les octets originaux des pages et téléchargements. Les prérequis sont les bases du terminal, des chemins et des onglets, ainsi que l'identification des adresses, noms et ports ; aucune administration Nginx ou IPv6 n'est requise. Les 70 minutes sont une estimation de l'auteur.

Guide Server et Guide Client sont des nœuds réseau isolés partageant le noyau de cette instance de formation, pas des VM distinctes. Modifiez uniquement les instructions d'écoute de guide.conf et l'AAAA cible/numéro de série SOA de guide.zone ; enregistrez les téléchargements dans l'espace client. Ne changez ni routes, adresses, activation IPv6, autres sites, pages sources ni paramètres de la plateforme. Ce réseau local préparé n'implique pas IPv6 public, RA, DHCPv6, tunnels ou NAT64.

Comparer les familles d'adresses

Dans cette étape, vous lirez le guide IPv4 fonctionnel, puis distinguerez une adresse IPv6 joignable d'une application à l'écoute. Commencez dans Guide Client. Son terminal démarre dans /home/labex/project/ipv6-guide/client ; son shell et son répertoire persistent indépendamment de Guide Server. pwd affiche le répertoire courant :

pwd

Les adresses IPv4 comportent quatre parties décimales, comme 10.77.0.10. IPv6 utilise huit groupes de chiffres hexadécimaux. Les zéros initiaux d'un groupe peuvent être omis ; un seul :: remplace une suite de groupes entièrement nuls. Ici, fd77:7::10 signifie fd77:0007:0000:0000:0000:0000:0000:0010. Le 10 final est hexadécimal, contrairement à la dernière partie décimale de l'adresse IPv4. Ces adresses privées de formation ne garantissent pas l'accès à Internet public.

curl récupère une ressource HTTP. -4 impose IPv4, -f traite les réponses HTTP d'erreur comme des échecs, -s masque la progression et -S affiche néanmoins les erreurs. --noproxy '*' contourne les proxies pour tous les hôtes ; les guillemets maintiennent * littéral au lieu de développer des noms de fichiers. Le port 8080 sélectionne l'application du guide. -o enregistre les octets reçus dans un fichier ; v4 est un dossier de sortie préparé :

curl --noproxy '*' -4 -fsS http://guide.riverlight.test:8080/index.html -o v4/index.html

Un enregistrement réussi n'affiche généralement rien. head -c 180 lit les 180 premiers octets sans modifier le fichier :

head -c 180 v4/index.html

Attendez du HTML contenant Riverlight Gathering. C'est la référence fonctionnelle à préserver. L'affichage complet dans le navigateur nécessite aussi sa feuille de style, que vous enregistrerez plus tard.

Testez maintenant l'adresse IPv6 préparée. ping -6 envoie des requêtes d'écho IPv6 ; -c 1 s'arrête après une requête. Cela teste la joignabilité réseau, pas HTTP :

ping -6 -c 1 fd77:7::10

Une réponse est attendue. Dans une URL, une adresse IPv6 littérale est entourée de crochets pour distinguer ses deux-points du séparateur de port. Placez l'URL entière entre guillemets. -6 impose IPv6 ; --max-time 3 limite la requête à trois secondes :

curl --noproxy '*' -6 -fsS --max-time 3 'http://[fd77:7::10]:8080/'

Cette requête est censée échouer avec curl: (7) et une connexion refusée. L'adresse IPv6 existe et répond aux échos, mais l'application n'a pas ouvert ce point d'accès IPv6. Un délai dépassé signifie au contraire qu'aucune réponse utile n'est arrivée dans le temps imparti ; il diffère d'un refus immédiat. Ne résolvez aucun des deux en désactivant IPv6. Un navigateur double pile ordinaire peut réessayer en IPv4 : y voir une page ne prouverait donc pas IPv6.

Un nom mal saisi peut provoquer l'erreur curl 6, indiquant un échec de résolution. Comparez l'orthographe, puis répétez la première commande. Une erreur dans le chemin de sauvegarde produit une erreur d'écriture locale ; vérifiez pwd et le chemin indiqué v4/index.html. Ces problèmes diffèrent de HTTP 404, où un serveur joignable indique que la ressource demandée est absente.

Faire écouter le service web en IPv6

Dans cette étape, vous conserverez l'écoute IPv4 fonctionnelle et ajouterez une écoute IPv6 séparée. Passez dans Guide Server. Le terminal démarre dans /home/labex/project/ipv6-guide/config. cat lit la table des points de connexion et la courte configuration cible :

cat endpoints.tsv
cat guide.conf

Le guide doit utiliser 10.77.0.10 et fd77:7::10, port 8080. Le point d'accueil utilise le port 8081 : préservez-le. server_name sélectionne le nom du site, root situe ses pages originales et index choisit la page d'accueil. Les accolades regroupent un serveur ; chaque directive se termine par un point-virgule.

ss lit les sockets du noyau. -l sélectionne les écoutes, -t TCP, -n les adresses et ports numériques et -p les processus propriétaires :

ss -ltnp

Repérez Nginx sur IPv4 10.77.0.10:8080 ; le guide n'a pas encore d'écoute IPv6. Le socket IPv6 :8081 du point d'accueil ne dessert pas le port du guide.

Vous remplacerez tout le fichier court par un modèle complet. cat > guide.conf écrit dans ce fichier en remplaçant son contenu. <<'NGINX' ouvre un here-document : le shell prend littéralement les lignes suivantes jusqu'à une ligne contenant uniquement NGINX. Collez tout le bloc, marqueur final compris. D'abord, cp crée une sauvegarde locale ; le deuxième nom désigne la copie :

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 ouvre un point d'accès applicatif. La nouvelle adresse entre crochets est IPv6 ; ipv6only=on réserve cette écoute à IPv6. La ligne IPv4 conservée dessert IPv4 indépendamment. Configurer une adresse seule ne pourrait jamais créer ce socket d'écoute.

La commande préparée guide-control vérifie ou charge uniquement le service indépendant du cours. web-check exécute le test de configuration Nginx sans charger les changements :

guide-control web-check

Attendez syntax is ok et test is successful. Un point-virgule, une accolade ou une adresse mal saisis produisent une erreur indiquant fichier et ligne. Rien n'a été chargé. Répétez le modèle complet, puis vérifiez à nouveau. Pour revenir à la configuration IPv4 fonctionnelle initiale, cp guide.conf.before guide.conf restaure la sauvegarde ; vérifiez-la avant de la charger. Ne redémarrez ni Nginx ni le réseau de la plateforme.

web-load teste à nouveau, puis demande une recharge. Celle-ci conserve le processus maître du cours en appliquant la configuration enregistrée ; un fichier sauvegardé seul ne change pas le service :

guide-control web-load
ss -ltnp

Nginx doit posséder 10.77.0.10:8080 et [fd77:7::10]:8080. Si le journal signale un point de connexion occupé, comparez le fichier au modèle complet et consultez ss ; n'arrêtez pas un service sans rapport.

Passez dans Guide Client. -w affiche des faits de connexion après le corps. Le format entre guillemets contient \n pour un saut de ligne ; curl remplace %{remote_ip} par l'adresse réelle du pair et %{http_code} par le statut de réponse :

curl --noproxy '*' -6 -fsS --max-time 3 -w '\npeer=%{remote_ip} status=%{http_code}\n' 'http://[fd77:7::10]:8080/'

Attendez le HTML Riverlight, puis peer=fd77:7::10 status=200. Lisez aussi le contenu : une page par défaut sans rapport renvoyant 200 serait incorrecte. Cette requête directe réussie isole la couche application ; vous n'avez pas encore corrigé le nom du guide.

Faire pointer le nom vers le service IPv6 fonctionnel

Dans cette étape, vous corrigerez seulement l'AAAA cible et laisserez un vrai cache se mettre à jour naturellement. Commencez dans Guide Client. DNS, le système de noms de domaine, associe les noms à des données. Un enregistrement A fournit IPv4 ; AAAA fournit IPv6. La requête DNS elle-même peut passer par IPv4 tout en renvoyant une adresse IPv6.

dig interroge DNS. @10.77.0.2 sélectionne le serveur faisant autorité préparé, responsable de cette zone. +noall +answer masque les autres sections et affiche les réponses :

dig @10.77.0.2 guide.riverlight.test A +noall +answer
dig @10.77.0.2 guide.riverlight.test AAAA +noall +answer

Le A est correct : 10.77.0.10. L'AAAA indique actuellement fd77:7::99, qui ne correspond pas au service fonctionnel. Interrogez maintenant le résolveur de cache indépendant du client, sur l'adresse de bouclage 127.0.0.1 :

dig @127.0.0.1 guide.riverlight.test AAAA +noall +answer

Une ligne contient nom, TTL, IN, type et valeur. TTL signifie Time To Live : le nombre de secondes restantes pendant lesquelles une réponse en cache peut être réutilisée. La zone préparée utilise 30 secondes. Cette requête peut mettre l'ancienne adresse en cache, ce qui est normal.

Passez dans Guide Server et lisez toute la zone :

cat guide.zone

$TTL 30 définit la durée par défaut. @ représente la racine de cette zone. Le SOA (Start of Authority) indique la version de zone, ou numéro de série, dans le premier nombre entre parenthèses. NS identifie l'autorité. Les noms terminés par un point sont complets ; un nom court comme guide est relatif à riverlight.test. Préservez tous les enregistrements sauf l'AAAA du guide et faites passer le numéro de série de 1 à 2 pour cette révision. Ce numéro indique une version de zone ; il ne vide pas les caches clients existants.

Sauvegardez le fichier, puis remplacez toute la courte zone avec le here-document déjà enseigné. Les apostrophes autour de ZONE protègent aussi $TTL de l'expansion des variables du shell :

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 lance le validateur natif des zones BIND. Il ne change pas le DNS actif :

guide-control dns-check

Attendez loaded serial 2 et OK ; ici, loaded décrit la lecture du fichier par le validateur, pas un changement du serveur actif. En cas d'erreur de syntaxe, lisez la ligne indiquée, répétez le modèle complet et vérifiez. cp guide.zone.before guide.zone restaure le fichier original si nécessaire ; cela rétablit aussi l'ancien AAAA erroné. C'est donc un point de récupération, pas la réponse finale.

dns-load vérifie, puis utilise un canal de contrôle privé pour recharger uniquement la zone du cours :

guide-control dns-load

Passez dans Guide Client. Interrogez séparément autorité et cache :

dig @10.77.0.2 guide.riverlight.test AAAA +noall +answer
dig @127.0.0.1 guide.riverlight.test AAAA +noall +answer

L'autorité doit maintenant renvoyer fd77:7::10. Le cache peut encore montrer l'ancienne adresse jusqu'à expiration du TTL restant. sleep 31 attend 31 secondes sans modifier de cache :

sleep 31
dig @127.0.0.1 guide.riverlight.test AAAA +noall +answer

L'adresse IPv6 correcte est maintenant attendue. Aucun vidage global du cache ni changement de résolveur n'est nécessaire. Si l'autorité reste incorrecte, revenez à la zone enregistrée et à dns-load ; si elle est correcte mais que le cache diffère, lisez son TTL et répétez l'attente bornée. Supprimer l'AAAA retirerait l'accès IPv6 par nom au lieu de le réparer.

Forcez enfin une requête IPv6 par nom :

curl --noproxy '*' -6 -fsS --max-time 3 -w '\npeer=%{remote_ip} status=%{http_code}\n' http://guide.riverlight.test:8080/

Attendez le HTML Riverlight et peer=fd77:7::10 status=200. Un accès IPv6 direct réussi suivi d'un échec par nom oriente vers DNS, plutôt que vers une reconstruction de l'écoute.

Lire et télécharger le guide complet des deux façons

Dans cette étape, vous utiliserez tout le guide par les deux familles, en préservant le point d'accueil et les enregistrements protégés. Commencez dans Guide Client. Une page d'accueil correcte ne prouve pas le fonctionnement du détail, des styles ou du téléchargement complet.

Enregistrez les quatre ressources originales par le vrai nom du guide en IPv4. Le dossier préparé v4 contient seulement vos octets téléchargés ; chaque chemin -o désigne le fichier enregistré de la 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

Répétez en IPv6, avec des fichiers séparés pour ne pas écraser les preuves IPv4 :

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 compare deux fichiers octet par octet. L'absence de sortie et le retour à l'invite indiquent leur égalité ; une différence signalée indique un désaccord entre ressources. Comparez chacune, puis lisez le programme complet :

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

Lisez jusqu'à WET WEATHER et à la note finale sur l'événement synthétique. L'existence ou la taille du fichier ne prouverait pas la bonne réception de l'horaire complet et des informations d'accessibilité. Si deux mauvais fichiers sont identiques, cmp seul ne prouve pas non plus leur authenticité ; les contrôles comparent les originaux préparés et le service réel.

Passez dans Saved Guide. Sélectionnez Open IPv4 saved guide, lisez les cartes du programme, puis Make a day of it pour les informations d'arrivée et d'accessibilité. Sélectionnez Save the programme sur cette page pour télécharger le programme. Utilisez Back du navigateur pour revenir du détail à l'accueil, puis encore Back pour revenir à la sélection du lecteur. Choisissez Open IPv6 saved guide et répétez les mêmes liens et téléchargement. Les deux doivent présenter le même guide Riverlight complet.

Accueil Riverlight complet enregistré avec liens de détail et de programme fonctionnels

Lisez les trois cartes et utilisez les liens de visite et de téléchargement : cette page est votre véritable guide enregistré.

Ce lecteur ne lit que les fichiers v4 et v6 de Guide Client. Il ne récupère jamais de fichier manquant. Si un style ou une page manque, revenez dans Guide Client, répétez l'enregistrement de la famille et de la ressource exactes, puis rechargez le navigateur. La connexion navigateur-lecteur est une voie de présentation ; ce sont les requêtes à famille imposée et le pair réel du terminal qui établissent IPv6, pas l'URL du lecteur.

Passez dans Guide Client. Gardez le point d'accueil indépendant disponible par les deux familles :

curl --noproxy '*' -4 -fsS http://desk.riverlight.test:8081/
curl --noproxy '*' -6 -fsS http://desk.riverlight.test:8081/

Les deux réponses contiennent Welcome desk: open 10:00–20:00. Keep this site available.. Vérifiez les A et TXT préservés :

dig @10.77.0.2 guide.riverlight.test A +short
dig @10.77.0.2 contact.riverlight.test TXT +short

Attendez 10.77.0.10 et "Welcome desk opens at 10:00". Si une valeur protégée diffère, restaurez-la depuis le modèle original complet en conservant l'AAAA corrigé, puis validez et rechargez. Ne copiez pas les pages sources, n'ajoutez pas de proxy, ne remplacez pas de processus et ne modifiez pas d'adresses pour faire réussir un contrôle. Les contrôles observent les services actifs et les résultats enregistrés ; GET et requêtes DNS ordinaires peuvent alimenter les journaux natifs, mais ne chargent ni ne réparent votre travail.

Résumé

Vous avez étendu un guide IPv4 fonctionnel avec une vraie écoute IPv6, corrigé son AAAA et laissé un cache DNS séparé se mettre à jour naturellement. Les requêtes à famille imposée ont livré les mêmes originaux : accueil, arrivée, feuille de style et programme complet. Vous avez préservé IPv4, le point d'accueil, les autres enregistrements et le réseau préparé. Joignabilité, résolution, écoute et contenu applicatif correct sont des faits distincts.