Forum aux questions sur Application Gateway

Azure Application Gateway fournit un contrôleur de remise d’applications en tant que service. Il offre diverses fonctionnalités d’équilibrage de charge de couche 7 pour vos applications. Ce service est hautement disponible, évolutif et complètement managé par Azure.

Application Gateway prend en charge la mise à l’échelle automatique, le déchargement TLS et TLS de bout en bout, un pare-feu d’application web (WAF), l’affinité de session basée sur les cookies, le routage basé sur le chemin d’accès de l’URL, l’hébergement de plusieurs sites, et bien plus encore. Pour obtenir une liste complète des fonctionnalités prises en charge, voir Vue d’ensemble d’Application Gateway.

Application Gateway est un équilibreur de charge de couche 7, ce qui signifie qu’il fonctionne uniquement avec le trafic web (HTTP/HTTPS/WebSocket etHTTP/2). Il prend en charge des fonctionnalités telles que la terminaison TLS, l’affinité de session basée sur les cookies et le tourniquet (round robin) pour le trafic d’équilibrage de charge. Load Balancer équilibre la charge du trafic au niveau de la couche 4 (TCP ou UDP).

Application Gateway prend en charge les protocoles HTTP, HTTPS, HTTP/2 et WebSocket.

Consultez HTTP/2 support.

Consultez Ressources principales prises en charge.

Application Gateway v1 (Standard et WAF) est disponible dans toutes les régions d’Azure global. Elle est également disponible dans Microsoft Azure géré par 21Vianet et Azure Government

Pour la disponibilité d’Application Gateway v2 (Standard_v2 et WAF_v2), consultez Régions prises en charge pour Application Gateway v2

Application Gateway est un déploiement dédié dans votre réseau virtuel.

La redirection est prise en charge. Consultez Vue d’ensemble de la redirection Application Gateway.

Consultez l'ordre de traitement des écouteurs.

Si vous utilisez une adresse IP publique comme point de terminaison, vous trouverez les informations IP et DNS sur la ressource d’adresse IP publique. Vous pouvez également le trouver dans le portail Azure, dans la page de vue d’ensemble de la passerelle Application Gateway. Si vous utilisez des adresses IP internes, ces informations se trouvent dans la page Vue d'ensemble. Pour la référence SKU v1, les passerelles créées après le 1er mai 2023 n’ont pas de nom DNS par défaut automatiquement associé à la ressource IP publique. Pour la référence SKU v2, ouvrez la ressource IP publique et sélectionnez Configuration. Le champ Étiquette du nom DNS (facultatif) est disponible pour configurer le nom DNS.

Keep-Alive délai d’expiration régit la durée pendant laquelle la passerelle d’application attend qu’un client envoie une autre requête HTTP sur une connexion persistante avant de la réutiliser ou de la fermer. Le délai d’inactivité TCP régit la durée pendant laquelle une connexion TCP est conservée s’il n’y a pas d’activité.

Pour les connexions HTTP/1.1, le Keep-Alive délai d'attente dans les SKU Application Gateway v1 et v2 est de 120 secondes. Pour les adresses IP privées, la valeur n’est pas configurée avec un délai d’inactivité TCP de 5 minutes. Par défaut, le délai d’inactivité TCP est de 4 minutes sur l’adresse IP virtuelle du serveur frontal des SKU v1 et v2 d’Application Gateway. Vous pouvez configurer la valeur du délai d’inactivité TCP sur les instances Application Gateway v1 et v2 pour qu’elles soient comprises entre 4 minutes et 30 minutes. Pour les instances Application Gateway v1 et v2, vous devez accéder à l’adresse IP publique de la passerelle d’application et modifier le délai d’inactivité TCP sous le volet Configuration de l’adresse IP publique dans le portail. Vous pouvez définir la valeur du délai d’inactivité TCP de l’IP publique via PowerShell en exécutant les commandes suivantes :

$publicIP = Get-AzPublicIpAddress -Name MyPublicIP -ResourceGroupName MyResourceGroup
$publicIP.IdleTimeoutInMinutes = "15"
Set-AzPublicIpAddress -PublicIpAddress $publicIP

Pour les connexions HTTP/2 à l’adresse IP frontale sur la référence SKU Application Gateway v2, le délai d’inactivité est défini sur 180 secondes et n’est pas configuré.

Pour éviter un conflit et un comportement inattendu, assurez-vous que le délai d’inactivité TCP est défini comme étant identique ou plus long que le délai d’attente de conservation.

Oui. Application Gateway réutilise les connexions TCP existantes avec un serveur principal.

Non. Il n’existe aucun moyen de renommer une ressource Application Gateway. Vous devez créer une ressource portant un autre nom.

Non. Il n’existe aucun moyen de restaurer une ressource Application Gateway ou son adresse IP publique après une suppression. Vous devez créer une ressource.

Dans la référence SKU Application Gateway V1, l’adresse IP virtuelle peut changer si vous arrêtez et démarrez la passerelle d’application. Le nom DNS associé à la passerelle d’application, quant à lui, ne change pas pendant toute la durée de vie de la passerelle. Le nom DNS ne changeant pas, vous devez utiliser un alias CNAME et le faire pointer vers l’adresse DNS de la passerelle d’application. Dans la référence SKU Application Gateway v2, les adresses IP sont statiques. Par conséquent, l’adresse IP et le nom DNS ne changeront pas au cours de la durée de vie de la passerelle d’application.

