Résoudre les erreurs de passerelle incorrecte (502) dans Azure Application Gateway

Résumé

Découvrez comment résoudre les erreurs de passerelle incorrecte (502) dans Azure Application Gateway afin de pouvoir restaurer rapidement un accès fiable à vos applications web.

Note

Utilisez le module Azure Az PowerShell pour interagir avec Azure. Pour commencer, consultez Install Azure PowerShell. Pour savoir comment migrer vers le module Az PowerShell, consultez Migrate Azure PowerShell d’AzureRM vers Az.

Symptoms

Après avoir configuré un Application Gateway, vous pouvez voir l’erreur « Erreur de serveur : 502 - Le serveur web a reçu une réponse non valide alors qu’il agissait comme passerelle ou serveur proxy ». Cette erreur peut se produire pour les raisons suivantes :

Groupe de sécurité réseau, itinéraire défini par l’utilisateur ou problème DNS personnalisé

La cause

Si un groupe de sécurité réseau, un UDR ou un DNS personnalisé bloque l’accès au serveur principal, les instances de passerelle d’application ne peuvent pas atteindre le pool principal. Ce problème provoque des échecs de sonde, ce qui entraîne des erreurs 502.

Il se peut que vous ayez un NSG ou une UDR soit dans le sous-réseau de la passerelle d’application, soit dans le sous-réseau où les machines virtuelles (VM) de l’application sont déployées.

De même, la présence d’un DNS personnalisé dans le réseau virtuel (VNet) peut également entraîner des problèmes. Le serveur DNS configuré par l’utilisateur pour le réseau virtuel peut ne pas résoudre correctement un nom de domaine complet (FQDN) utilisé pour les membres du pool principal.

Solution

Validez vos configurations NSG, UDR et DNS. Pour ce faire, procédez comme suit :

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

  2. Vérifiez l’UDR associé au sous-réseau de passerelle d’application. Vérifiez que l’UDR ne dirige pas le trafic hors du sous-réseau principal. Par exemple, vérifiez s’il existe un routage vers des appliances réseau virtuelles ou des routes par défaut annoncées au sous-réseau de la passerelle Application Gateway à l’aide d’Azure ExpressRoute ou d’Azure VPN. Exécutez les commandes suivantes dans Azure PowerShell.

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

  3. Vérifiez les groupes de sécurité réseau (NSG) et les routes appliqués pour la machine virtuelle du back-end. Exécutez les commandes suivantes dans Azure PowerShell.

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

  4. Recherchez la présence de DNS personnalisé dans le réseau virtuel. Vérifiez DNS 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. S’il est présent, assurez-vous que le serveur DNS peut résoudre correctement le FQDN du membre du pool backend.

La sonde d’intégrité par défaut ne peut pas atteindre les machines virtuelles principales

La cause

Une erreur 502 peut également indiquer que la sonde d’intégrité par défaut ne peut pas atteindre les machines virtuelles principales.

Lorsque vous provisionnez une instance de passerelle d’application, elle configure automatiquement une sonde d’intégrité par défaut pour chaque BackendAddressPool en utilisant les propriétés de BackendHttpSetting.

Vous n’avez pas besoin de fournir d’entrée pour définir cette sonde. Plus précisément, lorsque vous configurez une règle d’équilibrage de charge, vous associez un BackendHttpSetting à un BackendAddressPool. Chacune de ces associations est associée à une sonde par défaut, et la passerelle d’application Application Gateway lance une connexion périodique de vérification d’intégrité vers chaque instance du BackendAddressPool sur le 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 Descriptif
URL de sonde http://127.0.0.1/ Chemin d’URL
Intervalle 30 Intervalle de sonde en secondes
Délai d’attente 30 Délai d’expiration de la sonde en secondes
Seuil de défaillance sur le plan de l’intégrité 3 Nombre de réessais de sonde Le serveur back-end est marqué comme étant indisponible lorsque le nombre d'échecs consécutifs atteint le seuil critique.

Solution

