Fonctionnement d’une passerelle applicative
Cet article explique comment une passerelle applicative accepte les requêtes entrantes, et comment elle les route vers le back-end.
Comment une passerelle d’application accepte une requête
Avant qu’un client envoie une requête à une passerelle d’application, il résout le nom de domaine de la passerelle d’application à l’aide d’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.
Le DNS Azure retourne l’adresse IP au client. Il s’agit de l’adresse IP front-end de la passerelle d’application.
La passerelle d’application accepte le trafic entrant sur un ou plusieurs écouteurs. Un écouteur est une entité logique qui vérifie les requêtes de connexion. Il est configuré avec un numéro de port, un protocole et une adresse IP front-end pour les connexions des clients à la passerelle d’application.
Si un WAF (pare-feu d’applications web) est utilisé, la passerelle d’application vérifie les en-têtes de requête et le corps, le cas échéant, par rapport aux règles WAF. Cette action détermine si la requête est valide ou si elle représente une menace pour la sécurité. Si la requête est valide, elle est routée vers le back-end. Si la requête est non valide et que le pare-feu d’applications web 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 requête est évaluée et journalisée, mais toujours transférée au serveur back-end.
Azure Application Gateway peut être utilisé en tant qu’équilibreur de charge d’application interne ou en tant qu’équilibreur de charge d’application accessible sur Internet. Une passerelle d’application accessible sur Internet utilise des adresses IP publiques. Le nom DNS d’une passerelle d’application accessible sur Internet peut être résolu publiquement en son adresse IP publique. Ainsi, les passerelles d’application accessibles sur Internet peuvent router les requêtes des clients depuis Internet.
Les passerelles d’application internes utilisent uniquement des adresses IP privées. Si vous utilisez une zone DNS privée ou personnalisée, le nom de domaine doit pouvoir être résolu en l’adresse IP privée d’Application Gateway en interne. Les équilibreurs de charge internes peuvent donc router uniquement les requêtes des clients ayant accès à un réseau virtuel pour la passerelle d’application.
Comment une passerelle d’application route une requête
Si une requête est valide et qu’elle n’est pas bloquée par le pare-feu d’applications web, la passerelle d’application évalue la règle de routage de requête associée à l’écouteur. Cette action permet de déterminer le pool de back-ends vers lequel router la requête.
Selon la règle de routage de requête, la passerelle d’application détermine si toutes les requêtes de l’écouteur doivent être routées vers un pool de back-ends spécifique, si elles doivent être routées vers des pools de back-ends distincts en fonction du chemin de l’URL, ou si elles doivent être redirigées vers un autre port ou un site externe.
Remarque
Les règles sont traitées dans l’ordre où elles sont listées dans le portail pour la référence SKU v1.
Quand la passerelle d’application sélectionne le pool de back-ends, elle envoie la requête à l’un des back-ends sains du pool (y.y.y.y). L’intégrité du serveur est déterminée par une sonde. Si le pool de back-ends contient plusieurs serveurs, la passerelle d’application utilise un algorithme de tourniquet (round robin) pour router les requêtes entre les serveurs sains. Cela permet d’équilibrer la charge des requêtes sur les serveurs.
Une fois que la passerelle d’application a sélectionné le back-end, elle ouvre une nouvelle session TCP auprès du back-end en fonction des paramètres HTTP. Les paramètres HTTP spécifient le protocole, le port et les autres paramètres de routage nécessaires à l’établissement d’une nouvelle session auprès du back-end.
Le port et le protocole utilisés dans les paramètres HTTP permettent de déterminer si le trafic entre la passerelle d’application et les back-ends est chiffré (chiffrement TLS de bout en bout) ou non chiffré.
Quand une passerelle d’application envoie la requête d’origine au back-end, elle respecte la configuration personnalisée définie dans les paramètres HTTP associés au remplacement du nom d’hôte, du chemin et du protocole. Cette action permet de conserver l’affinité de session basée sur les cookies, le drainage de connexion, la sélection du nom d’hôte à partir du back-end, etc.
Remarque
Si le pool de back-ends :
- Est un point de terminaison public, la passerelle d’application utilise son adresse IP publique front-end pour joindre le serveur. En l’absence d’adresse IP publique front-end, une adresse est affectée pour la connectivité externe sortante.
- Contient un FQDN pouvant être résolu de façon interne ou une adresse IP privée, la passerelle d’application route la requête vers le back-end à l’aide de ses adresses IP privées d’instance.
- Contient un point de terminaison externe ou un FQDN pouvant être résolu de manière externe, la passerelle d’application route la requête vers le back-end à l’aide de son adresse IP publique front-end. Si le sous-réseau contient des points de terminaison de service, la passerelle d’application route la requête vers le service via son adresse IP privée. La résolution DNS est basée sur une zone DNS privée ou un serveur DNS personnalisé, si ce type de configuration existe, ou utilise le DNS par défaut fourni par Azure. En l’absence d’adresse IP publique front-end, une adresse est affectée pour la connectivité externe sortante.
Résolution DNS du serveur back-end
Quand le serveur d’un pool back-end est configuré avec un nom de domaine complet (FQDN), Application Gateway effectue une recherche DNS pour obtenir les adresses IP du nom de domaine. La valeur IP est stockée dans le cache de votre passerelle applicative pour lui permettre d’atteindre les cibles plus rapidement lors du traitement des requêtes entrantes.
La passerelle applicative conserve ces informations mises en cache pour la période équivalente à la durée de vie (time to live, TTL) de cet enregistrement DNS et effectue une nouvelle recherche DNS une fois la TTL expirée. Si une passerelle détecte un changement d’adresse IP pour sa requête DNS suivante, elle démarre le routage du trafic vers cette destination mise à jour. En cas de problèmes, par exemple, si la recherche DNS ne parvient pas à recevoir une réponse ou si l’enregistrement n’existe plus, la passerelle continue d’utiliser la ou les dernières adresses IP connues. Cela garantit un impact minimal sur le chemin d’accès aux données.
Important
- Lorsque vous utilisez des serveurs DNS personnalisés avec le réseau virtuel d’Application Gateway, il est important que tous les serveurs répondent de manière cohérente avec les mêmes valeurs DNS. Lorsqu’une instance de votre application Gateway émet une requête DNS, elle utilise la valeur du serveur qui répond en premier.
- Les utilisateurs de serveurs DNS personnalisés locaux doivent garantir la connectivité à Azure DNS via programme de résolution privé Azure DNS (recommandé) ou une machine virtuelle de redirecteur DNS lors de l’utilisation d’une zone DNS privée pour le point de terminaison privé.
Modifications apportées à la requête
Une passerelle applicative insère six en-têtes supplémentaires dans toutes les requêtes avant de les transférer au serveur principal. Il s’agit d’en-têtes x-forwarded-for, x-forwarded-port, x-forwarded-proto, x-original-host, x-original-url et x-appgw-trace-id. Le format d’en-tête x-forwarded-for est une liste d’éléments IP séparés par des virgules : port.
Les valeurs valides pour x-forwarded-proto sont HTTP ou HTTPS. X-forwarded-port spécifie le port où la requête a pu joindre la passerelle d’application. L’en-tête X-original-host contient l’en-tête d’origine de l’hôte avec lequel la requête est arrivée. Cet en-tête est utile dans l’intégration de sites web Azure, où l’en-tête de l’hôte entrant est modifié avant que le trafic ne soit routé vers le back-end. Si l’option d’affinité de session est activée, un cookie d’affinité géré par la passerelle est ajouté.
x-appgw-trace-id est un GUID unique généré par une passerelle applicative pour chaque demande de client et présenté dans la demande transférée au membre du pool principal. Le GUID est constitué de 32 caractères alphanumériques sans tiret (par exemple : ac882cd65a2712a0fe1289ec2bb6aee7). Ce GUID peut être utilisé pour mettre en corrélation une demande reçue par une passerelle applicative et adressée à un membre du pool principal via la propriété transactionId dans les journaux de diagnostic.
Vous pouvez configurer la passerelle d’application pour qu’elle modifie les en-têtes de requête et de réponse par la réécriture des en-têtes HTTP et URL ou pour qu’elle modifie le chemin de l’URI à l’aide d’un paramètre de substitution de chemin. Toutefois, à moins que la passerelle d’application ne soit configurée dans ce but, toutes les requêtes entrantes sont proxysées vers le back-end.