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 ao agir 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 (Sistema de Nomes de Domínio) personalizado
• A sonda de integridade padrão não consegue acessar as VMs de back-end
• O tempo limite da solicitação de back-end é excedido
• O pool de back-end do gateway de aplicativo não está configurado ou está vazio
• Instâncias não saudáveis no 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.

Você pode ter um NSG ou UDR na sub-rede do gateway de aplicativo ou na sub-rede em que as VMs (máquinas virtuais) do aplicativo são implantadas.

Da mesma forma, a presença de um DNS personalizado na rede virtual (VNet) também pode causar problemas. O servidor DNS configurado pelo usuário para a VNet pode não resolver corretamente um FQDN (nome de domínio totalmente qualificado) usado para membros do pool de back-end.

Solução

Valide suas configurações de NSG, UDR e DNS. Para fazer isso, siga estas 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 anunciadas para a sub-rede do gateway de aplicativos usando o Azure ExpressRoute ou a Azure VPN. Execute os comandos a seguir no Azure PowerShell.

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

3. Verifique os NSGs e as rotas efetivas da VM de back-end. Execute os comandos a seguir no Azure PowerShell.

   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

Um erro 502 também pode indicar que a investigação de integridade padrão não pode alcançar VMs de back-end.

Quando você provisiona uma instância do gateway de aplicativo, ela configura automaticamente uma sonda 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 uma BackendHttpSetting a uma BackendAddressPool. Cada uma dessas associações tem uma sonda padrão configurada, e o Gateway de Aplicativo inicia uma conexão periódica de verificação de integridade com cada instância no BackendAddressPool, na porta especificada no elemento BackendHttpSetting.

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

Solução

Use as orientações a seguir para solucionar problemas da sonda de integridade padrã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 BackendHttpSetting protocolo 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 Azure NSGs bloqueando o tráfego de entrada ou 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 usando Azure Resource Manager (ARM) e ela estiver fora da VNet em que o gateway de aplicativo é implantado, configure um NSG 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 diretrizes de solução de problemas anteriores, siga estas diretrizes também.

• Especifique a sonda corretamente de acordo com o guia.
• Se você configurar o gateway de aplicativo para um único site, especifique o nome de host padrão como 127.0.0.1, a menos que isso esteja configurado de outra forma na sonda personalizada.
• Verifique se uma chamada para http://<host>:<port><path> retorne um código de resultado HTTP de 200.
• Verifique se Interval, Timeoute UnhealthyThreshold os valores estão dentro dos intervalos aceitáveis.
• Se você usar uma sonda HTTPS no SKU v2, o Application Gateway também envia o nome do host da sonda como o valor de SNI. Verifique se o nome do host corresponde ao SAN (nome alternativo da entidade) do certificado de back-end ou ao seu nome comum (CN) se o certificado não tiver SAN, conforme descrito no RFC 6125. O Gateway de Aplicativo não envia SNI quando o nome do host é um endereço IP, incluindo o padrão 127.0.0.1. Para ver as etapas para comparar o nome do host da sonda com o certificado, consulte Resolução F em Solucionar problemas de erros HTTP 502 no Gateway de Aplicativo do Azure. Se você não puder alterar o certificado do back-end, ajuste as configurações de validação HTTPS do back-end para usar um valor de SNI específico ou ignorar a validação do nome do assunto.

O tempo limite da solicitação do back-end foi excedido

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 dentro desse intervalo, a solicitação do usuário receberá um erro 502. No Application Gateway v2, se o gateway de aplicativo não receber uma resposta do aplicativo de back-end dentro desse período, a solicitação será enviada a um segundo membro do pool de back-end. Se a segunda solicitação também falhar, a solicitação do usuário receberá um erro 504. Se os usuários receberem 504 erros em vez de 502 erros, consulte Solucionar problemas de erros HTTP 504 em Gateway de Aplicativo do Azure.

Se o aplicativo de back-end levar rotineiramente mais tempo do que o intervalo configurado para responder (por exemplo, uma consulta ou relatório de execução longa), aumente o tempo limite de solicitação na configuração HTTP de back-end usada por esse pool de back-end.

Solução

O tempo limite da solicitação é uma propriedade da configuração HTTP de back-end, portanto, pools de back-end diferentes podem ter valores de tempo limite de solicitação diferentes. Aumente-o usando o portal Azure, CLI do Azure ou Azure PowerShell. O intervalo aceito é de 1 a 86400 segundos. Para obter mais informações, consulte o tempo limite da solicitação.

portal do Azure

Siga estas etapas:

1. No portal do Azure, acesse o gateway de aplicativo.
2. Em Configurações, selecione Configurações de back-end.
3. Selecione a configuração de back-end usada pelo pool de back-end afetado.
4. Aumente o valor de tempo limite de solicitação (segundos) para permitir mais tempo para o back-end responder.
5. Selecione Salvar.

CLI do Azure

Execute o seguinte comando na CLI do Azure:

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

Execute o seguinte comando no Azure PowerShell:

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

O pool de back-end do gateway de aplicativo 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 de Azure PowerShell, CLI do Azure ou no portal. Confira o exemplo a seguir para verificar o pool de endereços de back-end por Azure PowerShell.

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.

[{
    "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 (Transport Layer Security) instalado em servidores de back-end não corresponde ao nome do host recebido no cabeçalho da solicitação de host HTTP.

Em cenários em que o TLS de ponta a ponta está habilitado, faça a configuração editando as definições apropriadas de HTTP de back-end. Altere a configuração da opção protocolo de backend para HTTPS, quando necessário. Verifique se o DNS NAME do certificado TLS instalado nos servidores de back-end corresponde ao nome do host recebido pelo back-end no cabeçalho Host da solicitação HTTP.

Quando você conclui essa etapa, a segunda parte da comunicação que acontece com o Gateway de Aplicativo e os servidores de back-end é criptografada com TLS.

Por padrão, o Application Gateway envia ao back-end o mesmo cabeçalho de host HTTP que recebe do cliente. Verifique se o certificado TLS instalado no servidor de back-end é emitido com um DNS NAME que corresponda ao nome do host recebido pelo servidor de back-end no cabeçalho do host HTTP. Esse nome de host deve ser o mesmo recebido do cliente.

Solução

Para obter as etapas para alinhar o nome do host da investigação e o SNI com o SAN ou CN do certificado, consulte a Resolução F em Solucionar problemas de erros HTTP 502 no Gateway de Aplicativo do Azure. Para saber como as configurações de back-end Escolher o nome do host do destino de back-end e Substituir por um nome de domínio específico são mapeadas para o nome do certificado que o Application Gateway espera, consulte O Nome Comum (CN) não corresponde.