Configuration des écouteurs Application Gateway

Remarque

Nous vous recommandons d’utiliser le module Azure Az PowerShell pour interagir avec Azure. Pour bien démarrer, consultez Installer Azure PowerShell. Pour savoir comment migrer vers le module Az PowerShell, consultez Migrer Azure PowerShell depuis AzureRM vers Az.

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. Lorsque vous configurez l’écouteur, vous devez saisir pour ces paramètres des valeurs qui correspondent aux valeurs correspondantes de 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 écouteur, vous choisissez entre le type de base et le type multisite. Le choix dépend de la question de savoir si le routage dépend du nom de l’hôte dans la requête entrante.

Le routage dépend du nom de l’hôte	Type d’écouteur	Behavior
Non	Basique	Accepter et transférer toutes les requêtes de n’importe quel domaine vers les pools backend. Découvrez comment créer une passerelle d’application avec un écouteur de base.
Yes	Multi-sites	Transférez les requêtes vers différents pools principaux en fonction de l’en-tête hôte ou des noms d’hôte. Application Gateway se base sur des en-têtes d’hôte HTTP 1.1 pour héberger plusieurs sites web sur les mêmes adresses IP et port. Pour différencier les requêtes sur le même port, vous devez spécifier un nom d’hôte correspondant à la requête entrante.

Pour en savoir plus sur les auditeurs multi-sites, voir l’hébergement de plusieurs sites via Application Gateway.

Ordre de traitement des écouteurs

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. Si une règle avec un écouteur de base arrive en premier dans l’ordre, elle traite en premier et accepte toute demande pour cette combinaison port et IP. Pour éviter ce comportement, configurez d’abord les règles avec des écouteurs multi-sites, puis reléguez en dernière position dans la liste la règle avec l’écouteur de base.

Pour la référence SKU v2, la priorité de règle définit l’ordre dans lequel les écouteurs sont traités. Définissez les écouteurs génériques et de base avec un numéro de priorité supérieur à ceux des écouteurs spécifiques au site et multisites. Cette configuration garantit que les écouteurs spécifiques au site et multi-sites s’exécutent avant les écouteurs génériques et de base.

Le tableau suivant résume comment l’ordre de traitement est déterminé dans chaque SKU.

Référence (SKU)	Qu’est-ce qui détermine l’ordre	Configuration recommandée
v1	L’ordre des règles et le type d’auditeur. Si une règle avec un listener de base occupe la première place, elle est traitée en premier et accepte toutes les demandes pour ce port et cette combinaison d’adresses IP.	Configurez d’abord les règles avec des auditeurs multi-sites, puis poussez la règle avec l’auditeur de base à la dernière position de la liste.
v2	Priorité de la règle.	Définir les listeners génériques et de base avec un numéro de priorité supérieur à celui des listeners propres au site et multi-sites, afin que les listeners propres au site et multi-sites s’exécutent en premier.

Frontend IP address (Adresse IP frontale)

Choisissez l’adresse IP front-end que vous prévoyez d’associer à cet écouteur. L’auditeur écoute les requêtes entrantes sur cette IP.

Choisissez une adresse IP publique de frontend lorsque les clients atteignent l’application derrière cet écouteur via Internet. Choisissez une adresse IP frontale privée pour un point de terminaison interne qui n’est pas exposé à Internet, comme une application métier interne ou un niveau d’une application multiniveau qui nécessite néanmoins une répartition de charge, une persistance de session ou encore une terminaison TLS. Pour les combinaisons prises en charge, voir Configuration des adresses IP frontend.

Remarque

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

Port front-end

Associez un port front-end. Vous pouvez sélectionner un port existant ou en créer 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. Le même port peut être utilisé pour les écouteurs publics et privés.

Le port 80 est le choix typique pour un écouteur HTTP, et le port 443 est le choix typique pour un écouteur HTTPS. Utilisez un port personnalisé lorsque votre application en a besoin, et confirmez que la valeur se situe dans la plage autorisée pour votre SKU, car la plage prise en charge diffère entre les SKU v1 et v2.

Remarque

