Module Apache mod_proxy

Mandataires directs et mandataires/passerelles inverses

Le serveur HTTP Apache peut être configuré dans les deux modes mandataire direct et mandataire inverse (aussi nommé mode passerelle).

Un mandataire direct standard est un serveur intermédiaire qui s'intercale entre le client et le serveur demandé. Pour obtenir un contenu hébergé par le serveur demandé, le client envoie une requête au mandataire en nommant le serveur demandé comme cible. Le mandataire extrait alors le contenu depuis le serveur demandé et le renvoie enfin au client. Le client doit être configuré de manière appropriée pour pouvoir utiliser le mandataire direct afin d'accéder à d'autres sites.

L'accès à Internet depuis des clients situés derrière un pare-feu est une utilisation typique du mandataire direct. Le mandataire direct peut aussi utiliser la mise en cache (fournie par mod_cache) pour réduire la charge du réseau.

La fonctionnalité de mandataire direct est activée via la directive ProxyRequests. Comme les mandataires directs permettent aux clients d'accéder à des sites quelconques via votre serveur et de dissimuler leur véritable origine, il est indispensable de sécuriser votre serveur de façon à ce que seuls les clients autorisés puissent accéder à votre serveur avant d'activer la fonctionnalité de mandataire direct.

Un mandataire inverse (ou passerelle), quant à lui, apparaît au client comme un serveur web standard. Aucune configuration particulière du client n'est nécessaire. Le client adresse ses demandes de contenus ordinaires dans l'espace de nommage du mandataire inverse. Ce dernier décide alors où envoyer ces requêtes, et renvoie le contenu au client comme s'il l'hébergeait lui-même.

L'accès d'utilisateurs depuis Internet vers un serveur situé derrière un pare-feu est une utilisation typique du mandataire inverse. On peut aussi utiliser les mandataires inverses pour mettre en oeuvre une répartition de charge entre plusieurs serveurs en arrière-plan, ou fournir un cache pour un serveur d'arrière-plan plus lent. Les mandataires inverses peuvent aussi tout simplement servir à rassembler plusieurs serveurs dans le même espace de nommage d'URLs.

La fonctionnalité de mandataire inverse est activée via la directive ProxyPass ou le drapeau [P] de la directive RewriteRule. Il n'est pas nécessaire de définir ProxyRequests pour configurer un mandataire inverse.

Exemples simples

Les exemples ci-dessous illustrent de manière très basique la mise en oeuvre de la fonctionnalité de mandataire et ne sont là que pour vous aider à démarrer. Reportez-vous à la documentation de chaque directive.

Si en outre, vous désirez activer la mise en cache, consultez la documentation de mod_cache.

ProxyPass "/foo" "http://foo.example.com/bar"
ProxyPassReverse "/foo" "http://foo.example.com/bar"

ProxyRequests On
ProxyVia On

<Proxy "*">
  Require host internal.example.com
</Proxy>

ProxyPass "/some/ws/capable/path/" "http://example.com/some/ws/capable/path/" upgrade=websocket

Accès via un gestionnaire

Vous pouvez aussi forcer le traitement d'une requête en tant que requête de mandataire inverse en créant un gestionnaire de transfert approprié. Dans l'exemple suivant, toutes les requêtes pour des scripts PHP seront transmises au serveur FastCGI spécifié via un mandat inverse :

<FilesMatch "\.php$">
    # Les sockets Unix nécessitent une version 2.4.7 ou supérieure du
    # serveur HTTP Apache
    SetHandler  "proxy:unix:/path/to/app.sock|fcgi://localhost/"
</FilesMatch>

Cette fonctionnalité est disponible à partir de la version 2.4.10 du serveur HTTP Apache.

Workers

Le mandataire gère la configuration et les paramètres de communication des serveurs originaux au sein d'objets nommés workers. Deux types de worker sont fournis : le worker par défaut du mandataire direct et le worker par défaut du mandataire inverse. Il est aussi possible de définir explicitement des workers supplémentaires.

Les deux workers par défaut possèdent une configuration figée et seront utilisés si aucun autre worker ne correspond à la requête. Ils ne réutilisent pas les connexions et n'utilisent pas les connexions HTTP persistantes (Keep-Alive). En effet, les connexions TCP vers le serveur original sont fermées et ouvertes pour chaque requête.

Les workers définis explicitement sont identifiés par leur URL. Ils sont en général définis via les directives ProxyPass ou ProxyPassMatch lorsqu'on les utilise dans le cadre d'un mandataire inverse :

ProxyPass "/example" "http://backend.example.com" connectiontimeout=5 timeout=30

