MOOC:Support Act46 - Revision history

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

2019-06-05T03:47:58Z

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

Panelli at 03:45, 5 June 2019

2019-06-05T03:45:50Z

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

2017-02-17T12:38:56Z

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

Panelli: /* Mise en oeuvre de NAT64 sur R1 */

2016-08-29T11:46:14Z

‎Mise en oeuvre de NAT64 sur R1

Jlandru at 11:55, 18 May 2016

2016-05-18T11:55:08Z

Vlerouvillois: /* Mise en oeuvre de NAT64 sur R1 */

2016-05-16T08:21:46Z

‎Mise en oeuvre de NAT64 sur R1

Vlerouvillois: /* Mise en oeuvre de NAT64 sur R1 */

2016-05-16T08:21:04Z

‎Mise en oeuvre de NAT64 sur R1

Vlerouvillois: /* Conclusion */

2016-05-16T08:20:06Z

‎Conclusion

Vlerouvillois: /* Etape 3 : Configurer un reverse proxy web sur R2 */

2016-05-16T08:17:20Z

‎Etape 3 : Configurer un reverse proxy web sur R2

Vlerouvillois: /* Etape 3 : Configurer un reverse proxy web sur R2 */

2016-05-16T08:14:46Z

‎Etape 3 : Configurer un reverse proxy web sur R2

@@ Line 1: / Line 1: @@
 __NOTOC__
-= Activité 46:  Faites interopérer des applications IPv6 et IPv4=
+= Session 1 à 4 - 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. À ce stade du déploiement, nous avons 2 Internets :

@@ Line 1: / Line 1: @@
 __NOTOC__
-= Session3-Activité 46:  Faites interopérer des applications IPv6 et IPv4=
+= 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. À ce stade du déploiement, nous avons 2 Internets :

@@ Line 1: / Line 1: @@
 __NOTOC__
-= Activité 46:  Faites interopérer des applications IPv6 et IPv4=
+= Session3-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. À ce stade du déploiement, nous avons 2 Internets :

@@ Line 251: / Line 251: @@
 '''Nota :''' les commentaires préfixés par le caractère '#' ne sont pas à saisir. Ils servent uniquement à expliciter les lignes à entrer.
-Sur R2, ajoutez la route vers R1 pour le préfixe IPv4 utilisé pour représenter les postes IPv6 dans le réseau IPv4. Pour cela, vous allez vous connecter en mode utilisateur et passer en mode Quagga :
+Sur R2, ajoutez la route vers R1 pour le préfixe IPv4 utilisé pour représenter les noeuds IPv6 dans le réseau IPv4. Pour cela, vous allez vous connecter en mode utilisateur et passer en mode Quagga :
   root@vyos:~$ '''vtysh'''
   vyos# '''configure terminal'''
@@ Line 257: / Line 257: @@
   vyos(config)# exit
   vyos#
 Démarrez '''TAYGA''' sur R1 :

@@ Line 20: / Line 20: @@
 </center>
-== Etape 0 : Situation initiale ==
+= 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.
@@ Line 59: / Line 59: @@
 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 <tt>www.tp</tt> qui est en ''IPv4-only'' ?
-== Etape 1 : Configuration de NAT64/DNS64 ==
+= 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 en double pile R1.
@@ Line 77: / Line 77: @@
 </center>
-=== Allocation d'adresses ===
+== Allocation d'adresses ==
 Le préfixe IPv6 alloué à l'organisation en charge du réseau IPv6 est <tt>fd75:e4d9:cb77::/48</tt>. Elle réserve le SID (''Subnet ID'') <tt>64</tt> pour constituer un préfixe IPv6 NSP (''Network-Specific Prefix''). Le NSP utilisé pour la traduction est donc <tt>fd75:e4d9:cb77:64::/96</tt> (nous choisissons un préfixe de 96 bits pour embarquer l'adresse IPv4 sur les 32 bits de poids faible de l'adresse ''IPv4-converted'' comme indiqué par le RFC 6052). Le réseau IPv6, quant à lui, est identifié par le SID de valeur <tt>1</tt> pour former le préfixe <tt>fd75:e4d9:cb77:1::/64</tt>. Cette organisation dispose aussi du préfixe IPv4 <tt>192.0.3.0/24</tt>, qu'elle réserve pour les noeuds IPv6 utilisant le service NAT64.
