Solução de problemas de erros de gateway incorreto no Gateway de Aplicativo

Saiba como solucionar problemas de erros de gateway inválido (502) recebidos ao usar o Gateway de Aplicativo do Azure.

Visão geral

Após a configuração de um gateway de aplicativo, um dos erros que você pode encontrar é Erro de servidor: 502 - o servidor Web recebeu uma resposta inválida ao atuar como gateway ou servidor proxy. Esse erro pode ocorrer pelos seguintes motivos principais:

• O NSG, a UDR ou o DNS personalizado está bloqueando o acesso aos membros do pool de back-end.
• As VMs ou instâncias de back-end do conjunto de dimensionamento de máquinas virtuais não estão respondendo à investigação de integridade padrão.
• Configuração inválida ou incorreta de investigações de integridade personalizadas.
• O pool de back-end do Gateway de Aplicativo do Azure não está configurado ou está vazio.
• Nenhuma das VMs ou instâncias no conjunto de dimensionamento de máquinas virtuais é íntegra.
• Tempo limite de solicitação ou problemas de conectividade com solicitações de usuário.

Problema com o Grupo de Segurança de Rede, com a Rota definida pelo usuário ou com o DNS personalizado

Causa

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

O NSG/UDR pode estar presente na sub-rede do gateway de aplicativo ou na sub-rede em que as VMs do aplicativo estã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 DNS, UDR e NSG realizando 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 soluções de virtualização de rede ou rotas padrão anunciadas para a sub-rede do gateway de aplicativo via Azure ExpressRoute/VPN.

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

3. Verifique se o NSG e a rota com a VM de back-end estão funcionando corretamente

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

4. Verifique se há um DNS personalizado na VNet. O DNS pode ser verificado 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.

Problemas com a investigação de integridade padrão

Causa

Os erros 502 também podem ser indicadores frequentes de que a investigação de integridade padrão não consegue acessar VMs de back-end.

Quando uma instância do gateway de aplicativo é provisionada, ela configura automaticamente um teste de integridade padrão para cada BackendAddressPool usando as propriedades de BackendHttpSetting. Nenhuma entrada do usuário é necessária para definir essa investigação. Especificamente, quando uma regra de balanceamento de carga é configurada, é feita uma associação entre BackendHttpSetting e BackendAddressPool. Uma investigação padrão é configurada para cada um dessas associações, e o gateway de aplicativo inicia uma conexão de verificação de integridade periódica para cada instância em BackendAddressPool na porta especificada no 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 está escutando em 127.0.0.1.
• O protocolo da solicitação é determinado pelo protocolo BackendHttpSetting.
• O caminho do URI está 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 de HTTP 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 VMs clássicas ou o serviço de nuvem do Azure forem usados com um FQDN ou IP público, verifique se o ponto de extremidade correspondente está aberto.
• Se a VM for configurada por meio do Azure Resource Manager e estiver fora da VNet em que o gateway de aplicativo está implantado, um grupo de segurança de rede deverá ser configurado para permitir o acesso na porta desejada.

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

Problemas com a investigação de integridade personalizada

Causa

Investigações de integridade personalizadas oferecem flexibilidade adicional para o comportamento de investigação padrão. Ao usar investigações personalizadas, você pode configurar o intervalo de investigação, a URL, o caminho a testar e quantas respostas com falha devem ser aceitas antes de marcar a instância do pool de back-end como não íntegra.

As propriedades adicionais a seguir são adicionadas:

Solução

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

• Verifique se a investigação foi especificada corretamente, conforme 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 seja configurado de outra forma na investigação personalizada.
• Verifique se uma chamada para http://<host>:<port><path> retorna um código de resultado HTTP 200.
• Verifique se Interval, Timeout e UnhealthyThreshold estão dentro dos intervalos aceitáveis.
• Se usar uma investigação HTTPS, certifique-se de que o servidor de back-end não requer o SNI, configurando para isso um certificado fallback no próprio servidor de back-end.

Tempo limite de solicitação

Causa

Quando é recebida uma solicitação de usuário, o gateway de aplicativo aplica as regras configuradas para a solicitação e a roteia para uma instância de pool de back-end. Ele aguarda por um intervalo de tempo configurável para receber uma resposta da instância de back-end. Por padrão, o 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 de usuário obterá um erro 502. No Gateway de Aplicativo do Azure v2, se o gateway de aplicativo não receber uma resposta do aplicativo de backend nesse intervalo, a solicitação será tentada em um segundo membro do pool de backend. Se a segunda solicitação falhar, a solicitação do usuário receberá um erro 504.

Solução

O Gateway de Aplicativo permite a você definir essa configuração por meio de BackendHttpSetting, que pode então ser aplicado a diferentes pools. Pools de back-end diferentes podem ter BackendHttpSetting diferentes e, assim, um tempo limite de solicitação 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 um conjunto de dimensionamento de máquinas virtuais configurado no pool de endereços de back-end, ele não poderá encaminhar solicitações de clientes 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 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 back-end não inteiro. O exemplo a seguir mostra dois pools retornados que são configurados com um FQDN ou endereços IP para as VMs de back-end. O estado de provisionamento de BackendAddressPool deve ser 'Bem-sucedido'.

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 do BackendAddressPool estiverem não íntegras, o gateway de aplicativo não terá um back-end para o qual rotear a solicitação do usuário. Esse também pode ser o caso quando 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 a configuração tiver sido feita com um ponto de extremidade público, verifique se uma solicitação do navegador ao aplicativo Web é operacional.

O certificado SSL upstream não corresponde

Causa

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á ativado, uma configuração que se consegue editando as "Configurações HTTP de Back-end" apropriadas e alterando a configuração da configuração "Protocolo back-end" para HTTPS, é obrigatório garantir que o NOME DNS do certificado TLS instalado em servidores de back-end corresponda ao nome do host que é encaminhado ao back-end na solicitação de cabeçalho do host 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 Application Gateway envia o mesmo cabeçalho de host HTTP para o servidor back-end que recebe do cliente, é necessário assegurar que o certificado TLS instalado no servidor back-end seja emitido com um NOME DNS que corresponda ao nome do host recebido por esse servidor no cabeçalho de host HTTP. Lembre-se de que, a menos que especificado de outra forma, esse nome de host deve ser 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 de DNS do Azure e um registro A DNS nessa zona apontando www.contoso.com para o IP público do Gateway de Aplicativo específico que vai atender às solicitações.

Nesse Gateway de Aplicativo, você deve ter um ouvinte para o host www.contoso.com com uma regra que tenha a "Configuração HTTP de Back-end" forçada a usar o protocolo HTTPS (garantindo TLS de ponta a ponta). Essa mesma regra pode 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 de Retaguarda" da regra faz com que a segunda parte da comunicação, que ocorre entre as instâncias do Gateway de Aplicação e os servidores no back-end, passe a usar 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 APP GW --> 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 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 então retorna um erro do servidor: 502 – O servidor Web recebeu uma resposta inválida enquanto atuava como um gateway ou servidor proxy.

Próximas etapas

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