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

Artigo
12/18/2024

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

Nota

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

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:

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

Verifique o NSG efetivo e roteie com a VM de back-end

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

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

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:

Propriedade da sonda	valor	Description
URL da sonda	`http://127.0.0.1/`	Caminho do URL
Intervalo	30	Intervalo da sonda em segundos
Limite de Tempo Excedido	30	Tempo limite da sonda em segundos
Limiar com funcionamento incorreto	3	Contagem de novas tentativas da sonda. O servidor back-end é marcado para baixo depois que a contagem de falhas de teste consecutivas atinge o limite 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 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:

Propriedade da sonda	Description
Name	Nome da sonda. Esse nome é usado para se referir à sonda nas configurações HTTP de back-end.
Protocolo	Protocolo usado para enviar a sonda. O teste usa o protocolo definido nas configurações HTTP de back-end
Host	Nome do host para enviar a sonda. Aplicável somente quando o multissite está configurado no gateway de aplicativo. Isso é diferente do nome do host da VM.
Caminho	Caminho relativo da sonda. O caminho válido começa em '/'. O teste é enviado para <protocol>://<host>:<port><path>
Intervalo	Intervalo da sonda em segundos. Este é o intervalo de tempo entre duas sondas consecutivas.
Limite de Tempo Excedido	Tempo limite da sonda em segundos. Se uma resposta válida não for recebida dentro desse período de tempo limite, a sonda será marcada como falha.
Limiar com funcionamento incorreto	Contagem de novas tentativas da sonda. O servidor back-end é marcado para baixo depois que a contagem de falhas de teste consecutivas atinge o limite não íntegro.

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.

Partilhar via

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

Descrição geral

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

Causa

Solução

Problemas com a sonda de integridade padrão

Causa

Solução

Problemas com a sonda de integridade personalizada

Causa

Solução

Tempo limite do pedido

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óximos passos

Comentários

Recursos adicionais