Share via

Résolution des erreurs de passerelle incorrecte dans Application Gateway

  • Article

Découvrez comment résoudre les erreurs de passerelle incorrecte (502) reçues lors de l’utilisation d’Azure 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.

Vue d’ensemble

Après avoir configuré une passerelle Application Gateway, vous pouvez rencontrer l’erreur Erreur serveur 502 : Le serveur Web a reçu une réponse erronée lors de son utilisation en tant que passerelle ou serveur proxy. Cette erreur peut se produire pour les raisons suivantes :

Problème de groupe de sécurité réseau, de routage défini par l’utilisateur ou de DNS personnalisé

Cause

si l’accès au serveur principal est bloqué à cause d’un groupe de sécurité réseau, d’un itinéraire défini par l’utilisateur ou d’un DNS personnalisé, les instances de la passerelle d’application ne peuvent pas atteindre le pool principal. Ce problème provoque des échecs de sondes, à l’origine des erreurs 502.

Le groupe de sécurité réseau/l’itinéraire défini par l’utilisateur peut être présent dans le sous-réseau de la passerelle d’application ou dans le sous-réseau sur lequel les machines virtuelles d’application sont déployées.

De même, la présence d’un DNS personnalisé dans le réseau virtuel peut également entraîner des problèmes. Il se peut qu’un nom de domaine complet utilisé pour les membres du pool principal ne résolve pas tout, selon le serveur DNS configuré par l’utilisateur pour le réseau virtuel.

Solution

Validez la configuration du groupe de sécurité réseau, du routage défini par l’utilisateur et du DNS en effectuant les étapes suivantes :

  1. Vérifiez les groupes de sécurité réseau associés au sous-réseau de la passerelle d’application. Assurez-vous que la communication vers le serveur principal n’est pas bloquée. Pour plus d’informations, consultez Groupes de sécurité réseau.

  2. Vérifiez l’itinéraire défini par l’utilisateur associé au sous-réseau de la passerelle d’application. Assurez-vous que l’itinéraire défini par l’utilisateur ne détourne pas le trafic du sous-réseau principal. Vérifiez par exemple le routage vers les appliances virtuelles du réseau ou les itinéraires par défaut annoncés sur le sous-réseau de la passerelle d’application via ExpressRoute/VPN.

    $vnet = Get-AzVirtualNetwork -Name vnetName -ResourceGroupName rgName
Get-AzVirtualNetworkSubnetConfig -Name appGwSubnet -VirtualNetwork $vnet

  3. Vérifiez le groupe de sécurité réseau et le routage vers la machine virtuelle du serveur principal.

    Get-AzEffectiveNetworkSecurityGroup -NetworkInterfaceName nic1 -ResourceGroupName testrg
Get-AzEffectiveRouteTable -NetworkInterfaceName nic1 -ResourceGroupName testrg

  4. Vérifiez la présence d’un DNS personnalisé dans le réseau virtuel. Le DNS peut être vérifié en examinant les détails des propriétés du réseau virtuel dans la sortie.

    Get-AzVirtualNetwork -Name vnetName -ResourceGroupName rgName 
DhcpOptions            : {
                           "DnsServers": [
                             "x.x.x.x"
                           ]
                         }

  5. Le cas échéant, vérifiez que le serveur DNS peut résoudre correctement le nom de domaine complet du membre du pool principal.

Problèmes avec la sonde d’intégrité par défaut

Cause

Les erreurs 502 peuvent également indiquer que la sonde d’intégrité par défaut ne peut pas atteindre les machines virtuelles du serveur back-end.

Lorsqu’une instance de passerelle d’application est approvisionnée, elle configure automatiquement une sonde d’intégrité par défaut pour chaque BackendAddressPool à l’aide des propriétés de BackendHttpSetting. La configuration de cette sonde d’intégrité ne nécessite aucune action de la part de l’utilisateur. Plus précisément, lorsqu’une règle d’équilibrage de charge est configurée, une association est établie entre BackendHttpSetting et BackendAddressPool. Un contrôle par défaut est configuré pour chacune de ces associations et une passerelle d’application démarre régulièrement une connexion de contrôle d’intégrité à chaque instance dans le BackendAddressPool au niveau du port spécifié dans l’élément BackendHttpSetting.