Cette directive va créer un worker associé à l'URL du serveur original http://backend.example.com qui utilisera les valeurs de timeout données. Lorsqu'ils sont utilisés dans le cadre d'un mandataire direct, les workers sont en général définis via la directive ProxySet,

ProxySet "http://backend.example.com" connectiontimeout=5 timeout=30

ou encore via les directives Proxy et ProxySet :

<Proxy "http://backend.example.com">
  ProxySet connectiontimeout=5 timeout=30
</Proxy>

L'utilisation de workers définis explicitement dans le mode mandataire direct n'est pas très courante, car les mandataires directs communiquent en général avec de nombreux serveurs originaux. La création explicite de workers pour certains serveurs originaux peut cependant s'avérer utile si ces serveurs sont très souvent sollicités. A leur niveau, les workers explicitement définis ne possèdent aucune notion de mandataire direct ou inverse. Ils encapsulent un concept de communication commun avec les serveurs originaux. Un worker créé via la directive ProxyPass pour être utilisé dans le cadre d'un mandataire inverse sera aussi utilisé dans le cadre d'un mandataire directe chaque fois que l'URL vers le serveur original correspondra à l'URL du worker, et vice versa.

L'URL qui identifie un worker correspond à l'URL de son serveur original, y compris un éventuel chemin donné :

ProxyPass "/examples" "http://backend.example.com/examples"
ProxyPass "/docs" "http://backend.example.com/docs"

Dans cet exemple, deux workers différents sont définis, chacun d'eux utilisant des configurations et jeux de connexions séparés.

ProxyPass "/apps" "http://backend.example.com/" timeout=60
ProxyPass "/examples" "http://backend.example.com/examples" timeout=10

Les workers définis explicitement sont de deux sortes : workers directs et workers de répartition (de charge). Ils supportent de nombreux attributs de configuration importants décrits dans la directive ProxyPass. Ces mêmes attributs peuvent aussi être définis via la directive ProxySet.

Le jeu d'options disponibles pour un worker direct dépend du protocole spécifié dans l'URL du serveur original. Les protocoles disponibles comprennent ajp, fcgi, ftp, http et scgi.

Les workers de répartition sont des workers virtuels qui utilisent les workers directs, connus comme faisant partie de leurs membres, pour le traitement effectif des requêtes. Chaque répartiteur peut comporter plusieurs membres. Lorsqu'il traite une requête, il choisit un de ses membres en fonction de l'algorithme de répartition de charge défini.

Un worker de répartition est créé si son URL de worker comporte balancer comme indicateur de protocole. L'URL du répartiteur permet d'identifier de manière unique le worker de répartition. La directive BalancerMember permet d'ajouter des membres au répartiteur.

Contrôler l'accès à votre mandataire

Vous pouvez restreindre l'accès à votre mandataire via le bloc de contrôle <Proxy> comme dans l'exemple suivant :

<Proxy "*">
  Require ip 192.168.0
</Proxy>

Pour plus de détails sur les directives de contrôle d'accès, voir la documentation du module mod_authz_host.

Restreindre l'accès de manière stricte est essentiel si vous mettez en oeuvre un mandataire direct (en définissant la directive ProxyRequests à "on"). Dans le cas contraire, votre serveur pourrait être utilisé par n'importe quel client pour accéder à des serveurs quelconques, tout en masquant sa véritable identité. Ceci représente un danger non seulement pour votre réseau, mais aussi pour l'Internet au sens large. Dans le cas de la mise en oeuvre d'un mandataire inverse (en utilisant la directive ProxyPass avec ProxyRequests Off), le contrôle d'accès est moins critique car les clients ne peuvent contacter que les serveurs que vous avez spécifiés.

Voir aussi la variable d'environnement Proxy-Chain-Auth.

Ralentissement au démarrage

Si vous utilisez la directive ProxyBlock, les noms d'hôtes sont résolus en adresses IP puis ces dernières mises en cache au cours du démarrage à des fins de tests de comparaisons ultérieurs. Ce processus peut durer plusieurs secondes (ou d'avantage) en fonction de la vitesse à laquelle s'effectue la résolution des noms d'hôtes.

Mandataire en Intranet

Un serveur mandataire Apache httpd situé à l'intérieur d'un Intranet doit faire suivre les requêtes destinées à un serveur externe à travers le pare-feu de l'entreprise (pour ce faire, définissez la directive ProxyRemote de façon à ce qu'elle fasse suivre le protocole concerné vers le mandataire du pare-feu). Cependant, lorsqu'il doit accéder à des ressources situées dans l'Intranet, il peut se passer du pare-feu pour accéder aux serveurs. A cet effet, la directive NoProxy permet de spécifier quels hôtes appartiennent à l'Intranet et peuvent donc être accédés directement.