Oui. La référence SKU Application Gateway v2 prend en charge les adresses IP publiques statiques et les adresses IP internes statiques. La référence SKU v1 quant à elle prend en charge les adresses IP internes statiques.

Une passerelle applicative ne prend en charge qu’une seule adresse IP publique par protocole IP. Si la passerelle applicative est configurée en tant que DualStack, elle peut prendre en charge deux adresses IP publiques : une pour IPv4 et une pour IPv6.

Consultez Considérations relatives à la taille du sous-réseau Application Gateway.

Oui. En plus de plusieurs instances d’un déploiement Application Gateway donné, vous pouvez configurer une autre ressource Application Gateway unique dans un sous-réseau existant qui contient une autre ressource Application Gateway.

Un seul sous-réseau ne peut pas prendre en charge les références (SKU) v2 et v1 d’Application Gateway.

Oui, mais uniquement dans des scénarios spécifiques. Pour plus d’informations, consultez Configuration de l’infrastructure Application Gateway.

Oui. Consultez Modifications apportées à une requête.

La configuration des déploiements de nouvelles références SKU v1 d’Application Gateway peut prendre jusqu’à 20 minutes. Les modifications apportées à la taille ou au nombre des instances n’entraînent pas d’interruption, et la passerelle reste active pendant ce temps.

Pour la plupart des déploiements qui utilisent la référence SKU v2, le provisionnement prend environ 6 minutes. Toutefois, le processus peut prendre plus de temps en fonction du type de déploiement. Par exemple, les déploiements sur plusieurs zones de disponibilité avec de nombreuses instances peuvent prendre plus de 6 minutes.

Les mises à jour initiées à Application Gateway sont appliquées une de domaine de mise à jour à la fois. À mesure que les instances de chaque domaine de mise à jour sont mises à jour, les instances restantes dans d’autres domaines de mise à jour continuent de servir le trafic¹. Les connexions actives sont correctement vidées des instances en cours de mise à jour pendant un maximum de cinq minutes pour aider à établir la connectivité avec les instances d’un autre domaine de mise à jour avant le début de la mise à jour. Lors de la mise à jour, Application Gateway s’exécute temporairement à une capacité maximale réduite, déterminée par le nombre d’instances configurées. Le processus de mise à jour passe au prochain ensemble d’instances uniquement si l’ensemble actuel d’instances a été correctement mis à niveau.

¹ Nous vous recommandons de configurer un nombre minimal d’instances de 2 pour les déploiements de référence SKU Application Gateway v1 afin de garantir qu’au moins une instance peut traiter le trafic pendant l’application des mises à jour.

Application Gateway prend en charge le proxy de protocole TLS/TCP par son proxy de couche 4 en préversion.

Un proxy de couche 7 d’Application Gateway avec les protocoles HTTP(S) ne prend pas en charge les protocoles de messagerie comme SMTP, IMAP et POP3. Toutefois, pour certains services de messagerie les prenant en charge, comme le trafic Outlook Web Access (OWA), ActiveSync et AutoDiscovery qui utilise des protocoles HTTP(S), vous pouvez utiliser un proxy de couche 7 et leur trafic devrait transiter. (Remarque : Les exclusions dans les règles du pare-feu d’applications web peuvent être requises lors de l’utilisation d’une référence SKU du pare-feu d’applications web).

Oui. Pour plus d’informations, consultez Migrer Azure Application Gateway et le pare-feu d’applications web de v1 vers v2.

Oui. Le support de la référence SKU Application Gateway v1 va-t-il continuer ? Nous vous recommandons vivement de passer à v2 pour tirer parti des mises à jour de fonctionnalités dans cette référence SKU. Pour plus d’informations sur les différences de fonctionnalités entre v1 et v2, consultez Application Gateway v2 avec mise à l’échelle automatique et redondance interzone. Vous pouvez migrer manuellement des déploiements de référence SKU Application Gateway v1 vers v2 en suivant les instructions fournies dans notre document sur la migration v1-v2.

Non. Application Gateway v2 ne prend pas en charge les demandes de proxy avec l’authentification NTLM ou Kerberos.

Les noms d’en-tête de demande peuvent contenir des caractères alphanumériques et des traits d’union. Les noms d’en-tête de requête qui contiennent d’autres caractères sont ignorés lorsqu’une demande est envoyée à la cible principale. Les noms d’en-tête de réponse peuvent contenir n’importe quel caractère alphanumérique et des symboles spécifiques tels que définis dans RFC 7230.

Oui. Le navigateur Chromium mise à jour v80 a introduit un mandat sur les cookies HTTP sans l’attribut SameSite à traiter comme SameSite=Lax. Cela signifie que le cookie d’affinité d’Application Gateway ne sera pas envoyé par le navigateur dans un contexte tiers.

Pour prendre en charge ce scénario, Application Gateway injecte un autre cookie appelé ApplicationGatewayAffinityCORS en plus du cookie ApplicationGatewayAffinity existant. Ces cookies sont similaires, mais le cookie ApplicationGatewayAffinityCORS a deux attributs supplémentaires ajoutés : SameSite=None et Secure. Ces attributs maintiennent les sessions rémanentes même pour les requêtes cross-origin. Pour plus d’informations, consultez la section d’affinité basée sur les cookies .

