Resolução de problemas de erros de gateway incorreto no Gateway de Aplicação

Saiba como solucionar erros de gateway incorreto (502) recebidos ao usar o Gateway de Aplicativo do Azure.

Descrição geral

Depois de configurar um gateway de aplicativo, um dos erros que você pode ver é Erro de servidor: 502 - O servidor Web recebeu uma resposta inválida enquanto atuava como um gateway ou servidor proxy. Este erro pode acontecer pelas seguintes razões principais:

• NSG, UDR ou DNS personalizado está bloqueando o acesso aos membros do pool de back-end.
• As VMs de back-end ou instâncias do conjunto de dimensionamento de máquina virtual não estão respondendo à investigação de integridade padrão.
• Configuração inválida ou incorreta das pesquisas do estado de funcionamento personalizadas.
• O pool de back-end do Azure Application Gateway não está configurado ou vazio.
• Nenhuma das VMs ou instâncias no conjunto de dimensionamento de máquina virtual está íntegra.
• Tempo limite do pedido excedido ou problemas de conectividade com os pedidos do utilizador.

Grupo de Segurança de Rede, Rota Definida pelo Usuário ou Problema de DNS Personalizado

Causa

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

O NSG/UDR pode estar presente na sub-rede do gateway de aplicativo ou na sub-rede onde 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 rede virtual.

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. Certifique-se de que a comunicação com o back-end não esteja bloqueada. Para obter mais informações, consulte Grupos de segurança de rede.

2. Verifique UDR associado à sub-rede do gateway de aplicativo. Certifique-se de que o UDR não está direcionando o tráfego para fora 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 via ExpressRoute/VPN.

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

3. Verifique o NSG efetivo e roteie 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 rede virtual. O DNS pode ser verificado observando 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 corretamente o FQDN do membro do pool de back-ends.

Problemas com a sonda de integridade padrão

Causa

Os erros 502 também podem ser indicadores frequentes de que o teste de integridade padrão não pode alcançar VMs de back-end.

Quando uma instância de gateway de aplicativo é provisionada, ela configura automaticamente uma investigação de integridade padrão para cada BackendAddressPool usando propriedades de BackendHttpSetting. Nenhuma entrada do usuário é necessária para definir essa sonda. Especificamente, quando uma regra de balanceamento de carga é configurada, uma associação é feita entre um BackendHttpSetting e um BackendAddressPool. Um teste padrão é configurado para cada uma dessas associações e o gateway de aplicativo inicia uma conexão periódica de verificação de integridade para cada instância no BackendAddressPool na porta especificada no elemento BackendHttpSetting.

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

Solução

• O valor do host da solicitação será definido como 127.0.0.1. Verifique se um site padrão está configurado e escutando em 127.0.0.1.
• O protocolo da solicitação é determinado pelo protocolo BackendHttpSetting.
• O caminho do URI será definido como /.
• Se BackendHttpSetting especificar uma porta diferente de 80, o site padrão deverá ser configurado 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 se não há regras de firewall ou Grupos de Segurança de Rede do Azure bloqueando o tráfego de entrada ou de saída na porta configurada.
• Se as VMs clássicas do Azure ou o Serviço de Nuvem forem usados com um FQDN ou um IP público, verifique se o ponto de extremidade correspondente está aberto.
• Se a VM estiver configurada por meio do Gerenciador de Recursos do Azure e estiver fora da VNet onde o gateway de aplicativo é implantado, um Grupo de Segurança de Rede deverá ser configurado para permitir o acesso na porta desejada.

Para obter mais informações, consulte Configuração da infraestrutura do Application Gateway.

Problemas com a sonda de integridade personalizada

Causa

As sondas de integridade personalizadas permitem flexibilidade adicional ao comportamento de sondagem padrão. Ao usar testes personalizados, você pode configurar o intervalo de teste, a URL, o caminho para testar e quantas respostas com falha aceitar antes de marcar a instância do pool de back-end como não íntegra.

As seguintes propriedades adicionais são adicionadas:

Solução

Valide se a Sonda de Integridade Personalizada está configurada corretamente, conforme mostrado na tabela anterior. Além das etapas de solução de problemas anteriores, verifique também o seguinte:

• Certifique-se de que a sonda está especificada corretamente de acordo com o guia.
• Se o gateway de aplicativo estiver configurado para um único site, por padrão, o nome do host deverá ser especificado como 127.0.0.1, a menos que configurado de outra forma na sonda personalizada.
• Certifique-se de que uma chamada para o caminho> http://< host>:<port><retorne um código de resultado HTTP de 200.
• Verifique se Interval, Timeout e UnhealthyThreshold estão dentro dos intervalos aceitáveis.
• Se estiver usando uma sonda HTTPS, certifique-se de que o servidor back-end não exija SNI configurando um certificado de fallback no próprio servidor back-end.

Tempo limite do pedido

Causa

Quando recebe um pedido do utilizador, o gateway de aplicação aplica as regras configuradas ao pedido e encaminha-o para uma instância de conjunto de back-end. Este aguarda um intervalo de tempo configurável para obter uma resposta da instância de back-end. Por padrão, esse intervalo é de 20 segundos. No Gateway de Aplicação v1, se o gateway de aplicação não receber uma resposta da aplicação de back-end neste intervalo, o pedido do utilizador receberá um erro 502. No Gateway de Aplicação v2, se o gateway de aplicação não receber uma resposta da aplicação back-end neste intervalo, o pedido será tentado contra um segundo membro do pool back-end. Se o segundo pedido falhar, o pedido do utilizador recebe um erro 504.

Solução

O Gateway de Aplicação permite-lhe configurar esta definição através do BackendHttpSetting, que pode depois ser aplicado a diferentes quantidades. Diferentes quantidades de back-end podem ter diferentes BackendHttpSetting, e um tempo limite de pedido diferente configurado.

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

BackendAddressPool vazio

Causa

Se o gateway de aplicativo não tiver VMs ou conjunto de escala de máquina virtual 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 incorreto.

Solução

Verifique se o pool de endereços de back-end não está vazio. Isso pode ser feito via PowerShell, CLI ou portal.

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

A saída do cmdlet anterior deve conter pool de endereços de back-end não vazio. O exemplo a seguir mostra dois pools retornados que são configurados com um FQDN ou um endereço IP para as VMs de back-end. 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 íntegras em BackendAddressPool

Causa

Se todas as instâncias de BackendAddressPool não estiverem íntegras, o gateway de aplicativo não terá nenhum back-end para encaminhar a solicitação do usuário. Isso também pode ser o caso 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 VNet. Se configurado com um ponto de extremidade público, verifique se uma solicitação do navegador para o aplicativo Web é útil.

O certificado SSL upstream não corresponde

Causa

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

Em cenários onde o TLS de ponta a ponta está habilitado, uma configuração que é obtida editando as "Configurações HTTP de back-end" apropriadas e alterando a configuração da configuração de "Protocolo de back-end" para HTTPS, é obrigatório garantir que o CNAME do certificado TLS instalado nos servidores back-end corresponda ao nome do host que vem para o back-end na solicitação de cabeçalho de host HTTP.

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

Devido ao fato de que, por padrão, o Application Gateway envia o mesmo cabeçalho de host HTTP para o back-end que recebe do cliente, você precisará garantir que o certificado TLS instalado no servidor de back-end seja emitido com um CNAME que corresponda ao nome do host recebido por esse servidor de back-end no cabeçalho de 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ê tem um Application Gateway para atender às solicitações https para www.contoso.com de domínio. Você pode ter o domínio contoso.com delegado a uma Zona Pública de DNS do Azure e um registro DNS A nessa zona apontando www.contoso.com para o IP público do Gateway de Aplicativo específico que atenderá às solicitações.

Nesse Application Gateway, você deve ter um ouvinte para o host www.contoso.com com uma regra que tenha a "Configuração HTTP com backup" forçada a 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 HTTP com backup" da regra fará com que a segunda parte da comunicação que acontece entre as instâncias do Application Gateway e os servidores no back-end use TLS.

Se os servidores back-end não tiverem um certificado TLS emitido para o CNAME www.contoso.com ou *.contoso.com, a solicitação falhará com 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 back-end) não corresponderá ao nome do host no cabeçalho do host, e, portanto, a negociação TLS falhará.

www.contoso.com --> APP GW front-end IP --> Ouvinte 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 CNAME do certificado TLS instalado no servidor 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 acontece entre as instâncias do Application Gateway e o back-end, falhará com "O certificado SSL Upstream não corresponde" e lançará de volta um erro do servidor: 502 - O servidor Web recebeu uma resposta inválida ao agir como um gateway ou servidor proxy

Próximos passos

Se as etapas anteriores não resolverem o problema, abra um tíquete de suporte.