Planifier et implémenter une passerelle d’application Azure

  • 10 minutes

Azure Application Gateway est un équilibreur de charge de trafic web (couche OSI 7) qui vous permet de gérer le trafic vers vos applications web. Les équilibreurs de charge traditionnels fonctionnent au niveau de la couche de transport (couche OSI 4 - TCP et UDP) et acheminent le trafic en fonction de l’adresse IP et du port sources, vers une adresse IP et un port de destination.

Application Gateway peut prendre des décisions de routage basées sur des attributs supplémentaires d’une requête HTTP, par exemple des en-têtes d’hôte ou le chemin d’un URI. Par exemple, vous pouvez acheminer le trafic en fonction de l’URL entrante. Par conséquent, si /images est dans l’URL entrante, vous pouvez acheminer le trafic vers un ensemble spécifique de serveurs (considérés comme un pool) configurés pour les images. Si /vidéo se trouve dans l’URL, ce trafic est acheminé vers un autre pool optimisé pour les vidéos.

Diagramme montrant un exemple d’Azure Application Gateway.

Ce type de routage est connu comme l’équilibrage de charge de la couche d’application (couche OSI 7). Azure Application Gateway permet d’effectuer un routage basé sur une URL et bien plus encore.

Composants d’Application Gateway

Une passerelle d’application représente le seul point de contact des clients. Elle répartit le trafic d’application entrant sur plusieurs pools de back-ends, notamment des machines virtuelles Azure, des groupes de machines virtuelles identiques, Azure App Service ainsi que des serveurs locaux/externes.

Diagramme montrant les composants de passerelle d’application Azure.

Infrastructure

L’infrastructure Application Gateway comprend le réseau virtuel, les sous-réseaux, les groupes de sécurité réseau et les itinéraires définis par l’utilisateur.

Frontend IP address (Adresse IP frontale)

Vous pouvez configurer la passerelle d’application pour qu’elle ait une adresse IP publique, une adresse IP privée ou les deux. Une adresse IP publique est nécessaire quand vous hébergez un back-end auquel les clients doivent accéder par Internet par le biais d’une adresse IP virtuelle Internet.

Une adresse IP publique n’est pas nécessaire pour un point de terminaison interne non exposé à Internet. Une configuration front-end privée est utile pour les applications métier internes non exposées à Internet. Elle est également utile pour les services et niveaux inclus dans une application multiniveau qui se trouve dans une limite de sécurité non exposés à Internet, mais qui ont besoin d’une distribution de charge par tourniquet, de l’adhérence de session ou de la terminaison TLS.

Sont prises en charge une seule adresse IP publique et une seule adresse IP privée. Vous choisissez l’adresse IP front-end quand vous créez la passerelle d’application.

Remarque

Le front-end Application Gateway prend en charge les adresses IP à double pile (préversion publique). Vous pouvez créer jusqu’à quatre adresses IP front-end. Deux sont des adresses IPv4 (publiques et privées) et deux sont des adresses IPv6 (publiques et privées).

  • Concernant l’adresse IP publique, vous pouvez en créer une ou en utiliser une existante au même emplacement que la passerelle d’application. Pour plus d’informations, consultez Adresse IP publique statique ou dynamique.
  • Concernant l’adresse IP privée, vous pouvez spécifier une adresse IP privée du sous-réseau dans lequel la passerelle d’application est créée. Pour les déploiements de référence SKU Application Gateway v2, une adresse IP statique doit être définie lorsque vous ajoutez une adresse IP privée à la passerelle. Pour les déploiements de référence SKU Application Gateway v1, si vous ne spécifiez pas d’adresse IP, une adresse IP disponible est automatiquement sélectionnée à partir du sous-réseau. Le type d’adresse IP que vous sélectionnez (statique ou dynamique) n’est pas modifiable par la suite.

Une adresse IP front-end est associée à un écouteur, qui vérifie les demandes entrantes sur l’adresse IP front-end.

Vous pouvez créer des écouteurs privés et publics avec le même numéro de port. Toutefois, tenez compte de tout groupe de sécurité réseau associé au sous-réseau Application Gateway. En fonction de la configuration de votre groupe de sécurité réseau, vous autre peut-être besoin d’une règle de trafic entrant autorisé avec des adresses IP de destination en tant qu’adresses IP front-end publiques et privées de votre passerelle applicative. Lorsque vous utilisez le même port, votre passerelle applicative modifie la destination du flux entrant sur les adresses IP front-end de votre passerelle.

