Comment fonctionne une passerelle d’application

• 11/16/2019
• 4 minutes à lire
• • a
  • j
  • . D
  • s
  • v
  • +2

Cet article explique comment une passerelle d’application accepte les demandes entrantes et les achemine vers le backend.

Comment une passerelle d’application accepte une demande

1. Avant qu’un client n’envoie une demande à une passerelle d’application, il résout le nom de domaine de la passerelle d’application en utilisant un serveur DNS (Domain Name System). Azure contrôle l’entrée DNS car toutes les passerelles d’application sont dans le domaine azure.com.

2. Le DNS Azure renvoie l’adresse IP au client, qui est l’adresse IP frontale de la passerelle d’application.

3. La passerelle d’application accepte le trafic entrant sur un ou plusieurs listeners. Un listener est une entité logique qui vérifie les demandes de connexion. Il est configuré avec une adresse IP frontale, un protocole et un numéro de port pour les connexions des clients à la passerelle d’applications.

4. Si un pare-feu d’application Web (WAF) est utilisé, la passerelle d’applications vérifie les en-têtes de la requête et le corps, s’il est présent, par rapport aux règles WAF. Cette action détermine si la demande est une demande valide ou une menace pour la sécurité. Si la demande est valide, elle est acheminée vers le backend. Si la demande n’est pas valide et que le WAF est en mode Prévention, elle est bloquée en tant que menace pour la sécurité. S’il est en mode Détection, la demande est évaluée et enregistrée, mais elle est tout de même acheminée vers le serveur backend.

Azure Application Gateway peut être utilisé comme un équilibreur de charge d’application interne ou comme un équilibreur de charge d’application tourné vers l’internet. Une passerelle d’application tournée vers l’internet utilise des adresses IP publiques. Le nom DNS d’une passerelle d’application faisant face à l’Internet peut être résolu publiquement par son adresse IP publique. Par conséquent, les passerelles d’applications tournées vers l’Internet peuvent acheminer les demandes des clients depuis l’Internet.

Les passerelles d’applications internes utilisent uniquement des adresses IP privées. Si vous utilisez une zone DNS personnalisée ou privée, le nom de domaine doit pouvoir être résolu en interne à l’adresse IP privée de la passerelle d’application. Par conséquent, les équilibreurs de charge internes peuvent uniquement acheminer les demandes des clients ayant accès à un réseau virtuel pour la passerelle d’applications.

Comment une passerelle d’applications achemine une demande

Si une demande est valide et n’est pas bloquée par le WAF, la passerelle d’applications évalue la règle d’acheminement des demandes qui est associée à l’auditeur. Cette action détermine le pool de backend vers lequel acheminer la requête.

Sur la base de la règle de routage de requête, la passerelle d’applications détermine s’il faut acheminer toutes les requêtes sur l’écouteur vers un pool de backend spécifique, acheminer les requêtes vers différents pools de backend en fonction du chemin URL, ou rediriger les requêtes vers un autre port ou un site externe.

Lorsque la passerelle d’application sélectionne le pool de backend, elle envoie la requête à l’un des serveurs backend sains du pool (y.y.y.y). La santé du serveur est déterminée par une sonde de santé. Si le pool de backend contient plusieurs serveurs, la passerelle d’applications utilise un algorithme de rotation pour acheminer les demandes entre les serveurs sains. Cela équilibre la charge des demandes sur les serveurs.

Après avoir déterminé le serveur backend, la passerelle d’applications ouvre une nouvelle session TCP avec le serveur backend en fonction des paramètres HTTP. Les paramètres HTTP spécifient le protocole, le port et d’autres paramètres liés au routage qui sont nécessaires pour établir une nouvelle session avec le serveur backend.

Le port et le protocole utilisés dans les paramètres HTTP déterminent si le trafic entre la passerelle d’application et les serveurs backend est crypté (accomplissant ainsi TLS de bout en bout) ou non crypté.

Lorsqu’une passerelle d’applications envoie la requête originale au serveur backend, elle honore toute configuration personnalisée effectuée dans les paramètres HTTP liés au remplacement du nom d’hôte, du chemin et du protocole. Cette action maintient l’affinité de session basée sur les cookies, la vidange de connexion, la sélection du nom d’hôte à partir du backend, et ainsi de suite.

Modifications de la demande

Une passerelle d’application insère quatre en-têtes supplémentaires à toutes les demandes avant de les transmettre au backend. Ces en-têtes sont x-forwarded-for, x-forwarded-proto, x-forwarded-port et x-original-host. Le format de l’en-tête x-forwarded-for est une liste d’IP:port séparée par des virgules.

Les valeurs valides pour x-forwarded-proto sont HTTP ou HTTPS. X-forwarded-port spécifie le port où la requête a atteint la passerelle d’application. L’en-tête X-original-host contient l’en-tête d’hôte original avec lequel la requête est arrivée. Cet en-tête est utile dans l’intégration des sites Web Azure, où l’en-tête d’hôte entrant est modifié avant que le trafic ne soit acheminé vers le backend. Si l’affinité de session est activée en option, alors elle ajoute un cookie d’affinité géré par la passerelle.

Vous pouvez configurer la passerelle d’application pour modifier les en-têtes de demande et de réponse et l’URL en utilisant Rewrite HTTP headers and URL ou pour modifier le chemin URI en utilisant un paramètre path-override. Cependant, à moins d’être configurées de la sorte, toutes les demandes entrantes sont transmises par proxy au backend.

En savoir plus sur les composants de la passerelle d’application

.