Configurer Azure Application Gateway
Application Gateway dispose d’une série de composants qui s’associent pour acheminer les requêtes vers un pool de serveurs web et pour vérifier l’intégrité de ces serveurs web.
Configuration du frontend
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 lorsque vous hébergez un back-end auquel les clients doivent accéder par Internet à l’aide d’une adresse IP virtuelle Internet.
Configuration du backend
Le pool de back-ends est utilisé pour router les demandes vers les serveurs back-end qui les traitent. Vous pouvez créer un pool back-end vide avec votre passerelle applicative, puis ajouter des cibles back-end à ce pool back-end. Les cibles peuvent inclure des cartes d’interface réseau, des adresses IP publiques et privées ainsi que des groupes de machines virtuelles identiques.
Configurer les sondes d’intégrité
Azure Application Gateway analyse par défaut l’intégrité de toutes les ressources de son pool principal et supprime automatiquement du pool les ressources considérées comme défectueuses. Application Gateway continue de surveiller les instances défaillantes et les réintroduit dans le pool principal intègre une fois qu’elles redeviennent disponibles et répondent aux sondes d’intégrité. Par défaut, la passerelle d’application envoie les sondes d’intégrité avec le même port que celui défini dans les paramètres HTTP du serveur principal. Un port de sonde personnalisé peut être configuré à l’aide d’une sonde d’intégrité personnalisée.
L’adresse IP source qu’Application Gateway utilise pour les sondes d’intégrité dépend du pool de back-ends :
- Si l’adresse du serveur dans le pool de back-ends est un point de terminaison public, l’adresse source est l’adresse IP publique front-end de la passerelle d’application.
- Si l’adresse du serveur dans le pool de back-ends est un point de terminaison privé, l’adresse IP source vient de l’espace d’adressage IP privé du sous-réseau de la passerelle d’application.
Sonde d’intégrité par défaut
Une passerelle applicative configure automatiquement une sonde d’intégrité par défaut lorsque vous ne définissez pas de configuration de sonde personnalisée. Le comportement d’analyse par défaut consiste à lancer une requête HTTP GET aux adresses IP 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 d’application de manière à utiliser les serveurs principaux A, B et C, qui recevront le trafic réseau HTTP sur le port 80. Le monitoring de l’intégrité par défaut teste les trois serveurs toutes les 30 secondes pour obtenir une réponse HTTP saine avec un délai d’expiration de 30 secondes à 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/.
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
La table suivante répertorie les paramètres par défaut de la sonde d'intégrité :
| Propriétés de la sonde | Valeur | Description |
|---|---|---|
| URL de sonde | <protocol>://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 v2, les sondes d’intégrité attendent l’intervalle de la sonde avant d’effectuer une nouvelle vérification. Le serveur back-end est marqué comme étant inaccessible une fois que le nombre d’échecs consécutifs des sondes a atteint le seuil défini comme non sain. |
Intervalles d'analyse
Toutes les instances d’Application Gateway sondent le serveur principal indépendamment des autres. La même configuration de sonde s’applique à chaque instance d’Application Gateway. Par exemple, si la configuration de sonde consiste à envoyer des sondes d’intégrité toutes les 30 secondes, et si Application Gateway a deux instances, les deux instances envoient la sonde d’intégrité toutes les 30 secondes.
S’il existe plusieurs écouteurs, chacun d’entre eux sonde le serveur principal indépendamment des autres.
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 intervalle d’analyse et le nombre de réponses en échec autorisé avant que l’instance de pool principal 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 principal. |
| Protocol | Protocole utilisé pour envoyer la sonde. Cette propriété doit correspondre au protocole défini dans les paramètres HTTP du back-end. |
| Hôte | Nom d’hôte pour l’envoi de la sonde. |
| Chemin d’accès | Chemin relatif de la sonde. Un chemin d’accès valide commence par « / ». |
| Port | Si elle est définie, cette propriété est utilisée 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 principal est marqué comme étant défectueux après que 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.
Les critères de correspondance peuvent être spécifiés à l’aide de la cmdlet New-AzApplicationGatewayProbeHealthResponseMatch.
Configurer des é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 un écouteur, vous devez entrer des valeurs qui correspondent aux valeurs correspondantes dans la requête 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
Quand vous créez un nouvel écouteur, vous choisissez entre le type de base et le type multisite.
- De base : Toutes les requêtes sont acceptées et transférées aux pools de back-ends.
- Multi-site : transférer les requêtes vers différents pools back-end en fonction de l’en-tête ou des noms de l’hôte. Vous devez spécifier un nom d’hôte qui correspond à la requête entrante.
Ordre de traitement des
Pour la référence SKU v1, les demandes sont mises en correspondance en fonction de l’ordre des règles et du type d’écouteur. Pour la référence SKU v2, les écouteurs multisites sont traités avant les écouteurs de base.
Adresse IP front-end
Choisissez l’adresse IP front-end que vous prévoyez d’associer à cet écouteur. L’écouteur est à l’écoute des requêtes entrantes sur cette adresse IP.
Port front-end
Choisissez le port front-end. Sélectionnez un port existant ou créez-en un. Choisissez une valeur dans la plage de ports autorisée. Vous pouvez utiliser non seulement les ports connus, comme les ports 80 et 443, mais aussi tout port personnalisé autorisé qui convient. Un port peut être utilisé pour des écouteurs publics ou privés.
Protocol
Choisissez HTTP ou HTTPS :
- HTTP : le trafic entre le client et la passerelle applicative est non chiffré.
- HTTPS : active la terminaison TLS ou le chiffrement TLS de bout en bout. La connexion TLS se termine au niveau de la passerelle applicative. Le trafic entre le client et la passerelle applicative est chiffré. Si vous voulez un chiffrement TLS de bout en bout, vous devez choisir le protocole HTTPS et configurer le paramètre HTTP du back-end.
Pour configurer l’arrêt TLS et le chiffrement TLS de bout en bout, vous devez ajouter un certificat à l’écouteur pour permettre à la passerelle d’application de dériver une clé symétrique. La clé symétrique est utilisée pour chiffrer et déchiffrer le trafic de la passerelle. Le certificat de passerelle doit être au format Personal Information Exchange (PFX). Ce format vous permet d’exporter la clé privée que la passerelle utilise pour chiffrer et déchiffrer le trafic.
Présentation de la redirection
Vous pouvez utiliser Application Gateway pour rediriger le trafic. La passerelle dispose d’un mécanisme de redirection générique, qui permet de rediriger le trafic reçu sur un écouteur vers un autre écouteur ou vers un site externe. La redirection simplifie la configuration des applications, et optimise l’utilisation des ressources. Ces types de redirections sont pris en charge :
- 301 Redirection permanente
- 302 Trouvé.
- 303 Voir autres
- 307 Redirection temporaire
La prise en charge de la redirection Application Gateway offre les fonctionnalités suivantes :
- Redirection globale : redirige un écouteur vers un autre écouteur sur la passerelle. Cela permet la redirection HTTP vers HTTPS sur un site.
- Redirection basée sur le chemin d’accès : active la redirection HTTP vers HTTPS uniquement sur une zone de site spécifique, par exemple une zone de panier d’achat dénotée par /panier/*.
- Rediriger vers un site externe : nécessite un nouvel objet de configuration de redirection, qui spécifie l’écouteur cible ou le site externe vers lequel la redirection est souhaitée. L’élément de configuration prend également en charge des options qui permettent d’ajouter le chemin d’URI et la chaîne de requête à l’URL redirigée. La configuration de redirection est attachée à l’écouteur source au moyen d’une nouvelle règle.
Pour découvrir plus d’informations sur la configuration de la redirection dans Application Gateway, consultez Redirection basée sur un chemin d’URL à l’aide de PowerShell – Azure Application Gateway | Microsoft Learn.
Règles de routage des requêtes Application Gateway
Une règle de routage de requête est un composant clé pour une passerelle d’application, car elle détermine le mode de routage du trafic sur l’écouteur. La règle lie l’écouteur, le pool de back-ends et les paramètres HTTP back-end.
Quand un écouteur accepte une requête, la règle de routage de requête transfère la requête au back-end ou la redirige ailleurs. Si la requête est transférée au back-end, la règle de routage de requête définit le pool de back-ends à cibler. La règle de routage de requête détermine également si les en-têtes de la requête doivent être réécrits. Vous pouvez attacher un écouteur à une règle.
Il existe deux types de règle de routage des requêtes :
De base : Toutes les requêtes de l’écouteur associé (par exemple blog.contoso.com/*) sont transférées au pool de back-ends associé en utilisant le paramètre HTTP associé.
Basé sur un chemin : Cette règle d’acheminement vous permet de router les requêtes de l’écouteur associé vers un pool de back-ends spécifique, en fonction de l’URL de la requête. Si le chemin de l’URL d’une requête correspond au modèle de chemin d’une règle basée sur le chemin, la règle route cette requête. Elle applique le modèle de chemin uniquement au chemin de l’URL. Elle ne l’applique pas à ses paramètres de requête. Si le chemin de l’URL d’une requête d’écouteur ne correspond à aucune des règles basées sur le chemin, elle route la requête vers le pool de back-ends et les paramètres HTTP par défaut.
Paramètres HTTP
Une passerelle d’application route le trafic vers les back-ends (spécifiés dans la règle de routage de requête incluant les paramètres HTTP) à l’aide du numéro de port, du protocole et d’autres paramètres détaillés dans ce composant.
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é.
Ce composant est également utilisé pour :
Déterminer si une session utilisateur doit être conservée sur le même serveur à l’aide de l’affinité de session basée sur les cookies
Supprimer de manière appropriée les membres du pool de back-ends à l’aide du drainage de connexion
Associez une sonde d’intégrité personnalisée pour effectuer un monitoring de l’intégrité du back-end, définir l’intervalle du délai d’expiration de la requête, remplacer le nom d’hôte et le chemin d’accès dans la requête, et fournir une facilité de sélection unique pour spécifier les paramètres du back-end App Service.