Revision as of 16:52, 17 November 2015

Activité 46: Faites interopérer des applications IPv6 et IPv4

Dans l'état d'avancement de la migration vers IPv6, des clients IPv6 vont apparaitre dans l'Internet. En vertu de la continuité du service et de l'unité de l'Internet, ces hôtes doivent pouvoir accéder aux contenus disponibles sur l'Internet v4. A ce stade du déploiement nous avons 2 Internets:

• un Internet en IPv4 encore prépondérant du fait de ses services,
• un Internet en IPv6 de valeur moindre car il connecte aujourd'hui essentiellement des clients.

L'objectif de cette activité est de présenter les solutions d'interopération d'applications distribuées qui ne fonctionnent pas au dessus de la même version du protocole IP. Comme nous l'avons dit le plan de migration originel en double pile n'est plus applicable à cause du manque d'adresses IPv4 disponibles de nos jours.

Les différentes étapes de cette activité vont représenter une évolution temporel de l'Internet. Pour chacune de ces évolutions nous montrerons quelle technique de transition appliquer et comment l'appliquer.

La plateforme mise en oeuvre dans ce TP est représentée par la figure 1. Elle comporte :

• un client IPv6 uniquement disposant uniquement d'une adresse IPv6. Ce client, localisé sur le noeud pc1, représente les nouvelles machines qui apparaissent dans l'Internet pour former ce que l'on appelé par la suite l'Internet en IPv6,
• un routeur R1 en double pile. Un noeud qui a une connectivité avec l'Internet en IPv4 et en IPv6,
• un routeur R2 en IPv4. Un noeud représentant l'Internet en IPv4,
• un serveur web IPv4. Ce service sera hébergé sur le noeud PC2 et représentera les contenus disponibles sur l'Internet IPv4. Ce noeud hébergera également un serveur DNS.

Figure 1: Plateforme de l'activité.

Etape 0 : Situation initiale

Dans la situation initiale, nous nous situons avec un Internet majoritairement en IPv4 et des nouveaux réseaux en IPv6 hébergeant des clients. La plateforme de la figure 1 illustre cette situation. Le réseau IPv6 symbolise ces nouveaux réseaux de clients. Le coeur de réseau et les services fonctionnent en IPv4.

Dans la phase initiale, l'infrastructure de communication dans la plateforme est opérationnelle. Il reste à démarrer les services qui sont sur PC2. Les services sont le DNS pour la résolution de noms et le web.

Note: Pour vous loguer sur les stations PC1 et PC2, les identifiants/mots de passe sont apprenant'/'. (Pas de mot de passe).

Activez le service de nommage sur PC2 :

apprenant@MOOCIPv6:~$ sudo named -c /usr/local/etc/bind/named.conf

Pour tester la configuration, il faut maintenant interroger le serveur de noms pour un nom de la zone. Il existe des outils sous Linux permettant de faire explicitement ces requêtes, tels que host ou dig. La commande dig est disponible sur PC2

apprenant@MOOCIPv5:~$ dig @192.0.2.1 -t A www.tp +short

Vous pouvez également vérifiez que la résolution de nom fonctionne depuis R1 (en mode root) à l'aide de la commande host. Le mode root va nous servir à entrer des commandes Unix. Pour vous connecter en mode root sur R1 :

vyos login: root 
Password: root

L'adresse du serveur de nom à utiliser dans la commande host est 192.0.2.1. La syntaxe de la commande devient alors sur R1:

root@vyos:~# host www.tp 192.0.2.1

Le service applicatif web, nginx, a été activé dès le démarrage de la machine PC2. Vérifiez le bon fonctionnement de ce service depuis R1, à l'aide de la commande curl :

root@vyos:~# curl http://www.tp
Un contenu HTML doit s'afficher

La problématique qu'il reste à résoudre se pose dans les termes suivants : Comment PC1 qui est en IPv6-only peut-il accéder au service web www.tp qui est en IPv4-onlly ?

Etape 1 : Configuration de NAT64/DNS64

