Revision as of 17:04, 10 June 2015

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

Interopérabilité avec les services IPv4 par passerelles applicatives

Principe des passerelles applicatives

Les relais applicatifs 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 Exemple de relais applicatif pour le courrier électronique) configurées pour accéder aux deux versions du protocole. Les clients IPv6 émettent leurs requêtes vers le relais applicatif comme s'ils s'adressaient directement au service. Le relais interprète le contenu de ces requêtes pour les retransmettre ensuite en IPv4 à destination du service concerné.

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

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 relais applicatifs. Certains protocoles ne sont pas prévus pour intégrer un relai intermédiaire (par exemple telnet). D'autres protocoles, par leur nature propriétaire, ne permettent pas le développement de passerelles par de tièrce 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 relais applicatifs regroupent :

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

Exemples de cas d'usage

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 relai 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 relai :

• 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 relai 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

La passerelle HTTP est ici localisée dans le réseau des clients, généralement dans la DMZ du site ou sur le routeur domestique. 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 accès Web depuis les clients de 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.

• 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ème opérationnel 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.

Une solution moins coûteuse et plus rapide à mettre en oeuvre (mais avec bien sûr quelques limitations) consiste à déployer un relai inverse (reverse-proxy) proche du serveur. Le rôle de ce relai 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 parle au relai comme s'il s'agissait du service, le relai transfert les requêtes vers le serveur.

CDN: Voir section 10, 12 de RFC 6883 (Bortzmeyer)

Exemple pour l'interopérabilité d'un service mail

Conclusion