Revision as of 16:12, 6 April 2016

Activité 45: Interopérer des applications par passerelles applicatives

Contexte d'utilisation des 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 NAT64 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 certaines applications ne fonctionnent plus lorsque leurs communications passent par un NAT64. C'est par exemple 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 l'utilisation de NAT64 conduit à une situation d'échec, le recours à une passerelle applicative constitue une alternative pour les applications dont l'installation d'un relais intermédiaire est possible.

Outre la résolution de certains défauts de fonctionnement, la solution de la passerelle applicative offre une technique d'interopérabilité moins intrusive que NAT64 au niveau de l'infrastructure de communication. En effet, déployer NAT64 demande de modifier le routage et d'allouer des adresses. Le déploiement du NAT64 est transparent pour les hôtes mais nécessite des modifications au niveau de l'infrastructure de communication. Dans le cas du déploiement d'une passerelle applicative, nous sommes dans une situation inverse, les modifications sont à apporter uniquement dans la configuration des hôtes : installation de la passerelle, mais aussi du client qui, dans certains cas, doit être configuré pour déléguer ses requêtes à la passerelle, à l'instar du navigateur web dont on configure la référence du proxy par exemple). Ainsi, il est possible avec une passerelle applicative d'avoir un déploiement progressif d'IPv6 dans le réseau sans perturber les services en place. Dans le cadre d'une infrastructure de communication en production, cette caractéristique peut être appréciée.

Enfin, dans le cas d'un client IPv4 qui se connecte à des serveurs de l'Internet v6, la passerelle applicative est de nos jours la seule méthode d'intéropérabilité. Mais il est vrai que ce scénario n'est pas encore d'actualité au vu de l'état du déploiement de l'Internet v6. Nous allons détailler dans la suite de cette activité les scénarios d'utilisation de ce dispositif dans le cas d'un client IPv6 avec un serveur IPv4.

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: Communication par passerelle applicative.

Une 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, etc.). 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,
• ...

Cas du service Web

Il s'agit ici de faire communiquer des clients avec des services Web, client et serveur 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.

ALG placée du coté du client

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ée du coté client.

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.

ALG placée du coté du 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 6589 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 comme montré par la figure 3. 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.

Figure 3: Exemple de passerelle applicative placée du coté 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. Le listing suivant donne un extrait de la configuration d'un relais inverse opéré par le logiciel nginx. La configuration consiste à indiquer à renvoyer les requêtes web reçues en IPv6 vers le serveur resté joignable en IPv4

#cat  /etc/nginx/sites-available/default
...
location / {
        proxy_pass http://192.0.2.1/;
}

Dans le contexte initial, le service Web n'est accessible qu'en IPv4. L'adresse IPv4 du service (notée S4) 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ée dans la figure 4.

Figure 4: Accès direct pour les clients IPv4.

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

• 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 (notée S6) comme l'adresse IPv6 officielle du serveur.

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 reverse proxy comme indiquée 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 [RFC 6883] :

• 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 dans la couche d'application, elles sont transparentes pour l'infrastructure de communications (routeurs). Elles ne demandent pas des modifications au niveau du réseau. Cependant, les passerelles applicatives posent des contraintes qui limitent leur usage^[1], telles que :

• introduction d'un délai pour le traitement des paquets,
• difficultés à passer le facteur d'échelle, et possibilité de congestion,
• applications non conçues pour fonctionner avec un relais intermédiaire.

En effet, 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. Enfin, une passerelle applicative n'est pas forcément le meilleur choix si le protocole applicatif embarque des adresses IP.

Références bibliographiques

1. ↑ IPv6.com. (2008). Tech spotlight. ALG - Application Level Gateway

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
• RFC 6883 IPv6 Guidance for Internet Content Providers and Application Service Providers Analyse
• RFC 7269 NAT64 Deployment Options and Experience Analyse