Apache est un serveur Web polyvalent qui offre un ensemble complet de fonctionnalités de support, certaines via des extensions. Dans cet article, nous utiliserons le module mod_proxy pour configurer Apache dans un rôle de proxy inverse.
Bien qu'Apache ne soit peut-être pas votre premier choix en tant que proxy inverse, avec des alternatives plus modernes comme NGINX ayant tendance à attirer l'attention, mod_proxy est utile pour les serveurs qui exécutent déjà Apache et doivent maintenant acheminer le trafic vers un autre service. Vous pouvez configurer un hôte virtuel Apache pour transmettre les demandes d'un domaine donné à un serveur Web distinct.
Nous utilisons Apache 2.4 avec un système basé sur Debian pour les besoins de ce guide. Nous supposerons également que les serveurs vers lesquels vous souhaitez transférer le trafic sont déjà accessibles par le réseau à partir de votre hôte Apache. Cet article se concentre sur l'activation du proxy basé sur un hôte virtuel unique, mais mod_proxy est également configurable globalement, dans le cadre de la configuration de votre serveur Apache, ou au niveau du répertoire via les fichiers .htaccess.
Activation du module proxy
mod_proxy est inclus avec l'installation par défaut d'Apache. Utilisez a2enmod pour activer le module et son composant HTTP indépendant maintenant :
sudo a2enmod proxy sudo a2enmod proxy_http
Cela configure Apache pour prendre en charge les connexions HTTP par proxy vers d'autres hôtes. Le module est configuré à l'aide d'instructions préfixées par Proxy dans vos fichiers de configuration Apache. Nous allons les configurer ensuite.
Configuration d'un hôte virtuel proxy
Let’s configurer un hôte virtuel qui transfère example.com à l'adresse IP interne 192.168.0.1. Vous devez ajouter un enregistrement DNS pour example.com qui pointe vers votre hôte Apache.
Publicité
Le proxy dans ce scénario permet aux visiteurs d'accéder de manière transparente à votre serveur Web interne via une adresse externe. Apache agit comme le gardien qui achemine le trafic vers sa destination finale. L'utilisateur verra example.com, même si Apache résout les requêtes via le serveur séparé.
Ajoutez un nouveau fichier d'hôte virtuel dans /etc/apache2/sites-available avec le contenu suivant :
<VirtualHost *:80> ServerName example.com ProxyPass/http://192.168.0.1/nocanon ProxyPassReverse/http://192.168.0.1/</VirtualHost>
Les directives ProxyPass et ProxyPassReverse spécifient que le trafic vers example.com doit être envoyé par proxy à 192.168.0.1. Le mot-clé optionnel nocanon demande à Apache de transmettre l'URL brute au serveur distant. Sans ce mot-clé, Apache canonisera automatiquement l'URL, ce qui peut être incompatible avec certains serveurs et frameworks. L'utilisation de nocanon garantit la compatibilité mais peut affecter votre sécurité car elle désactive la protection intégrée d'Apache contre les attaques par proxy basées sur les URL.
ProxyPassReverse doit être fourni pour distinguer votre configuration en tant que configuration de proxy inverse. Apache utilisera l'URL fournie pour réécrire les en-têtes de réponse Location, Content-Location et URI émis par votre backend. Cela garantit que les requêtes suivantes continuent d'atteindre le proxy inverse, au lieu d'essayer d'atteindre directement le serveur interne.
Cette configuration va proxy toutes les requêtes. Vous pouvez restreindre le proxy à un chemin spécifique tel que /media en ajustant les instructions ProxyPass et ProxyPassReverse :
ProxyPass /media http://192.168.0.1/ProxyPassReverse /media http://192.168.0.1/Advertisement
L'ajout de plusieurs règles ProxyPass vous permet de router les requêtes entre plusieurs cibles à l'aide d'un hôte virtuel. Les règles sont mises en correspondance dans l'ordre dans lequel elles sont écrites. Si vous avez besoin d'un comportement de routage plus complexe, utilisez plutôt la directive ProxyPassMatch. Ceci est équivalent à ProxyPass mais compare les URL entrantes à une expression régulière :
ProxyPassMatch ^/client/(.*)/images$ http://192.168.0.1/
Enregistrez votre fichier d'hôte virtuel et activez-le à l'aide de la commande a2ensite. Cela prend le nom de base de votre fichier, par rapport au répertoire des sites disponibles :
sudo a2ensite example-proxy-vhost
Redémarrez Apache pour appliquer vos modifications :
sudo service apache2 restart
Votre simple proxy devrait maintenant être opérationnel. Essayez de visiter example.com – vous devriez voir le contenu servi par 192.168.0.1. La requête se termine sur votre hôte Apache qui la transmet ensuite à votre serveur interne.
Utilisation de SSL
L'exemple ci-dessus omet SSL. Dans une charge de travail de production, vous souhaitez configurer cela en ajoutant les paramètres SSLCertificateFile et SSLCertificateKeyFile à votre hôte virtuel. Ceux-ci spécifient le certificat SSL et la clé à utiliser lors de la validation des connexions SSL. Vous pouvez également utiliser le certbot de Let’s Encrypt’s pour automatiser la configuration.
Configurer SSL de cette manière signifie que la connexion sécurisée sera interrompue sur votre hôte Apache. La connexion entre Apache et votre cible proxy se fera via HTTP simple.
Si vous avez également besoin que la connexion proxy soit sécurisée, vous devez utiliser les options SSLProxy fournies par mod_ssl. SSLProxyEngine = On fonctionnera comme la configuration la plus basique, à condition qu'Apache et votre serveur proxy cible aient accès aux mêmes certificats. Cette option indique aux informations SSL d'être transmises via la connexion proxy.
Options de proxy
Les proxys inversés Apache ont plusieurs directives facultatives que vous pouvez utiliser pour ajuster le comportement de transfert . Voici quelques options couramment utilisées :
- ProxyAddHeaders – Apache transmet par défaut les en-têtes X-Forwarded-Host, XForwarded-For et X-Forwarded-Server à votre serveur principal. Ceux-ci permettent à votre backend d'identifier qu'une requête a été proxy via Apache. Définir cet en-tête sur Off empêche Apache d'ajouter ces en-têtes.
- ProxyErrorOverride– Apache n'interférera pas avec les réponses envoyées par votre serveur principal, sauf indication contraire. Si votre backend sert un code d'erreur 400, 404, 500 ou tout autre code d'erreur, l'utilisateur recevra ce contenu tel quel. La définition de ProxyErrorOverride change cela, laissant Apache remplacer le contenu des pages d'erreur par le ErrorDocument configuré à la place. Cela peut être souhaitable dans les situations où vous souhaitez que les erreurs de tous vos backends soient gérées de manière uniforme avec une configuration centralisée sur l'hôte proxy.
- ProxyPassReverseCookieDomain– Cela fonctionne de manière similaire à la directive ProxyPassReverse obligatoire (pour le proxy inverse). Il réécrira le domaine dans les en-têtes Set-Cookie pour référencer le nom de l'hôte virtuel, plutôt que le nom d'hôte du serveur principal dont il provient.
- ProxyPreserveHost &# 8211 ; Apache envoie généralement son propre nom d'hôte à vos serveurs principaux en tant que valeur de l'en-tête Host. La définition de cette directive signifie que l'en-tête Host d'origine sera envoyé à la place. Cela peut être nécessaire lorsque votre logiciel principal effectue son propre routage basé sur le nom d'hôte.
- ProxyTimeout– Utilisez cette directive pour ajuster le temps d'attente d'Apache pendant que votre serveur principal traite une requête proxy. Apache annulera la requête et renverra un code d'erreur au client si le délai d'expiration est dépassé. Il s'agit par défaut de la valeur de délai d'attente au niveau du serveur.
Publicité
Vous pouvez définir ces directives en tant que lignes supplémentaires dans votre fichier d'hôte virtuel. N'oubliez pas de redémarrer le service Apache à chaque fois que vous appliquez une modification.
Load Balancing
L'implémentation du proxy inverse d'Apache prend également en charge l'équilibrage de charge entre plusieurs backends différents. Cela permet à une requête à example.com d'atteindre n'importe lequel des serveurs de votre pool d'équilibrage.
<Proxy balancer://example-balancer> BalancerMember http://192.168.0.1 BalancerMember http://192.168.0.2 ProxySet lbmethod=bytraffic </Proxy> ProxyPass/balancer://example-balancer ProxyPassReverse/balancer://example-balancer
Cet exemple achemine les demandes vers l'un des deux serveurs du pool example-balancer. L'algorithme d'équilibrage de charge est défini par le paramètre lbmethod ; la valeur bytraffic utilisée ici essaie de garantir que chacun des serveurs gère une quantité égale de trafic.
La méthode alternative d'équilibrage des byrequests est une version plus simple de bytraffic qui donne à chaque backend une part égale des requêtes entrantes. L'équilibreur de bybusyness suit le nombre de requêtes traitées par chaque backend, puis en attribue de nouvelles aux moins “occupé” backend.
Résumé
Le module mod_proxy peut transformer Apache en un hôte proxy inverse qui vous permet d'utiliser le routage basé sur le nom pour accéder à plusieurs services indépendants. Vous pouvez également ajouter un équilibrage de charge pour assurer la stabilité et la disponibilité en répartissant les requêtes sur l'ensemble de votre parc de serveurs.
Publicité
D'autres variantes de proxy sont également disponibles. Vous pouvez utiliser un proxy pour les connexions FTP, WebSocket et HTTP2, entre autres, en installant des modules complémentaires supplémentaires avec mod_proxy. La liste complète des modules est disponible dans la doc Apache.