Reverse proxy

Centos-7 - Mise en oeuvre d'un Reverse Proxy sous Apache

 

Préambule

La mise en place d'un Reverse Proxy dans l'infrastructure d'hébergement web est justifiée par le nombre de sites WEB à gérer. Le reverse proxy s'intercale logiquement entre le routeur (ici une box) et le ou les serveurs Web internes. Il reçoit tout le traffic HTTP/HTTPS/FTP/... entrant (les demandes de pages web par exemple) pour le rediriger sur les serveurs Web internes et il renvoie les pages demandées aux internautes qui les ont sollictés (traffic sortant). Il gère donc les demandes et les réponses. Il est transparent pour l'usager.

 

Reverse proxy

 

Pourquoi s'encombrer d'une machine supplémentaire ?

Avec le reverse proxy, il est possible, puisque c'est son rôle, d'effectuer une redirection des sites web et c'est justement cette fonctionnalité là qui nous intéresse. En effet, les sites utilisateurs seront hébergés sur les serveurs web internes. Dès lors, deux solutions d'hébergement sont possibles : l'utilisation des hôtes virtuels (VirtualHost) ou l'utilisation du répertoire utilisateur (Userdir). Avec le VirtualHost, il va falloir emprisonner l'utilisateur dans le répertoire physique de son site pour lui donner le droit de modifier ses fichiers via le protocole FTP. Ce n'est pas simple.
Avec le "UserDir", on a pas ce problème, puisque l'utilisateur est déjà cantonné dans sa home directory (/home/userxxx) et Apache permet de monter un site web dans le répertoire privé de l'utilisateur. Pour accéder à son site web personnel, l'utilisateur doit en revanche saisir dans la barre de navigation une adresse du style : http://<Serveur Web>/~<Compte Utilisateur>. Cette adresse étant ingérable en externe, il faut pouvoir la transformer en http://<Mon_Site>.pbr18.fr et c'est là qu'intervient le Reverse Proxy. Il va effectuer un mappage de l'URL http://MonSite.pbr18.fr sur l'URL http://ServeurWebLocal/~utilisateurXXX ni vu ni connu. Cool !

 

De fait, 4 situations peuvent se présenter :

Le reverse proxy reçoit de l'internaute une requette HTTP et il la renvoie sur un des serveurs web en HTTP.
Le reverse proxy reçoit de l'internaute une requete HTTP et il la renvoie sur un des serveurs web en HTTPS.
Le reverse proxy reçoit de l'internaute une requête HTTPS et il la renvoie sur un des serveurs web en HTTP.
Le reverse proxy reçoit de l'internaute une requête HTTPS et il la renvoie sur un des serveurs web en HTTPS.

 

Prérequis

- Une machine virtuelle dédié au Reverse Proxy montée en serveur CentOS-7 core 1611 minimal à jour, @IP 192.168.1.40
- Ajout de la machine virtuelle dans le DNS du réseau local
- Apache 2.4 installé (installation classique)
- Redirection du port 80 externe de la Livebox sur le port 80 interne (fonction NAT).
- Serveur Web local (serweb) qui dispose lui aussi d'Apache 2.4
- Un premier domaine d'hébergement (infos1.pbr18.xyz)
- Un second domaine d'hébergement (infos2.pbr18.xyz)
- Deux comptes "utilisateur", (user1 pour infos1.pbr18.xyz et user2 pour infos2.pbr18.xyz).

Modules Apache

C'est le module mod_proxy qui permet d'utiliser Apache comme reverse-proxy. D'autres modules peuvent venir compléter la fonction comme :

  • mod_proxy_connect ajoute la fonction proxy pour le tunneling SSL
  • mod_headers autorise la modification des en-têtes HTTP
  • mod_proxy_http contient les fonctions proxy pour les requêtes HTTP et HTTPS.
  • mod_proxy_html permet la réécriture des liens HTML
  • mod_proxy_ftp ajoute la fonction proxy pour les requêtes FTP
  • mod_cache, mod_disk_cache et mod_mem_cache gérent les fonctions de cache du serveur Apache.
  • mod_deflate permet de compresser les flux.

 

Configuration

Création du fichier de configuration sur le serveur faisant office de Reverse Proxy (192.168.1.40),

# cd /etc/httpd/conf.d
# touch rproxy.conf     // création du fichier de configuration

Ajout du site web de "User1"