Un écouteur actif est un écouteur associé à une règle et l’envoi du trafic à un pool principal. Un écouteur qui redirige uniquement du trafic n’est pas un écouteur actif. Les écouteurs associés à des règles de redirection ne sont pas considérés comme actifs. Si la règle de redirection est une règle basée sur le chemin d’accès, tous les chemins d’accès de cette règle de redirection doivent rediriger le trafic ou bien l’écouteur est considéré comme actif. Pour plus d’informations sur la limite des composants individuels, consultez abonnement Azure et les limites de service, les quotas et les contraintes.

La référence SKU v1 d’Application Gateway prend en charge les scénarios de haute disponibilité lorsque vous avez déployé deux instances ou plus. Azure distribue ces instances entre les domaines de mise à jour et d’erreur pour garantir qu'elles n’échouent pas toutes en même temps. La référence SKU v1 prend en charge la scalabilité en ajoutant plusieurs instances de la même passerelle pour partager la charge.

La référence SKU v2 garantit automatiquement que les nouvelles instances sont réparties sur les domaines d’erreur et les domaines de mise à jour. Si vous choisissez une redondance de zone, les instances les plus récentes sont également réparties sur les zones de disponibilité pour offrir une résilience zonale en cas d’échec.

Utilisez Azure Traffic Manager pour distribuer le trafic entre plusieurs passerelles d’application dans différents centres de données.

Oui. Vous pouvez configurer le drainage de connexion afin de modifier des membres au sein d’un pool principal sans interrompre le service. Pour plus d’informations, consultez la section Drainage de connexion d’Application Gateway.

Oui. La référence SKU v2 d’Application Gateway prend en charge la mise à l’échelle automatique. Pour plus d’informations, consultez Application Gateway avec mise à l’échelle automatique et redondance interzone.

Non. Aucun temps d’arrêt n’a lieu, les instances sont réparties entre les domaines de mise à niveau et les domaines d’erreur.

Oui.

Oui.

Oui. Application Gateway est toujours déployé dans un sous-réseau de réseau virtuel. Ce sous-réseau ne peut contenir que des instances Application Gateway. Pour plus d’informations, consultez Exigences de réseau virtuel et de sous-réseau.

Si vous disposez d’une connectivité IP, Application Gateway peut communiquer avec des instances en dehors du réseau virtuel dans lequel il se trouve. Application Gateway peut également communiquer avec des instances extérieures à l'abonnement dans lequel il se trouve. Si vous envisagez d'utiliser des adresses IP internes en tant que membres de pool de back-ends, utilisez le Peering de réseaux virtuels ou la passerelle VPN Azure.

Comme n’importe quel programme de résolution DNS, la ressource Application Gateway respecte la valeur Durée de vie (TTL) de l’enregistrement DNS du serveur principal. Une fois la durée de vie terminée, la passerelle effectue une recherche pour mettre à jour ces informations DNS. Pendant cette recherche, si votre passerelle d’application rencontre un problème d’obtention d’une réponse (ou qu’aucun enregistrement DNS n’est trouvé), la passerelle continue d’utiliser la dernière valeur DNS connue pour servir le trafic. Pour plus d’informations, consultez Fonctionnement d’une passerelle d’application.

Les instances de votre passerelle d’application utilisent la configuration DNS du réseau virtuel pour la résolution de noms. Après avoir modifié une configuration de serveur DNS, vous devez redémarrer (Arrêter et démarrer) la passerelle d’application pour les nouveaux serveurs DNS à attribuer. Jusqu’à présent, les résolutions de noms basées sur un nom de domaine complet pour la connectivité sortante peuvent échouer.

Non. Mais vous pouvez déployer d’autres passerelles d’application dans le sous-réseau.

Vous pouvez uniquement déplacer une passerelle applicative d’un sous-réseau à un autre au sein du même réseau virtuel. Ceci est pris en charge avec v1 avec un front-end public et privé (allocation dynamique) et v2 avec un front-end public uniquement. Nous ne pouvons pas déplacer la passerelle applicative vers un autre sous-réseau si la configuration IP front-end privée est allouée statiquement. La passerelle d’application doit se trouver dans un état Arrêté pour effectuer cette action. L’arrêt ou le démarrage de v1 modifie l’adresse IP publique. Cette opération peut uniquement être effectuée à l’aide d’Azure PowerShell et d’Azure CLI en exécutant les commandes suivantes :

Azure PowerShell

$VNet = Get-AzVirtualNetwork -Name "<VNetName>" -ResourceGroupName "<ResourceGroup>"
$Subnet = Get-AzVirtualNetworkSubnetConfig -Name "<NewSubnetName>" -VirtualNetwork $VNet
$AppGw = Get-AzApplicationGateway -Name "<ApplicationGatewayName>" -ResourceGroupName "<ResourceGroup>"
Stop-AzApplicationGateway -ApplicationGateway $AppGw
$AppGw = Set-AzApplicationGatewayIPConfiguration -ApplicationGateway $AppGw -Name $AppGw.GatewayIPConfigurations.Name -Subnet $Subnet
#If you have a private frontend IP configuration, uncomment and run the next line:
#$AppGw = Set-AzApplicationGatewayFrontendIPConfig -Name $AppGw.FrontendIPConfigurations.Name[1] -Subnet $Subnet -ApplicationGateway $AppGw
Set-AzApplicationGateway -ApplicationGateway $AppGw

Pour plus d’informations, consultez Set-AzApplicationGatewayIPConfiguration.

Azure CLI

