Name: Tremplin Numérique
Price range: $$$

Apache est un serveur Web polyvalent qui offre une gamme complète de fonctionnalités de support, certaines via des extensions. Dans cet article, nous utiliserons le mod_proxy module 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 qui 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 depuis 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 .htaccess des dossiers.

Sommaire

Activation du module proxy

mod_proxy est inclus avec l’installation par défaut d’Apache. Utiliser 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 Proxy-instructions préfixées dans vos fichiers de configuration Apache. Nous allons les configurer ensuite.

Configuration d’un hôte virtuel proxy

Mettons en place un hôte virtuel qui transmet 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.

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é.

Ajouter un nouveau fichier d’hôte virtuel à l’intérieur /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>

le ProxyPass et ProxyPassReverse directives précisent que le trafic vers example.com devrait être mandataire de 192.168.0.1. L’optionnel nocanon Le mot-clé 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. Utilisant nocanon garantit la compatibilité mais peut affecter votre niveau de sécurité car il désactive la protection intégrée d’Apache contre les attaques de 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 Location, Content-Location, et URI en-têtes de réponse é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 demandes. Vous pouvez restreindre le proxy à un chemin spécifique tel que /media en ajustant le ProxyPass et ProxyPassReverse instructions:

ProxyPass /media http://192.168.0.1/
ProxyPassReverse /media http://192.168.0.1/

Ajout de plusieurs ProxyPass rules vous permet d’acheminer les requêtes entre plusieurs cibles à l’aide d’un hôte virtuel. Les règles sont mises en correspondance dans l’ordre où elles sont écrites. Si vous avez besoin d’un comportement de routage plus complexe, utilisez le ProxyPassMatch directive à la place. Ceci équivaut à ProxyPass mais fait correspondre 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 en utilisant le a2ensite commander. Cela prend le nom de base de votre fichier, par rapport au sites-available annuaire:

sudo a2ensite example-proxy-vhost

Redémarrez Apache pour appliquer vos modifications :

sudo service apache2 restart

Votre proxy simple 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 par proxy à votre serveur interne.

Utiliser SSL

L’exemple ci-dessus omet SSL. Dans une charge de travail de production, vous voudriez configurer cela en ajoutant SSLCertificateFile et SSLCertificateKeyFile paramètres à 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 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 le SSLProxy options 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 passe X-Forwarded-Host, XForwarded-For, et X-Forwarded-Server en-têtes à votre serveur principal par défaut. 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. Réglage ProxyErrorOverride change cela, laissant Apache remplacer le contenu des pages d’erreur par le ErrorDocument plutôt. Cela peut être souhaitable dans les situations où vous souhaitez que les erreurs de tous vos backends soient gérées uniformément avec une configuration centralisée sur l’hôte proxy.
ProxyPassReverseCookieDomain – Cela fonctionne de la même manière que l’obligatoire (pour le proxy inverse) ProxyPassReverse directif. Il réécrira le domaine en Set-Cookie en-têtes pour référencer le nom de l’hôte virtuel, plutôt que le nom d’hôte du serveur principal dont ils proviennent.
ProxyPreserveHost – Apache envoie généralement son propre nom d’hôte à vos serveurs principaux en tant que valeur du Host entête. La définition de cette directive signifie que la original Host l’en-tête 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 est par défaut au niveau du serveur Timeout valeur.

Vous pouvez définir ces directives sous forme de lignes supplémentaires dans votre fichier hôte virtuel. N’oubliez pas de redémarrer le service Apache à chaque fois que vous appliquez une modification.

L’équilibrage de charge

L’implémentation du proxy inverse d’Apache prend également en charge l’équilibrage de charge entre plusieurs backends différents. Cela permet à une demande de example.com touchez l’un 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 requêtes vers l’un des deux serveurs du example-balancer bassin. L’algorithme d’équilibrage de charge est défini par le lbmethod réglage; la bytraffic La valeur utilisée ici essaie de s’assurer que chacun des serveurs gère une quantité égale de trafic.

L’alternative byrequests balancing method est une version plus simple de bytraffic qui donne à chaque backend une part égale des demandes entrantes. le bybusyness balancer suit le nombre de requêtes traitées par chaque backend, puis en attribue de nouvelles au backend le moins « occupé ».

Résumé

le mod_proxy Le module peut transformer Apache en un hôte proxy inverse qui vous permet d’utiliser un 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 demandes sur l’ensemble de votre parc de serveurs.

D’autres variantes de proxy sont également disponibles. Vous pouvez proxy des connexions FTP, WebSocket et HTTP2, entre autres, en installant des modules complémentaires à côté mod_proxy. La liste complète des modules est disponible dans la doc Apache.