# vi rproxy.conf
-># Configuration serveur reverse proxy
# User1 -> infos1.pbr18.xyz
<VirtualHost 192.168.1.40>   
   ServerName infos1.pbr18.xyz       // l'URL du site web
   ServerAlias www.infos1.pbr18.xyz  // l'alias du site

   ProxyPreserveHost On             // On préserve l'URL entrante
   ProxyRequests off                // Mode proxy désactivé
   ProxyPass / http://serweb/~user1/ connectiontimeout=5 timeout=30
   ProxyPassReverse / http://serweb/~user1/

   ErrorLog /var/log/rproxy.log     // Désactiver cette ligne sous Centos-7.4 1708.
   LogLevel debug
</VirtualHost>

Commentaires :

On créé un fichier le configuration dans le répertoire de gestion des virtualHosts (/etc/httpd/conf.d) qu'on appellera pour l'exemple "rproxy.conf".
Le VirtualHost est référencée par l'adresse IP du Reverse Proxy (ici 192.168.1.40).
Le ServerName correspond à l'adresse internet du site de l'utilisateur (ici infos1.pbr18.xyz). C'est en fait le nom de domaine complet du site qui a été choisi par l'utilisateur user1 au moment de sa création. C'est aussi l'adresse qui sera saisit sur Internet pour accéder au site web de "user1".
ProxyRequest Off. Le mode proxy du serveur apache est désactivé pour ne laisser que le rôle de Reverse Proxy actif.
ProxyPass et ProxyPassReverse permet d'associer la racine du site web à l'URL spécifiée en regard. L'URL "infos1.pbr18.xyz" sera mappée sur l'URL interne "serweb/~user1/" par la directive proxyPass et la directive ProxyPassreverse effectue le mappage inverse pour la réponse.
ErrorLog : Le fichier de log du Reverse Proxy.qu'il faudra créer dans le répertoire "/var/log/". Attention, cette directive empêche le demarrage d'Apache 2.4 sous CentOS 7-4 core 1708. Il faudra donc la désactiver

Ajout du site web de User2

# vi rproxy.conf
-># Configuration serveur reverse proxy
# User2 -> infos2.pbr18.xyz
<VirtualHost 192.168.1.40>    
   ServerName infos2.pbr18.xyz       // l'URL du site web 
   ServerAlias www.infos2.pbr18.xyz  // l'alias du site

   ProxyPreserveHost On             // On préserve l'URL entrante
   ProxyRequests off                // Mode proxy désactivé 
   ProxyPass / http://serweb/~user2/ connectiontimeout=5 timeout=30
   ProxyPassReverse / http://serweb/~user2/

   ErrorLog /var/log/rproxy.log
   LogLevel debug
</VirtualHost>

 

Test de la solution.

Si vous êtes abonné chez Free ou SFR ou sa finilale Red By SFR, pas de soucis pour tester en interne (réseau local domestique) le bon fonctionnement de votre installation. En revanche, si vous être chez Orange, ça se complique un peu bien qu'on puisse s'en sortir avec l'astuce ci-après.

Astuce pour tester son site web local à partir de son propre réseau local chez Orange

Aussi surprenant que celà puisse paraître, ce n'est pas si évident au demeurant. Selon la configuration des DNS et c'est l'option que j'ai prise, je dispose d'un DNS pour résoudre les accès à partir d'Internet et d'un autre DNS pour les accès intranet (derrière la Box sur mon réseau local). A partir de mon intranet, j'ai bien la vision locale des sites que j'ai montés. En revanche, pour disposer de la vision externe, il faut que je sorte de mon réseau local. Une solution acceptable consiste à aller chez mon voisin mais ce n'est pas très pratique et à la longue ça risque d'énerver. On peut encore envisager de trouver un resto sympathique mais les coûts deviennent rapidement prohibitifs.

Il existe une solution pourtant très simple pour valider en toute facilité mes sites internet à partir d'un réseau Intranet, l'utilisation du navigateur TOR. En effet, le navigateur TOR fait appel à un système de serveurs Internet dont l'un d'entre eux exécutera votre requête à votre place et vous renverra la réponse. La requête est donc exécutée à l'extérieur du réseau local et je peux maintenant tester et valider mes sites web comme si j'étais un internaute lambda.

Le Browser TOR est disponible sur Windows, MacOS et Linux en 32/64 bits.