Configuration des écouteurs Application Gateway
Remarque
Nous vous recommandons d’utiliser le module Azure Az PowerShell pour interagir avec Azure. Pour commencer, 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.
Si vous souhaitez que toutes vos demandes (pour tous les domaines) soient acceptées et transmises aux pools back-end, choisissez le type « de base ». Découvrez comment créer une passerelle d’application avec un écouteur de base.
Si vous souhaitez transférer les requêtes HTTP vers différents pools principaux en fonction de l’en-tête d’hôte ou des noms d’hôte, choisissez le type d’écouteur « multisite ». 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 demandes sur le même port, vous devez spécifier un nom d’hôte qui correspond à la requête entrante. Pour en savoir plus, consultez Hébergement de plusieurs sites à l’aide d’Application Gateway.
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. 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, les écouteurs multisite sont traités avant les écouteurs de base, sauf si la priorité de la règle est définie. Si vous utilisez la priorité de règle, les écouteurs à caractères génériques doivent être définis comme prioritaires avec un nombre supérieur à celui des écouteurs non génériques, pour garantir que les écouteurs non génériques s’exécutent avant les écouteurs génériques.
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.
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.
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)
Protocol
Choisissez HTTP ou HTTPS :
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 de la passerelle Application Gateway détecte un coffre de clés mal configuré, il fait passer 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
Prise en charge d’autres protocoles
Prise en charge de HTTP2
La prise en charge du protocole HTTP/2 est disponible pour les clients se connectant aux écouteurs de passerelle d’application uniquement. 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
Vous pouvez également activer la prise en charge de HTTP2 à l’aide du portail Azure en sélectionnant Activé sous HTTP2 dans Application Gateway > Configuration.
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.