Utilisez les conseils suivants pour résoudre les problèmes de sonde d’intégrité par défaut.

  • La valeur hôte de la requête est définie sur 127.0.0.1. Vérifiez qu’un site par défaut est configuré et écoute à 127.0.0.1.
  • Le BackendHttpSetting protocole détermine le protocole de la requête.
  • Le chemin d’accès de l’URI est défini sur /*.
  • Si BackendHttpSetting spécifie un port autre que 80, configurez le site par défaut pour écouter sur ce port.
  • L'appel à protocol://127.0.0.1:port doit retourner un code de statut HTTP de 200. Ce code doit être retourné au cours de la période d’expiration 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 ce port.
  • Si vous utilisez Azure machines virtuelles classiques ou service cloud avec un nom de domaine complet ou une adresse IP publique, assurez-vous d’ouvrir le endpoint correspondant.
  • Si vous configurez la machine virtuelle à l'aide de Azure Resource Manager (ARM) et qu'elle se trouve en dehors du réseau virtuel où la passerelle d'application est déployée, configurez un groupe de sécurité réseau pour autoriser l'accès sur le port souhaité.

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

Configuration non valide ou incorrecte des sondes d’intégrité personnalisées

La cause

Les sondes de santé personnalisées vous offrent plus de flexibilité que le comportement de détection par défaut. Lorsque vous utilisez des sondes personnalisées, vous pouvez définir l’intervalle de la sonde, l’URL, le chemin d’accès à tester et le nombre de réponses ayant échoué avant de marquer l’instance du pool principal comme non saine.

Le tableau suivant décrit les propriétés supplémentaires que vous pouvez définir.

Propriétés de la sonde Descriptif
Nom Nom de la sonde. Utilisez ce nom pour faire référence à la sonde dans les paramètres HTTP principaux.
Protocole Protocole utilisé pour envoyer la sonde. La sonde utilise le protocole défini dans les paramètres HTTP principaux.
Host Nom d’hôte auquel envoyer la sonde. Ce nom d’hôte est différent du nom d’hôte de la machine virtuelle. Dans la référence SKU v1, Application Gateway utilise cette valeur uniquement comme en-tête hôte de la requête de sonde. Dans le SKU v2, la valeur est utilisée à la fois comme en-tête Host et comme valeur SNI (Server Name Indication).
Chemin Chemin relatif de la sonde. Le chemin d’accès valide commence à partir de « / ». La sonde est envoyée au <protocole> ://<host> :<port><path>.
Intervalle Intervalle d’analyse en secondes. Cette valeur définit l’intervalle de temps entre deux sondes consécutives.
Délai d’attente Délai d’expiration de la sonde en secondes. Si une réponse valide n’est pas reçue dans ce délai d’attente, la sonde est marquée comme ayant échoué.
Seuil de défaillance sur le plan de l’intégrité Nombre de réessais de sonde Le serveur back-end est marqué comme étant indisponible lorsque le nombre d'échecs consécutifs atteint le seuil critique.

Solution

Vérifiez que vous avez correctement configuré la sonde d’intégrité personnalisée, comme indiqué dans le tableau précédent. Outre les conseils de dépannage précédents, suivez également ces instructions.

  • Vérifiez que vous spécifiez la sonde correctement conformément au guide.
  • Si vous configurez la passerelle Application Gateway pour un site unique, spécifiez 127.0.0.1 comme nom d’hôte par défaut, sauf si vous le configurez autrement dans la sonde personnalisée.
  • Vérifiez qu’un appel à http://<host>:<port><path> renvoie un code de résultat HTTP de 200.
  • Vérifiez que Intervalles valeurs et UnhealthyThreshold les Timeoutvaleurs se trouvent dans les plages acceptables.
  • Si vous utilisez une sonde HTTPS dans la référence SKU v2, Application Gateway envoie également le nom d’hôte de la sonde comme valeur SNI. Assurez-vous que le nom d’hôte correspond au nom d’autre objet du certificat principal (SAN) ou à son nom commun (CN) si le certificat n’a pas de SAN, comme décrit dans RFC 6125. Application Gateway n’envoie pas SNI lorsque le nom d’hôte est une adresse IP, y compris la valeur par défaut 127.0.0.1. Pour connaître les étapes à suivre pour comparer le nom d’hôte de la sonde au certificat, consultez Résolution F dans Résoudre les erreurs HTTP 502 dans Azure Application Gateway. Si vous ne pouvez pas modifier le certificat principal, ajustez les paramètres de validation HTTPS back-end pour utiliser une valeur SNI spécifique ou ignorer la validation du nom de l’objet.

Le délai d’attente de la requête du backend est dépassé

La cause

Lorsque la passerelle d’application reçoit une demande d’utilisateur, elle applique les règles configurées à la requête et l’achemine vers une instance de pool principal. Il attend un intervalle de temps configurable pour une réponse de l’instance 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 principale dans cet intervalle, la demande de l’utilisateur obtient 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 par rapport à un deuxième membre du pool principal. Si la deuxième demande échoue également, la requête utilisateur obtient une erreur 504 à la place. Si les utilisateurs reçoivent des erreurs 504 au lieu de 502 erreurs, consultez Résoudre les erreurs HTTP 504 dans Azure Application Gateway.

Si votre application back-end prend régulièrement plus de temps que l’intervalle configuré pour répondre (par exemple, une requête ou un rapport de longue durée), augmentez le délai d’expiration de la requête sur le paramètre HTTP principal utilisé par ce pool principal.

Solution

Le délai d’expiration de la requête est une propriété du paramètre HTTP du back-end. Les différents pools principaux peuvent donc avoir des valeurs de délai d’attente de requête différentes. Augmentez-le en utilisant le portail Azure, Azure CLI ou Azure PowerShell. La plage acceptée est de 1 à 86400 secondes. Pour plus d’informations, consultez Délai d’expiration de la demande.

Portail Azure

Suivez ces étapes :

  1. Dans le portail Azure, accédez à votre passerelle d’application.
  2. Sous Paramètres, sélectionnez Paramètres principaux.
  3. Sélectionnez le paramètre de back-end utilisé par le pool principal concerné.
  4. Augmentez la valeur du délai d’expiration de la requête (secondes) pour permettre au serveur principal de répondre plus longtemps.
  5. Cliquez sur Enregistrer.

Azure CLI

Exécutez la commande suivante dans Azure CLI :

az network application-gateway http-settings update \
  --gateway-name <application-gateway-name> \
  --resource-group <resource-group-name> \
  --name <backend-http-settings-name> \
  --timeout <time-out-in-seconds>

Azure PowerShell

Exécutez la commande suivante dans Azure PowerShell :

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

Note

L’augmentation du délai d’attente de la requête masque uniquement le symptôme si le back-end est lent en raison d’un problème sous-jacent, tel que la forte sollicitation du processeur ou de la mémoire, la contention de base de données ou une requête inefficace. Vérifiez également le temps de réponse de l’application back-end avant d’augmenter la valeur du délai d’expiration.

Le pool principal d’Application Gateway n’est pas configuré ou est vide

La cause

Si la passerelle d’application n’a pas de machines virtuelles ni de groupe de machines virtuelles identiques configurées dans le pool d’adresses back-end, elle ne peut pas acheminer de demande client et envoie une erreur de passerelle défectueuse.

Solution

Vérifiez que le pool d’adresses backend n’est pas vide. Vous pouvez vérifier cette condition via Azure PowerShell, Azure CLI ou le portail. Consultez l’exemple suivant pour vérifier le pool d’adresses back-end via Azure PowerShell.

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

La sortie de l’applet de commande précédente doit contenir un pool d'adresses back-end non vide. L’exemple suivant montre deux pools retournés configurés avec un nom de domaine complet ou des adresses IP pour les machines virtuelles principales. L’état d’approvisionnement du BackendAddressPool fichier doit être Succeeded.

[{
    "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 saines dans BackendAddressPool

La cause

Si toutes les instances de BackendAddressPool sont défaillantes, la passerelle d’application n’a pas de back-end pour acheminer les requêtes des utilisateurs. Cette condition peut également se produire lorsque les instances back-end sont saines, mais que l’application requise n’est pas déployée.

Solution

Vérifiez que les instances sont saines et que l’application est correctement configurée. Vérifiez si les instances back-end peuvent répondre à un test ping à partir d’une autre machine virtuelle dans le même réseau virtuel. Si vous configurez un point de terminaison public, vérifiez qu’une demande de navigateur à l’application web est serviceable.

Le certificat SSL en amont ne correspond pas

La cause

Le certificat TLS (Transport Layer Security) installé sur les serveurs principaux ne correspond pas au nom d’hôte reçu dans l’en-tête de requête de l’hôte HTTP.

Dans les scénarios où TLS de bout en bout est activé, obtenez la configuration en modifiant les paramètres HTTP principaux appropriés. Remplacez la configuration du paramètre de protocole back-end par HTTPS si nécessaire. Vérifiez que le DNS NAME du certificat TLS installé sur les serveurs back-end correspond au nom d’hôte transmis au back-end dans l’en-tête Host de la requête HTTP.

Lorsque vous effectuez cette étape, la deuxième partie de la communication qui se produit avec Application Gateway et les serveurs principaux est chiffrée avec TLS.

Par défaut, Application Gateway envoie le même en-tête d’hôte HTTP au back-end qu’il reçoit du client. Vérifiez que le certificat TLS installé sur le serveur back-end comporte un DNS NAME correspondant au nom d’hôte reçu par ce serveur back-end dans l’en-tête Host HTTP. Ce nom d’hôte doit être identique à celui reçu du client.

Solution

Pour connaître les étapes permettant d'aligner le nom d'hôte de la sonde et SNI avec le san ou le cn du certificat, consultez Résolution F dans Résoudre les erreurs HTTP 502 dans Azure Application Gateway. Pour savoir comment les paramètres principaux choisir le nom d’hôte à partir de la cible du serveur principal et remplacer par un nom de domaine spécifique correspondent au nom du certificat attendu par Application Gateway, voir Le nom commun (CN) ne correspond pas.

  • Last updated on