Dans cette étape, nous installons la proposition de l'IETF NAT64/DNS64 qui répond à la problématique de l'interopérabilité de systèmes utilisant une version du protocole IP différente. Le relais auxiliaire DNS64 et le NAT64 seront placés sur le noeud double pile R1.

Le déploiement du NAT64 se situe dans le scénario 1 indiqué par le RFC 6144 dans lequel les clients d'un réseau IPv6 d'une organisation accèdent aux serveurs IPv4 de l'Internet. Dans ce scénario, la solution NAT64 peut être avec ou sans état.

Le NAT64 que nous allons déployer dans notre plateforme est un traducteur sans état. Avant d'étudier sa mise en oeuvre effective, nous allons revoir le principe de fonctionnement de cette solution de traduction. Le traducteur effectue la traduction de l'adresse source et de l'adresse de destination d'un paquet par la méthode sans état. Ce mode de traduction de l'adresse implique que l'adresse IPv4 est imbriquée dans l'adresse IPv6 comme indiquée par le RFC 6052. Ainsi lorsqu'un client IPv6 envoie une requête à un serveur IPv4, l'adresse IPv4 du serveur doit être transformée en une adresse IPv6 pour le client. C'est cette adresse qui sera utilisée comme adresse de destination par le client. Et quand le serveur IPv4 renvoie une réponse au client IPv6, il doit utiliser une adresse IPv4 comme adresse de destination. Adresse qu'il aura appris en recevant la requête. Comme la traduction d'adresse s'effectue sans état, ceci implique que l'adresse IPv4 du client à été fournie par le client lui-même. En d'autres termes, le client IPv6 dispose parmi ses adresses unicast, d'une adresse IPv6 qui imbrique son adresse IPv4. Donc d'après la terminologie indiquée par le RFC 6144, il s'agit d'allouer au client IPv6 une adresse IPv6 IPv4-translatable en plus de son adresse IPv6 unicast routable.

Reste le problème de la transformation de l'adresse IPv4 du serveur en une adresse IPv6 pour qu'elle soit utilisable par le client pour envoyer ses requêtes. C'est ici que nous avons besoins du DNS auxiliaire DNS64. Il va transformer une adresse IPv4 en une adresse IPv6 qui est qualifiée de IPv4-converted. Pour ce faire, il va ajouter un préfixe à l'adresse IPv4. Dans la figure 2, le préfixe utilisé notée pref64:: est un préfixe IPv6 réservé à l'usage de la traduction.

Figure 2: Opérations du DNS64.

Allocation d'adresses

Le préfixe IPv6 alloué à l'organisation en charge du réseau IPv6 est fd75:e4d9:cb77::/48. Elle réserve le SID (Subnet ID) 64 pour constituer le préfixe IPv6 spécifique à la traduction fd75:e4d9:cb77:64::/96. Le réseau IPv6, quant à lui, est identifié par le SID de valeur 1, soit le préfixe fd75:e4d9:cb77:1::/64. Cette organisation dispose aussi du préfixe IPv4 192.0.3.0/24 quelle réserve à la traduction. La figure 3 montre la répartition des identifiants d'interface, des SID et des préfixes IPv4. Les identifiants d'hôte au niveau du réseau IPv4 central sont 129 pour R2 et 130 pour R1.

Figure 3: Allocation des préfixes et identifiants.

L'allocation des adresses pour chaque noeud est donc faite selon le tableau 1.

Il est à noter que bien que PC1 soit un noeud IPv6 uniquement, il possède une adresse IPv4. Cette adresse n'est pas allouée à l'interface. Elle est imbriquée dans une adresse IPv6 qui elle sera attribuée à l'interface réseau de PC1. De ce fait, PC1 aura bien 2 adresses unicast IPv6 routables: une utilisée pour les communications avec des noeuds IPv6 (SID positionné à 1) et une autre (SID positionné à 64) utilisée pour les communications avec des noeuds IPv4. Lorsque PC1 envoie une requête à PC2, il utilise comme adresse source fd75:e4d9:cb77:64::192.0.3.3 (qui se note également fd75:e4d9:cb77:64::c000:303)et comme adresse de destination fd75:e4d9:cb77:64::192.0.2.1 (qui se note également fd75:e4d9:cb77:64::c000:201). Une fois le NAT64 passé, les adresses deviennent respectivement sur les réseaux IPv4 : source 192.0.3.3 et destination 192.0.2.1.