Lors de l’utilisation d’écouteurs privés et publics avec le même numéro de port, votre passerelle applicative remplace la « destination » du flux de trafic entrant par les adresses IP front-end de votre passerelle. Ainsi, en fonction de la configuration de votre groupe de sécurité réseau, vous aurez peut-être besoin d’une règle de trafic entrant avec des adresses IP de destination en tant qu’adresses IP front-end publiques et privées de votre passerelle applicative.

Règle de trafic entrant :

• Source : (selon vos besoins)
• Adresses IP de destination : adresses IP front-end publiques et privées de votre passerelle applicative.
• Port de destination : (en fonction de la configuration de l’écouteur)
• Protocole : TCP

Règle de trafic sortant : (aucun besoin spécifique)

Protocole

Choisissez HTTP ou HTTPS. Choisissez HTTPS lorsque le trafic entre le client et la passerelle d’application doit être chiffré, ce qui permet également à la passerelle de décharger le chiffrement et le déchiffrement afin que vos serveurs backend ne soient pas surchargés par la surcharge de calcul TLS. Choisissez HTTP lorsque ce chiffrement n’est pas nécessaire pour le trafic que cet écouteur accepte.

• Si vous choisissez HTTP, le trafic entre le client et la passerelle d’application est non chiffré.

• Sélectionnez HTTPS si vous voulez un arrêt TLS ou un chiffrement TLS de bout en bout. Le trafic entre le client et la passerelle Application Gateway est chiffré et la connexion TLS se termine au niveau de la passerelle d’application. Si vous souhaitez un chiffrement TLS de bout en bout pour la cible back-end, vous devez également choisir HTTPS dans le paramètre HTTP du back-end . Cela garantit que le trafic est chiffré lorsque la passerelle d’application initie une connexion à la cible back-end.

Pour configurer une terminaison TLS, un certificat TLS/SSL doit être ajouté à l’écouteur. Cela permet à la passerelle Application Gateway de déchiffrer le trafic entrant et de chiffrer le trafic de réponse au client. Le certificat fourni à l’Application Gateway doit être au format PFX (Personal Information Exchange) qui contient les clés privées et publiques.

Remarque

Lorsque vous utilisez un certificat TLS de Key Vault pour un écouteur, vous devez vous assurer que votre Application Gateway a toujours accès à cette ressource de coffre de clés liée et à l’objet de certificat qu’il contient. Cela permet des opérations homogènes de la fonctionnalité de terminaison TLS tout en gérant l’intégrité globale de votre ressource de passerelle. Si une ressource Application Gateway détecte un coffre de clés mal configuré, elle place automatiquement les écouteurs HTTPS associés à l'état désactivé. Plus d’informations

Certificats pris en charge

Voir Vue d’ensemble de la terminaison TLS et du TLS de bout en bout avec Application Gateway.

Support de protocoles supplémentaires

Assistance HTTP/2

Application Gateway prend en charge le protocole HTTP/2 pour les clients qui se connectent aux écouteurs d’Application Gateway. La communication avec les pools de serveurs backend utilise toujours HTTP/1.1. Par défaut, la prise en charge du protocole HTTP/2 est désactivée. Le extrait de code Azure PowerShell suivant montre comment activer ce support :

$gw = Get-AzApplicationGateway -Name test -ResourceGroupName hm

$gw.EnableHttp2 = $true

Set-AzApplicationGateway -ApplicationGateway $gw

Important

Lorsque vous créez une ressource de passerelle d’application via le portail Azure, l’option par défaut pour HTTP2 est activée. Vous pouvez choisir Désactivé lors de la création, et réactiver le support HTTP/2 en sélectionnant Activé sous HTTP2 dans Configuration de la passerelle > d’application sur le portail Azure.

Dans les cas où un client ne supporte pas HTTP/2, la connexion utilise HTTP/1.1. Activer HTTP/2 ne désactive pas HTTP/1.1 ; cela permet de prendre en charge les deux.

Remarque

