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.

Symptoms

Une fois que vous avez configuré une passerelle d’application, vous pouvez voir l'erreur du serveur : 502 - Le serveur web a reçu une réponse non valide lorsqu'il agissait en tant que passerelle ou serveur proxy. Cette erreur peut se produire pour les raisons suivantes :

• Groupe de sécurité réseau (NSG), itinéraire défini par l’utilisateur (UDR) ou problème DNS personnalisé.
• La sonde d’intégrité par défaut ne peut pas atteindre les machines virtuelles principales.
• Problèmes de délai d’attente ou de connectivité des demandes des utilisateurs.
• Le pool principal d’Application Gateway n’est pas configuré ou vide.
• Instances non saines dans BackendAddressPool.
• Le certificat SSL en amont ne correspond pas.

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.

Le NSG/UDR peut être présent soit dans le sous-réseau de passerelle d'application, soit dans le sous-réseau où sont déployées les machines virtuelles d'application.

De même, la présence d’un DNS personnalisé dans le réseau virtuel peut également entraîner des problèmes. Un nom de domaine complet utilisé pour les membres du pool de backend peut ne pas être résolu correctement par le serveur DNS configuré par l'utilisateur pour le réseau virtuel.

Solution

Validez la configuration du NSG, de l'UDR (Route définie par l'utilisateur) et du DNS en suivant les étapes suivantes :

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 le routage vers des appliances virtuelles réseau ou des itinéraires par défaut publiés vers 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 NSG et l'itinéraire effectifs avec la VM backend.

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

4. Vérifiez 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

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

Lorsque vous approvisionnez une instance de passerelle d’application, elle configure automatiquement une sonde d’intégrité par défaut pour chaque BackendAddressPool à l’aide des 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 a une sonde par défaut configurée et la passerelle d’application démarre une connexion de contrôle d’intégrité périodique à 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 :

Solution

• 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 protocole BackendHttpSetting 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 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’il n’existe aucune règle de pare-feu ni Azure groupes de sécurité réseau bloquant le trafic entrant ou sortant sur le port configuré.
• 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 via Azure Resource Manager et qu'elle se trouve en dehors du réseau virtuel où la passerelle d'application est déployée, vous devez configurer un groupe de sécurité Network Security Group 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 :

Solution

Vérifiez que vous avez correctement configuré la sonde d’intégrité personnalisée, comme indiqué dans le tableau précédent. En plus des étapes de résolution des problèmes précédentes, vérifiez également les étapes suivantes :

• Vérifiez que vous spécifiez la sonde correctement conformément au guide.
• Si vous configurez la passerelle d’application pour un site unique, spécifiez le nom d’hôte par défaut comme 127.0.0.1, à moins de l'avoir configuré 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 les valeurs Interval, Timeout et UnhealthyThreshold se trouvent dans les plages acceptables.
• Si vous utilisez une sonde HTTPS, assurez-vous que le serveur principal n’a pas besoin de SNI en configurant un certificat de secours sur le serveur principal lui-même.

Problèmes de délai d’attente ou de connectivité des demandes utilisateur

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, la requête utilisateur obtient une erreur 504.

Solution

Vous pouvez configurer ce paramètre via backendHttpSetting, que vous pouvez appliquer à différents pools. Différents pools principaux peuvent avoir différentes configurations BackendHttpSetting et différents paramètres de délai d’expiration des requêtes.

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

Le pool principal d’Application Gateway n’est pas configuré ou 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 PowerShell, l’interface CLI ou le portail.

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 doit être Succeeded.

TexteDesPoolsD'AdressesDeBackend :

[{
    "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 installé sur les serveurs principaux ne correspond pas au nom d’hôte reçu dans l’en-tête de demande d’hôte.

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

Pour rappel, l’effet de l’activation sur les « paramètres HTTP principaux » de l’option HTTPS de protocole plutôt que HTTP est que la deuxième partie de la communication qui se produit entre les instances de La passerelle Application Gateway et les serveurs principaux sont chiffrées 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 qu’il reçoit du client, vous devez vous assurer que le certificat TLS installé sur le serveur principal, est émis avec un NOM DNS 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 serait identique à celui reçu du client.

Par exemple:

Imaginez que vous disposez d’une passerelle Application Gateway pour traiter les requêtes https pour le domaine www.contoso.com. Vous pouvez avoir le domaine contoso.com délégué à une zone publique Azure DNS et un enregistrement DNS A 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 a le « paramètre HTTP backend » forcé à utiliser le protocole HTTPS (garantissant un chiffrement 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 le savons, activer HTTPS dans le « paramètre HTTP des services principaux » de la règle fait que la deuxième partie de la communication qui se produit entre les instances de l'Application Gateway et les serveurs dans le back-end utilise TLS.

Si les serveurs principaux n’ont pas de certificat TLS émis pour le NOM www.contoso.com DNS ou *.contoso.com, la requête échoue avec l’erreur du serveur : 502 - Le serveur web a reçu une réponse non valide 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 échoue.

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

Solution

Il est nécessaire que le NOM DNS du certificat TLS installé sur le serveur principal, correspond au nom d’hôte configuré dans les paramètres du back-end 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 « Le certificat SSL en amont ne correspond pas » et lève une erreur de serveur : 502 - Le serveur web a reçu une réponse non valide tout en agissant en tant que passerelle ou serveur proxy