Règle de trafic entrant :

  • Source : en fonction de vos besoins
  • Destination : adresses IP front-end publiques et privées de votre passerelle applicative.
  • Port de destination : en fonction des écouteurs configurés
  • Protocole : TCP

Règle de trafic sortant : Aucune exigence spécifique

Écouteurs

Un écouteur est une entité logique qui vérifie les demandes de connexion entrante en utilisant le port, le protocole, l’hôte et l’adresse IP. Quand vous configurez l’écouteur, vous devez entrer des valeurs qui correspondent aux valeurs indiquées dans la demande entrante sur la passerelle.

Quand vous créez une passerelle d’application à l’aide du portail Azure, vous créez également un écouteur par défaut en choisissant le protocole et le port pour l’écouteur. Vous pouvez choisir d’activer ou non la prise en charge du protocole HTTP2 sur l’écouteur. Une fois que vous avez créé la passerelle d’application, vous pouvez modifier les paramètres de cet écouteur par défaut (appGatewayHttpListener) ou créer des écouteurs.

Type d’écouteur

Un écouteur est une entité logique qui vérifie les requêtes de connexion entrantes. Un écouteur accepte une requête si le protocole, le port, le nom d’hôte et l’adresse IP associés à la requête correspondent à ceux associés à la configuration de l’écouteur.

Avant d’utiliser une passerelle d’application, vous devez ajouter au moins un écouteur. Vous pouvez connecter plusieurs écouteurs à une passerelle d’application, et les utiliser pour le même protocole.

Une fois qu’un écouteur a détecté les requêtes entrantes des clients, la passerelle d’application les route vers les membres du pool de back-ends configuré dans la règle.

Les écouteurs prennent en charge les ports et les protocoles suivants.

Ports

Un port est le point d’écoute de la requête du client. Vous pouvez configurer des ports pour les références SKU v1 et v2 comme indiqué ci-dessous.

Référence (SKU) Plage de ports prise en charge Exception(s)
V2 1 à 64 999 22
V1 1 à 65 502 3389

Protocoles

Application Gateway prend en charge quatre protocoles : HTTP, HTTPS, HTTP/2 et WebSocket :

Remarque

La prise en charge du protocole HTTP/2 est disponible pour les clients se connectant aux écouteurs Application Gateway uniquement. La communication avec les pools de serveurs back-end s’effectue toujours sur HTTP/1.1. Par défaut, la prise en charge du protocole HTTP/2 est désactivée. Vous pouvez choisir de l’activer.

  • Spécifiez les protocoles HTTP ou HTTPS dans la configuration de l’écouteur.
  • La prise en charge des protocoles WebSockets et HTTP/2 est effectuée de manière native. La prise en charge de WebSocket est activée par défaut. Il n’existe aucun paramètre configurable par l’utilisateur permettant d’activer ou de désactiver de manière sélective la prise en charge de WebSocket. Utilisez WebSockets avec les écouteurs HTTP et HTTPS.

Utilisez un écouteur HTTPS pour l’arrêt TLS. Un écouteur HTTPS déplace les tâches de chiffrement et de déchiffrement vers votre passerelle d’application pour que vos serveurs web ne soient pas saturés par la surcharge.

Règles de routage des requêtes

Quand vous créez une passerelle d’application à l’aide du portail Azure, vous créez une règle par défaut (rule1). Cette règle lie l’écouteur par défaut (appGatewayHttpListener) au pool de back-ends par défaut (appGatewayBackendPool) et aux paramètres HTTP du back-end par défaut ( appGatewayBackendHttpSettings). Après avoir créé la passerelle, vous pouvez modifier les paramètres de la règle par défaut ou créer de nouvelles règles.

Type de règle