az network application-gateway stop -g <ResourceGroup> -n <ApplicationGatewayName>
az network application-gateway update -g <ResourceGroup> -n <ApplicationGatewayName> --set gatewayIpConfigurations[0].subnet.id=<subnetID>

Consultez Groupes de sécurité réseau dans le sous-réseau Application Gateway.

Consultez Les routes définies par l’utilisateur prises en charge dans le sous-réseau Application Gateway.

Non. stratégies de point de terminaison de service pour les comptes de stockage ne sont pas prises en charge dans le sous-réseau Application Gateway et la configuration qui bloque le trafic de l’infrastructure Azure.

Consultez Limites d’Application Gateway.

Oui. Application Gateway peut avoir une adresse IP interne et une adresse IP externe par passerelle d’application.

Oui. Le peering de réseaux virtuels permet d'équilibrer la charge du trafic dans d'autres réseaux virtuels.

Oui, tant que le trafic est autorisé.

L’architecture orientée microservices est prise en charge. Pour effectuer une sonde sur différents ports, vous devez configurer plusieurs paramètres back-end.

Non.

Consultez Ordre de traitement des règles.

Le champ hôte Spécifie le nom auquel envoyer la sonde lorsque vous avez configuré plusieurs sites sur Application Gateway. Sinon, utilisez 127.0.0.1. Cette valeur est différente du nom d’hôte de la machine virtuelle. Elle se présente au format <protocole>://<hôte>:<port><chemin>.

Oui. Consultez Restreindre l’accès à des adresses IP sources spécifiques.

Oui, vous pouvez utiliser des écouteurs publics et privés avec le même numéro de port pour prendre en charge simultanément les clients publics et privés. Si un groupe de sécurité réseau (NSG) est associé au sous-réseau de votre passerelle d’application, une règle de trafic entrant spécifique peut être nécessaire en fonction de sa configuration. En savoir plus.

Application Gateway v2 prend en charge les front-ends IPv4 et IPv6. Actuellement, la prise en charge IPv6 est disponible uniquement pour les nouvelles passerelles d’application. Pour prendre en charge IPv6, le réseau virtuel doit être double pile. Application Gateway v1 ne prend pas en charge les réseaux virtuels à double pile.

Les références SKU Application Gateway v1 peuvent s’exécuter dans un mode d’opération approuvé FIPS 140-2, communément appelé « mode FIPS ». Le mode FIPS appelle un module de chiffrement validé FIPS 140-2 qui garantit l’activation des algorithmes conformes à FIPS pour le chiffrement, le hachage et la signature. Pour vous assurer que le mode FIPS est activé, le paramètre FIPSMode doit être configuré via PowerShell, un modèle Azure Resource Manager ou une API REST une fois l’abonnement inscrit pour activer la configuration de FIPSmode.

Remarque : dans le cadre de la conformité FedRAMP, le gouvernement des États-Unis impose que les systèmes fonctionnent en mode approuvé par FIPS après août 2024.

Étapes d’activation du mode FIPS dans la référence SKU V1 :

Étape 1 : enregistrez la fonctionnalité « AllowApplicationGatewayEnableFIPS » pour inscrire l’abonnement à la configuration du mode FIPS.

Pour vous inscrire à l’aide d’Azure PowerShell, ouvrez une invite Cloud Shell et entrez la commande suivante :

Register-AzProviderFeature -FeatureName AllowApplicationGatewayEnableFIPS -ProviderNamespace Microsoft.Network

Pour vous inscrire à l’aide du Portail Azure :

• Connectez-vous au Portail Azure et recherchez Fonctionnalités de préversion.
• Entrez AllowApplicationGatewayEnableFIPS dans la zone de filtre. Sélectionnez Application Gateway V1 Autoriser le mode FIPS, puis sélectionnez Inscrire.

Étape 2 : définissez la propriété enableFips sur True à l’aide de PowerShell, du modèle Azure Resource Manager ou de l’API REST.

# Get the application gateway
$appgw = Get-AzApplicationGateway -Name <ApplicationGatewayName> -ResourceGroupName <ResourceGroupName>
# Set the EnableFips property
$appgw.EnableFips = $true
# Update the application gateway
Set-AzApplicationGateway -ApplicationGateway $appgw

La modification du mode FIPS n’affecte pas la disponibilité globale des suites de chiffrement sur les passerelles V1. Toutefois, lorsque vous utilisez le chiffrement à courbe elliptique pour les chiffrements, avec le mode FIPS désactivé, vous pouvez utiliser curve25519, NistP256 et NistP384, tandis qu’avec le mode FIPS activé, uniquement NistP256 et NistP384 sont autorisés et curve25519 est désactivé. Étant donné que curve25519 devient indisponible en mode FIPS, assurez-vous que vos clients prennent en charge NistP256 ou NistP384 pour la communication sécurisée avant d’activer FIPS.

Application Gateway v2 prend actuellement en charge la configuration frontale d’adresse IP privée uniquement (aucune adresse IP publique) via la préversion publique. Pour plus d’informations, consultez déploiement d’Application Gateway privé (préversion).

Pour la prise en charge générale actuelle de la disponibilité, Application Gateway v2 prend en charge les combinaisons suivantes :

• adresse IP privée et adresse IP publique
• adresse IP publique uniquement

Pour limiter le trafic uniquement aux adresses IP privées avec les fonctionnalités actuelles, procédez comme suit :

1. Créer une Application Gateway avec une adresse IP frontend publique et privée

