Un reverse proxy vous servirait à quoi ? A proposer une « interface » au monde extérieur avec vos différentes applications web par exemple. Ce qui se trouve derrière le reverse proxy Apache n’a pas d’importance… Que se soit un autre serveur Apache, un serveur Tomcat, un IIS ou bien une application web fonctionnant sur un numéro de port différent du 80.

Il permet également de sécuriser les systèmes qui sont placés derrière ce proxy. En étant en frontal sur le web et en présentant son « interface ». Le proxy apparait comme un Apache aux yeux des bots de scan. On peut même laisser sa signature exprès pour que les bots n’aillent pas plus loin. Il sera identifié comme serveur Apache par un scan externe.

Explications du reverse proxy Apache

reverse_proxy_apache

Le client doit accéder l’application Pyload par exemple. Celle-ci fonctionne sur le server2 sur le port 8080. Faire un simple DNAT sur le firewall est possible, mais quand on a plusieurs applications et une seule adresse IP, cela devient impossible…

Avec le reverse proxy Apache, le client accède à l’application en tapant http://MON_DOMAINE_OU_IP/application et les requêtes sont redirigées vers http://server2:8080. Cela est invisible pour lui. Vous pouvez faire de même pour toutes vos applications sur vos différents serveurs, même pour des serveurs IIS de Windows…

Mise en place

Pour la gestion du proxy Apache, les paquets suivants sont nécessaires :

$ apt-get install apache2 libapache2-mod-proxy-html

Pour activer la gestion de proxy, il faut activer le module Apache :

$ a2enmod proxy_http

Pour la gestion de proxy html avec réécriture des url dans le contenu des pages html vous aurez besoin d’activer les modules Apache :

$ a2enmod proxy_html headers

Beaucoup d’application, comme Pyload, ne sont pas codées en liens relatifs, mais en liens absolus… Et sans utiliser les modules en question, vous vous retrouveriez avec des liens externes en http://10.xxx.xxx.xxx/applications/qqch par exemple…

 

D’abord, configurer ce qui est autorisé dans le fichier du site (surtout utile pour ProxyRequests). Pour ma part, aucune restrictions, cela se configure comme un « Directory ».

$ vim /etc/apache2/sites_enabled/000-default
<Proxy *>
Order allow,deny
Allow from all
</Proxy>

Voici la configuration d’exemple pour l’application Pyload. Ceci est valide pour Apache v2.1+. Pour les versions moins récentes, la configuration est donnée après.

ProxyPass /pyload/ http://127.0.0.1:8081/
ProxyPassReverse /pyload/ http://127.0.0.1:8081/
ProxyHTMLURLMap http://127.0.0.1:8081 /pyload
<Location /pyload/>
ProxyHTMLEnable On                                     #### v2.1 min
ProxyHTMLExtended on
ProxyPassReverse /
ProxyHTMLURLMap / /pyload/
RequestHeader unset Accept-Encoding
</Location>

ProxyHTMLLogVerbose On # pour afficher de quoi debugger

Pour Apache plus vieux que le 2.1 :

ProxyPass /pyload/ http://127.0.0.1:8081/
ProxyPassReverse /pyload/ http://127.0.0.1:8081/
ProxyHTMLURLMap http://127.0.0.1:8081 /pyload
<Location /pyload/>
SetOutputFilter proxy-html                            #### older 2.1
ProxyPassReverse /
ProxyHTMLURLMap / /pyload/
RequestHeader unset Accept-Encoding
</Location>

Certaines applications on besoin de règles de réécriture des url. Il faut activer le module « rewrite » d’Apache. Voici une configuration d’exemple :

ProxyPass /pyload/ http://127.0.0.1:8081/
ProxyPassReverse /pyload/ http://127.0.0.1:8081/
RewriteRule ^/pyload$ /pyload/ [R]
ProxyHTMLURLMap http://127.0.0.1:8081 /pyload
<Location /pyload/>
    SetOutputFilter proxy-html
    ProxyPassReverse /
    ProxyHTMLURLMap / /pyload/
    RequestHeader unset Accept-Encoding
</Location>

Problème courant

Lorsque l’on utilise un domaine pour le proxy de notre application comme « http://test.monlinux.net« , on a généralement aucun problème. Mais lorsque l’on prend un sous-dossier comme « http://192.168.1.2/pyload« , des problèmes peuvent apparaitre avec les liens des css, javascript ajax, etc.

Une grande partie des problèmes d’intégration sont liés à l’application. Il faut parfois chercher les bonnes options pour le proxy Apache, mais jusqu’ici aucune application bien conçue ne m’a posé problème.

Plus d’infos sur le mod_proxy via le site d’Apache.

N’hésitez pas à faire un test de benchmark de vos applications web en directe et à travers le reverse proxy pour vérifier les performances. Vous verrez que le mod_proxy ne change presque rien et que la réécriture des url change un peu la donne par contre…

 

 

Articles relatifs :