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

Artigo
12/26/2023

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

Observação

Recomendamos que você use o módulo Az PowerShell do Azure para interagir com o Azure. Para começar, consulte Instalar o Azure PowerShell. Para saber como migrar para o módulo Az PowerShell, confira Migrar o Azure PowerShell do AzureRM para o Az.

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:

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.
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
```

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

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

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:

Propriedades da investigação	Valor	Descrição
URL de investigação	`http://127.0.0.1/`	Caminho da URL
Intervalo	30	Intervalo da investigação em segundos
Tempo limite	30	Tempo limite da investigação em segundos
Limite não íntegro	3	Contagem de repetições da investigação. O servidor back-end é marcado após a contagem de falhas de investigação consecutivas atingir o limite de não íntegro.

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 está 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 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:

Propriedades da investigação	Descrição
Nome	O nome da investigação. Este é o nome usado para se referir à investigação nas configurações de HTTP de back-end.
Protocolo	O protocolo usado para enviar a investigação. A investigação usa o protocolo definido nas configurações de HTTP do back-end
Host	O nome do host para enviar a investigação. Aplicável somente quando vários sites são configurados no gateway de aplicativo. Isso é diferente do nome de host de VM.
Caminho	O caminho relativo da investigação. Um caminho válido começa com '/'. A investigação é enviada para <protocol>://<host>:<port><path>
Intervalo	Intervalo de investigação em segundos. Este é o intervalo de tempo entre duas investigações consecutivas.
Tempo limite	Tempo limite da investigação em segundos. Se uma resposta válida não for recebida nesse período limite, a investigação será marcada como com falha.
Limite não íntegro	Contagem de repetições da investigação. O servidor back-end é marcado após a contagem de falhas de investigação consecutivas atingir o limite de não íntegro.

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 v2, se o gateway de aplicativo não receber uma resposta do aplicativo de back-end nesse intervalo, a solicitação será feita 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

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 nos servidores de back-end não corresponde ao nome do host recebido no cabeçalho da solicitação do host.

Nos cenários em que o TLS de ponta a ponta estiver habilitado, uma configuração obtida pela edição das "Configurações de HTTP de back-end" apropriadas e pela alteração da configuração do "Protocolo de back-end" para HTTPS, deve-se garantir que o CNAME do certificado TLS instalado nos servidores de back-end corresponda ao nome do host que chega ao back-end na solicitação do 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 do HTTP, será que a segunda parte da comunicação que ocorre entre as instâncias do Gateway de Aplicativo e os servidores de back-end será 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ê precisará garantir que o certificado TLS instalado no servidor de back-end seja emitido com um CNAME 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 deve ser o mesmo que o recebido do cliente.

Por exemplo:

Imagine que você tem um Gateway de Aplicativo para atender as solicitações https do 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 nessa zona apontando www.contoso.com para o IP público do Gateway de Aplicativo específico que 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 Com Suporte" forçada a usar o HTTPS de protocolo (garantindo o 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 o HTTPS na "Configuração HTTP de Backup" da regra fará com que a segunda parte da comunicação que acontece entre as instâncias do Gateway de Aplicativo e os servidores no back-end use TLS.

Se os servidores de back-end não tiverem um certificado TLS emitido para o CNAME www.contoso.com ou *.contoso.com, a solicitação falhará com Erro de Servidor: 502 - O servidor Web recebeu uma resposta inválida enquanto atuava como 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 --> IP de front-end do APP GW --> Ouvinte com uma regra que configura "Configurações HTTP de Back-end" para usar o HTTPS de protocolo em vez de o HTTP --> Pool de Back-end --> Servidor Web (precisa ter um certificado TLS instalado em www.contoso.com)

Solução

é necessário que o CNAME 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 acontece entre as instâncias do Gateway de Aplicativo e o back-end falhará com "O certificado SSL upstream não corresponde" e gerará um Erro de 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.

Compartilhar via

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

Visão geral

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

Causa

Solução

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

Causa

Solução

Problemas com a investigação de integridade personalizada

Causa

Solução

Tempo limite de solicitação

Causa

Solução

BackendAddressPool vazio

Causa

Solução

Instâncias não íntegras em BackendAddressPool

Causa

Solução

O certificado SSL upstream não corresponde

Causa

Solução

Próximas etapas

Comentários

Recursos adicionais