2. Ne créez aucun écouteur pour l’adresse IP de serveur frontend public. Application Gateway n’écoute aucun trafic sur l’adresse IP publique si aucun écouteur n’est créé pour celui-ci.

3. Créez et associez un groupe de sécurité réseau pour le sous-réseau Application Gateway avec la configuration suivante dans l’ordre de priorité :

   1. Autorisez le trafic de source comme balise de service GatewayManager, de destination en tant que n’importe quelet le de port de destination 65200-65535. Cette plage de ports est nécessaire pour la communication avec l’infrastructure Azure. Ces ports sont protégés (verrouillés) par l’authentification par certificat. Les entités externes, y compris les administrateurs d’utilisateurs de la passerelle, ne peuvent pas initier de modifications sur ces points de terminaison sans que les certificats appropriés soient en place.

   2. Autorisez le trafic à partir de source comme balise de service AzureLoadBalancer et le de destination port en tant que tout.

   3. Refuser tout le trafic entrant de source comme balise de service Internet et le port de destination comme n’importe quelle. Donnez à cette règle la priorité la plus faible dans les règles de trafic entrant

   4. Conservez les règles par défaut comme AllowVNetInBound afin que l’accès sur une adresse IP privée ne soit pas bloqué.

   5. La connectivité Internet sortante ne peut pas être bloquée. Sinon, vous rencontrez des problèmes avec la journalisation et les métriques.

Exemple de configuration de groupe de sécurité réseau pour un accès d’adresse IP privée uniquement :

Vous pouvez utiliser Azure PowerShell ou Azure CLI pour arrêter et démarrer Application Gateway. Lorsque vous arrêtez et démarrez Application Gateway, la facturation s’arrête et démarre également. Toute opération PUT effectuée sur une passerelle Application Gateway arrêtée (comme l’ajout d’une balise, d’une sonde d’intégrité ou d’un écouteur) déclenche un démarrage. Nous vous recommandons d’arrêter la passerelle Application Gateway une fois la configuration mise à jour.

# Stop an existing Azure Application Gateway instance

$appGateway = Get-AzApplicationGateway -Name $appGatewayName -ResourceGroupName $resourceGroupName
Stop-AzApplicationGateway -ApplicationGateway $appGateway       

# Start an existing Azure Application Gateway instance

$appGateway = Get-AzApplicationGateway -Name $appGatewayName -ResourceGroupName $resourceGroupName
Start-AzApplicationGateway -ApplicationGateway $appGateway           

# Stop an existing Azure Application Gateway instance

az network application-gateway stop -g MyResourceGroup -n MyAppGateway

# Start an existing Azure Application Gateway instance

az network application-gateway start -g MyResourceGroup -n MyAppGateway

Application Gateway prend en charge les certificats auto-signés, les certificats d’autorité de certification (CA), les certificats de validation étendue (EV), les certificats à plusieurs domaines (SAN) et les certificats génériques.

Application Gateway prend en charge les suites de chiffrement ci-dessous :

• TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
• TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
• TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
• TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
• TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
• TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
• TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
• TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
• TLS_DHE_RSA_WITH_AES_256_CBC_SHA
• TLS_DHE_RSA_WITH_AES_128_CBC_SHA
• TLS_RSA_WITH_AES_256_GCM_SHA384
• TLS_RSA_WITH_AES_128_GCM_SHA256
• TLS_RSA_WITH_AES_256_CBC_SHA256
• TLS_RSA_WITH_AES_128_CBC_SHA256
• TLS_RSA_WITH_AES_256_CBC_SHA
• TLS_RSA_WITH_AES_128_CBC_SHA
• TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
• TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
• TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
• TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
• TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
• TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
• TLS_DHE_DSS_WITH_AES_256_CBC_SHA256
• TLS_DHE_DSS_WITH_AES_128_CBC_SHA256
• TLS_DHE_DSS_WITH_AES_256_CBC_SHA
• TLS_DHE_DSS_WITH_AES_128_CBC_SHA
• TLS_RSA_WITH_3DES_EDE_CBC_SHA
• TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA

Pour savoir comment personnaliser les options TLS, consultez Configurer les versions de stratégie TLS et les suites de chiffrement sur Application Gateway.

Oui. Application Gateway prend en charge le déchargement TLS et le protocole TLS de bout en bout, qui déchiffre le trafic vers le back-end.

Oui. Vous pouvez configurer Application Gateway pour refuser TLS1.0, TLS1.1 et TLS1.2. Par défaut, SSL 2.0 et 3.0 sont déjà désactivés et ne sont pas configurables.

Oui. Dans Application Gateway, vous pouvez configurer des suites de chiffrement. Pour définir une stratégie personnalisée, activez au moins une des suites de chiffrement suivantes :

• TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
• TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
• TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
• TLS_RSA_WITH_AES_128_GCM_SHA256
• TLS_RSA_WITH_AES_256_CBC_SHA256
• TLS_RSA_WITH_AES_128_CBC_SHA256

Application Gateway utilise SHA256 pour la gestion back-end.

Application Gateway prend en charge jusqu'à 100 certificats TLS/SSL.

Oui, Application Gateway prend en charge les certificats avec des extensions OCSP et l’agrafage OCSP pour les certificats de serveur.

Application Gateway prend en charge jusqu’à 100 certificats d’authentification.

La référence SKU v2 d’Application Gateway prend en charge Key Vault. Pour plus d'informations, consultez Arrêt de TLS avec des certificats Key Vault.

