Revision as of 15:53, 16 September 2015

> MOOC>Contenu>Séquence 4 > Activité 45

Activité 45: Interopérabilité avec les services IPv4 par passerelles applicatives

Il n'existe pas une solution magique à tous les problèmes. Le déploiement bien trop lent d'IPv6 a laissé une situation peu satisfaisante face au manque d'adresses IPv4. La migration vers IPv6 ne pourra pas se faire sans la traduction. Comme nous l'avons vu, la traduction au niveau réseau à l'aide de NAT64 est un dispositif qui vise à faciliter le déploiement des clients IPv6 tout en étant aussi utilisable pour rendre les serveurs IPv4 accessibles à l'Internet v6. Si NAT 64 est une solution fonctionnelle pour la communication avec des systèmes IPv4. Le retour d'expérience rapporté par les RFC 6586 et RFC 7269 montre que des applications ne fonctionnent plus lorsque leurs communications passent par un NAT64. Comme c'est le cas de la signalisation de la téléphonie (les adresses IP sont transmises dans la signalisation, et ne sont pas traduites par NAT64). Lorsque les applications fonctionnent ou peuvent fonctionner avec un relais. Autrement dit, si la communication ne s'effectue pas de bout en bout (de la source à la destination), une solution reposant sur une passerelle applicative peut être envisagée. Cette solution présente l'avantage d'être indépendante du routage et de l'adressage. En effet, l'installation d'une passerelle applicative n'implique pas les routeurs du réseau et se limite à la configuration d'hôtes. Au contraire de l'installation d'un NAT64 qui demande le routage d'un préfixe particulier.
Nous allons voir dans la suite de cette activité les scénarios d'utilisation de ce dispositif ainsi qu'une de ses applications .

Principe des passerelles applicatives

Les passerelles applicatives ou ALG (Application Level Gateway) représentent le moyen le plus simple pour assurer une relation entre le monde IPv4 et le monde IPv6. Il s'agit de machines avec une double pile (cf. figure 1) configurées pour accéder aux deux versions du protocole. Les clients IPv6 émettent leurs requêtes vers la passerelle applicative comme s'ils s'adressaient directement au service. La passerelle interprète le contenu de ces requêtes pour les retransmettre ensuite en IPv4 à destination du service concerné.

Figure 1: Exemple de passerelle applicative pour le courrier électronique.