Quand vous créez une règle, vous choisissez entre le type de base et le type basé sur un chemin.

  • Choisissez le type de base pour transférer toutes les demandes sur l’écouteur associé (par exemple, blog.contoso.com/*) à un seul pool de back-ends.
  • Choisissez le type basé sur un chemin pour router les demandes provenant de chemins d’URL spécifiques vers des pools de back-ends spécifiques. Le modèle de chemin s’applique uniquement au chemin de l’URL, pas à ses paramètres de demande.

Écouteur associé

Associez un écouteur à la règle de sorte que la règle de routage des demandes associée à l’écouteur soit évaluée pour déterminer le pool de back-ends vers lequel router la demande.

Pool de back-ends associé

Associez à la règle le pool de back-ends qui contient les cibles back-end qui servent les demandes que l’écouteur reçoit.

  • Pour une règle de base, un seul pool de back-ends est autorisé. Toutes les demandes sur l’écouteur associé sont transférées à ce pool de back-ends.
  • Pour une règle basée sur un chemin, ajoutez plusieurs pools de back-ends qui correspondent à chaque chemin d’URL. Les demandes correspondant à ce chemin d’URL entré sont transférées au pool de back-ends correspondant. De plus, ajoutez un pool de back-ends par défaut. Les demandes qui ne correspondent à aucun chemin d’URL dans la règle sont transférées à ce pool.

Paramètre HTTP du back-end associé

Ajoutez un paramètre HTTP de back-end pour chaque règle. Les demandes sont routées depuis la passerelle d’application vers les cibles back-end à l’aide du numéro de port, du protocole et d’autres informations spécifiées dans ce paramètre.

Pour une règle de base, un seul paramètre HTTP du back-end est autorisé. Toutes les demandes sur l’écouteur associé sont transférées aux cibles back-end correspondantes en utilisant ce paramètre HTTP.

Pour une règle basée sur un chemin, ajoutez plusieurs paramètres HTTP du back-end qui correspondent à chaque chemin d’URL. Les demandes correspondant à ce chemin d’URL dans ce paramètre sont transférées aux cibles back-end correspondantes en utilisant les paramètres HTTP qui correspondent à chaque chemin d’URL. En outre, ajoutez un paramètre HTTP par défaut. Les demandes qui ne correspondent à aucun chemin d’URL dans cette règle sont transférées au pool back-end par défaut en utilisant le paramètre HTTP par défaut.

Paramètre de redirection

Si la redirection est configurée pour une règle de base, toutes les demandes sur l’écouteur associé sont redirigées vers la cible. Il s’agit d’une redirection globale. Si la redirection est configurée pour une règle basée sur un chemin, seules les demandes dans une zone de site spécifique sont redirigées. Prenons l’exemple d’une zone de panier d’achat indiquée par /cart/*. Il s’agit d’une redirection basée sur un chemin.

Port d'écoute

Choisissez l’écouteur comme cible de redirection pour rediriger le trafic depuis un écouteur vers un autre sur la passerelle. Ce paramètre est obligatoire quand vous voulez activer la redirection HTTP vers HTTPS. Il redirige le trafic depuis l’écouteur source qui vérifie les demandes HTTP entrantes vers l’écouteur de destination qui vérifie les demandes HTTPS entrantes. Vous pouvez également choisir d’inclure la chaîne et le chemin de requête de la demande d’origine dans la demande transférée à la cible de redirection.

Capture d’écran montrant un exemple de page des paramètres de configuration de redirection.

Site externe

Choisissez un site externe quand vous voulez rediriger le trafic sur l’écouteur associé à cette règle vers un site externe. Vous pouvez choisir d’inclure la chaîne de requête de la demande d’origine dans la demande transférée à la cible de redirection. Vous ne pouvez pas transférer le chemin au site externe qui était dans la demande d’origine.

Réécrire les en-têtes et les URL HTTP

En utilisant des règles de réécriture, vous pouvez ajouter, supprimer ou mettre à jour les en-têtes de requête et de réponse HTTP(S) ainsi que les paramètres du chemin URL et de la chaîne de requête lorsque les paquets de requête et de réponse se déplacent entre le client et des pools principaux via la passerelle d’application.

Vous pouvez régler les en-têtes et les paramètres d’URL sur des valeurs statiques ou d’autres en-têtes et variables de serveur. Cela facilite les cas d’usage importants, tels que l’extraction d’adresses IP des clients, la suppression d’informations sensibles relatives au back-end, le renforcement de la sécurité, etc.

Paramètres HTTP

La passerelle d’application route le trafic vers les serveurs back-end en utilisant la configuration que vous spécifiez ici. Après avoir créé un paramètre HTTP, vous devez l’associer à une ou plusieurs règles de routage des demandes.

Azure Application Gateway utilise des cookies gérés par passerelle pour gérer les sessions utilisateur. Quand un utilisateur envoie la première demande à Application Gateway, il définit un cookie d’affinité dans la réponse avec une valeur de hachage qui contient les détails de la session, afin que les demandes suivantes incluant le cookie d’affinité soient routées vers le même serveur back-end pour conserver l’adhérence.

Cette fonctionnalité est pratique quand vous voulez conserver une session utilisateur sur le même serveur et quand l’état de session est enregistré localement sur le serveur pour une session utilisateur. Si l’application ne peut pas gérer l’affinité basée sur les cookies, vous ne pouvez pas utiliser cette fonctionnalité. Pour l’utiliser, assurez-vous que les clients prennent en charge les cookies.

Remarque

Certaines analyses de vulnérabilité peuvent signaler le cookie d’affinité Application Gateway, car les indicateurs Secure ou HttpOnly ne sont pas définis. Ces analyses ne tiennent pas compte du fait que les données du cookie sont générées à l’aide d’un hachage unidirectionnel. Le cookie ne contient pas d’informations utilisateur et est utilisé exclusivement pour le routage.

Vidage des connexions

Le drainage des connexions vous permet de supprimer correctement les membres d’un pool de back-ends pendant les mises à jour de service planifiées. Cela s’applique aux instances principales qui sont

  • supprimées explicitement du pool backend,
  • supprimées pendant les opérations de mise à l’échelle ou
  • signalées comme défectueuses par les sondes d’intégrité.

Vous pouvez appliquer ce paramètre à tous les membres d’un pool de backend en activant le drainage des connexion dans les paramètres du backend. Cela garantit que toutes les instances de désinscription dans un pool principal ne reçoivent pas de nouvelles requêtes/connexions tout en conservant les connexions existantes jusqu’à la valeur de délai d’expiration configurée. Cela est également vrai pour les connexions WebSocket.

Type de configuration Valeur
Valeur par défaut quand le drainage de connexion n’est pas activé dans le paramètre du back-end 30 secondes
Valeur définie par l’utilisateur quand le drainage de connexion est activé dans le paramètre du back-end 1 à 3 600 secondes

La seule exception concerne les demandes liées à la désinscription des instances en raison d’une affinité de session gérée par la passerelle et qui continueront d’être transmises par proxy aux instances de désinscription.

Protocol

Application Gateway prend en charge les protocoles HTTP et HTTPS pour router les requêtes vers les serveurs back-end. Si vous choisissez HTTP, le trafic vers les serveurs back-end n’est pas chiffré. Si des communications non chiffrées ne sont pas acceptables, sélectionnez HTTPS.

Ce paramètre combiné avec HTTPS dans l’écouteur prend en charge le chiffrement TLS de bout en bout. Celui-ci vous permet de transmettre en toute sécurité des données sensibles chiffrées au serveur back-end. Chaque serveur back-end du pool de back-ends pour lequel un chiffrement TLS de bout en bout est activé doit être configuré avec un certificat afin de sécuriser la communication.

Port

Ce paramètre spécifie le port où les serveurs back-end écoutent le trafic provenant de la passerelle applicative Application Gateway. Vous pouvez configurer des ports allant de 1 à 65535.

Certificat racine approuvé

Si vous sélectionnez HTTPS comme protocole back-end, la passerelle applicative nécessite un certificat racine approuvé pour faire confiance au pool de back-ends et activer le protocole SSL de bout en bout. Par défaut, l’option Utiliser le certificat d’autorité de certification connu est définie sur Non. Si vous prévoyez d’utiliser un certificat auto-signé ou un certificat signé par une autorité de certification interne, vous devez fournir à la passerelle applicative Application Gateway le certificat public correspondant que le pool de back-ends utilisera. Ce certificat doit être chargé directement dans la passerelle applicative au format .CER.

Si vous prévoyez d’appliquer un certificat sur le pool de back-ends signé par une autorité de certification publique approuvée, vous pouvez définir l’option Utiliser le certificat de l’autorité de certification connue sur Oui et ignorer le chargement d’un certificat public.

Délai d’expiration de la demande

Ce paramètre spécifie le nombre de secondes pendant lesquelles la passerelle applicative attend de recevoir une réponse du serveur back-end.

Remplacer le chemin back-end

Ce paramètre vous permet de configurer un chemin de transfert personnalisé facultatif à utiliser quand la demande est transférée au back-end. Toute partie du chemin entrant qui correspond au chemin personnalisé dans le champ Remplacer le chemin back-end est copiée dans le chemin transféré. Le tableau suivant montre comment agit cette fonctionnalité :

Quand le paramètre HTTP est attaché à une règle de routage des demandes de base :

Demande d’origine Remplacer le chemin backend Demande transférée au back end
/home/ /override/ /override/home/
/home/secondhome/ /override/ /override/home/secondhome/

Quand le paramètre HTTP est attaché à une règle de routage des demandes basée sur un chemin :

Demande d’origine Règle de chemin Remplacer le chemin backend Demande transférée au back end
/pathrule/home/ /pathrule* /override/ /override/home/
/pathrule/home/secondhome/ /pathrule* /override/ /override/home/secondhome/
/home/ /pathrule* /override/ /override/home/
/home/secondhome/ /pathrule* /override/ /override/home/secondhome/
/pathrule/home/ /pathrule/home* /override/ /override/
/pathrule/home/secondhome/ /pathrule/home* /override/ /override/secondhome/
/pathrule/ /pathrule/ /override/ /override/

Utiliser une sonde personnalisée

Ce paramètre associe une sonde personnalisée à un paramètre HTTP. Vous pouvez associer une seule sonde personnalisée à un paramètre HTTP. Si vous n’associez pas explicitement une sonde personnalisée, la sonde par défaut est utilisée pour superviser l’intégrité du back-end. Nous vous recommandons de créer une sonde personnalisée pour mieux contrôler la supervision de l’intégrité de vos back-ends.

Remarque

La sonde personnalisée ne supervise pas l’intégrité du pool de back-ends, sauf si le paramètre HTTP correspondant est explicitement associé à un écouteur.

Configuration du nom d’hôte

Application Gateway permet à la connexion établie au back-end d’utiliser un nom d’hôte différent de celui utilisé par le client pour se connecter à Application Gateway. Même si cette configuration peut être utile dans certains cas, remplacer le nom d’hôte de sorte qu’il soit différent entre le client et la passerelle applicative et entre la passerelle applicative et la cible back-end est une opération délicate.

En production, il est recommandé de conserver le même nom d’hôte entre le client et la passerelle applicative et entre la passerelle applicative et la cible back-end. Cela évite les problèmes potentiels liés aux URL absolues, aux URL de redirection et aux cookies liés à l’hôte.

Avant de configurer Application Gateway autrement, prenez connaissance des conséquences possibles d’une telle configuration, qui sont abordées de façon plus détaillée dans le Centre des architectures : Conserver le nom d’hôte HTTP d’origine entre un proxy inverse et son application web de back-end.

Un paramètre HTTP influence l’en-tête HTTP Host dont se sert Application Gateway pour se connecter au back-end sur deux plans :

  • Choisir un nom d’hôte à partir d’une adresse backend
  • Remplacement du nom d’hôte

Choisir un nom d’hôte à partir d’une adresse back-end

Cette fonctionnalité définit dynamiquement l’en-tête de l’hôte dans la requête sur le nom d’hôte du pool de back-ends. Elle utilise une adresse IP ou un nom de domaine complet.

Cette fonctionnalité s’avère utile quand le nom de domaine du back end est différent du nom DNS de la passerelle d’application et que le back-end s’appuie sur un en-tête d’hôte spécifique pour se résoudre en point de terminaison correct.

En exemple de cas, considérez des services multilocataire en tant que back-end. Un service d’application est un service multilocataire qui utilise un espace partagé avec une seule adresse IP. Ainsi, un service d’application est uniquement accessible par le biais des noms d’hôte configurés dans les paramètres du domaine personnalisé.

Par défaut, le nom de domaine personnalisé est example.azurewebsites.net. Pour accéder à votre service d’application via une passerelle applicative en utilisant un nom d’hôte qui n’est pas explicitement inscrit dans le service d’application ou le nom de domaine complet de la passerelle applicative, vous pouvez remplacer le nom d’hôte dans la demande d’origine par celui du service d’application. Pour cela, activez le paramètre Choisir un nom d’hôte à partir d’une adresse back-end.

Pour un domaine personnalisé dont le nom DNS personnalisé existant est mappé au service d’application, il est déconseillé d’activer le paramètre Choisir un nom d’hôte à partir d’une adresse back-end.

Remplacement du nom d’hôte

Cette fonctionnalité remplace l’en-tête de l’hôte dans la demande entrante sur la passerelle d’application par le nom d’hôte que vous spécifiez.

Par exemple, si www.contoso.com est spécifié dans le paramètre Nom d’hôte, la demande d’origine *https://appgw.eastus.cloudapp.azure.com/path1 est remplacée par *https://www.contoso.com/path1 quand la demande est transférée au back-end.

Pool back-end

Vous pouvez pointer un pool de back-ends vers quatre types de membres de back-end : une machine virtuelle spécifique, un groupe de machines virtuelles identiques, une adresse IP/un nom de domaine complet ou un service d’application.

Après avoir créé un pool de back-ends, vous devez l’associer à une ou plusieurs règles de routage des demandes. Vous devez également configurer des sondes d’intégrité pour chaque pool de back-ends sur votre passerelle d’application. Quand une condition de règle de routage des demandes est remplie, la passerelle d’application transfère le trafic aux serveurs sains (comme déterminé par les sondes d’intégrité) dans le pool de back-ends correspondant.

Sondes d’intégrité

Azure Application Gateway analyse l’intégrité de tous les serveurs de son pool principal et arrête automatiquement d’envoyer du trafic à tout serveur qu’il considère non sain. Les sondes continuent à analyser un tel serveur défectueux et la passerelle recommence à acheminer le trafic vers celui-ci dès que les sondes le détectent comme sain.

La sonde par défaut utilise le numéro de port du paramètre principal associé et d’autres configurations prédéfinies. Vous pouvez utiliser Sondes personnalisées pour les configurer de votre façon.

Comportement des sondes

Une adresse IP source

L’adresse IP source des sondes dépend du type de serveur principal :

  • Si l’adresse du serveur dans le pool principal est un point de terminaison public, l’adresse source est l’adresse IP publique front-end de la passerelle applicative.
  • Si le serveur du pool principal est un point de terminaison privé, l’adresse IP source proviendra de l’espace d’adressage du sous-réseau de votre passerelle applicative.

Opérations des sondes

Une passerelle commence à déclencher des sondes immédiatement après avoir configuré une règle, en l’associant à un paramètre principal et à un pool principal (et à l’écouteur, bien sûr). L’illustration montre que la passerelle sonde indépendamment tous les serveurs du pool principal. Les requêtes entrantes qui commencent à arriver sont envoyées uniquement aux serveurs sains. Un serveur principal est marqué comme non sain par défaut jusqu’à ce qu’une réponse de sonde positive soit reçue.

Diagramme montrant un exemple d’opérations de sonde d’intégrité de passerelle d’application Azure.

Les sondes requises sont déterminées en fonction de la combinaison unique du serveur principal et du paramétrage backend. Par exemple, considérez une passerelle avec un pool principal unique avec deux serveurs et deux paramétrages back-end, chacun ayant des numéros de port différents. Lorsque ces paramétrages backend distincts sont associés au même pool principal à l’aide de leurs règles respectives, la passerelle crée des sondes pour chaque serveur et la combinaison du paramétrage backend. Vous pouvez le visualiser sur la page Intégrité du serveur principal.

Capture d’écran montrant un exemple des paramètres d’intégrité du back-end.

De plus, toutes les instances de la passerelle applicative sondent les serveurs principaux indépendamment les uns des autres.

Remarque

Le rapport d’intégrité du serveur principal est mis à jour en fonction de l’intervalle d’actualisation de la sonde correspondante et ne dépend pas de la requête de l’utilisateur.

Sonde d’intégrité par défaut

Une passerelle d’application configure automatiquement une sonde d’intégrité par défaut lorsque vous ne définissez pas de configuration de sonde personnalisée. Le comportement de monitoring par défaut consiste à lancer une requête HTTP GET aux adresses IP qui sont configurées dans le pool de back-ends. En ce qui concerne les sondes par défaut, si les paramètres HTTP du serveur principal sont configurés pour HTTPS, la sonde utilise HTTPS pour tester l’intégrité des serveurs principaux.

Par exemple : vous configurez votre passerelle applicative pour utiliser les serveurs back-end A, B et C, qui recevront le trafic réseau HTTP sur le port 80. Les tests de monitoring de l’intégrité par défaut testent les trois serveurs toutes les 30 secondes pour obtenir une réponse HTTP intègre, avec un délai d’expiration de 30 secondes pour chaque requête. Le code d’état d’une réponse HTTP correcte est compris entre 200 et 399. Dans ce cas, la requête HTTP GET pour la sonde d’intégrité se présente comme suit : http://127.0.0.1/. Consultez également Codes de réponse HTTP dans Application Gateway.

Si la vérification de la sonde par défaut échoue pour le serveur A, la passerelle d’application arrête de transférer des requêtes vers ce serveur. La sonde par défaut continue de contrôler le serveur A toutes les 30 secondes. Lorsque le serveur A répond correctement à une requête de sonde d’intégrité par défaut, la passerelle d’application recommence à transférer les requêtes vers le serveur.

Paramètres de sonde d’intégrité par défaut

Propriétés de la sonde Valeur Description
URL de sonde <protocole>://127.0.0.1:<port>/ Le protocole et le port sont hérités des paramètres HTTP principaux auxquels la sonde est associée
Intervalle 30 Durée de l’attente, en secondes, avant l’envoi de la sonde d’intégrité suivante.
Délai d’attente 30 Durée de l’attente, en secondes, de la passerelle d’application pour une réponse de la sonde avant que la sonde ne soit déclarée comme défectueuse. Si une sonde renvoie un état intègre, le serveur principal correspondant est immédiatement marqué comme étant intègre.
Seuil de défaillance sur le plan de l’intégrité 3 Détermine le nombre de sondes à envoyer en cas d’échec de la sonde d’intégrité standard. Dans la référence SKU v1, ces sondes d’intégrité supplémentaires sont envoyées de façon rapprochée pour déterminer rapidement l’intégrité du serveur principal et ne tiennent pas compte de l’intervalle d’analyse. Dans le cas du SKU v2, les sondes d’intégrité attendent l’intervalle. Le serveur back-end est marqué comme étant défectueux lorsque le nombre d’échecs consécutifs a atteint le seuil de défaillance.

La sonde d’intégrité par défaut examine uniquement <protocole>://127.0.0.1:<port> pour déterminer l’état d’intégrité. Si vous devez configurer la sonde d’intégrité de sorte qu’elle accède à une URL personnalisée ou modifier d’autres paramètres, vous devez utiliser des sondes personnalisées.

Sonde d’intégrité personnalisée

Les sondes personnalisées vous permettent d’avoir un contrôle plus précis de l’analyse de l’intégrité. En utilisant des sondes personnalisées, vous pouvez notamment configurer un nom d’hôte personnalisé, un chemin d’URL, un intervalle de sondage et le nombre de réponses en échec autorisé avant que l’instance de pool de back-ends ne soit marquée comme non saine.

Paramètres de sonde d’intégrité personnalisée

Le tableau suivant fournit des définitions pour les propriétés d’une sonde d’intégrité personnalisée.

Propriétés de la sonde Description
Nom Nom de la sonde. Ce nom est utilisé pour identifier et désigner la sonde dans les paramètres HTTP du serveur back-end.
Protocol Protocole utilisé pour envoyer la sonde. Ceci doit correspondre au protocole défini dans les paramètres HTTP backend auquel il est associé.
Host Nom d’hôte pour l’envoi de la sonde. Dans la référence SKU v1, cette valeur est uniquement utilisée pour l’en-tête d’hôte de la requête de sonde. Dans la référence SKU v2, elle est utilisée en tant qu’en-tête d’hôte et SNI.
Path Chemin relatif de la sonde. Un chemin d’accès valide commence par « / »
Port S’il est défini, il est utilisé en tant que port de destination. Sinon, il utilise le même port que les paramètres HTTP auxquels il est associé. Cette propriété est uniquement disponible dans la référence SKU v2
Intervalle Intervalle d’analyse en secondes. Cette valeur correspond à l’intervalle de temps qui s’écoule entre deux analyses consécutives.
Délai d’attente Délai d’expiration de l’analyse en secondes. Si aucune réponse valide n’est reçue dans le délai imparti, la sonde est marquée comme étant en échec.
Seuil de défaillance sur le plan de l’intégrité Nombre de tentatives d’analyse Le serveur back-end est marqué comme étant non sain lorsque le nombre d’échecs consécutifs a atteint le seuil de défaillance.

Correspondance des sondes

Par défaut, une réponse HTTP(S) avec un code d’état compris entre 200 et 399 est considérée comme intègre. Les sondes d’intégrité personnalisées prennent également en charge deux critères de correspondance. Des critères de correspondance peuvent être utilisés pour éventuellement modifier l’interprétation par défaut de ce qui rend une réponse intègre.

Les éléments suivants sont des critères de correspondance :

  • Correspondance de code d’état de la réponse HTTP : le critère de correspondance de la sonde pour l’acceptation du code de réponse http spécifié par l’utilisateur ou des plages de codes de réponse. Les codes d’état de réponse séparées par des virgules individuelles ou une plage de codes d’état sont pris en charge.
  • Correspondance du corps de la réponse HTTP : critère de correspondance de la sonde qui examine le corps de la réponse HTTP et correspond à une chaîne spécifiée par l’utilisateur. La correspondance ne tient compte que de la présence d’une chaîne spécifiée par l’utilisateur dans le corps de la réponse et n’est pas une correspondance d’expression régulière complète. La correspondance spécifiée doit être de 4090 caractères ou moins.

Les critères de correspondance peuvent être spécifiés à l’aide de la cmdlet New-AzApplicationGatewayProbeHealthResponseMatch.

Par exemple :

Azure PowerShell

$match = New-AzApplicationGatewayProbeHealthResponseMatch -StatusCode 200-399




$match = New-AzApplicationGatewayProbeHealthResponseMatch -Body "Healthy"

Les critères de correspondance peuvent être attachés à la configuration de la sonde à l’aide d’un opérateur -Match dans PowerShell.

Cas d’usage des sondes personnalisées

  • Si un serveur principal autorise l’accès aux utilisateurs authentifiés uniquement, les sondes de passerelle applicative reçoivent un code de réponse 403 au lieu de 200. Les clients (utilisateurs) étant limités à s’authentifier pour le trafic en direct, vous pouvez configurer le trafic de la sonde pour accepter 403 comme réponse attendue.
  • Lorsqu’un serveur principal dispose d’un certificat générique (*.contoso.com) installé pour servir différents sous-domaines, vous pouvez utiliser une sonde personnalisée avec un nom d’hôte spécifique (requis pour SNI) qui soit accepté pour établir une sonde TLS positive et signaler que ce serveur est sain. Avec « remplacer le nom d’hôte » dans le paramétrage principal défini sur NO, les différents noms d’hôte entrants (sous-domaines) sont transmis comme tels au backend.

Considérations liées au groupe de sécurité réseau (NSG)

Un contrôle précis du sous-réseau Application Gateway via des règles NSG est possible en préversion publique. Pour plus d’informations, cliquez ici.

Avec les fonctionnalités actuelles, il existe certaines restrictions :

Vous devez autoriser le trafic Internet entrant sur les ports TCP 65503-65534 pour la référence (SKU) Application Gateway v1, et sur les ports TCP 65200-65535 pour la référence (SKU) v2 avec le sous-réseau de destination en tant que Any et la source en tant que balise de service GatewayManager. Cette plage de ports est nécessaire pour la communication avec l’infrastructure Azure.

En outre, la connectivité Internet sortante ne peut pas être bloquée, et le trafic entrant provenant de la balise AzureLoadBalancer doit être autorisé.

Fonctionnement d’une passerelle applicative

Diagramme montrant un exemple de fonctionnement d’une passerelle d’application Azure.

Comment une passerelle d’application accepte une requête

  1. 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.
  2. Le DNS Azure retourne l’adresse IP au client. Il s’agit de l’adresse IP front-end de la passerelle d’application.
  3. 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.
  4. 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.

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

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

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.

  • Lorsque vous utilisez des serveurs DNS personnalisés avec le réseau virtuel d’Application Gateway, il est essentiel que tous les serveurs soient identiques et répondent de manière cohérente avec les mêmes valeurs DNS.
  • Les utilisateurs de serveurs DNS personnalisés locaux doivent garantir la connectivité à Azure DNS via Azure DNS Private Resolver (recommandé) ou une machine virtuelle de redirecteur DNS lors de l’utilisation d’une zone DNS privée pour un 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.