Remarque
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.
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. 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
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 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. Pour éviter cela, configurez d’abord les règles avec des écouteurs multisites et poussez la règle avec l’écouteur de base vers la dernière position de liste.
Pour la référence SKU v2, la priorité de règle définit l’ordre dans lequel les écouteurs sont traités. Les écouteurs génériques (wildcard) et de base doivent se voir attribuer une priorité avec un numéro supérieur à celui des écouteurs spécifiques à un site et multisites, afin de garantir que ces derniers 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’écouteur écoute les demandes entrantes sur cette adresse 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 front-end : 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 Présentation de la terminaison TLS et du chiffrement TLS de bout en bout avec Application Gateway
Support de protocoles supplémentaires
Prise en charge de "HTTP/2"
La prise en charge du protocole HTTP/2 est disponible uniquement pour les clients se connectant aux points d'écoute de la passerelle d’application. La communication avec les pools de serveurs back-end est toujours HTTP/1.1. Par défaut, la prise en charge du protocole HTTP/2 est désactivée. L’extrait de code Azure PowerShell suivant montre comment activer cette prise en charge :
$gw = Get-AzApplicationGateway -Name test -ResourceGroupName hm
$gw.EnableHttp2 = $true
Set-AzApplicationGateway -ApplicationGateway $gw
Important
Lors de la création d’une ressource de passerelle d’application via le portail Azure, l’option par défaut pour HTTP2 est définie comme activée. Vous pouvez choisir Désactivé pendant la création et réactiver la prise en charge de HTTP2 à l’aide du portail Azure en sélectionnant Activé sous HTTP2 dans La configuration d’Application Gateway>.
Dans les cas où HTTP2 n’est pas pris en charge par un client, HTTP1.1 sera utilisé. L’activation de HTTP2 ne désactive pas HTTP1.1 ; il permet la prise en charge des deux.
Remarque
Application Gateway prend uniquement en charge HTTP/2 sur TLS (écouteurs HTTPS). Les tentatives de mise à niveau du protocole HTTP/2 Cleartext (h2c) à partir de HTTP/1.1 ne sont pas prises en charge et entraînent une erreur 403 Interdit. Les clients qui tentent de mettre à niveau h2c doivent utiliser des connexions HTTP/2 natives via HTTPS ou rester sur HTTP/1.1.
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 retournés par Application Gateway. Les codes de réponse pour lesquels vous pouvez configurer les pages d’erreur sont 400, 403, 405, 408, 500, 502, 503 et 504. Vous pouvez utiliser la configuration des pages d’erreur à un niveau global ou spécifique à l’écouteur pour les définir de manière précise pour chaque écouteur. Pour plus d’informations, consultez Créer des pages d’erreur personnalisées Application Gateway.
Remarque
Une erreur provenant du serveur back-end est passée non modifiée par Application Gateway au client.
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. Cette gestion TLS centralisée permet également de spécifier une stratégie TLS centrale adaptée à vos besoins de sécurité. Vous pouvez choisir une stratégie TLS prédéfinie ou personnalisée.
Vous configurez la stratégie TLS pour contrôler les versions du protocole TLS. Vous pouvez configurer une passerelle d’application afin qu’elle utilise une version de protocole minimale pour les négociations 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 la manière dont les demandes reçues sur l’écouteur sont routées vers le back-end.