Un ou plusieurs passerelles peuvent être installées en fonction des services rendus disponibles sur le réseau (par exemple : serveur d'impression, serveur de messagerie, web, ...). Les machines clientes doivent être configurées pour adresser leurs requêtes applicatives à ces passerelles.

L'usage de ces techniques est très fréquent dans les réseaux privés pour communiquer avec l'extérieur. Tous les protocoles ne peuvent pas utiliser les passerelles applicatives. Certains protocoles ne sont pas prévus pour intégrer un relais intermédiaire (par exemple telnet). D'autres protocoles, par leur nature propriétaire, ne permettent pas le développement de passerelles par une tierce partie si celle ci n'est pas disponible (comme par exemple Skype). Mais comme la liste suivante l'indique, les ALG concernent des applications courantes qui représentent une partie importante du trafic. Cela permet également d'alléger le travail d'autres mécanismes de transition qui sont plus complexes à mettre en œuvre.
Les passerelles applicatives regroupent :

• les proxies et les caches web,
• les spoolers d'impression,
• les serveurs de courrier électronique,
• les serveurs DNS,
• ...

Exemple pour l'interopérabilité avec les services web

Il s'agit ici de faire communiquer des clients avec des services Web, chacun utilisant une version différente du protocole IP. La passerelle applicative utilisée dans ce cas est un relais HTTP qui va interpréter les requêtes des clients pour les retransmettre vers le serveur Web. Deux modèles de déploiement existent pour ce type de relais :

• le déploiement d'un serveur mandataire (proxy) dans le réseau des clients, leur permettant d'atteindre les serveurs extérieurs, dont ceux qui n'utilisent pas la même version du protocole IP,
• le déploiement d'un relais inverse (reverse proxy) dans le réseau du serveur, permettant d'accepter les requêtes des clients qui n'utilisent pas la même version du protocole IP que le serveur.

Interopérabilité côté clients

Le relais HTTP est ici localisé dans le réseau des clients, généralement dans la DMZ du site ou sur le routeur domestique comme le montre la figure 2. Les clients sont configurés pour utiliser cette passerelle en tant que serveur mandataire afin d'atteindre les services Web extérieurs. Ce type de déploiement est couramment utilisé pour sécuriser les clients d'accès Web vers des sites malveillants.

Afin de permettre l'interopérabilité entre les différentes versions du protocole IP, la passerelle est connectée et configurée sur un réseau double pile. Si par exemple les clients sont sur un réseau seulement IPv6, l'adresse IPv6 de la passerelle leur est indiquée en tant que serveur mandataire. La passerelle recevra alors les requêtes HTTP de ces clients et les relaiera vers les services demandées en IPv4 ou en IPv6 selon le protocole utilisé par le serveur.

Figure 2: Exemple de passerelle applicative placé du coté client.

• Client IPv6
• Proxy web double pile en coupure du réseau des clients
• Service IPv4

Le listing suivant donne un extrait de la configuration d'un serveur Apache pour que celui-ci serve de relais aux requêtes émises par des navigateurs. Aucune configuration n'est relative au protocole IPv6. Il suffit d'activer la fonction de proxy.

#cat /usr/local/etc/apache/httpd.conf
#
# Proxy Server directives. Uncomment the following lines to
# enable the proxy server:
#
<IfModule mod_proxy.c>
ProxyRequests On
<Directory proxy:*>
Order deny,allow
Allow from all
</Directory>
#
# Enable/disable the handling of HTTP/1.1 "Via:" headers.
# ("Full" adds the server ver.;"Block" removes all outgoing Via: headers)
# Set to one of: Off | On | Full | Block
#
ProxyVia On
</IfModule>
# End of proxy directives.

Interopérabilité côté service

La problématique ici à résoudre est de rendre un service Web accessible avec les 2 versions du protocole IP alors que celui-ci n'en utilise qu'une seule. S'ajoute à cette problématique la contrainte opérationnelle du service : le fonctionnement du site web sera-t'il perturbé par l'intégration d'IPv6 ? L'expérience utilisateur des visiteurs va-t'elle être impactée ?

Pour rendre accessible un service Web en IPv6, la solution la plus simple consiste à activer la connectivité IPv6 sur le réseau où est connecté ce service, ainsi que sur la machine qui l'héberge. Mais cette solution pose un ensemble de problèmes opérationnels car l'infrastructure d'hébergement d'un site Web peut être assez complexe (système d'équilibrage de charge ou load balancers, cache, etc.). Une réelle étude du passage à IPv6 de cette infrastructure peut être nécessaire pour effectuer une transition pérenne. Le RFC 6883 s'intéresse à cette problématique et délivre un ensemble de conseils pour les hébergeurs qui veulent rendre leurs serveurs accessibles en IPv6.

Déploiement d'un relais inverse

Une solution moins coûteuse et plus rapide à mettre en oeuvre (mais avec bien sûr quelques limitations) consiste à déployer un relais inverse (reverse-proxy) proche du serveur. Le rôle de ce relais est d'accepter les requêtes vers le service Web utilisant la version du protocole qui n'est pas encore déployée sur le serveur. Les clients envoient leur requête au relais de manière transparente, comme s'il s'agissait du service. Le relais se charge pour le client de transférer les requêtes vers le serveur et de recevoir sa réponse, en utilisant le protocole IP déployé sur le serveur.

Dans la mise en oeuvre du relais inverse, une étape importante consiste en la configuration du DNS. En effet, l'adresse du relais doit être renseignée comme l'un des enregistrements pour le service concerné. Ainsi, par exemple, pour un service seulement accessible en IPv4, l'adresse IPv6 du relais sera renseignée comme enregistrement AAAA au même niveau que l'enregistrement A de l'adresse du serveur.

Dans le contexte initial, le service Web n'est accessible qu'en IPv4. L'adresse IPv4 du service est enregistrée dans le DNS, celle-ci est récupérée par les clients à partir du nom du service afin d'initier une connexion vers le serveur comme montré par la figure 3.

Figure 3: Accès direct pour les clients IPv4

Le scénario d'intégration d'IPv6 dans sur un service Web par un relais inverse passe par 2 actions comme représenté par la figure 4:

• La mise en place d'un relais inverse dans l'infrastructure du service, sur un réseau double-pile ;
• L'enregistrement de l'adresse IPv6 du relais comme l'adresse IPv6 officielle du serveur.

Figure 4: Mise en place d'un relais inverse pour les clients IPv6.

Un client possédant une connectivité IPv6 et souhaitant consulter le service va résoudre le nom du service en 2 adresses, une IPv4 et une IPv6. La préférence à IPv6 du navigateur lui fera utiliser en priorité cette adresse. Sa requête se fera alors de manière transparente à destination du proxy comme indiqué par la figure 5.

Figure 5: Accès par le relais inverse pour les clients IPv6.

Le relais inverse propose donc une solution simple pour assurer une interopérabilité de son service Web avec IPv6. Cependant elle n'est pas adaptée à des sites à large audience. Même largement dimensionné, un unique relais ne pourrait pas absorber la portion IPv6 des requêtes, même si celle-ci est encore en dessous des 10%. De plus le relais constitue un point de faiblesse unique (SPOF, Single Point of Failure) pouvant compromettre l'accès au service.

Utilisation d'un service d'hébergement ou de distribution des contenus

Pour ces sites à large audience, plusieurs solutions peuvent être envisagées pour permettre l'interopérabilité avec IPv6 :

• Migrer son infrastructure d'hébergement en double-pile (comme mentionné plus haut, cette solution est la plus complexe) ;
• Faire appel à un service d'hébergement offrant une connectivité double-pile ;
• Continuer à héberger son service en IPv4, mais utiliser un réseau de distribution de contenus (CDN, Content Delivery Network) double-pile.

Les 2 dernières solutions permettent au responsable du service de déléguer la complexité de l'intégration et de la gestion d'IPv6 à un prestataire extérieur. Ces services sont aujourd'hui assez répandus. Les hébergeurs de sites Web offrent maintenant couramment un accès double-pile aux services hébergés, que ce soit sur des offres de serveurs mutualisés ou dédiés. Toutes les prestations d'hébergement des acteurs majeurs en France que sont OVH, Gandi ou Online, intègrent IPv6 dans leurs offres.

Les réseaux de distribution de contenus (ou CDN) ont pour objectif de répliquer le contenu du service en différents points stratégiques du réseau, permettant aux utilisateurs d'accéder plus rapidement au service et à l'infrastructure du service d'être soulagée d'une partie du trafic. Les CDNs peuvent de plus permettre l'interopérabilité avec IPv6 en jouant le même rôle que le relais inverse vu précédemment, avec bien sûr une infrastructure plus robuste. Des services de CDN comme Akamai, CloudFlare ou Cedexis permettent ainsi d'offrir des contenus en IPv6 alors que ceux-ci sont hébergés sur des services seulement IPv4.

Conclusion

Les passerelles applicatives offrent un moyen simple d'interopération entre des clients et des serveurs qui n'utilisent pas la même version du protocole IP. Parce qu'elles interprètent le contenu du paquet à plusieurs niveaux, elles sont transparentes pour le client comme pour le serveur.

Cependant, cette solution ne s'applique qu'aux protocoles applicatifs permettant d'avoir un relais intermédiaire. Des protocoles propriétaires, ainsi que certains protocoles assurant la confidentialité des communications peuvent rendre impossible la mise en oeuvre d'un tel dispositif (pour un protocole de sécurité, une telle passerelle pourrait s'apparenter à un homme-au-milieu). De plus, selon le protocole utilisé, la mise en oeuvre d'une telle passerelle peut s'avérer complexe : par exemple, SIP nécessite une interprétation de l'ensemble de la signalisation.

Références bibliographiques

Pour aller plus loin

RFC et leur analyse par S. Bortzmeyer

• RFC 6144 Framework for IPv4/IPv6 Translation Analyse
• RFC 6384 An FTP Application Layer Gateway (ALG) for IPv6-to-IPv4 Translation
• RFC 6586 Experiences from an IPv6-Only Network Analyse
• RFC 6589: Considerations for Transitioning Content to IPv6 Analyse