Solucionar erros de gateway inválido (502) no Gateway de Aplicativo do Azure

Resumo

Saiba como solucionar erros de gateway inválido (502) no Gateway de Aplicativo do Azure para que você possa restaurar rapidamente o acesso confiável aos seus aplicativos Web.

Symptoms

Depois de configurar um gateway de aplicativo, você poderá ver o erro Erro do servidor: 502 – o servidor Web recebeu uma resposta inválida enquanto atuava como um gateway ou servidor proxy. Esse erro pode ocorrer pelos seguintes motivos:

• NSG (grupo de segurança de rede), UDR (rota definida pelo usuário) ou problema de DNS personalizado.
• A sondagem de integridade padrão não consegue acessar VMs de back-end.
• Tempo limite de solicitação ou problemas de conectividade com solicitações do usuário.
• O backend pool do Application Gateway não está configurado ou está vazio.
• Instâncias não saudáveis em BackendAddressPool.
• O certificado SSL upstream não corresponde.

Grupo de segurança de rede, rota definida pelo usuário ou problema de DNS personalizado

Motivo

Se um NSG, UDR ou DNS personalizado bloquear o acesso ao back-end, as instâncias do gateway de aplicativo não poderão acessar o pool de back-end. Esse problema causa falhas de investigação, resultando em 502 erros.

O NSG/UDR pode estar presente na sub-rede do gateway de aplicativo ou na sub-rede em que as VMs do aplicativo são implantadas.

Da mesma forma, a presença de um DNS personalizado na VNet também pode causar problemas. Um FQDN usado para membros do pool de back-end pode não ser resolvido corretamente pelo servidor DNS configurado pelo usuário para a VNet.

Solução

Valide a configuração de NSG, UDR e DNS seguindo as seguintes etapas:

1. Verifique os NSGs associados à sub-rede do gateway de aplicativo. Verifique se a comunicação com o back-end não está bloqueada. Para saber mais, confira Grupos de segurança de rede.

2. Verifique a UDR associada à sub-rede do gateway de aplicativo. Verifique se a UDR não está direcionando o tráfego para longe da sub-rede de back-end. Por exemplo, verifique se há roteamento para dispositivos virtuais de rede ou rotas padrão que estão sendo anunciadas para a sub-rede do gateway de aplicativo por meio do ExpressRoute/VPN.

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

3. Verifique o NSG efetivo e a rota com a VM de back-end.

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

4. Verifique a presença de DNS personalizado na VNet. Verifique o DNS examinando os detalhes das propriedades da VNet na saída.

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

5. Se estiver presente, verifique se o servidor DNS pode resolver o FQDN do membro do pool de back-end corretamente.

A sonda de integridade padrão não consegue alcançar as VMs de back-end

Motivo

502 erros também podem indicar que a sonda de integridade padrão não consegue alcançar as VMs de back-end.

Quando você provisiona uma instância de gateway de aplicativo, ela configura automaticamente uma investigação de integridade padrão para cada BackendAddressPool usando propriedades do BackendHttpSetting. Você não precisa fornecer nenhuma entrada para configurar esta sonda. Especificamente, quando você configura uma regra de balanceamento de carga, associa um BackendHttpSetting a um BackendAddressPool. Cada uma dessas associações tem uma sonda padrão configurada, e o gateway de aplicação realiza verificações de integridade periódicas para cada instância no BackendAddressPool, conforme especificado na porta do elemento BackendHttpSetting.

A tabela a seguir lista os valores associados à investigação de integridade padrão:

Solução