Le tableau suivant répertorie les valeurs associées à la sonde d’intégrité par défaut :

Propriétés de la sonde Valeur Description
URL de sonde http://127.0.0.1/ Chemin d'accès de l'URL
Intervalle 30 Intervalle d’analyse en secondes
Délai d’attente 30 Délai d’expiration de l’analyse en secondes
Seuil de défaillance sur le plan de l’intégrité 3 Nombre de tentatives d’analyse Le serveur back-end est marqué comme étant défectueux lorsque le nombre d’échecs consécutifs a atteint le seuil de défaillance.

Solution

  • La valeur d’hôte de la requête sera définie sur 127.0.0.1. Assurez-vous qu’un site par défaut est configuré et qu’il écoute sur le port 127.0.0.1.
  • Le protocole de la requête est déterminé par le protocole BackendHttpSetting.
  • Le chemin d’accès de l’URI sera défini sur /.
  • Si BackendHttpSetting spécifie un port autre que 80, le site par défaut doit être configuré pour écouter sur ce port.
  • L’appel à protocol://127.0.0.1:port doit renvoyer un code de résultat HTTP 200. Ce code doit être renvoyé dans un délai de 30 secondes.
  • Vérifiez que le port configuré est ouvert et qu’aucune règle de pare-feu ou aucun groupe de sécurité réseau Azure ne bloque le trafic entrant ou sortant sur le port configuré.
  • Si vous utilisez des machines virtuelles Azure classiques ou un service cloud avec un nom de domaine complet ou une adresse IP publique, assurez-vous que le point de terminaison correspondant est ouvert.
  • Si la machine virtuelle est configurée via Azure Resource Manager et se trouve en dehors du réseau virtuel dans lequel est déployée la passerelle d’application, un groupe de sécurité réseau doit être configuré pour autoriser l’accès sur le port souhaité.

Pour plus d’informations, consultez Configuration de l’infrastructure Application Gateway.

Problèmes avec la sonde d’intégrité personnalisée

Cause

Les sondes d’intégrité personnalisées apportent davantage de flexibilité au comportement de contrôle par défaut. Lorsque vous utilisez des sondes personnalisées, vous pouvez configurer l’intervalle de sondage, l’URL, le chemin à tester et le nombre de réponses en échec autorisé avant que l’instance de pool de back-ends soit marquée comme étant défectueuse.

Les propriétés supplémentaires suivantes sont ajoutées :

Propriétés de la sonde Description
Nom Nom de la sonde. Ce nom est utilisé pour désigner la sonde dans les paramètres HTTP du serveur back-end.
Protocol Protocole utilisé pour envoyer la sonde. La sonde utilise le protocole défini dans les paramètres HTTP du serveur back-end
Hôte Nom d’hôte pour l’envoi de la sonde. S’applique uniquement lorsque plusieurs sites sont configurés sur la passerelle d’application. Ce nom est différent du nom d’hôte de la machine virtuelle.
Path Chemin relatif de la sonde. Le chemin valide commence par « / ». La sonde est envoyée à <protocole>://<hôte>:<port><chemin d’accès>
Intervalle Intervalle d’analyse en secondes. Il s’agit de l’intervalle de temps qui s’écoule entre deux analyses consécutives.
Délai d’attente Délai d’expiration de l’analyse en secondes. Si aucune réponse valide n’est reçue dans le délai imparti, la sonde est marquée comme étant en échec.
Seuil de défaillance sur le plan de l’intégrité Nombre de tentatives d’analyse Le serveur back-end est marqué comme étant défectueux lorsque le nombre d’échecs consécutifs a atteint le seuil de défaillance.

Solution