Maintenant que nous avons posé le principe de fonctionnement de la technique DNS64/NAT64 pour cette plateforme, nous allons configurer ces différents éléments.

Configuration de PC1

Pour vous loguer sur les stations PC1 et PC2, les identifiants/mots de passe sont apprenant'/'. (Pas de mot de passe).

Fixer l'adresse de l'interface eth0 de PC1, avec l'IID positionné à la valeur 3, conformément au tableau 1

apprenant@MOOCIPv6:~$ sudo ifconfig eth0 fd75:e4d9:cb77:1::3/64

Puis, ajoutez, sur PC1, l'adresse IPv6 traduisible en IPv4. La longueur du préfixe est fixéee à 128 bits, car le préfixe n'identifie pas un lien.

apprenant@MOOCIPv6:~$ sudo ifconfig eth0 fd75:e4d9:cb77:64::192.0.3.3/128

Ensuite il faudrait théoriquement indiquer une route au préfixe réservé à la traduction. Cette route doit faire converger le trafic vers le traducteur NAT64. Ceci serait surtout vrai s'il y avait des routeurs intermédiaires entre PC1 et le traducteur NAT64, ou si le traducteur était hébergé sur un équipement autre que le routeur. Elle pourrait être positionnée par la commande:

route -A inet6 fd75:e4d9:cb77:64::/64 gw fd75:e4d9:cb77:1::1

Dans notre cas, PC1 n'a pas besoin de route spécifique pour le préfixe IPv6 de traduction, puisque la passerelle de traduction NAT64 est elle même hébergée sur le routeur par défaut pour PC1.

Enfin, renseignez le serveur de nom qui sera utilisé au niveau du réseau IPv6; il s'agit du DNS64 qui sera configuré par la suite sur R1:

apprenant@MOOCIPv6:~$ sudo nano -w /etc/resolv.conf
nameserver fd75:e4d9:cb77:1::1

Mise en oeuvre du DNS64

Les versions récentes du logiciel serveur DNS, BIND/named, peuvent assurer le rôle DNS64. Le logiciel TOTD (Trick Or Treat Daemon) peut également être utilisé pour cet usage. TOTD est un petit DNS cache également dénommé DNS auxiliaire dans notre contexte de mise en oeuvre de la traduction NAT64. Son objectif principal est de traduire les adresses IPv4 en IPv6 en ajoutant le préfixe réservé à la traduction à l'adresse IPv4 retournée par le DNS.

Sur notre plateforme, c'est le noeud R1 qui supportera le service DNS auxiliaire et le noeud PC2 qui fera office de serveur DNS général. Avant de démarrer le service DNS auxiliaire, compléter le contenu du fichier de configuration par les informations nécessaires à la traduction. Sur R1 (en mode root), éditez le fichier de configuration de TOTD

root@vyos:~# nano -w /etc/totd.conf

et renseignez les informations suivantes dans le fichier:

forwarder 192.0.2.1          # IPv4 address for name server
prefix fd75:e4d9:cb77:64::   # /96 by default
port 53

Le forwarder correspond à l'adresse IPv4 du serveur DNS général. La ligne prefix indique dans notre cas le NSP (Network-Specific Prefix) qui sera utilisé pour transformer une adresse IPv4 en une adresse IPv6 dite (IPv4-converted).

Démarrez le logiciel

root@vyos:~# /etc/init.d/totd start

Vérifiez que tout s'est bien passé, en consultant la fin du journal système à l'aide de la commande:

root@vyos:~# tail /var/log/messages

Vous pouvez également vérifiez la présence du processus daemon totd à l'aide de la commande

root@vyos:~# ps -edf | grep totd

Nota : Le symbole | (pipe Unix) est obtenu en appuyant simultanément sur les touches AltGr et 6 du clavier azerty de votre PC

