Parmi les nombreux modules d'Apache 2, il en est qui permettent d'aller au-delà de la simple utilisation de "serveur web".

L'une d'elle est celle du reverse proxy (proxy inverse pour les francophones).
A l'inverse d'une proxy qui sert de "mandataire" pour récupérer du contenu à la demande d'un client (navigateur), le proxy-inverse reçoit les demandes pour un serveur et les "ré-aiguille" vers la destination finale.

A noter qu'Apache peut faire office de proxy, mais attention à ne pas en ouvrir l'accès "extérieur" faute de quoi votre serveur servira rapidement de relais à toutes sortes de spammeurs ou autres personnes cherchant à surfer anonymement. De manière générale pour l'usage d'un proxy "direct" (forward proxy) on utilisera plutôt le programme Squid.

Parmi les nombreuses fonctionnalités d'une proxy inverse on peut noter :

• La centralisation des connexions entrantes pour de multiples serveurs Web, qu'ils soient sous Apache ou non, et situés sur la machine locale, distante, ou un mélange des deux.
• Par extension, Apache permet également de faire de l'équilibrage de charge (load balancing) entre plusieurs instances d'un même serveur web. Cet usage a deux intérêts : augmenter la charge supportée par un site en augmentant la capacité de traitement par l'ajout de serveurs, et la tolérance aux panneq grâce à la redondance.
• La possibilité de se mettre en "frontal" d'un autre serveur web pour en étendre les possibilités (SSL, authentification, protection applicative, etc...)

La configuration de base du reverse proxy est assez simple, dans la plupart des cas, deux lignes sont suffisantes :

ProxyPass /chemin http[s]://www.cible.com:port/ ProxyPassReverse /chemin http[s]://www.cible.com:port/

La première ligne en elle-même gère le travail du reverse proxy, la seconde est nécessaire pour "traduire" également les messages de redirection.
Elle peut être remplacée par certaines directives du module mod_rewrite, pour des opérations plus complexes.

De façon générale ces deux lignes permettent de définir un reverse proxy, qui va rediriger les requêtes vers /chemin sur l'URL http[s]://www.cible.com:port/
Ces lignes sont valables pour un site, un hôte virtuel (virtualhost) ou un répertoire, selon la partie du fichier de configuration où elles sont présentes.

Quelques remarques :

• le chemin peut être simplement "/" dans ce cas c'est tout le site (serveur ou hôte virtuel) qui est redirigé.
• Bien entendu votre serveur Apache doit pouvoir retrouver l'URL cible (assurez-vous que votre configuration DNS est correcte).
• La cible peut être en HTTP ou HTTPS, et comme la source pourra être ou non en en SSL vous pouvez donc rediriger une URL sécurisée vers un serveur non sécurisé (pratique pour rendre "SSL" un serveur web qui ne l'est pas) ((en fait les 4 combinaisons sont possibles, mais elles n'ont pas toutes le même intérêt)).
• Vous pouvez utiliser un port non standard, ce qui est bien pratique pour renvoyer vers un serveur web différent, situé sur la même machine.

Intéressons-nous donc à la création d'un reverse proxy SSL.

Imaginons que votre serveur applicatif ne soit pas capable de gérer SSL mais que vous voudriez pouvoir en proposer une version sécurisée.

Votre fichier de configuration pour commencerait donc par :

NameVirtualHost *:443

<VirtualHost *:443>
ServerAdmin [email protected]
ServerName application.exemple.com

Jusque là rien de bien sorcier, nous déclarons un serveur virtuel  sur le port 443, indiquant l'adresse mail de l'administrateur et le nom DNS auquel il doit répondre.

SSLEngine on
SSLProxyEngine on
SSLCertificateFile /etc/ssl/certs/cert.crt
SSLCertificateKeyFile /etc/ssl/certs/ssl.key
SSLHonorCipherOrder On
SSLCipherSuite RC4-SHA:HIGH:!ADH

Nous mettons en route le serveur SSL, et rendons la capacité disponible pour le reverse proxy.
Ensuite nous indiquons les chemins vers le certificat SSL et la clé privée.

Enfin les deux dernières lignes permettent de définir les méthode d'encryption utilisées, et bien sur vous avez retenues celles qui ne sont pas vulnérables à BEAST !

ProxyRequests Off
<Proxy *>
Order deny,allow
Allow from all
</Proxy>

ProxyPass / http://application.exemple.com/
ProxyPassReverse / http://application.exemple.com/
</VirtualHost>

La dernière partie concerne la fonctionnalité de reverse proxy : tout d'abord on s'assure que la proxy "directe" (non inverse) est coupée (voir les raisons plus haut), puis on autorise l'accès à notre reverse proxy à tous (vous pouvez bien sur définir des règles plus strictes).

Enfin on termine avec les deux lignes indiquant à Apache de "servir" pour cet hôte virtuel SSL, la version "non SSL" du site, en utilisant son adresse HTTP.

Bien entendu, il s'agit d'une configuration de base et vous pouvez ajouter d'autres directives.

Il faut bien sur activer, en utilisant la commande a2enmod par exemple, les modules qui vont bien, à savoir : mod_ssl, mod_proxy et mod_proxy_http.

Cette capacité pratique et puissante d'Apache 2 sera reprise dans de futurs billets...