@@ Line 128: / Line 128: @@
 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 ===
+== Configuration de PC1 ==
 Fixez l'adresse IPv6 de l'interface eth0 de PC1, avec l'IID positionné à la valeur <tt>3</tt>, conformément au tableau 1. La commande de configuration d'interface doit s'exécuter avec les droits ''root'' indiqués par la commande ''sudo'' :
@@ Line 146: / Line 146: @@
   nameserver '''fd75:e4d9:cb77:1::1'''
-=== Mise en oeuvre du DNS64 sur R1===
+== Mise en oeuvre du DNS64 sur R1==
 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 et de répondre au client DNS avec le RR de type AAAA correspondant (voir la figure 2).
@@ Line 196: / Line 196: @@
 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 sur R1===
+== Mise en oeuvre de NAT64 sur R1==
 '''TAYGA'''<ref> http://www.litech.org/tayga/</ref> (''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.
@@ Line 269: / Line 269: @@
 Observez les captures de part et d'autre du traducteur '''TAYGA'''.
-== Etape 2 : Connectivité  IPv6 par tunnel ==
+= 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. Sur notre plateforme, 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 cas, le tunnel reliera le réseau IPv6 (de R1) au routeur de bordure du réseau du serveur web (R2) comme indiqué par la figure 4.
@@ Line 355: / Line 355: @@
 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 ==
+= Etape 3 : Configurer un reverse proxy web sur R2 =
 Dans cette dernière étape, la base des clients en IPv6 est devenue 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'applicatif web soit compatible avec IPv6, surtout s'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.
@@ Line 427: / Line 427: @@
 * après R2, les paquets sont au format IPv4. Quelles sont les adresses de source et de destination ?
-== Conclusion ==
+= Conclusion =
 Au cours de cette activité, nous avons pu déployer 2 solutions d'interopérabilité entre un client 'IPv6 uniquement' et un serveur resté en IPv4. Nous avons aussi pu expérimenter comment étendre la connectivité au-dessus d'équipements qui ne sont pas en IPv6, au moyen d'un tunnel. Au-delà des techniques, ce que nous avons voulu montrer, c'est que le déploiement d'IPv6 s'effectue bien progressivement, sans arrêter l'existant ou sans avoir à acheter de nouveaux équipements ou, pire, remplacer ceux déjà en place. De plus, cela montre également que le déploiement de nouveaux réseaux peut (devrait !?) se faire nativement en IPv6 puisque l'accès aux ressources restées dans l'ancien monde IPv4 peut se faire de manière transparente du point de vue des clients 'uniquement v6'.

@@ Line 231: / Line 231: @@
 '''Nota :''' les commentaires préfixés par le caractère '#' ne sont pas à saisir. Il servent uniquement à expliciter les lignes à mettre dans le fichier.
 <!--
-Configurez les routes pour TAYGA sur R1:
+Configurez les routes pour TAYGA sur R1 :
   root@vyos~# '''tayga --mktun'''              # create nat64 device
   root@vyos~# '''ip link set nat64 up'''       # activate nat64 device
@@ Line 241: / Line 241: @@
 -->
-Configurez les routes pour TAYGA sur R1:
+Configurez les routes pour TAYGA sur R1 :
   root@vyos~# '''tayga --mktun'''              # create nat64 device
   root@vyos~# '''ip link set nat64 up'''       # activate nat64 device

@@ Line 219: / Line 219: @@
 R1 vient d'être configuré en double pile.
-Il reste à configurer le logiciel '''TAYGA''' sur R1:
+Il reste à configurer le logiciel '''TAYGA''' sur R1 :
 -->

@@ Line 429: / Line 429: @@
 == Conclusion ==
-Au cours de cette activité, nous avons pu déployer 2 solutions d'interopérabilité entre un client IPv6 uniquement et un serveur resté en IPv4. Nous avons aussi pu expérimenter comment étendre la connectivité au dessus d'équipements qui ne sont pas en IPv6 au moyen d'un tunnel. Au delà des techniques, ce que nous avons voulu montrer c'est que le déploiement d'IPv6 s'effectue bien progressivement, sans arrêter l'existant ou sans avoir à acheter de nouveaux équipements, ou pire, remplacer ceux déjà en place. De plus cela montre également que le déploiement de nouveaux réseaux peut (devrait !?) se faire nativement en IPv6, puisque l'accès aux ressources restées dans l'ancien monde IPv4 peut se faire de manière transparente du point de vue des clients uniquement v6.
+Au cours de cette activité, nous avons pu déployer 2 solutions d'interopérabilité entre un client 'IPv6 uniquement' et un serveur resté en IPv4. Nous avons aussi pu expérimenter comment étendre la connectivité au-dessus d'équipements qui ne sont pas en IPv6, au moyen d'un tunnel. Au-delà des techniques, ce que nous avons voulu montrer, c'est que le déploiement d'IPv6 s'effectue bien progressivement, sans arrêter l'existant ou sans avoir à acheter de nouveaux équipements ou, pire, remplacer ceux déjà en place. De plus, cela montre également que le déploiement de nouveaux réseaux peut (devrait !?) se faire nativement en IPv6 puisque l'accès aux ressources restées dans l'ancien monde IPv4 peut se faire de manière transparente du point de vue des clients 'uniquement v6'.
-Certes, la coexistence avec IPv4 complique le déploiement d'IPv6. Mais la réutilisation de l'existant est la condition nécessaire à l'adoption d'IPv6 dans l'Internet. Cette activité a montré que des solutions fonctionnelles existaient pour utiliser IPv6 dans un réseau IPv4.
+Certes, la coexistence avec IPv4 complique le déploiement d'IPv6. Mais la réutilisation de l'existant est la condition nécessaire à l'adoption d'IPv6 dans l'Internet. Cette activité a montré que des solutions fonctionnelles existent pour utiliser IPv6 dans un réseau IPv4.
 =Pour aller plus loin=
 <references />

@@ Line 394: / Line 394: @@
   '''}'''
   ...
-'''Nota''' : attention ! le <tt>;</tt> en fin de ligne est nécessaire. Les <tt>...</tt> ne sont pas à saisir ; ils représentent le contenu actuel du fichier.
+'''Attention !''' le <tt>;</tt> en fin de ligne est nécessaire. Les <tt>...</tt> ne sont pas à saisir ; ils représentent le contenu actuel du fichier.
 L'appel de l'éditeur s'effectue par la commande :
@@ Line 418: / Line 418: @@
   apprenant@MOOCIPv6:~$ '''dig -t AAAA www.tp +short'''
-Vérifier que l'accès au web est maintenant possible à travers le proxy par la commande <tt>curl</tt>. Mais, avant cela, vous allez activer une capture du trafic entre R1 et R2, et entre R2 et PC2.
+Vérifiez que l'accès au web est maintenant possible à travers le proxy par la commande <tt>curl</tt>. 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'''