Vérifiez que la sonde d’intégrité personnalisée est correctement configurée comme montré dans la table précédente. Outre les étapes de dépannage précédentes, vérifiez également les points suivants :

  • Assurez-vous que la sonde est correctement spécifiée suivant les indications du guide.
  • Si la passerelle d’application est configurée pour un seul site, le nom d’hôte par défaut doit être spécifié sous la forme 127.0.0.1, sauf s’il est configuré d’une autre manière dans la probe personnalisée.
  • Assurez-vous qu’un appel à http://<hôte>:<port><chemin d’accès> retourne un code de résultat HTTP 200.
  • Assurez-vous que les paramètres Interval, Time-out et UnhealtyThreshold se trouvent dans la plage acceptable.
  • Si vous utilisez une sonde HTTPS, vérifiez que le serveur back-end ne nécessite pas SNI en configurant un certificat de secours sur le serveur back-end lui-même.

Délai d’attente de la demande

Cause

À réception d’une demande utilisateur, la passerelle d’application applique les règles configurées à la demande, et route cette demande vers une instance de pool de back-ends. Application Gateway observe un temps d’attente (configurable) pour recevoir une réponse de l’instance de serveur back-end. Par défaut, cet intervalle est de 20 secondes. Dans Application Gateway v1, si la passerelle d’application ne reçoit pas de réponse de l’application back-end dans cet intervalle, la demande utilisateur recevra une erreur 502. Dans Application Gateway v2, si la passerelle d’application ne reçoit pas de réponse de l’application back-end dans cet intervalle, la demande est tentée sur un deuxième membre du pool de back-ends. Si la deuxième requête échoue, la demande de l’utilisateur reçoit une erreur 504.

Solution

Application Gateway vous permet de configurer ce paramètre via BackendHttpSetting, pour l’appliquer ensuite à différents pools. Les pools de back-ends peuvent avoir des paramètres BackendHttpSetting différents et des délais d’attente divers.

    New-AzApplicationGatewayBackendHttpSettings -Name 'Setting01' -Port 80 -Protocol Http -CookieBasedAffinity Enabled -RequestTimeout 60

Pool d’adresses principal vide

Cause

Si la passerelle d’application ne dispose d’aucune machine virtuelle ou d’aucun groupe de machines virtuelles identiques configurés dans le pool d’adresses back-end, elle ne pourra pas router les demandes client et enverra alors une erreur de passerelle incorrecte.

Solution

Vérifiez que le pool d’adresses back-end n’est pas vide. Vous pouvez pour cela utiliser PowerShell, l’interface de ligne de commande ou le portail.

Get-AzApplicationGateway -Name "SampleGateway" -ResourceGroupName "ExampleResourceGroup"

La sortie du cmdlet de commande ci-dessus doit contenir un pool d’adresses back-end non vide. L’exemple suivant illustre le renvoi de deux pools configurés avec un nom de domaine complet ou des adresses IP pour les machines virtuelles du serveur principal. L’approvisionnement de BackendAddressPool doit se trouver à l’état « Succeeded » (Réussi).

BackendAddressPoolsText :

[{
    "BackendAddresses": [{
        "ipAddress": "10.0.0.10",
        "ipAddress": "10.0.0.11"
    }],
    "BackendIpConfigurations": [],
    "ProvisioningState": "Succeeded",
    "Name": "Pool01",
    "Etag": "W/\"00000000-0000-0000-0000-000000000000\"",
    "Id": "/subscriptions/<subscription id>/resourceGroups/<resource group name>/providers/Microsoft.Network/applicationGateways/<application gateway name>/backendAddressPools/pool01"
}, {
    "BackendAddresses": [{
        "Fqdn": "xyx.cloudapp.net",
        "Fqdn": "abc.cloudapp.net"
    }],
    "BackendIpConfigurations": [],
    "ProvisioningState": "Succeeded",
    "Name": "Pool02",
    "Etag": "W/\"00000000-0000-0000-0000-000000000000\"",
    "Id": "/subscriptions/<subscription id>/resourceGroups/<resource group name>/providers/Microsoft.Network/applicationGateways/<application gateway name>/backendAddressPools/pool02"
}]

Instances non intègres dans BackendAddressPool

Cause

Si aucune des instances de BackendAddressPool n’est saine, la passerelle d’application ne dispose d’aucun serveur back-end vers lequel router la demande utilisateur. Cette situation peut également se produire lorsque les instances de serveurs back-end sont saines, mais que l’application nécessaire n’est pas déployée.