Pour un acheminement (basé sur l'hôte) sur plusieurs domaines, vous pouvez créer des écouteurs multisites, configurer des écouteurs utilisant le protocole HTTPS et associer les écouteurs aux règles d'acheminement. Pour plus d’informations, consultez Hébergement de plusieurs sites à l'aide d'Application Gateway.

Non. Utilisez uniquement des caractères alphanumériques dans votre mot de passe de fichier .pfx.

Les membres de l’autorité de certification/navigateur ont récemment publié des rapports détaillant plusieurs certificats émis par les fournisseurs d’autorité de certification utilisés par nos clients, Microsoft et la plus grande communauté technologique qui n’étaient pas conformes aux normes du secteur pour les autorités de certification approuvées publiquement. Les rapports concernant les autorités de certification non conformes sont disponibles ici :

• Bogue 1649951
• Bogue 1650910

Selon les exigences de conformité du secteur, les fournisseurs d’autorité de certification ont commencé à révoquer les autorités de certification non conformes et à émettre des autorités de certification conformes, ce qui oblige les clients à réédition de leurs certificats. Microsoft collabore étroitement avec ces fournisseurs pour réduire l’impact potentiel sur les services Azure. Toutefois, vos certificats ou certificats auto-émis utilisés dans les scénarios BYOC (Bring Your Own Certificate) sont toujours à risque d’être révoqués de manière inattendue.

Pour vérifier si les certificats utilisés par votre application ont été révoqués, consultez 'annonce de DigiCert et le suivi de révocation de certificats . Si vos certificats ont été révoqués ou sont révoqués, vous devez demander de nouveaux certificats auprès du fournisseur d’autorité de certification utilisé dans vos applications. Pour éviter que la disponibilité de votre application soit interrompue en raison d’une révocation inattendue de certificats ou pour mettre à jour un certificat qui a été révoqué, consultez Révocation des autorités de certification non conformes potentiellement impactant les services Azure du client.

Pour plus d’informations spécifiques à Application Gateway :

Si vous utilisez un certificat émis par l’une des icAs révoquées, la disponibilité de votre application peut être interrompue. Selon votre application, vous pouvez recevoir différents messages d’erreur, y compris, mais pas limités à :

• Certificat non valide/certificat révoqué
• Délai de connexion dépassé
• HTTP 502

Pour éviter toute interruption de votre application en raison de ce problème ou pour réexécuter une autorité de certification qui a été révoquée, vous devez effectuer les actions suivantes :

1. Contactez votre fournisseur de certificats pour savoir comment émettre à nouveau vos certificats.
2. Une fois qu’ils sont réécrits, mettez à jour vos certificats sur Application Gateway/WAF avec la chaîne complète de d’approbation (feuille, intermédiaire et certificat racine). En fonction de l’emplacement où vous utilisez votre certificat, soit sur l’écouteur, soit sur les paramètres HTTP de la passerelle d’application, suivez les étapes ci-dessous pour mettre à jour les certificats. Pour plus d’informations, consultez les liens de documentation mentionnés.
3. Mettez à jour vos serveurs d’applications back-end pour utiliser le certificat réémis. Selon le serveur principal que vous utilisez, les étapes de mise à jour de votre certificat peuvent varier. Recherchez la documentation de votre fournisseur.

Pour mettre à jour le certificat dans votre écouteur :

1. Dans le portail Azure, ouvrez votre ressource Application Gateway.
2. Ouvrez les paramètres de l’écouteur associés à votre certificat.
3. Sélectionnez renouveler ou modifier le certificat sélectionné.
4. Chargez votre nouveau certificat PFX avec le mot de passe et sélectionnez Enregistrer.
5. Accédez au site web et vérifiez s’il fonctionne comme prévu. Pour plus d’informations, consultez Renouveler des certificats Application Gateway.

Si vous référencez des certificats à partir de Key Vault dans votre écouteur Application Gateway, nous vous recommandons les étapes suivantes pour une modification rapide :

1. Dans le portail Azure, accédez à vos paramètres Key Vault associés à la passerelle d’application.
2. Ajoutez ou importez le certificat réédité dans votre magasin. Pour plus d’informations, consultez Démarrage rapide : Créer un coffre de clés à l’aide du portail Azure.
3. Une fois le certificat importé, accédez à vos paramètres d’écouteur Application Gateway et, sous Choisir un certificat dans key Vault, sélectionnez la liste déroulante Certificat , puis sélectionnez le certificat récemment ajouté.
4. Sélectionnez Enregistrer. Pour plus d’informations sur l’arrêt TLS sur Application Gateway avec des certificats Key Vault, consultez arrêt TLS avec des certificats Key Vault.

Pour mettre à jour le certificat dans vos paramètres HTTP :

Si vous utilisez la référence SKU v1 du service Application Gateway/WAF, vous devez charger le nouveau certificat en tant que certificat d’authentification back-end.

1. Dans le portail Azure, ouvrez votre ressource Application Gateway.
2. Ouvrez les paramètres HTTP associés à votre certificat.
3. Sélectionnez Ajouter un certificat, chargez le certificat réédition, puis sélectionnez Enregistrer.
4. Vous pouvez supprimer l’ancien certificat ultérieurement en sélectionnant le bouton ... bouton options en regard de l’ancien certificat. Sélectionnez Supprimer , puis sélectionnez Enregistrer. Pour plus d’informations, consultez Configurer le chiffrement TLS de bout en bout avec Application Gateway à partir du portail.

Si vous utilisez la référence SKU v2 du service Application Gateway/WAF, vous n’êtes pas obligé de charger le nouveau certificat dans les paramètres HTTP, car la référence SKU v2 utilise des « certificats racines approuvés » et aucune action n’est nécessaire ici.

Oui. Le routage de Couche 7 et de Couche 4 via la passerelle applicative utilise la même configuration IP front-end. Ainsi, vous pouvez diriger tous vos clients vers une adresse IP unique (publique ou privée), et la même ressource de passerelle les routera en fonction des protocoles d’écouteur configurés et des ports.

Bien que le trafic HTTP(S) puisse également être traité via des protocoles proxy L4, ceci est déconseillé. La solution proxy L7 d’Application Gateway offre un meilleur contrôle et une sécurité accrue sur les protocoles HTTP(S) grâce à des fonctionnalités avancées telles que les réécritures, l’affinité de session, la redirection, les webSockets, WAF et bien plus encore.

Les propriétés de ressources des fonctionnalités de la Couche 4 sont différentes de celles de la Couche 7. En conséquence, lors de l’utilisation de l’API REST ou de l’interface CLI, vous devez utiliser les propriétés suivantes.

• REST API
• INTERFACE DE LIGNE DE COMMANDE

Non. Vous ne pouvez pas établir de liaison croisée entre des propriétés de Couche 4 et de Couche 7. Par conséquent, une règle de routage vous permet uniquement de lier un écouteur de type Couche 4 à un paramètre back-end de type Couche 4.

Vous ne pouvez pas utiliser le même nom pour une propriété de Couche 7 (httpListeners) et de Couche 4 (listeners). Cela s’applique également à d’autres propriétés de Couche 4 telles que backendSettingsCollection et routingRules.

Absolument. Comme pour le proxy de Couche 7, vous pouvez ajouter un point de terminaison privé au pool de back-ends de votre passerelle applicative. Ce point de terminaison privé doit être déployé dans un sous-réseau adjacent du réseau virtuel de votre passerelle applicative.

Il n’utilise pas Keepalive pour les connexions back-end. Pour chaque requête entrante sur la connexion de l’écouteur front-end, Application Gateway lance une nouvelle connexion back-end pour répondre à cette requête.

Le serveur back-end voit l’adresse IP de la passerelle applicative. Actuellement, nous ne prenons pas en charge la « préservation de l’adresse IP du client », par le biais de laquelle l’application back-end peut être informée de l’adresse IP du client d’origine.

La même configuration de stratégie TLS/SSL s’applique à la Couche 7 (HTTPS) et à la Couche 4 (protocole TLS). Vous pouvez maintenant utiliser le profil SSL (pour la stratégie TLS spécifique à l’écouteur et l’authentification mutuelle) pour les écouteurs TLS. Toutefois, un profil SSL peut actuellement être associé à un écouteur TLS via l’interface de ligne de commande, PowerShell ou l’API REST uniquement.

Non. Le routage d’un client vers le même serveur back-end n’est pas pris en charge pour le moment. Les connexions seront distribuées conformément au principe du tourniquet (round robin) aux serveurs d’un pool de back-ends.

Oui, la fonctionnalité de mise à l’échelle automatique fonctionne également pour les pics et les réductions de trafic pour le protocole TLS ou TCP.

Les fonctionnalités de Web Application Firewall (WAF) ne fonctionnent pas pour l’utilisation de la Couche 4.

Non. La prise en charge d’UDP n’est pas disponible à l’heure actuelle.

La même liste de plage de ports autorisée et d’exceptions s’applique également au proxy de couche 4.

L’utilisation d’un port commun pour les écouteurs TLS/TCP n’est actuellement pas prise en charge.

Kubernetes permet de créer des ressources deployment et service pour exposer un groupe de pods en interne dans le cluster. Pour exposer le même service en externe, une Ingressressource est définie, ce qui permet l’équilibrage de charge, l’arrêt TLS et l’hébergement virtuel basé sur le nom. Pour satisfaire cette ressource Ingress, un contrôleur d’entrée est nécessaire, qui écoute les modifications apportées aux ressources Ingress et configure les stratégies d’équilibreur de charge.

Le contrôleur d’entrée Application Gateway (AGIC) permet 'application Gateway d’être utilisé comme entrée pour un Azure Kubernetes Service, également appelé cluster AKS.

La configuration directe d’Application Gateway n’est pas prise en charge.

S’il est nécessaire de modifier les paramètres sur Application Gateway, apportez la modification à l’aide de la configuration exposée sur le contrôleur d’entrée ou d’autres objets Kubernetes, par exemple à l’aide d’annotations prises en charge. Une fois qu'une passerelle d'application est reliée à un contrôleur d'entrée de passerelle d'application (AGIC), presque toute la configuration de cette passerelle sera synchronisée et contrôlée par le contrôleur d'entrée. Si vous essayez de configurer directement Application Gateway de manière impérative ou via l’infrastructure en tant que code, ces modifications seront finalement remplacées par le contrôleur d’entrée.

Actuellement, une instance d’un contrôleur d’entrée ne peut être associée qu’à une passerelle d’application.

AGIC tente d’associer automatiquement la ressource de table de routage au sous-réseau Application Gateway, mais peut échouer en raison de l’absence d’autorisations de l’AGIC. Si AGIC ne parvient pas à associer la table de routage au sous-réseau Application Gateway, une erreur s’affiche dans les journaux AGIC. Dans ce cas, vous devez associer manuellement la table de routage créée par le cluster AKS au sous-réseau d’Application Gateway. Pour plus d’informations, consultez Routes définies par l’utilisateur prises en charge.

Oui, tant que les réseaux virtuels font l’objet d’un peering et qu’ils n’ont pas d’espaces d’adressage qui se chevauchent. Si vous exécutez AKS avec kubenet, veillez à associer la table de routage générée par AKS au sous-réseau Application Gateway.

Pour connaître les différences entre AGIC déployées via Helm et déployées en tant que module complémentaire AKS, consultez Différence entre le déploiement Helm et le module complémentaire AKS.

Consultez ici les différences entre l’AGIC déployé via Helm et celui déployé en tant que module complémentaire AKS, en particulier les tables qui documentent les scénarios pris en charge par l’AGIC déployé via Helm, par opposition à un module complémentaire AKS. En général, le déploiement via Helm vous permet de tester les fonctionnalités bêta et les candidats aux versions préliminaires avant une version officielle.

Non. Le module complémentaire AGIC est un service géré, ce qui signifie que Microsoft met automatiquement à jour le module complémentaire vers la dernière version stable.

L’authentification mutuelle est une authentification à double sens entre un client et un serveur. L’authentification mutuelle avec Application Gateway permet actuellement à la passerelle de vérifier le client qui envoie la requête : c’est l’authentification du client. En général, seul le client authentifie Application Gateway. Étant donné qu’Application Gateway peut désormais également authentifier le client, il s’agit d’une authentification mutuelle : Application Gateway et le client s’authentifient mutuellement.

Non, l’authentification mutuelle n’est actuellement possible qu’entre le client frontend et Application Gateway. L’authentification mutuelle principale n’est actuellement pas prise en charge.

Application Gateway fournit trois types de journaux :

• ApplicationGatewayAccessLog : le journal d’accès contient toutes les requêtes envoyées au serveur frontal de la passerelle d’application. Les données incluent l’adresse IP de l’appelant, l’URL demandée, la latence de réponse, le code de retour, et les octets d’entrée et de sortie. Il contient un enregistrement par instance Application Gateway.
• ApplicationGatewayPerformanceLog: le journal des performances capture les informations de performances pour chaque passerelle d’application. Parmi les informations consignées figurent notamment le débit en octets, le nombre total de requêtes traitées, le nombre de requêtes ayant échoué, ainsi que le nombre d'instances de serveur principal saines ou non saines.
• ApplicationGatewayFirewallLog: pour les passerelles d’application que vous configurez avec WAF, le journal de pare-feu contient des demandes enregistrées via le mode de détection ou le mode de prévention.

Tous les journaux sont collectés toutes les 60 secondes. Pour plus d’informations, consultez 'intégrité principale, les journaux de diagnostic et les métriques pour Application Gateway.

Pour vérifier leur intégrité, utilisez la cmdlet PowerShell Get-AzApplicationGatewayBackendHealth ou le portail. Pour plus d’informations, consultez Diagnostics Application Gateway.

Les journaux de diagnostic sont envoyés au compte de stockage du client. Les clients peuvent définir la stratégie de rétention en fonction de leurs préférences. Les journaux de diagnostic peuvent également être envoyés à un Event Hub ou à des journaux d’activité Azure Monitor. Pour plus d’informations, consultez Diagnostics Application Gateway.

Dans le portail, dans le volet de menu d’une passerelle d’application, sélectionnez journal d’activité pour accéder au journal d’audit.

Oui. Dans Application Gateway, les alertes sont configurées sur les métriques. Pour plus d’informations, consultez Métriques Application Gateway et Recevoir des notifications d’alerte.

Vous pouvez afficher et analyser les journaux d’accès de plusieurs façons. Utilisez les journaux d'activité Azure Monitor, Excel, Power BI, etc.

Vous pouvez également utiliser un modèle Resource Manager qui installe et exécute le célèbre analyseur de journal d’activité GoAccess pour les journaux d’accès Application Gateway. GoAccess fournit des statistiques de trafic HTTP précieuses telles que les visiteurs uniques, les fichiers demandés, les hôtes, les systèmes d’exploitation, les navigateurs ou les codes d’état HTTP. Pour plus d’informations, consultez le fichier Lisez-moi dans le dossier de modèles Resource Manager dans GitHub.

En règle générale, vous voyez un état inconnu lorsque l’accès au serveur principal est bloqué par un groupe de sécurité réseau, un DNS personnalisé ou un routage défini par l’utilisateur sur le sous-réseau Application Gateway. Pour plus d’informations, consultez intégrité principale, journalisation des diagnostics et métriques pour Application Gateway.

En raison des limitations actuelles de la plateforme, si vous disposez d’un groupe de sécurité réseau sur le sous-réseau Application Gateway v2 (Standard_v2, WAF_v2) et si vous avez activé les journaux de flux NSG sur celui-ci, vous voyez un comportement non déterministe. Ce scénario n’est actuellement pas pris en charge.

Application Gateway ne déplace pas ou ne stocke pas les données client hors de la région dans laquelle elle est déployée.

Étapes suivantes

• Pour en savoir plus sur Application Gateway, consultez Qu’est-ce qu’Azure Application Gateway ?.
• Pour en savoir plus sur l’arrêt TLS et le protocole TLS de bout en bout avec Application Gateway, consultez Activer le protocole TLS de bout en bout sur Azure Application Gateway.