@@ Line 356: / Line 356: @@
 == Etape 3 : Configurer un reverse proxy web sur R2 ==
-Dans cette dernière étape, la base des clients en IPv6 est devenue 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'applicatif web soit compatible à IPv6, surtout s'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.
+Dans cette dernière étape, la base des clients en IPv6 est devenue 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'applicatif web soit compatible avec IPv6, surtout s'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 à l'aide d'un NAT64. Mais nous avons vu aussi qu'il faut faire des modifications de routes, qu'il faut 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.
+Nous avons vu, dans l'étape 1, qu'un  client IPv6 peut accéder au serveur à l'aide d'un NAT64. Mais nous avons vu aussi qu'il faut faire des modifications de routes, qu'il faut 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 dans ce cas. Cette solution repose sur le niveau application de l'architecture de réseau et n'implique plus la couche de réseau. Il s'agit maintenant de déployer une passerelle applicative.
 Dans cette étape, nous allons 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 <tt>nginx</tt> pour activer la redirection des requêtes vers le serveur. Pour cela passez en mode root, en terminant la session en cours par la commande <tt>exit</tt> jusqu'à voir s'afficher l'invite de connexion :
+Sur le routeur R2, éditez la configuration du serveur <tt>nginx</tt> pour activer la redirection des requêtes vers le serveur. Pour cela, passez en mode ''root'', en terminant la session en cours par la commande <tt>exit</tt> jusqu'à voir s'afficher l'invite de connexion :
   login: '''root'''
   password: '''root'''
