J’ai récemment dû installer et configurer un proxy inverse à l’aide du serveur IIS et de son extension de réécriture d’URL. Au premier abord, la configuration d’un emplacement cible pour la redirection semblait plutôt simple, mais cette tâche s’est avérée plus complexe que prévu.

Étape 1 : Comprendre en quoi consiste la réécriture d’URL

L’écriture d’URL est une extension IIS qui peut être téléchargée ici : http://www.iis.net/downloads/microsoft/url-rewrite En gros, elle permet de réécrire à la volée l’URI de votre choix (d’où son nom), quel que soit le sens (en entrée et en sortie). C’est donc l’outil idéal lorsque vous possédez un proxy inverse et que vous souhaitez tout simplement transmettre la requête effectuée auprès de http://www.proxy.com/domain/soft1 vers http://soft1/, par exemple. Chaque demande suit le parcours présenté dans le diagramme de séquence de la Figure 1.

Figure 1 – La réécriture d’URL en action

Lorsque vous devez configurer une redirection appropriée, vous devez penser à effectuer les deux actions suivantes :

1. Configurer les règles de trafic entrant qui vont convertir l’adresse publique de votre service (ici http://www.proxy.com/domain/soft1 ) en adresse interne (ici http://soft1)
2. Configurer les règles de trafic sortant qui vont corriger les liens relatifs et absolus dans les réponses du serveur soft1 de façon à ce qu’ils puissent être couverts par la requête du client

Dans les deux cas, une règle n’est rien d’autre qu’une façon simple d’appliquer une méthode String.Replace dans la requête/réponse.

Étape 2 : Écrire les règles de trafic entrant

Les règles de trafic entrant sont utilisées pour convertir la requête reçue de la part du client sous la forme d’une adresse publique en requête envoyée à un serveur interne, non exposé tout en préservant la partie de la requête ne nécessitant aucune conversion.

Figure 2 – Exemple de règle de trafic entrant

Il convient de garder à l’esprit les points clés suivants :

• Dans une grande majorité des cas, les utilisateurs préfèrent laisser la variable serveur HTTP_ACCEPT_ENCODING vide, sans doute parce qu’ils savent qu’ils vont devoir écrire des règles de trafic sortant pour adapter les liens dans les réponses. Or, ce n’est pas possible si la réponse est compressée. Il est donc préférable de supprimer les libellés « gzip/deflate » de la partie accept_encoding de l’en-tête. Remarquez que pour remplacer une variable serveur, vous devez l’enregistrer dans l’écran View server variable (Afficher la variable serveur).
• Bien que le modèle par défaut, à savoir ^/(.*), suffise dans la grande majorité des cas, vous pouvez être amené à rencontrer d’autres mécanismes qui exigent le recours à des modèles différents (comme le mécanisme d’authentification des formulaires ASP.Net et son paramètre returnurl). Dans ce cas, vous devez écrire plusieurs règles : une pour chaque cas particulier, au moyen d’un modèle spécifique (quelque chose comme ^/(.*)\?returnurl=/(.*)\?(.*) pour ASP.Net), puis la règle passe-partout. N’oubliez pas de définir l’indicateur « Arrêter le traitement des règles suivantes » pour chacune d’elles !
• Sachez également que la réécriture des URL ne se limite pas à la racine d’un site. Par exemple, vous pouvez effectuer une redirection vers http://soft1/Appli/{R:1} voire transmettre l’URI d’entrée en tant que paramètre, comme http://soft1/query.aspx?uri={R:1}
• Si vous indiquez explicitement le préfixe http:// lors de la réécriture de l’URL, vous ajoutez de façon efficace le déchargement SSL à votre proxy inverse. Si vous souhaitez conserver le chiffrement, vous devez ajouter une condition sur {CACHE_URL} avec le modèle ^(https?):// et commencer la réécriture de l’URL en utilisant {C:1}://

Étape 3 : Écrire les règles de trafic sortant

Les règles de trafic sortant permettent de modifier la réponse envoyée par le serveur de façon à ce que les liens qu’elle contient pointent vers votre proxy inverse plutôt que vers le serveur réel. Cela concerne aussi bien les liens absolus (modifier http://soft1/icon.png en http://www.proxy.com/domain/soft1/icon.png) que les liens relatifs (remplacer /icon.png par /domain/soft1/icon.png). Pourquoi est-ce nécessaire ? Interrogez-nous plutôt sur ce qui risque de se passer si vous ne le faites pas :

1. Le client envoie la requête http://www.proxy.com/domain/soft1
2. La règle de trafic entrant se déclenche et réécrit la requête en la convertissant en http://soft1/
3. Le serveur soft1 répond avec une page http contenant <img src=”/icon.png”/>
4. Le client envoie la requête http://www.proxy.com/icon.png
5. 404 – Page introuvable !

Donc, en gros, vous devez réécrire certains liens, à moins que vous n’utilisiez une application monopage. D’où l’intérêt des règles de trafic sortant !

Figure 3 – Exemple de règle de trafic sortant

En ce qui concerne les règles de trafic entrant, voici quelques points clés à retenir :

• Vous avez besoin d’au moins une règle pour les chemins relatifs (modèle ^/(.*)) et une autre pour les chemins absolus (modèle ^http://soft1/(.*)).
• Vous pouvez réécrire les chemins absolus et les convertir en chemins relatifs. Par exemple, vous pouvez convertir ^http://soft1/(.*) en /domain/soft1/{R:1}.
• Par défaut, une règle ne s’applique que dans les libellés définis au sein du corps de la réponse. Si aucun libellé n’a été spécifié, la règle effectue une opération globale de recherche et remplacement, ce qui est utile si vous avez besoin de modifier le contenu d’une variable javaScript, par exemple.
• Si vous voulez réécrire 30 réponses (redirection/réécriture), par exemple dans le but de pouvoir lier des proxys inverses, vous devez ajouter une règle qui permet de remplacer la variable serveur RESPONSE_Location.