Difference between revisions of "MOOC:Support Act46"
From Livre IPv6
(→Etape 2 : Mise en oeuvre d'un tunnel IPv6 sur IPv4) |
(→Etape 0 : Situation initiale) |
||
| Line 39: | Line 39: | ||
apprenant@MOOCIPv6:~$ '''/etc/init.d/bind restart''' | apprenant@MOOCIPv6:~$ '''/etc/init.d/bind restart''' | ||
| − | Vérifiez que la résolution de nom fonctionne depuis R1 à l'aide de la commande <tt>dig</tt | + | Vérifiez que la résolution de nom fonctionne depuis R1 à l'aide de la commande <tt>dig</tt>. |
L'adresse du serveur de nom à utiliser est indiquée par <tt>@192.0.2.1</tt>. | L'adresse du serveur de nom à utiliser est indiquée par <tt>@192.0.2.1</tt>. | ||
vyos login: '''root''' | vyos login: '''root''' | ||
Revision as of 07:11, 12 November 2015
> MOOC >Contenu>Ateliers>Activité 46
> MOOC >Contenu>Séquence 4>Activité 46
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 localise 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ésenteront les contenus disponibles sur l'Internet IPv4. Ce noeud hébergera également un serveur DNS.
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
Vérifiez que tout s'est bien passé, en consultant la fin du journal système à l'aide de la commande:
apprenant@ tail /var/log/syslog
Un message d'erreur indiquerait alors une erreur de configuration, qu'il y aurait lieu de corriger avant de poursuivre l'activité. Dans ce cas corriger les erreurs et redémarrer le service par la commande
apprenant@MOOCIPv6:~$ /etc/init.d/bind restart
Vérifiez que la résolution de nom fonctionne depuis R1 à l'aide de la commande dig. L'adresse du serveur de nom à utiliser est indiquée par @192.0.2.1.
vyos login: root Password: root root@vyos:~# dig @192.0.2.1 -t A www.tp +search +short
Activez le service web sur PC2 :
apprenant@MOOCIPv6:~$ sudo nginx
Vérifiez le bon fonctionnement de ces services depuis R1 :
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 sans état effectue la traduction de l'adresse source et de l'adresse de destination d'un paquet par la méthode sans état. La traduction de l'adresse sans état 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 avec 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é 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 comporte 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.
Allocation d'adresses
Le préfixe IPv6 alloué pour 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. Cette organisation dispose aussi du préfixe IPv4 192.0.3.0/24 quelle réserve à la traduction. Le réseau IPv6 est identifié par le SID de valeur 1. La figure 3 montre la répartition des identifiants d'interface, des SID et des préfixes IPv4. Par soucis de simplification, nous utiliserons les mêmes identifiants d'interface en IPv4 et en IPv6
L'allocation des adresses pour chaque noeud est donc faite selon le tableau 1.
| Noeuds | @ IPv4 | @ IPv6 |
|---|---|---|
| PC1 | fd75:e4d9:cb77:1::3 | |
| 192.0.3.3 | fd75:e4d9:cb77:64::192.0.3.3 | |
| R1 | 192.0.3.1 | fd75:e4d9:cb77:64::192.0.3.1 |
| fd75:e4d9:cb77:1::1 | ||
| 192.0.1.130 | ||
| R2 | 192.0.1.129 | |
| 192.0.2.2 | ||
| PC2 | 192.0.2.1 |
Tableau 1: Allocation des adresses.
Il est à noter que bien que PC1 soit un noeud IPv6 uniquement, il possède une adresse IPv4. Cette adresse n'est pas mise à 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 IPv6 routables: une utilisée pour les communications avec des noeuds IPv6 et une autre utilisée pour les communictions avec des noeuds IPv4. Lorsque PC1 envoie une requête à PC2, il utilise comme adresse source fd75:e4d9:cb77:64::192.0.3.3 et comme adresse de destination fd75:e4d9:cb77:64::192.0.2.3. Une fois le NAT64 passé, les adresses deviennent 192.0.3.3 et 192.0.2.3 respectivement adresse source et adresse destination.
Maintenant que nous avons posé le principe de fonctionnement de la technique DNS64/NAT64 pour cette plateforme, nous allons configuré 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).
Ajoutez l'adresse IPv6 traduisible en IPv4. La longueur du préfixe est fixée à 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
Enuite il faut indiquer une route au préfixe réservé à la traduction. La route doit faire converger le trafic vers le NAT64. Ceci serait surtout vrai si il y avait des routeurs intermédiaires entre PC1 et NAT64. Ceci s'effectuerai 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 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 :
apprenant@MOOCIPv6:~$ vi /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 proxy. 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 la 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 comme nous l'avons vu jusqu'à présent. Avant de démarrer le service DNS auxiliaire, compléter le contenu du fichier de configuration par les informations nécessaire à la traduction. Sur R1 (en mode root), éditez le fichier de configuration de TOTD
root@vyos:~# nano /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 DNS. Le préfixe indique 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
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
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. Pour illustrer la figure 2 sur le fonctionnement du DNS64, vous pouvez voir les échanges par une capture du trafic sur l'interface eth0 et eth1 de R1. Cette capture est à faire lors d'une résolution de www.tp en une adresse IPv6 demandé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 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. Nous allons commencer par configurer les interfaces réseaux de R1, l'interface eth0 avec les informations liées à IPv6 et eth1 à IPv4.
root@vyos~# ifconfig eth0 inet6 add fd75:d0d0:1e1a:2::1/64 root@vyos~# ifconfig eth1 192.0.1.1/24
Ensuite il reste à indiquer les routes statiques :
root@vyos~# ip route add 192.0.2.0/24 via 192.0.1.2 dev eth1
R1 vient d'être configuré en double pile. Il reste à rendre interoperable les 2 versions Pour cela nous allons onfigurez le logiciel TAYGA:
root@vyos~# nano /etc/tayga.conf tun-device nat64 ipv4-addr 192.0.3.1 prefix fd75:e4d9:cb77:64::/96 # End
Configurez le réseau 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.1.1 dev nat64 #router address root@vyos~# ip -6 addr add fd75:e4d9:cb77:1::1 dev 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
Sur R2, ajoutez la route vers le préfixe utilisé pour représenter les postes IPv6 en IPv4
vyos@vyos:~$ vtysh vyos# configure terminal vyos(config)# ip route 192.0.3.0/24 192.0.2.1
Démarrez TAYGA sur R1
root@vyos~# tayga -d
Le service est maintenant opérationnel. Pour le valider faire un simple test de connectivité ping depuis PC1 :
apprenant@MOOCIPv6:~$ ping6 www.tp
Maintenant, testez que le client IPv6 (sur PC1) accède bien au service web :
apprenant@MOOCIPv6:~$ curl http://www.tp
Etape 2 : Mise en oeuvre d'un tunnel IPv6 sur IPv4
Le temps se faisant, 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. Dans cette étape, nous allons établir un tunnel du réseau IPv6 (de R1) au routeur de bordure du réseau du serveur web (R2) comme indiquée par la figure 4.
Sur R1, configurer le point d'entrée du tunnel
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
Sur R2, configurer le point de sortie du tunnel
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
Vérifiez la connectivité depuis R1
vyos@vyos:~# ping6 fd75:e4d9:cb77:fff::2/64
Observez les paquets sur une capture réseau entre R1 et R2
Vérifiez la connectivité depuis PC1
apprenant@MOOCIPv6:~$ ping6 fd75:e4d9:cb77:fff::2/64
Quel est le problème ?
Ajouter la route sur R2
vyos@vyos:~$ vtysh vyos# configure terminal vyos(config)# ipv6 route ::/0 tun0
Vérifiez la connectivité depuis PC1
Etape 3 : Configurer un reverse proxy web sur R2
Sur R2, éditez la configuration du serveur nginx pour activer la redirection des requêtes vers le serveur
login: root
password: root
vyos# vi /etc/nginx/sites-available/default
...
location / {
proxy_pass http://192.0.2.1/;
}
Sur PC2, modifiez la configuration du DNS pour enregistrer l'adresse IPv6 du proxy
apprenant@MOOCIPv6:~$ sudo vi /usr/local/etc/bind/db.tp
...
www IN A 192.0.2.1
IN AAAA fd75:e4d9:cb77:fff::2
Relancez le serveur named
apprenant@MOOCIPv6:~$ sudo killall named apprenant@MOOCIPv6:~$ sudo named -c /usr/local/etc/bind/named.conf
Sur PC1, vérifiez que la nouvelle adresse IPv6 a bien été prise en compte
apprenant@MOOCIPv6:~$ host www.tp
Vérifier que l'accès est maintenant possible à travers le proxy, en capturant le trafic entre R1 et R2, et entre R2 et PC2.
apprenant@MOOCIPv6:~$ curl http://www.tp