Pour tester le bon fonctionnement du DNS64, nous allons faire une résolution de nom du web depuis PC1. Sur PC1, demandez l'adresse IPv4 de www.tp.

apprenant@MOOCIPv6:~$ dig www.tp

puis l'adresse IPv6

apprenant@MOOCIPv6:~$ dig -t AAAA www.tp

Observez, le préfixe IPv6 qui a été ajouté à l'adresse IPv4 (notée en hexadécimal).

Vous pouvez analyser les échanges, en relançant ces commandes, après avoir démarré une capture du trafic sur l'interface eth0 et sur l'interface eth1 de R1 afin d'illustrer le fonctionnement du DNS64 comme le fait la figure 2. Cette capture est à effectuer lors d'une résolution de www.tp en une adresse IPv6 initiée par PC1.

Ainsi par l'affichage des messages 'DNS standard query' et 'DNS standard response' pour les requêtes en amont et en aval de R1, vous verrez que le DNS auxiliaire a bien transformé la réponse de type 'A' en une réponse de type 'AAAA'.

Mise en oeuvre de NAT64

TAYGA^[1] (Simple, no fuss NAT64 for Linux) est une mise en oeuvre libre sous Linux du RFC 6145, la version sans état du NAT64. Ce NAT64 fonctionne sur une machine double pile et marque la frontière entre le réseau IPv6 et le réseau IPv4. Il nécessite un service de résolution de noms reposant sur un DNS auxiliaire tel que TOTD que nous venons de voir. Les messages des requêtes des clients IPv6 ont une adresse de destination dont le préfixe correspond au préfixe ajouté par le DNS64. Le rôle du relais NAT64 est de prendre en charge les flux pour ces adresses et de les traduire pour accéder aux services disponibles dans le monde IPv4.

TAYGA est installé sur le routeur R1. Commencez la configureation de TAYGA en éditant le fichier /etc/tayga.conf

root@vyos~# nano -w /etc/tayga.conf
tun-device nat64                # device name for nat64
ipv4-addr 192.0.3.1             # IPv4 address that TAYGA will  use
prefix fd75:e4d9:cb77:64::/96   # NSP 

Nota: les commentaires préfixés par le caractère '#' ne sont pas à saisir. Il servent uniquement à expliciter le sens des lignes à rentrer. Configurez les routes pour TAYGA sur R1:

root@vyos~# tayga --mktun              # create nat64 device
root@vyos~# ip link set nat64 up       # activate nat64 device
root@vyos~# ip addr add 192.0.2.130/25 dev nat64    #IPv4 nat64 router address
root@vyos~# ip -6 addr add fd75:e4d9:cb77:1::1/64 dev nat64  #IPv6 nat64 router address
root@vyos~# ip route add 192.0.3.0/24 dev nat64
root@vyos~# ip -6 route add fd75:e4d9:cb77:64::/96 dev nat64
root@vyos~# ip -6 route add fd75:e4d9:cb77:64::c000:303/120 dev eth0   # route to pc1

Nota: les commentaires préfixés par le caractère '#' ne sont pas à saisir. Il servent uniquement à expliciter le sens des lignes à rentrer.

Sur R2, ajoutez la route vers le préfixe utilisé pour représenter les postes IPv6 en IPv4. Pour cela vous aller vous connecter en mode utilisateur et passer en mode Quagga.

root@vyos:~$ vtysh
vyos# configure terminal
vyos(config)# ip route 192.0.3.0/24 192.0.2.130
vyos(config)# exit
vyos#

Démarrez TAYGA sur R1

root@vyos~# tayga

Le service est maintenant opérationnel. Pour le valider faire un simple test de connectivité ping depuis PC1 :

apprenant@MOOCIPv6:~$ ping6 -c 5 www.tp

Observez le contenu des trames échangées de part et d'autre du traducteur TAYGA (capture sur les liens des interfaces eth0 et eth1 de R1) : type de datagrammes, adresses sources et destinations, ...

Maintenant, testez que le client IPv6 (sur PC1) accède bien au service web :

