HTTP : le protocole du Web passé en revue


précédentsommairesuivant

VII. Proxies

Les proxies sont très utilisés de nos jours, sur le Web notamment. Nous allons tenter d'expliquer leur fonctionnement et leur utilité.

VII-A. Définitions

Un proxy est un serveur qui va agir à la place d'un autre. C'est une machine intercalée sur le réseau, qui souvent "prend la place" logique d'une autre.
On distingue 2 cas de proxies HTTP : forward ou reverse, et il est très important de comprendre la différence entre un forward et un reverse proxy.
Dans un forward proxy, les clients demandent à un serveur de relayer la requête vers le serveur de destination. Cela se fait généralement en réglant le navigateur et en lui spécifiant un proxy à utiliser (pas toujours, on peut aussi régler le réseau pour utiliser un proxy de manière totalement transparente). En entreprise, c'est assez courant : le firewall bloque le port 80, les clients doivent donc obligatoirement passer par le proxy pour aller surfer sur le Web. Le proxy va alors souvent mettre en cache des ressources qu'il pourra resservir à différents clients.
Image non disponible

Dans un reverse proxy, les utilisateurs accèdent à un contenu sur un serveur (par exemple http://serveur/page/ressource) mais ce contenu n'est en réalité pas stocké sur ce serveur. Celui-ci va alors agir comme un proxy vers le serveur de destination. Ces serveurs proxy peuvent aussi jouer un rôle dans l'équilibrage de charge (load balancing), ils peuvent par exemple contacter plusieurs serveurs de destination en fonction de leur charge respective, mais ceci dépasse le cadre de cet article.
Image non disponible

Il est bien sûr possible de mixer le forward et le reverse proxy, et il est aussi possible que plusieurs proxies relayent la requête du client entre eux en créant alors un chemin de proxies.
Le but principal des proxies HTTP est souvent le même : si une machine proxy proche du client possède la ressource demandée et que celle-ci est valide, la chaine va alors être brisée et le serveur d'origine (ainsi que les éventuels proxies intermédiaires) ne sera alors pas contacté.
Il existe des protocoles, comme "ICP" (Inter Cache Protocol), capables de faire communiquer les caches entre eux, dans des relations parents/enfants. Cela dépasse le cadre de cet article, notez simplement quelques protocoles s'ils vous intéressent : ICP, CARP, HTC et WCCP.

VII-B. Rôles

Les rôles d'un proxy HTTP sont très divers :

  1. cache: C'est clairement le rôle principal et la partie sur laquelle nous allons nous étendre dans le chapitre suivant, un proxy va pouvoir mettre en cache une ressource qu'un client A lui demande, et éventuellement la resservir à un client B la demandant plus tard. Il y a donc économie de bande passante et de latence réseau, car le serveur original dissimulé derrière le (ou les) proxy n'est pas réintérrogé et souvent le serveur proxy se situe physiquement proche des clients (donc un routage et une latence optimale) ;
  2. authentification : un proxy peut demander à ses utilisateurs de s'authentifier avec lui avant de pouvoir l'utiliser. C'est un processus simple de contrôle de l'accès au web ;
  3. filtrage de requête : très à la mode dans les entreprises, un proxy va pouvoir interdir telle ou telle requête à tel ou tel client. L'exemple typique est le cas des sites à caractères pornographiques, ou encore les sites de partage de vidéos. Une liste de sites est alors chargée dans le serveur proxy, qui l'analyse à chaque requête de client ;
  4. filtrage de réponse : plus rare mais tout aussi possible, le proxy va analyser la source (HTML souvent) de la réponse, et remplacer des parties de codes avant d'envoyer la réponse modifiée au client. Typiquement il pourra s'agir de plublicités ou encore de javascripts malicieux. Notez que les reverses proxies utilisent une telle technique pour réécrire les liens des pages afin qu'ils ne comportent pas d'indication sur le serveur de destination. Apache permet ceci via mod_proxy_html ;
  5. balance de charge: un proxy peut aiguiller certains clients, sur cetains serveurs, en fonction de la ressource demandée. C'est assez rare, d'autres solutions plus adaptées et jouant avec les couches basses d'OSI existent. (Voyez mod_proxy_balancer de Apache) ;
  6. préchargement: charger des données avant même qu'un client ne les demande, en supposant qu'il va les demander dans le futur. Le cas classique des images d'une page HTML est très explicite : le proxy télécharge en avance les images sur le serveur original, à la seconde même ou le client lui a demandé la page HTML les comportant ;
  7. transcodage: le proxy peut traduire ou transcoder les caractères d'une page, en fonction des préférences linguistiques du client et de la réponse du serveur.

Il existe sur l'Internet des tonnes de proxies HTTP. La plupart sont des reverse, et en entreprise, souvent, des forwards proxies sont présents. Les tâches principales d'un proxy HTTP sont le cache et le filtrage, notamment en entreprise.
Souvent, un proxy signale qu'il a été utilisé en rajoutant sa signature au travers d'un en-tête spécifique : "Via"; mais ça n'est pas obligatoire : un proxy peut alors agir de manière totalement transparente, et il demeure impossible de savoir qu'il est là à première vue. Certes, une analyse bas niveau du réseau au moyen de tcpdump, traceroute ou autres outils Linux permettra de découvrir les proxies sur le chemin.

VII-C. La mise en place sur les clients

Pour mettre en place un forward proxy sur un client (navigateur), il existe 3 méthodes :

  1. indiquer explicitement au client quel serveur utiliser comme proxy ;
  2. indiquer explicitement au client un script javascript qui va determiner le serveur proxy à utiliser ;
  3. utiliser du filtrage réseau bas niveau pour rerouter la requête de manière transparente vers un proxy.

Dans le cas d'une mise en place manuelle, il faut configurer chaque client. Pour Firefox, il suffit d'aller dans les options avancées du réseau, et indiquer le serveur et le port du proxy. Pour les programmes comme wget ou lynx, ils scrutent une variable d'environnement "http_proxy".
L'autre méthode consiste à indiquer l'adresse URL vers un script PAC (Proxy Auto Configuration) écrit en javascript, qui devra alors retourner l'adresse d'un serveur proxy que le navigateur utilisera pour effectuer sa requête. Cette technique est pratique dans le cas d'une entreprise, car tous les navigateurs auront dans leur configuration le même fichier PAC qu'il suffira alors de changer pour repercuter les modifications partout.
Le script PAC va pouvoir aussi faire tourner les adresses des serveurs proxy qu'il retourne, en fonction du hasard ou de la requête effectuée (équilibrage de charge)
La valeur de retour d'un telle fonction est de la forme :

 
Sélectionnez

PROXY host:port
SOCKS host:port
DIRECT

Il est important de noter que ce script doit être situé sur un serveur HTTP accessible du client, et doit être retourné avec un en-tête "Content-Type: application/x-ns-proxy-autoconfig" sinon il ne sera pas reconnu comme script de configuration automatique par les navigateurs Webs.
Le PAC a été inventé par Netscape dans sa version 2 et est encore largement utilisé en entreprise de nos jours.

Enfin la troisième méthode, elle, est totalement transparente. On appelle celà un "proxy d'interception" (et non pas un proxy transparent). Ceci consiste à modifier les règles de routage du routeur physique qui se charge de la requête, afin de détecter s'il s'agit d'une requête HTTP (port 80). Si c'est le cas, la requête est alors routée vers un serveur proxy.
Cisco propose des protocoles pour cela, certains switchs matériels aussi (le firmware DD-WRT propose cela), mais sinon, toute machine UNIX peut faire l'affaire.
Nous allons prendre comme exemple une machine Linux avec un noyau supérieur à 2.4 (autorisant la commande iptables et ayant un module netfilter).

routage bas niveau pour proxy d'interception
Sélectionnez

> iptables -t nat -A PREROUTING -p tcp -i eth0 --dport 80 -j REDIRECT --to-ports 8080

Ce code suppose que la machine de routage est la même que la machine qui heberge le proxy. Sinon, il faudra faire du NAT de source et de destination.
Tout le monde peut tester ceci, il suffit d'une machine Linux avec un noyau 2.4 ou plus et de 2 cartes réseaux. Bien sûr il faudrait compléter un tel script de manière à ce que si le proxy ne fonctionne plus, le traffic soit libéré.

VII-D. Exemple pratique

Squid est un excellent produit, il s'agit d'un programme dédié à la tâche de proxy HTTP. Cependant nous allons baser un exemple pratique avec Apache et mod_proxy.
Un article est entièrement dédié à la création d'un forward proxy avec Apache, je vous y renvoie.

mod_proxy ne supporte pas encore les proxies transparents. Pour celà, vous devez indiquer
RewriteEngine on
RewriteCond %{THE_REQUEST} ^[A-Z]{3,5}\ (/[^?\ ]*)
RewriteRule ^/ http://%{HTTP_HOST}%1 [NE,P]

dans votre VirtualHost.
Ceci permet de réécrire la requête en une requête de proxy.

Un proxy repère une requête à proxier grâce à la ligne de requête. Une requête vers un proxy comporte toute l'URL dans la ligne de requête, et non juste la ressource demandée.
Cette transformation est mise en oeuvre par les clients HTTP usuels, ainsi en cas de proxy transparent, cette transformation n'est pas effectuée.


précédentsommairesuivant

Vous avez aimé ce tutoriel ? Alors partagez-le en cliquant sur les boutons suivants : Viadeo Twitter Facebook Share on Google+   

  

Copyright © 2009 Julien PAULI. Aucune reproduction, même partielle, ne peut être faite de ce site ni de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu'à trois ans de prison et jusqu'à 300 000 € de dommages et intérêts.