• O valor do host da solicitação é definido como 127.0.0.1. Verifique se um site padrão está configurado e se está ouvindo em 127.0.0.1.
• O protocolo BackendHttpSetting determina o protocolo da solicitação.
• O caminho do URI está definido como /*.
• Se BackendHttpSetting especificar uma porta diferente de 80, configure o site padrão para escutar nessa porta.
• A chamada para protocol://127.0.0.1:port deve retornar um código de resultado HTTP de 200. Esse código deve ser retornado dentro do período de tempo limite de 30 segundos.
• Verifique se a porta configurada está aberta e não há regras de firewall ou Grupos de Segurança de Rede do Azure bloqueando o tráfego de entrada e saída na porta configurada.
• Se você utilizar VMs clássicos do Azure ou Serviço de Nuvem com um FQDN ou um IP público, certifique-se de abrir o endpoint correspondente.
• Se você configurar a VM por meio de Azure Resource Manager e ela estiver fora da VNet em que o gateway de aplicativo está implantado, você deverá configurar um grupo de segurança Network para permitir o acesso na porta desejada.

Confira mais informações em Configuração da infraestrutura do Gateway de Aplicativo.

Configuração inválida ou inadequada de sondas de integridade personalizadas

Motivo

Sondas de saúde personalizadas oferecem mais flexibilidade do que o comportamento de sondagem padrão. Ao usar investigações personalizadas, você pode definir o intervalo de investigação, a URL, o caminho a ser testado e quantas respostas com falha aceitar antes de marcar a instância do pool de back-end como não saudável.

A tabela a seguir descreve as propriedades adicionais que você pode definir:

Solução

Valide se você configurou a investigação de integridade personalizada corretamente, conforme mostrado na tabela anterior. Além das etapas de solução de problemas anteriores, verifique também as seguintes etapas:

• Especifique a sonda corretamente de acordo com o guia.
• Se você configurar o gateway de aplicação para um único site, especifique o nome do Host padrão como 127.0.0.1, a menos que você o configure de maneira diferente na sondagem personalizada.
• Verifique se uma chamada para http://<host>:<port><path> retorne um código de resultado HTTP de 200.
• Verifique se os valores Interval, Timeout e UnhealthyThreshold estão dentro dos intervalos aceitáveis.
• Se você usar uma sonda HTTPS, certifique-se de que o servidor backend não requer SNI configurando um certificado de fallback no próprio servidor backend.

Problemas de tempo limite ou de conectividade com solicitações do usuário

Motivo

Quando o gateway de aplicativo recebe uma solicitação de usuário, ele aplica as regras configuradas à solicitação e roteia-a para uma instância do pool de back-end. Ele aguarda um intervalo de tempo configurável para uma resposta da instância de back-end. Por padrão, esse intervalo é de 20 segundos. No Gateway de Aplicativo v1, se o gateway de aplicativo não receber uma resposta do aplicativo de back-end nesse intervalo, a solicitação do usuário receberá um erro 502. No Gateway de Aplicativo v2, se o gateway de aplicativo não receber uma resposta do aplicativo de back-end nesse intervalo, a solicitação será tentada em relação a um segundo membro do pool de back-end. Se a segunda solicitação falhar, a solicitação do usuário receberá um erro 504.

Solução

Você pode definir essa configuração por meio do BackendHttpSetting, que pode ser aplicado a pools diferentes. Pools de back-end diferentes podem ter diferentes configurações de BackendHttpSetting e diferentes configurações de tempo limite de solicitação.

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

O backend pool do Application Gateway não está configurado ou está vazio

Motivo

Se o gateway de aplicativo não tiver VMs ou conjunto de escalonamento de máquinas virtuais configurado no pool de endereços de back-end, ele não poderá rotear nenhuma solicitação do cliente e enviará um erro de gateway inválido.

Solução

Verifique se o pool de endereços de back-end não está vazio. Você pode verificar essa condição por meio do PowerShell, da CLI ou do portal.

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

A saída do cmdlet anterior deve conter um pool de endereços de backend não vazio. O exemplo a seguir mostra dois pools retornados que estão configurados com um FQDN ou endereços IP para as VMs de backend. O estado de provisionamento do BackendAddressPool deve ser Succeeded.

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"
}]

Instâncias não saudáveis no BackendAddressPool

Motivo

Se todas as instâncias de BackendAddressPool estiverem com problemas, o gateway de aplicativo não terá nenhum back-end para onde encaminhar as solicitações dos usuários. Essa condição também pode ocorrer quando as instâncias de back-end estão íntegras, mas não têm o aplicativo necessário implantado.

Solução

Verifique se as instâncias estão íntegras e se o aplicativo está configurado corretamente. Verifique se as instâncias de back-end podem responder a um ping de outra VM na mesma rede virtual. Se você configurar um ponto de extremidade público, garanta que uma solicitação de navegador para o aplicativo web possa ser atendida.

O certificado SSL upstream não corresponde

Motivo

O certificado TLS instalado em servidores de back-end não corresponde ao nome do host recebido no cabeçalho da solicitação do host.

Em cenários em que o TLS de ponta a ponta está habilitado, uma configuração que é obtida editando as "Configurações HTTP de Backend" apropriadas e alterando a configuração do "Protocolo de backend" para HTTPS, é obrigatório garantir que o NOME DNS do certificado TLS instalado nos servidores de backend corresponda ao nome do host que chega ao backend na solicitação do cabeçalho HTTP.

Como lembrete, o efeito de habilitar nas "Configurações HTTP de Back-end" a opção do protocolo HTTPS em vez de HTTP é que a segunda parte da comunicação que ocorre entre as instâncias do Gateway de Aplicativo e os servidores de back-end é criptografada com TLS.

Devido ao fato de que, por padrão, o Gateway de Aplicativo envia o mesmo cabeçalho de host HTTP para o back-end que recebe do cliente, você precisa garantir que o certificado TLS instalado no servidor de back-end seja emitido com um NOME DNS que corresponda ao nome do host recebido pelo servidor de back-end no cabeçalho do host HTTP. Lembre-se de que, a menos que especificado de outra forma, esse nome de host seria o mesmo que o recebido do cliente.

Por exemplo:

Imagine que você tenha um Gateway de Aplicativo para atender às solicitações https para o domínio www.contoso.com. Você pode ter o domínio contoso.com delegado a uma Zona Pública DNS do Azure e um registro DNS A nessa zona apontando www.contoso.com para o IP público do Gateway de Aplicações específico que responderá às solicitações.

Nesse Gateway de Aplicações, você deve ter um listener para o host www.contoso.com com uma regra que tenha a "Configuração HTTP de Back-End" configurada para usar o protocolo HTTPS (garantindo TLS de ponta a ponta). Essa mesma regra poderia ter configurado um pool de back-end com duas VMs executando o IIS como servidores Web.

Como sabemos, habilitar HTTPS na "Configuração de HTTP em Back-end" da regra faz com que a segunda parte da comunicação entre as instâncias do Gateway de Aplicativo e os servidores no back-end utilize TLS.

Se os servidores de back-end não tiverem um certificado TLS emitido para o NOME www.contoso.com DNS ou *.contoso.com, a solicitação falhará com o Erro do Servidor: 502 – o servidor Web recebeu uma resposta inválida ao agir como um gateway ou servidor proxy porque o certificado SSL upstream (o certificado instalado nos servidores de back-end) não corresponde ao nome do host no cabeçalho do host, e, portanto, a negociação do TLS falha.

www.contoso.com --> IP de front-end do Gateway de Aplicativos --> Listener com uma regra que configura "Configurações HTTP de back-end" para usar o protocolo HTTPS em vez de HTTP --> Pool de back-end --> servidor Web (precisa ter um certificado TLS instalado para www.contoso.com)

Solução

É necessário que o NOME DNS do certificado TLS instalado no servidor de back-end corresponda ao nome do host configurado nas configurações de back-end HTTP. Caso contrário, a segunda parte da comunicação de ponta a ponta que ocorre entre as instâncias do Application Gateway e o back-end falha com "O certificado SSL upstream não corresponde" e retorna um erro do servidor: 502 – O servidor Web recebeu uma resposta inválida enquanto atuava como um gateway ou servidor proxy