-Editez le fichier <tt>/etc/nginx/nginx.conf</tt>, pour remplacer la directive
+Editez le fichier <tt>/etc/nginx/nginx.conf</tt> pour remplacer la directive
   ...
   pid /run/nginx.pid
@@ Line 394: / Line 394: @@
   '''}'''
   ...
-'''Nota''' : Attention le <tt>;</tt> en fin de ligne est nécessaire. Les <tt>...</tt> ne sont pas à saisir, ils représentent le contenu actuel du fichier.
+'''Nota''' : attention ! le <tt>;</tt> en fin de ligne est nécessaire. Les <tt>...</tt> ne sont pas à saisir ; ils représentent le contenu actuel du fichier.
-L'appel de l'éditeur s'effectue par la commande:
+L'appel de l'éditeur s'effectue par la commande :
   root@vyos:~# '''nano -w /etc/nginx/sites-available/default'''
-Démarrez le serveur nginx:
+Démarrez le serveur nginx :
   root@vyos:~# '''nginx -c /etc/nginx/nginx.conf'''
@@ Line 409: / Line 409: @@
                   '''IN              AAAA            fd75:e4d9:cb77:fff::2'''
-Relancez le serveur <tt>named</tt>. Pour cela, arrêtez le processus named, puis relancez le :
+Relancez le serveur <tt>named</tt>. Pour cela, arrêtez le processus ''named'' puis relancez-le :
   apprenant@MOOCIPv6:~$ '''sudo killall named'''
@@ Line 418: / Line 418: @@
   apprenant@MOOCIPv6:~$ '''dig -t AAAA www.tp +short'''
-Vérifier que l'accès au web est maintenant possible à travers le proxy par la commande <tt>curl</tt>. Mais avant cela, vous allez activer une capture du trafic entre R1 et R2, et entre R2 et PC2.
+Vérifier que l'accès au web est maintenant possible à travers le proxy par la commande <tt>curl</tt>. 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 :
+Dans les fenêtres de capture, vous pouvez vérifier que :
-* les paquets d'établissement d'un connexion TCP entre PC1 et R2 sur IPv6 circulent entre R1 et R2,
+* les paquets d'établissement d'une connexion TCP entre PC1 et R2 sur IPv6 circulent entre R1 et R2 ;
-* l'adresse de destination IPv6 de la connexion (<tt>fd75:e4d9:cb77:fff::2</tt>) est l'adresse IPv6 du ''reverse proxy'', qui est aussi celle de l'interface du tunnel du noeud R2,
+* l'adresse de destination IPv6 de la connexion (<tt>fd75:e4d9:cb77:fff::2</tt>) est l'adresse IPv6 du ''reverse proxy'', qui est aussi celle de l'interface du tunnel du noeud R2 ;
 * après R2, les paquets sont au format IPv4. Quelles sont les adresses de source et de destination ?