apprenant@MOOCIPv6:~$ curl http://www.tp

Oberservez les captures de part et d'autre du traducteur TAYGA

Etape 2 : Connectivité IPv6 par tunnel

Au fil du temps, l'Internet en IPv6 croît. L'organisation en charge du serveur web obtient une connectivité en IPv6. Cette connectivité est établie au moyen d'un tunnel. Le tunnel va servir à traverser les équipements d'infrastructure qui ne sont pas encore compatibles avec IPv6. Dans notre plateforme, le tunnel reliera le réseau IPv6 (de R1) au routeur de bordure du réseau du serveur web (R2) comme indiquée par la figure 4. Le tunnel aura un préfixe extrait du préfixe fd75:e4d9:cb77::/48 et complété avec le SID à la valeur fff pour former un préfixe de 64 bits. Les identifiants d'interfaces des extremités du tunnel sont indiqués par la figure 4.

Figure 4: Connectivité par tunnel.

Avant de passer à la configuration du tunnel, "déloguez" vous du mode root sur les routeurs

root@vyos:~# exit

Pour vous "reloguer" en mode utilisateur

login: vyos
password: vyos

L'invite de commande dans ce mode est

vyos@vyos~$

Sur le routeur R1, l'extrémité du tunnel (coté réseau IPv6) sera créée et configurée en enchaînant les commandes suivantes :

