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

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. Confira Instalar o Azure PowerShell para começar. 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:

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.

  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:

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.

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 está configurada corretamente conforme a 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 UnhealtyThreshold 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 obterá um erro 502.

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

Próximas etapas

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