Les utilisateurs d'un Intranet ont tendance à oublier le nom du domaine local dans leurs requêtes WWW, et demandent par exemple "http://un-serveur/" au lieu de http://un-serveur.example.com/. Certains serveurs mandataires commerciaux acceptent ce genre de requête et les traitent simplement en utilisant un nom de domaine local implicite. Lorsque la directive ProxyDomain est utilisée et si le serveur est configuré comme mandataire, Apache httpd peut renvoyer une réponse de redirection et ainsi fournir au client l'adresse de serveur correcte, entièrement qualifiée. C'est la méthode à privilégier car le fichier des marque-pages de l'utilisateur contiendra alors des noms de serveurs entièrement qualifiés.

Ajustements relatifs au protocole

Pour les cas où mod_proxy envoie des requêtes vers un serveur qui n'implémente pas correctement les connexions persistantes ou le protocole HTTP/1.1, il existe deux variables d'environnement qui permettent de forcer les requêtes à utiliser le protocole HTTP/1.0 avec connexions non persistantes. Elles peuvent être définies via la directive SetEnv.

Il s'agit des variables force-proxy-request-1.0 et proxy-nokeepalive.

<Location "/buggyappserver/">
  ProxyPass "http://buggyappserver:7001/foo/"
  SetEnv force-proxy-request-1.0 1
  SetEnv proxy-nokeepalive 1
</Location>

A partir de la version 2.4.26 du serveur HTTP Apache, la définition de la variable d'environnement "no-proxy" permet de désactiver mod_proxy dans le traitement de la requête courante. Cette variable doit être définie via la directive SetEnvIf car la directive SetEnv n'est pas évaluée assez tôt.

Corps de requêtes

Certaines méthodes de requêtes comme POST comportent un corps de requête. Le protocole HTTP stipule que les requêtes qui comportent un corps doivent soit utiliser un codage de transmission fractionnée (chunked transfer encoding), soit envoyer un en-tête de requête Content-Length. Lorsqu'il fait suivre ce genre de requête vers le serveur demandé, mod_proxy_http s'efforce toujours d'envoyer l'en-tête Content-Length. Par contre, si la taille du corps est importante, et si la requête originale utilise un codage à fractionnement, ce dernier peut aussi être utilisé dans la requête montante. Ce comportement peut être contrôlé à l'aide de variables d'environnement. Ainsi, si elle est définie, la variable proxy-sendcl assure une compatibilité maximale avec les serveurs demandés en imposant l'envoi de l'en-tête Content-Length, alors que proxy-sendchunked diminue la consommation de ressources en imposant l'utilisation d'un codage à fractionnement.

Dans certaines circonstances, le serveur doit mettre en file d'attente sur disque les corps de requêtes afin de satisfaire le traitement demandé des corps de requêtes. Par exemple, cette mise en file d'attente se produira si le corps original a été envoyé selon un codage morcelé (et possède une taille importante), alors que l'administrateur a demandé que les requêtes du serveur d'arrière-plan soient envoyées avec l'en-tête Content-Length ou en HTTP/1.0. Cette mise en file d'attente se produira aussi si le corps de la requête contient déjà un en-tête Content-Length, alors que le serveur est configuré pour filtrer les corps des requêtes entrantes.

En-têtes de requête du mandataire inverse

Lorsqu'il est configuré en mode mandataire inverse (en utilisant par exemple la directive ProxyPass), mod_proxy_http ajoute plusieurs en-têtes de requête afin de transmettre des informations au serveur demandé. Ces en-têtes sont les suivants :

X-Forwarded-For

L'adresse IP du client.

X-Forwarded-Host

L'hôte d'origine demandé par le client dans l'en-tête de requête HTTP Host.

X-Forwarded-Server

Le nom d'hôte du serveur mandataire.

Ces en-têtes doivent être utilisés avec précautions sur le serveur demandé, car ils contiendront plus d'une valeur (séparées par des virgules) si la requête originale contenait déjà un de ces en-têtes. Par exemple, vous pouvez utiliser %{X-Forwarded-For}i dans la chaîne de format du journal du serveur demandé pour enregistrer les adresses IP des clients originaux, mais il est possible que vous obteniez plusieurs adresses si la requête passe à travers plusieurs mandataires.

Voir aussi les directives ProxyPreserveHost et ProxyVia directives, qui permettent de contrôler d'autres en-têtes de requête.

Note : Si vous devez ajouter des en-têtes particuliers à la requête mandatée, utilisez la directive RequestHeader.