• La première commande consiste à passer en mode administrateur par configure.
• La commande set interfaces tunnel tun0 address 'fd75:e4d9:cb77:fff::1/64' crée une interface de tunnel configuré, dénommée tun0. Cette interface est identifiée par une adresse IP. Le tunnel étant un lien et en tant que tel, il possède un préfixe. Ce préfixe est ajouté à la table de routage de R1.
• Le mode d'encapsulation pour le tunnel est spécifié par la commande set interfaces tunnel tun0 encapsulation 'sit' . Le mode SIT (Simple Internet Transition) indique une méthode d'encapsulation d'IPv6 dans IPv4.
• La commande set interfaces tunnel tun0 local-ip '192.0.2.130' précise l'adresse IPv4 des paquets IPv4 qui encapsuleront les paquets IPv6. Il s'agit ici de l'adresse source pour les paquets émis et l'adresse de destination pour les paquets reçus.
• La commande set interfaces tunnel tun0 remote-ip '192.0.2.129' précise l'adresse IPv4 de l'autre extrémité du tunnel. Cette adresse est utilisée comme adresse de destination pour les paquets IPv4 émis. Ainsi un paquet IPv6 émis dans ce tunnel sera encapsulé dans un paquet IPv4 dont les adresses source et destination sont connues.
• La commande set interfaces tunnel tun0 mtu '1480' précise la taille de la MTU (Maximum Transmission Unit) appliquée sur ce tunnel. Par défaut, tous liens utilisés par IPv6 doivent pouvoir acheminer des paquets de taille de 1280 octets sans demander de fragmentation [RFC 2460]. Dans le RFC 4213, il est précisés qu'un tunnel statique a une MTU par défaut de 1280 octets. Dans notre cas, l'interface physique sur lequel repose le tunnel est Ethernet. La taille de la MTU est de 1500 octets. Autrement dit un paquet IPv4 aura une longueur maximum sans segmentation de 1500 octets (en-tête comprise). Si un tel paquet IPv4 encapsule un paquet IPv6, il reste 1480 octets (1500 octets moins 20 octets pour l'en-tête IPv4) pour le paquet IPv6. Donc pour améliorer la performance du tunnel, nous pouvons indiquer une MTU plus importante que 1280 octets. Ainsi moins de paquets seront nécessaires pour transporter la même quantité de données pour les transferts de fichiers.
• enfin la commande commit termine la séquence des commandes en mode administrateur pour revenir en mode utilisateur.

vyos@vyos:~$ configure
vyos@vyos# set interfaces tunnel tun0 address 'fd75:e4d9:cb77:fff::1/64' 
vyos@vyos# set interfaces tunnel tun0 encapsulation 'sit' 
vyos@vyos# set interfaces tunnel tun0 local-ip '192.0.2.130' 
vyos@vyos# set interfaces tunnel tun0 remote-ip '192.0.2.129' 
vyos@vyos# set interfaces tunnel tun0 mtu '1480' 
vyos@vyos# commit

Vérifiez votre saisie en affichant la configuration des interfaces (en mode Quagga)

vyos@vyos:# vtysh
vyos# show interface

Vous devez retrouvez sur l'interface tun0 l'adresse IPv6 que vous venez d'attribuer. Vérifiez la configuration des routes en affichant le contenu de la table de routage

vyos# show ipv6 route

Recommencer la même série de commandes, en ajustant les paramètres, pour l'autre coté du tunnel à savoir sur le routeur R2:

vyos@vyos:~$ configure
vyos@vyos# set interfaces tunnel tun0 address 'fd75:e4d9:cb77:fff::2/64'
vyos@vyos# set interfaces tunnel tun0 encapsulation 'sit'
vyos@vyos# set interfaces tunnel tun0 local-ip '192.0.2.129'
vyos@vyos# set interfaces tunnel tun0 remote-ip '192.0.2.130'
vyos@vyos# set interfaces tunnel tun0 mtu '1480'
vyos@vyos# commit

Depuis R1, toujours en mode Quagga, vérifier que le tunnel est actif et fonctionne en effectuant un test de connectivité avec l'autre extrémité du tunnel:

vyos# ping ipv6 fd75:e4d9:cb77:fff::2

Nota: l'arrêt de la commande ping s'effectue par un CTRL+C (appui simultané sur les touches Ctrl et c).

Sur une des interfaces ethernet entre R1 et R2, effectuez une capture lors du ping entre ces 2 noeuds afin d'observer les paquets échangés. Vous pouvez voir comment IPv6 est encapsulé dans un paquet IPv4. D'ailleurs quel est le numéro de protocole utilisé par IPv4 pour identifier IPv6 ?

Recommencez le test de connectivité depuis PC1.

apprenant@MOOCIPv6:~$ ping6 -c 5 fd75:e4d9:cb77:fff::2

Oups, cela ne marche plus. Quel est le problème ? Vous pouvez vérifier que PC1 à bien une route par défaut:

apprenant@MOOCIPv6:~$ route -A inet6

Qu'en est-il de la route de la réponse à la requête du ping? Regardez la table de routage sur R2 (en mode Quagga):

vyos@vyos:~$ vtysh
vyos# show ipv6 route

R2 n'a pas de route pour joindre le lien de PC1 qui est identifié par le préfixe fd75:e4d9:cb77:1::/64. Il faut donc ajouter une route à R2. En fait, nous n'allons pas ajouter une route particulière mais une route générale à savoir la route par défaut. En effet, on peut considérer que l'Internetv6 est du coté de R1. Sur R2, cet ajout s'effectue en mode configuration dans Quagga de la manière suivante :

vyos# configure terminal
vyos(config)# ipv6 route ::/0 tun0
vyos(config)# exit

Verifiez que l'entrée "route par défaut" a bien été ajoutée à la table de routage IPv6 de R2

vyos# show ipv6 route

Recommencez le test de connectivité depuis PC1

apprenant@MOOCIPv6:~$ ping6 -c 5 fd75:e4d9:cb77:fff::2

Si vous avez laissé la capture de trafic sur une des interfaces Ethernet entre R1 ou R2, vous pouvez voir les messages ICMPv6 circuler dans des paquets IPv6 eux-mêmes dans des paquets IPv4.

Au cours de cette étape, nous avons utilisé un tunnel configuré (encore appelé statique). La connectivité IPv6 a pu ainsi s'étendre au-dessus d'équipements qui devaient rester en IPv4. Ceci montre qu'il n'est pas nécessaire de changer ses équipements réseaux pour déployer IPv6 et que cela se fait bien progressivement.

Etape 3 : Configurer un reverse proxy web sur R2

Dans cette dernière étape, la base des clients en IPv6 est devenu conséquente. Une connectivité IPv6 arrive jusqu'au serveur web. Celui-ci fonctionne malgré tout toujours en IPv4. Cependant, l'hébergeur du serveur ne souhaite pas passer le service web en IPv6. Il n'est pas certain que l'application soit compatible à IPv6 surtout si il n'a pas les codes sources. Dans le doute, il préfère donc laisser son service en IPv4 mais il souhaite cependant répondre, nativement en IPv6, aux requêtes des clients en IPv6.

Nous avons vu dans l'étape 1 qu'un client IPv6 peut accéder au serveur mais nous avons vu il faut faire des modifications de routes lorsqu'un NAT64 doit être utilisé. Il faut aussi gérer un plan d'adressage en IPv6 et en IPv4 pour la traduction. Tout ceci n'est pas toujours possible notamment si les droits pour la configuration du réseau ne sont pas disponibles aux personnes en charge des serveurs. Une autre solution existe qui repose sur le niveau application de l'architecture de réseau. Cette solution n'implique plus la couche réseau. Il s'agit ici de déployer une passerelle applicative.

Nous allons, dans cette étape, mettre en oeuvre un reverse proxy web. Il sera en charge de recevoir les requêtes IPv6 pour le serveur et de les relayer au serveur en IPv4.

Sur le routeur R2, éditez la configuration du serveur nginx pour activer la redirection des requêtes vers le serveur. Pour cela reppassez en mode root, après vous être "délogué" de la manière suivante:

vyos# exit
vyos@vyos# exit
vyos@vyos:~$ exit

login: root
password: root

Editez le fichier /etc/nginx/nginx.conf, pour remplacer la directive

...
pid /run/nginx.pid
...

par

...
pid /var/run/nginx.pid
...

à l'aide de l'éditeur nano.

root@vyos:~# nano -w /etc/nginx/nginx.conf

Editez le fichier /etc/nginx/sites-available/default pour remplacer la directive

...
location / {
       # First attempt to serve request as file, then
       # as directory, then fall back to displaying a 404.
       try_files $uri $uri/ =404;
       # Uncomment to enable naxsi.rules
       # include /etc/ngingx/naxsi.rules
}
...

par

...
location / {
        proxy_pass http://192.0.2.1/;
}
...

Nota : Attention le ; en fin de ligne est nécessaire.

root@vyos:~# nano -w /etc/nginx/sites-available/default

Démarrez le serveur nginx.

root@vyos:~# nginx -c /etc/nginx/nginx.conf

Le service de DNS doit maintenant identifier le reverse proxy comme le serveur web en IPv6. Pour cela sur PC2, modifiez la configuration du DNS pour enregistrer l'adresse IPv6 du proxy:

apprenant@MOOCIPv6:~$ sudo nano -w /usr/local/etc/bind/db.tp
...
www             IN              A               192.0.2.1
                IN              AAAA            fd75:e4d9:cb77:fff::2

Relancez le serveur named. Pour cela, arrêter le processus named puis relancez le:

apprenant@MOOCIPv6:~$ sudo killall named
apprenant@MOOCIPv6:~$ sudo named -c /usr/local/etc/bind/named.conf

Sur le client IPv6 PC1, vérifiez que la résolution de nom du serveur web donne bien l'adresse IPv6 du proxy.

apprenant@MOOCIPv6:~$ dig -t AAAA www.tp +short

Vérifier que l'accès est maintenant possible à travers le proxy. Mais avant cela, vous allez activer une capture du trafic entre R1 et R2, et entre R2 et PC2.

apprenant@MOOCIPv6:~$ curl -6 http://www.tp

Dans les fenêtres de capture, vous pouvez vérifier :

• un paquet IPv6 pour la requête circule entre R1 et R2,
• l'adresse de destination IPv6 de la requête (fd75:e4d9:cb77:fff::2) est l'adresse IPv6 de l'interface du tunnel du noeud R2 qui est aussi le reverse proxy,
• après R2, les paquets sont au format IPv4. Quelles sont les adresses de source et de destination ?

Conclusion

Pour aller plus loin

1. ↑ http://www.litech.org/tayga/