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.
Observação
Recomendamos que você use o módulo Az PowerShell do Azure para interagir com o Azure. Para começar, confira 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 $vnetVerifique 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 testrgVerifique 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:portdeve 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 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 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.
Comentários
Em breve: Ao longo de 2024, eliminaremos os problemas do GitHub como o mecanismo de comentários para conteúdo e o substituiremos por um novo sistema de comentários. Para obter mais informações, consulte https://aka.ms/ContentUserFeedback.
Enviar e exibir comentários de