Application Gateway prend uniquement en charge HTTP/2 sur TLS (écouteurs HTTPS). Application Gateway ne prend pas en charge les tentatives de mise à jour du protocole HTTP/2 Cleartext (h2c) depuis HTTP/1.1 et renvoie une erreur 403 Forbidden. Les clients qui tentent des mises à jour H2C doivent utiliser des connexions HTTP/2 natives via HTTPS ou rester sur HTTP/1.1.

Prise en charge de HTTP/3 (QUIC)

Important

Le support HTTP/3 dans Azure Application Gateway est actuellement en aperçu. Dans la préversion, les fonctionnalités, la disponibilité et d’autres aspects de cette fonctionnalité peuvent changer en réponse aux commentaires.

Cette préversion est fournie sans contrat de niveau de service et n’est pas recommandée pour les charges de travail de production. Certaines fonctionnalités peuvent ne pas être prises en charge ou avoir des fonctionnalités limitées.

Pour plus d’informations, consultez Conditions d'utilisation supplémentaires pour les versions préliminaires de Microsoft Azure.

Application Gateway ne prend en charge HTTP/3 que pour les connexions clients utilisant des écouteurs Basic. Un auditeur compatible HTTP/3 peut également accepter le trafic HTTP/1.1 ou HTTP/2 des clients. La communication depuis la passerelle d’application vers les pools de serveurs backend continue d’utiliser HTTP/1.1.

Le support HTTP/3 est désactivé par défaut.

Comment le support HTTP/3 est-il annoncé

Application Gateway annonce le support HTTP/3 en utilisant l’en-tête de réponse HTTP Alt-Svc. Lorsque vous activez HTTP/3 sur un écouteur, Application Gateway inclut l’en-tête Alt-Svc suivant dans les réponses.

Alt-Svc: h3=":<listener-port>"; ma=86400

Lorsque vous désactivez HTTP/3, Application Gateway n’inclut pas l’en-tête Alt-Svc.

Les clients supportant HTTP/3 peuvent utiliser le service annoncé pour établir une connexion QUIC sur le port d’écoute. Les clients qui ne supportent pas HTTP/3 continuent d’utiliser HTTP/2 ou HTTP/1.1 sur TCP.

Prise en charge de WebSocket

La prise en charge de WebSocket est activée par défaut. Il n’existe aucun paramètre configurable par l’utilisateur pour l’activer ou la désactiver. Vous pouvez utiliser des WebSockets avec des écouteurs HTTP et HTTPS.

Pages d’erreur personnalisées

Vous pouvez définir des pages d’erreur personnalisées pour différents codes de réponse que la passerelle d’application renvoie. Vous pouvez configurer des pages d’erreur pour les codes de réponse 400, 403, 405, 408, 500, 502, 503 et 504. Utilisez une configuration de page d’erreur au niveau global ou spécifique à un listener afin de les définir de façon granulaire pour chaque listener. Pour plus d’informations, consultez Créer des pages d’erreur personnalisées Application Gateway.

Remarque

Application Gateway transmet une erreur du serveur backend au client sans la modifier.

Stratégie de protocole TLS

Vous pouvez centraliser la gestion des certificats TLS/SSL et réduire la surcharge de chiffrement-déchiffrement d’une batterie de serveurs back-end. La gestion centralisée du TLS permet également de spécifier une politique TLS centrale adaptée à vos besoins de sécurité. Vous pouvez choisir une politique TLS prédéfinie ou personnalisée .

Vous configurez la politique TLS pour contrôler les versions du protocole TLS. Vous pouvez configurer une passerelle d’application pour utiliser une version minimale du protocole pour les handshakes TLS à partir de TLS 1.0, TLS 1.1, TLS 1.2 et TLS 1.3. Par défaut, SSL 2.0 et 3.0 sont désactivés et ne sont pas configurables. Pour plus d’informations, consultez Vue d’ensemble de la stratégie TLS Application Gateway.

Après avoir créé un écouteur, vous l’associez à une règle de routage des demandes. Cette règle détermine comment les requêtes reçues par l’auditeur sont acheminées vers le back-end.

Étapes suivantes

• Découvrir les règles de routage des requêtes.