Le problème
Il est de plus en plus facile aujourd’hui d’avoir chez soit une connexion internet rapide et permanente. De nombreux bidouilleurs, admins réseau en herbe ou confirmés ont donc pu installer un serveur web (au hasard apache) et commencer a héberger leurs pages et projets persos. Quelques temps ont passés, le réseau familial a grandi, aujourd’hui apache est installé sur une machine serveur dédiée pour la version "de production" et un autre apache sur la machine perso sert aux tests. Ce serait super pratique de pouvoir accéder séparément a ces deux serveurs à partir d’internet ... mais il n’y a qu’une seule IP publique :(
Routage ou Proxy ?
Dès qu’un besoin de partage de ressources, contrôle d’accès et/ou filtrage se fait sentir, une solution simple et efficace est de placer une machine entre les différents intervenants, celle-ci pouvant voir et agir sur les flux de données. On peut considérer que, très grossièrement, plus les actions réalisées sont simples et automatiques plus on agit sur les couches basses du système ; et plus les traitements sont compliqués et demandent des paramétrages plus on monte vers les couches applicatives.
Un proxy est, d’une façon générale un logiciel se faisant passer pour un service aux yeux des utilisateurs et qui, selon son bon vouloir et de la configuration imposée par l’administrateur réalise une requête vers le service réel et renvoi le résultat à l’utilisateur. Il ne s’agit ni d’un pont ni d’un routeur au sens réseau des termes car un proxy agit au niveau applicatif. Par la réciproque du principe énoncé plus haut on en déduira qu’un proxy permet un réglage très fin des conditions de passage des requêtes non plus seulement en fonction de la source ou de la destination réseau, mais également en fonction du contenu de la demande !
Intérêt d’un Reverse Proxy
Lorsque l’on parle de proxy http, ce qui vient à l’idée en premier est le contrôle des utilisateurs depuis l’intérieur d’un réseau voulant en sortir. Mais un proxy peut également être utilisé pour contrôler les requêtes arrivant de l’extérieur et à destination d’un serveur du réseau interne, on parle alors de reverse proxy.
Toute requête faite depuis l’extérieur va être analysée par le Reverse Proxy. Ce dernier étant en mesure d’extraire des informations applicatives, il peut déterminer le nom du serveur appelé (www.foo.bar par exemple) ce qui est très utile lorsque plusieurs domaines sont gérés sur le même serveur ; le type de navigateur à la source ; le répertoire et le nom de la page sur le site ... etc. Une fois les données qu’il estime pertinentes extraites, il fait une requête sur un serveur http à l’intérieur du réseau et renvoi la réponse au demandeur externe.
La solution a notre problème initial devient évidente : si le proxy fait la requête au serveur web après en avoir extrait tous les éléments, il peut attaquer plusieurs serveurs suivant le contenu de cette requête. eureka !
Apache, la solution low-cost
Le nombre de cas d’utilisation étant très important, la solution présentée dans cette partie considère deux noms de domaine qui arrivent sur la meme ip et qui doivent être séparés vers deux serveurs. Le traitement en fonction des noms de pages est un cas d’exercice intéressant dont la découverte est laissée aux lecteurs :)
Apache dispose sous forme de module de toutes les fonctions nécessaires pour faire office de proxy (reverse ou non). Avant toute autre chose, il faut donc indiquer dans le fichier de configuration le chargement de ce module (par example : LoadModule proxy_module modules/libproxy.so - Apache 1.3.x - ou modules/mod_proxy.so - Apache 2.x). Seules les fonctions de reverses vont être utilisées, il n’est donc pas nécessaire (ni souhaitable) de laisser le proxy de sortie actif, la directive ProxyRequests Off permet cette inhibition.
La machine va recevoir des requêtes à destination de plusieurs domaines, il faut donc recouvrir aux hôtes virtuels (vhosts) pour séparer leurs traitements. Un premier vhost reprend les options de configuration du site principal. Une fois cette conversion réalisée, ce site peut être testé, il doit continuer à fonctionner exactement comme avant. Afin de traiter les requettes à destination du nouveau domaine, un second vhost est créé, mais cette fois sans directive "DocumentRoot". Dans ce vhost, le reverse proxy est utilisé au moyen des deux directives "ProxyPass" et "ProxyPassReverse" prenant chacune en paramètre le répertoire de base (en général "/") et l’URL pour réaliser la requête coté serveur. Elles vont se charger d’aller chercher les informations depuis le second serveur (celui qui est normalement invisible depuis l’extérieur). Oui, vous avez bien lu, c’est tout, c’est simplissime non ? Si comme moi vous aimez pouvoir commencer en analysant un exemple, je vous en donne un au paragraphe suivant :)
Configuration apache par l’exemple
Voici les données significatives d’un apache configuré pour gérer un domaine "bob.info" :
(...) ServerRoot /etc/apache ServerName www.bob.info DocumentRoot /var/www/localhost/htdocs (...)
Une fois modifié puis ajouté le second domaine "alice.info", le nouveau format de la configuration est de la forme :
(...) LoadModule proxy_module modules/libproxy.so # Pour Apache 1.3.x ou LoadModule proxy_module modules/mod_proxy.so # pour Apache 2.x ProxyRequests OffNameVirtualHost * # # Premier vhost (site d’origine) # <VirtualHost *> ServerName www.bob.info DocumentRoot /var/www/localhost/htdocs </VirtualHost> # # Second vhost utiliseant le reverse proxy # 192.168.0.1 est l’exemple d’IP du second serveur http # <VirtualHost *> ServerName www.alice.info ProxyPass / http://192.168.0.1/ ProxyPassReverse / http://192.168.0.1/ </VirtualHost>
RSS 2.0