Solution

Assurez-vous que les instances sont intègres et que l’application est correctement configurée. Vérifiez si les instances de serveurs back-end peuvent répondre à une commande ping générée par une autre machine virtuelle résidant dans le même réseau virtuel. Si vous utilisez un point de terminaison public, assurez-vous qu’une requête de navigateur à l’application web est accessible.

Le certificat SSL en amont ne correspond pas

Cause

Le certificat TLS installé sur les serveurs principaux ne correspond pas au nom d’hôte reçu dans l’en-tête de demande de l’hôte.

Dans les scénarios où le TLS de bout en bout est activé, une configuration obtenue en modifiant les « paramètres du serveur principal HTTP » appropriés et en modifiant la configuration du paramètre « Protocole back-end » sur HTTPS, il est indispensable de s’assurer que le CNAME du certificat TLS installé sur les serveurs principaux correspond au nom d’hôte entrant dans le serveur principal dans la demande d’en-tête d’hôte HTTP.

Pour rappel, l’effet de l’activation sur les « paramètres du serveur principal HTTP » de l’option de protocole HTTPS plutôt que HTTP est que la deuxième partie de la communication qui se produit entre les instances d’Application Gateway et les serveurs principaux sera chiffrée avec TLS.

En raison du fait que par défaut, Application Gateway envoie le même en-tête d’hôte HTTP au serveur principal que celui qu’il reçoit du client, vous devez vous assurer que le certificat TLS installé sur le serveur principal est émis avec un CNAME qui correspond au nom d’hôte reçu par ce serveur principal dans l’en-tête de l’hôte HTTP. N’oubliez pas que, sauf indication contraire, ce nom d’hôte est identique à celui reçu du client.

Par exemple :

Imaginez que vous disposez d’une passerelle Application Gateway pour traiter les requêtes https du domaine www.contoso.com. Vous pouvez avoir le domaine contoso.com délégué à une zone publique Azure DNS et un enregistrement DNS dans cette zone pointant www.contoso.com vers l’adresse IP publique de la passerelle Application Gateway spécifique qui va traiter les requêtes.

Sur cette passerelle Application Gateway, vous devez disposer d’un écouteur pour l’hôte www.contoso.com, avec une règle qui force les « paramètres du serveur principal HTTP » à utiliser le protocole HTTPS (garantissant le protocole TLS de bout en bout). Cette même règle peut avoir configuré un pool principal avec deux machines virtuelles exécutant IIS en tant que serveurs web.

Comme nous savons, l'activation de HTTPS dans les « paramètres du serveur principal HTTP » de la règle fera en sorte que la deuxième partie de la communication entre les instances de la passerelle Application Gateway et les serveurs principaux utilise TLS.

Si les serveurs principaux n’ont pas de certificat TLS émis pour le CNAME www.contoso.com ou *.contoso.com, la requête échoue avec Erreur du serveur : 502 : le serveur Web a reçu une réponse erronée lors de son utilisation en tant que passerelle ou serveur proxy., car le certificat SSL en amont (le certificat installé sur les serveurs principaux) ne correspond pas au nom d’hôte dans l’en-tête de l’hôte, et par conséquent, la négociation TLS échouera.

www.contoso.com --> IP front-end APP GW --> Écouteur avec une règle qui configure « Paramètres du serveur principal HTTP » pour utiliser le protocole HTTPS plutôt que HTTP --> Pool principal --> Serveur web (doit avoir un certificat TLS installé pour www.contoso.com)

Solution

Il est nécessaire que le CNAME du certificat TLS installé sur le serveur principal corresponde au nom d’hôte configuré dans les paramètres du serveur principal HTTP, sinon la deuxième partie de la communication de bout en bout qui se produit entre les instances de la passerelle Application Gateway et le serveur principal échoue avec un message « Le certificat SSL en amont ne correspond pas » et renvoie une erreur de serveur : 502 : le serveur Web a reçu une réponse erronée lors de son utilisation en tant que passerelle ou serveur proxy.

Étapes suivantes

Si les étapes précédentes ne vous permettent pas de résoudre le problème, ouvrez un ticket d’incident.