Notes
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
Les paramètres principaux vous permettent de gérer les configurations des connexions principales établies à partir d’une ressource de passerelle d’application vers un serveur du pool principal. Une configuration des paramètres principaux peut être associée à une ou plusieurs règles de routage.
Types de paramètres principaux dans Application Gateway
Bien que les utilisateurs du portail voient uniquement l’option « Paramètres principaux », les utilisateurs d’API ont accès à deux types de paramètres. Vous devez utiliser la configuration correcte, en fonction du protocole.
- Paramètres HTTP principaux : il s’agit des configurations de proxy de couche 7 qui prennent en charge les protocoles HTTP et HTTPS.
- Paramètres Backend : il s’agit des configurations de proxy Layer 4 (préversion) qui prennent en charge les protocoles TLS et TCP.
Affinité basée sur les cookies
Azure Application Gateway utilise des cookies gérés par passerelle pour gérer les sessions utilisateur. Lorsqu’un utilisateur envoie la première requête à 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. Ce processus permet aux requêtes suivantes qui transportent le cookie d’affinité d’être routés vers le même serveur back-end, ce qui permet de maintenir 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.
La mise à jour v80 du navigateur Chromium a permis que les cookies HTTP sans attribut SameSite soient traités comme SameSite=Lax. Pour les requêtes CORS (Cross-Origin Resource Sharing), si le cookie doit être envoyé dans un contexte tiers, il doit utiliser les attributs SameSite=None; Secure et il doit être envoyé seulement via HTTPS. Dans le cas contraire, dans un scénario HTTP uniquement, le navigateur n’envoie pas les cookies dans le contexte tiers. L’objectif de cette mise à jour à partir de Chrome est d’améliorer la sécurité et d’éviter les attaques par falsification de requête intersites (CSRF).
Pour prendre en charge ce changement, à partir du 17 février 2020, Application Gateway (tous les types de références SKU) injecte un autre cookie appelé ApplicationGatewayAffinityCORS en plus du cookie ApplicationGatewayAffinity existant. Deux attributs supplémentaires (« SameSite=None; Secure ») ont été ajoutés au cookie ApplicationGatewayAffinityCORS de sorte que les sessions persistantes soient maintenues même pour les requêtes cross-origin.
Le nom du cookie d’affinité par défaut est ApplicationGatewayAffinity et vous pouvez le modifier. Si, dans votre topologie de réseau, vous déployez plusieurs passerelles d’application en ligne, vous devez définir des noms de cookies uniques pour chaque ressource. Si vous utilisez un nom de cookie d’affinité personnalisé, un cookie supplémentaire est ajouté avec le suffixe CORS. Par exemple : CustomCookieNameCORS.
Remarque
Si l’attribut SameSite=None est défini, il est obligatoire que le cookie contienne également l’indicateur Sécurisé et qu’il doit être envoyé via HTTPS. Si l’affinité de session est exigée sur CORS, vous devez migrer votre charge de travail vers HTTPS. Reportez-vous à la documentation sur le déchargement TLS et le TLS de bout en bout pour l'Application Gateway. Consultez la vue d’ensemble du protocole SSL, Configurer une passerelle d’application avec arrêt TLS et configurer le protocole TLS de bout en bout.
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. Elle s’applique aux instances principales qui sont explicitement supprimées du pool principal.
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. Ce processus est également vrai pour les connexions WebSocket.
| Type de configuration | Valeur |
|---|---|
| Valeur par défaut lorsque le drainage de connexion n’est pas activé dans le paramètre principal | 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 à ce processus est que les demandes sont liées à la désinscription des instances en raison de l’affinité de session gérée par la passerelle. Ces demandes continuent d’être transférées aux instances de désinscription.
Remarque
Il existe une limitation selon laquelle une mise à jour de configuration met fin aux connexions en cours après le délai de drainage de connexion. Pour résoudre cette limitation, vous devez augmenter le délai d’expiration de la connexion dans les paramètres back-end à une valeur supérieure à la durée de téléchargement maximale attendue du client.
Protocole
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é
Lors de la sélection du protocole HTTPS dans les paramètres principaux, la ressource application gateway utilise son magasin de certificats d’autorité de certification racine approuvé par défaut pour vérifier la chaîne et l’authenticité du certificat fourni par le serveur principal.
Par défaut, la ressource Application Gateway inclut des certificats d’autorité de certification populaires, autorisant des connexions TLS principales transparentes lorsque le certificat de serveur principal est émis par une autorité de certification publique. Toutefois, si vous envisagez d’utiliser une autorité de certification privée ou un certificat auto-généré, vous devez fournir le certificat d’autorité de certification racine correspondant (.cer) dans cette configuration des paramètres principaux.
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. La valeur par défaut est de 20 secondes. Toutefois, vous souhaiterez peut-être ajuster ce paramètre aux besoins de votre application.
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 back-end Demande transférée au back end /domicile/ /outrepasser/ /override/home/ /home/secondhome/ /outrepasser/ /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 back-end Demande transférée au back end /pathrule/accueil/ /pathrule* /outrepasser/ /override/home/ /pathrule/home/secondhome/ /pathrule* /outrepasser/ /override/home/secondhome/ /domicile/ /pathrule* /outrepasser/ /override/home/ /home/secondhome/ /pathrule* /outrepasser/ /override/home/secondhome/ /pathrule/accueil/ /pathrule/home* /outrepasser/ /outrepasser/ /pathrule/home/secondhome/ /pathrule/home* /outrepasser/ /override/secondhome/ /règledechemin/ /règledechemin/ /outrepasser/ /outrepasser/
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. Bien que cette configuration puisse être utile dans certains cas, faites preuve de prudence en remplaçant le nom d’hôte de sorte qu’il soit différent entre la passerelle d’application et le client par rapport à la cible back-end.
Dans les environnements de production, il est recommandé d’utiliser le même nom d’hôte pour la connexion du client à la passerelle d’application et de la passerelle d’application à la cible du serveur principal. Cette pratique é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 qui s’écarte de cela, passez en revue les implications de cette configuration, comme expliqué plus en détail dans Le Centre d’architecture : conservez le nom d’hôte HTTP d’origine entre un proxy inverse et son application web 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 back-end »
- « 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.
Exemple : des services multilocataires 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, la configuration recommandée n’est pas pour activer le nom d’hôte choisi à partir de l’adresse principale.
Remarque
Ce paramètre n’est pas obligatoire pour App Service Environment, qui est un déploiement dédié.
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 elle est spécifiée dans le paramètre nom d’hôte , la requête d’origine *https://appgw.eastus.cloudapp.azure.com/path1 est remplacée par *https://www.contoso.com/path1 lorsque la requête est transférée au serveur principal.