Resolver problemas de estado de funcionamento do back-end no Gateway de Aplicação

  • Artigo

Descrição geral

Por predefinição, a Gateway de Aplicação do Azure pesquisa os servidores de back-end para verificar o estado de funcionamento e para verificar se estão prontos para executar pedidos. Os usuários também podem criar testes personalizados para mencionar o nome do host, o caminho a ser investigado e os códigos de status a serem aceitos como Íntegros. Em cada caso, se o servidor de back-end não responder com êxito, o Gateway de Aplicação sinaliza o servidor como em Mau Estado de Funcionamento e deixa de reencaminhar pedidos para o servidor. Depois de o servidor começar a responder com êxito, o Gateway de Aplicação retoma o reencaminhamento dos pedidos.

Como verificar a integridade do back-end

Para verificar o estado de funcionamento o seu conjunto de back-end, pode utilizar a página de Estado de Funcionamento do Back-End no portal do Azure. Em alternativa, pode utilizar o Azure PowerShell, a CLI ou a API REST.

O status recuperado por qualquer um desses métodos pode ser qualquer um dos seguintes estados:

  • Bom estado de funcionamento
  • Mau estado de funcionamento
  • Desconhecido

O Application Gateway encaminha uma solicitação para um servidor do pool de back-end se seu status estiver íntegro. Se todos os servidores em um pool de back-end não estiverem íntegros ou desconhecidos, os clientes poderão encontrar problemas para acessar o aplicativo de back-end. Leia mais para entender as diferentes mensagens relatadas pela Backend Health, suas causas e sua resolução.

Nota

Se o usuário não tiver permissão para ver os status de integridade do back-end, No results. será exibido.

Estado de saúde do back-end: Não íntegro

Se o status de integridade do back-end não estiver íntegro, a exibição do portal será semelhante à seguinte captura de tela:

Application Gateway backend health - Unhealthy

Caso esteja usando uma consulta do Azure PowerShell, CLI ou API REST do Azure, você receberá uma resposta semelhante ao exemplo a seguir:

PS C:\Users\testuser\> Get-AzApplicationGatewayBackendHealth -Name "appgw1" -ResourceGroupName "rgOne"
BackendAddressPools :
{Microsoft.Azure.Commands.Network.Models.PSApplicationGatewayBackendHealthPool}
BackendAddressPoolsText : [
{
                              "BackendAddressPool": {
                                "Id": "/subscriptions/536d30b8-665b-40fc-bd7e-68c65f816365/resourceGroups/rgOne/providers/Microsoft.Network/applicationGateways/appgw1/b
                          ackendAddressPools/appGatewayBackendPool"
                              },
                              "BackendHttpSettingsCollection": [
                                {
                                  "BackendHttpSettings": {
                                    "TrustedRootCertificates": [],
                                    "Id": "/subscriptions/536d30b8-665b-40fc-bd7e-68c65f816365/resourceGroups/rgOne/providers/Microsoft.Network/applicationGateways/appg
                          w1/backendHttpSettingsCollection/appGatewayBackendHttpSettings"
                                  },
                                  "Servers": [
                                    {
                                      "Address": "10.0.0.5",
                                      "Health": "Healthy"
                                    },
                                    {
                                      "Address": "10.0.0.6",
                                      "Health": "Unhealthy"
                                    }
                                  ]
                                }
                              ]
                            }
                        ]

Depois de receber um estado de servidor de back-end em mau estado de funcionamento para todos os servidores num conjunto de back-end, os pedidos não são reencaminhados para os servidores e o Gateway de Aplicação devolve um erro "502 Gateway Incorreto" ao cliente que está a pedir. Para solucionar esse problema, verifique a coluna Detalhes na guia Integridade do back-end.

A mensagem exibida na coluna Detalhes fornece informações mais detalhadas sobre o problema e, com base nesses detalhes, você pode começar a solucionar o problema.

Nota

A solicitação de teste padrão é enviada no formato de <protocol>://127.0.0.1:<port>. Por exemplo, http://127.0.0.1:80 para uma sonda HTTP na porta 80. Somente códigos de status HTTP de 200 a 399 são considerados íntegros. O protocolo e a porta de destino são herdados das configurações HTTP. Se você quiser que o Application Gateway investigue em um protocolo, nome de host ou caminho diferente e reconheça um código de status diferente como Íntegro, configure um teste personalizado e associe-o às configurações HTTP.

Mensagens de erro

Tempo limite do servidor de back-end

Mensagem: o tempo do back-end para responder à pesquisa de estado de funcionamento do gateway de aplicação é superior ao limiar de tempo limite na definição da pesquisa.

Causa: depois de o Gateway de Aplicação enviar um pedido de pesquisa HTTP(S) ao servidor de back-end, aguarda uma resposta do servidor de back-end durante um período configurado. Se o servidor de back-end não responder dentro do período configurado (o valor de tempo limite), será marcado como em Mau Estado de Funcionamento até começar a responder dentro do período de tempo limite configurado novamente.

Resolução: verifique o motivo pelo qual o servidor de back-end ou a aplicação não está a responder dentro do período de tempo limite configurado, bem como as dependências da aplicação. Por exemplo, verifique se a base de dados tem algum problema que possa acionar um atraso na resposta. Se estiver ciente do comportamento da aplicação e este responder apenas após o valor de tempo limite, aumente o valor de tempo limite das definições de pesquisa personalizada. Tem de ter uma pesquisa personalizada para alterar o valor de tempo limite. Para obter informações sobre como configurar uma sonda personalizada, consulte a página de documentação.

Para aumentar o valor de tempo limite, siga estas etapas:

  1. Acesse o servidor back-end diretamente e verifique o tempo necessário para o servidor responder nessa página. Você pode usar qualquer ferramenta para acessar o servidor de back-end, incluindo um navegador usando ferramentas de desenvolvedor.
  2. Depois de descobrir o tempo necessário para o aplicativo responder, selecione a guia Sondas de integridade e, em seguida, selecione a sonda associada às configurações HTTP.
  3. Insira qualquer valor de tempo limite maior que o tempo de resposta do aplicativo, em segundos.
  4. Salve as configurações de teste personalizadas e verifique se a integridade do back-end aparece como Íntegro agora.

Erro de resolução de DNS

Mensagem: O Application Gateway não pôde criar uma sonda para esse back-end. Normalmente, esta situação acontece quando o FQDN do back-end não foi inserido corretamente. 

Causa: Se o pool de back-end for do tipo Endereço IP, FQDN (nome de domínio totalmente qualificado) ou Serviço de Aplicativo, o Gateway de Aplicativo resolverá para o endereço IP do FQDN inserido por meio do DNS (padrão personalizado ou do Azure). Em seguida, o gateway de aplicação tenta ligar-se ao servidor na porta TCP mencionada nas definições HTTP. No entanto, se esta mensagem for apresentada, sugere que o Gateway de Aplicação não conseguiu resolver com êxito o endereço IP do FQDN introduzido.

Resolução:

  1. Verifique se o FQDN introduzido no conjunto de back-end está correto e se é um domínio público. Em seguida, tente resolvê-lo a partir do computador local.
  2. Se conseguir resolver o endereço IP, poderá haver algo de errado com a configuração do DNS na rede virtual.
  3. Verifique se a rede virtual está configurada com um servidor DNS personalizado. Se for o caso, verifique o servidor DNS sobre o motivo pelo qual não consegue resolver para o endereço IP do FQDN especificado.
  4. Se estiver a utilizar o DNS predefinido do Azure, verifique no registo de nomes de domínio se foi concluído um mapeamento de registos A ou CNAME adequado.
  5. Se o domínio for privado ou interno, tente resolvê-lo a partir de uma VM na mesma rede virtual. Se conseguir resolvê-lo, reinicie o Gateway de Aplicação e verifique novamente. Para reiniciar o Gateway de Aplicação, tem de parar e iniciar com os comandos do PowerShell descritos nestes recursos ligados.

Erro de conexão TCP

Mensagem: O Gateway de Aplicação não conseguiu ligar-se ao back-end. Verifique se o back-end responde na porta usada para a pesquisa. Verifique também se algum NSG/UDR/Firewall está a bloquear o acesso ao IP e à porta deste back-end.

Causa: após a fase de resolução do DNS, o Gateway de Aplicação tenta ligar-se ao servidor de back-end na porta TCP configurada nas definições de HTTP. Se o Gateway de Aplicação não conseguir estabelecer uma sessão TCP na porta especificada, a pesquisa será marcada como Em Mau Estado de Funcionamento com esta mensagem.

Solução: Se receber este erro, siga estes passos:

  1. Verifique se você pode se conectar ao servidor back-end na porta mencionada nas configurações HTTP usando um navegador ou PowerShell. Por exemplo, execute o seguinte comando: Test-NetConnection -ComputerName www.bing.com -Port 443.

  2. Se a porta mencionada não for a porta desejada, insira o número de porta correto para o Application Gateway se conectar ao servidor back-end.

  3. Se você não conseguir se conectar na porta a partir da sua máquina local também, então:

    a. Verifique as configurações do NSG (grupo de segurança de rede) do adaptador de rede e da sub-rede do servidor back-end e se as conexões de entrada com a porta configurada são permitidas. Se não estiverem, crie uma nova regra para permitir as conexões. Para saber como criar regras NSG, consulte a página de documentação.

    b. Verifique se as configurações NSG da sub-rede do Application Gateway permitem tráfego público e privado de saída, para que uma conexão possa ser feita. Verifique a página do documento fornecida na etapa 3a para saber mais sobre como criar regras NSG.

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

    c. Verifique as configurações de rotas definidas pelo usuário (UDR) do Application Gateway e da sub-rede do servidor back-end para verificar se há anomalias de roteamento. Verifique se o UDR não está direcionando o tráfego para fora da sub-rede de back-end. Por exemplo, verifique se há rotas para dispositivos virtuais de rede ou rotas padrão sendo anunciadas para a sub-rede do Gateway de Aplicativo por meio da Rota Expressa do Azure e/ou VPN.

    d. Para verificar as rotas e regras efetivas para um adaptador de rede, você pode usar os seguintes comandos do PowerShell:

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

  4. Se você não encontrar nenhum problema com NSG ou UDR, verifique seu servidor back-end para problemas relacionados ao aplicativo que estão impedindo os clientes de estabelecer uma sessão TCP nas portas configuradas. Algumas coisas a verificar:

    a. Abra um prompt de comando (Win+R -> cmd), digite netstat e selecione Enter.

    b. Verifique se o servidor está escutando na porta configurada. Por exemplo:

            Proto Local Address Foreign Address State PID
        TCP 0.0.0.0:80 0.0.0.0:0 LISTENING 4

    c. Se não estiver escutando na porta configurada, verifique as configurações do servidor Web. Por exemplo: ligações de site no IIS, bloco de servidor no NGINX e host virtual no Apache.

    d. Verifique as definições da firewall do SO para se certificar de que o tráfego de entrada para a porta é permitido.

Incompatibilidade de código de status HTTP

Mensagem: O código de status da resposta HTTP do back-end não correspondeu à configuração do teste. Esperado:{HTTPStatusCode0} Recebido:{HTTPStatusCode1}.

Causa: Após a ligação TCP ter sido estabelecida e um handshake TLS ter sido concluído (se o TLS estiver ativado), o Gateway de Aplicação enviará a pesquisa como um pedido HTTP GET para o servidor de back-end. Conforme descrito anteriormente, o teste padrão será para , e considera os <protocol>://127.0.0.1:<port>/códigos de status de resposta no intervalo de 200 a 399 como Íntegros. Se o servidor retornar qualquer outro código de status, ele será marcado como Não íntegro com esta mensagem.

Solução: Dependendo do código de resposta do servidor de back-end, você pode executar as etapas a seguir. Alguns dos códigos de status comuns estão listados aqui:

Erro Ações
Incompatibilidade do código de status da sonda: Recebido 401 Verifique se o servidor back-end requer autenticação. As sondas do Application Gateway não podem passar credenciais para autenticação. Permita "HTTP 401" em uma correspondência de código de status de teste ou sonde para um caminho onde o servidor não requer autenticação.
Incompatibilidade do código de status da sonda: Recebido 403 Acesso proibido. Verifique se o acesso ao caminho é permitido no servidor back-end.
Incompatibilidade do código de status da sonda: Recebido 404 Página não encontrada. Verifique se o caminho do nome do host está acessível no servidor back-end. Altere o nome do host ou o parâmetro path para um valor acessível.
Incompatibilidade do código de status da sonda: Recebido 405 As solicitações de teste para o Application Gateway usam o método HTTP GET. Verifique se o servidor permite esse método.
Incompatibilidade do código de status da sonda: Recebido 500 Erro de servidor interno. Verifique o estado de funcionamento do servidor de back-end e se os serviços estão em execução.
Incompatibilidade do código de status da sonda: Recebido 503 Serviço indisponível. Verifique o estado de funcionamento do servidor de back-end e se os serviços estão em execução.

Ou, se você acha que a resposta é legítima e deseja que o Application Gateway aceite outros códigos de status como Íntegro, você pode criar uma sonda personalizada. Essa abordagem é útil em situações em que o site de back-end precisa de autenticação. Como as solicitações de teste não possuem credenciais de usuário, elas falharão e um código de status HTTP 401 será retornado pelo servidor de back-end.

Para criar uma sonda personalizada, siga estas etapas.

Incompatibilidade do corpo da resposta HTTP

Mensagem: O corpo da resposta HTTP do back-end não correspondeu à configuração do teste. O corpo da resposta recebida não contém {string}.

Causa: quando cria uma pesquisa personalizada, pode marcar um servidor de back-end como em Bom Estado de Funcionamento ao corresponder uma cadeia do corpo da resposta. Por exemplo, pode configurar o Gateway de Aplicação para aceitar "não autorizado" como uma cadeia para corresponder. Se a resposta do servidor de back-end para a solicitação de teste contiver a cadeia de caracteres não autorizada, ela será marcada como Íntegra. Caso contrário, é marcado como Não íntegro com a mensagem dada.

Solução: Para resolver este problema, siga estes passos:

  1. Acesse o servidor back-end localmente ou de uma máquina cliente no caminho da sonda e verifique o corpo da resposta.
  2. Verifique se o corpo da resposta de configuração de pesquisa personalizada no Gateway de Aplicação corresponde ao que está configurado.
  3. Se não corresponderem, altere a configuração de pesquisa para que tenha o valor de cadeia de carateres correto a aceitar.

Saiba mais sobre a correspondência de sonda do Application Gateway.

Nota

Para todas as mensagens de erro relacionadas ao TLS, para saber mais sobre o comportamento do SNI e as diferenças entre o SKU v1 e v2, verifique a página de visão geral do TLS.

O Nome Comum (CN) não corresponde

Mensagem: (Para V2) O Nome Comum do certificado folha apresentado pelo servidor back-end não corresponde ao nome do host de Configuração de Sonda ou Back-end do gateway de aplicativo.
(Para V1) O nome comum (CN) do certificado de back-end não corresponde.

Causa (para V2): este problema ocorrerá se tiver selecionado o protocolo HTTPS na definição de back-end e se nem o nome do anfitrião da Pesquisa Personalizada nem da Definição de Back-end (por essa ordem) corresponderem ao Nome Comum (CN) do certificado do servidor de back-end.
(Para V1) O FQDN do destino do pool de back-end não corresponde ao Common Name (CN) do certificado do servidor de back-end.

Solução: As informações de nome de host são críticas para a conexão HTTPS de back-end, pois esse valor é usado para definir a Indicação de Nome do Servidor (SNI) durante o handshake TLS. Você pode corrigir esse problema das seguintes maneiras com base na configuração do gateway.

Para V2,

  • Se você estiver usando uma sonda padrão – Você pode especificar um nome de host na configuração de back-end associada do gateway de aplicativo. Você pode selecionar "Substituir com nome de host específico" ou "Escolher nome de host do destino de back-end" na configuração de back-end.
  • Se você estiver usando uma Sonda Personalizada – Para Sonda Personalizada, poderá usar o campo "host" para especificar o Nome Comum do certificado do servidor de back-end. Como alternativa, se a configuração de back-end já estiver configurada com o mesmo nome de host, você pode escolher "Escolher nome de host da configuração de back-end" nas configurações de teste.

Para V1, verifique se o FQDN do destino do pool de back-end é igual ao Common Name (CN).

Dicas: Para determinar o nome comum (CN) do certificado do(s) servidor(es) de back-end, você pode usar qualquer um desses métodos. Observe também que, de acordo com a RFC 6125 , se existir uma SAN, a verificação SNI será feita apenas em relação a esse campo. O campo de nome comum será correspondido se não houver SAN no certificado.

  • Usando o navegador ou qualquer cliente: Acesse o servidor back-end diretamente (não através do Application Gateway) e clique no cadeado do certificado na barra de endereço para visualizar os detalhes do certificado. Você vai encontrá-lo na seção "Emitido para". Screenshot that shows certificate details in a browser.

  • Ao fazer login no servidor back-end (Windows):

    1. Entre na máquina onde seu aplicativo está hospedado.
    2. Selecione Win + R ou clique com o botão direito do mouse no botão Iniciar e selecione Executar.
    3. Digite certlm.msc e selecione Enter. Você também pode procurar o Gerenciador de Certificados no menu Iniciar.
    4. Localize o certificado (normalmente em Certificados - Computador Local\Pessoal\Certificados) e abra o certificado.
    5. Na guia Detalhes, verifique o Assunto do certificado.

  • Ao fazer login no servidor back-end (Linux): Execute este comando OpenSSL especificando o nome do arquivo de certificado correto openssl x509 -in certificate.crt -subject -noout

O certificado de back-end expirou

Mensagem: O certificado de back-end é inválido. A data atual não está dentro do intervalo de datas "Válido de" e "Válido até" no certificado.

Causa: Um certificado expirado é considerado não seguro e, por conseguinte, o gateway de aplicação marca o servidor de back-end com um certificado expirado como em mau estado de funcionamento.

Solução: A solução depende de qual parte da cadeia de certificados expirou no servidor back-end.

Para V2 SKU,

  • Certificado Folha expirado (também conhecido como Domínio ou Servidor) – Renove o certificado do servidor com o provedor de certificados e instale o novo certificado no servidor back-end. Certifique-se de ter instalado a cadeia de certificados completa composta por Leaf (topmost) > Intermediate(s) > Root. Com base no tipo de Autoridade de Certificação (CA), você pode executar as seguintes ações no gateway.

    • CA conhecida publicamente: se o emissor do certificado for uma autoridade de certificação conhecida, você não precisará executar nenhuma ação no gateway de aplicativo.
    • CA privada: Se o certificado folha for emitido por uma autoridade de certificação privada, você precisará verificar se o certificado de autoridade de certificação raiz de assinatura foi alterado. Nesses casos, você deve carregar o novo certificado de autoridade de certificação raiz (. CER) para a configuração de back-end associada do seu gateway.

  • Certificado Intermediário ou Raiz expirado – Normalmente, esses certificados têm períodos de validade relativamente longos (uma década ou duas). Quando o certificado Root/Intermediate expirar, recomendamos que você verifique com seu provedor de certificados os arquivos de certificado renovados. Certifique-se de ter instalado esta cadeia de certificados atualizada e completa que inclui Leaf (topmost) > Intermediate(s) > Root o servidor back-end.

    • Se o certificado raiz permanecer inalterado ou se o emissor for uma autoridade de certificação conhecida, você NÃO precisará executar nenhuma ação no gateway de aplicativo.
    • Ao usar uma autoridade de certificação privada, se o próprio certificado de autoridade de certificação raiz ou a raiz do certificado intermediário renovado tiver sido alterado, você deverá carregar o novo certificado raiz na configuração de back-end do gateway de aplicativo.

Para V1 SKU,

  • Renove o certificado Leaf expirado (também conhecido como Domínio ou Servidor) com sua CA e carregue o mesmo certificado folha (. CER) para a configuração de back-end associada do seu gateway de aplicativo.

O certificado intermédio não foi encontrado

Mensagem: O certificado intermediário está ausente da cadeia de certificados apresentada pelo servidor back-end. Verifique se a cadeia de certificados está completa e ordenada corretamente no servidor back-end.

Causa: o(s) certificado(s) intermediário(s) não está(ão) instalado(s) na cadeia de certificados no servidor back-end.

Solução: Um certificado intermediário é usado para assinar o certificado Leaf e, portanto, é necessário para completar a cadeia. Verifique junto da Autoridade de Certificação (AC) os Certificados intermédios necessários e instale-os no servidor de back-end. Esta cadeia deve começar com o Certificado de Folha, seguido do(s) certificado(s) intermédio(s) e, finalmente, do certificado de Raiz da AC. Recomendamos que instale a cadeia completa no servidor de back-end, incluindo o certificado de AC de Raiz. Para referência, consulte o exemplo de cadeia de certificados em A folha deve estar na parte superior da cadeia.

Nota

Um certificado autoassinado que NÃO é uma Autoridade de Certificação também resultará no mesmo erro. Isso ocorre porque o gateway de aplicativo considera esse certificado autoassinado como certificado "Leaf" e procura seu certificado intermediário de assinatura. Você pode seguir este artigo para gerar corretamente um certificado autoassinado.

Estas imagens mostram a diferença entre os certificados autoassinados. Screenshot showing difference between self-signed certificates.

O certificado de folha ou servidor não foi encontrado

Mensagem: O certificado Leaf está ausente da cadeia de certificados apresentada pelo servidor back-end. Verifique se a cadeia está completa e ordenada corretamente no servidor back-end.

Causa: o certificado de Folha (também conhecida como Domínio ou Servidor) está em falta na cadeia de certificados do servidor de back-end.

Solução: Você pode obter o certificado folha da sua Autoridade de Certificação (CA). Instale este certificado de folha e todos os respetivos certificados de assinatura (certificados Intermédios e de Raiz da AC) no servidor de back-end. Esta cadeia deve começar com o Certificado de Folha, seguido do(s) certificado(s) intermédio(s) e, finalmente, do certificado de Raiz da AC. Recomendamos que instale a cadeia completa no servidor de back-end, incluindo o certificado de AC de Raiz. Para referência, consulte o exemplo de cadeia de certificados em A folha deve estar na parte superior da cadeia.

O certificado do servidor não é emitido por uma autoridade de certificação conhecida publicamente

Mensagem: O certificado do servidor back-end não é assinado por uma autoridade de certificação (CA) conhecida. Para usar certificados de CA desconhecidos, seu certificado raiz deve ser carregado na configuração de back-end do gateway de aplicativo.

Causa: você escolheu "certificado de autoridade de certificação conhecido" na configuração de back-end, mas o certificado raiz apresentado pelo servidor de back-end não é conhecido publicamente.

Solução: Quando um certificado Leaf é emitido por uma Autoridade de Certificação (CA) privada, o certificado da CA raiz de assinatura deve ser carregado na Configuração de Back-end associada do gateway de aplicativo. Isto permite que o seu gateway de aplicação estabeleça uma ligação fidedigna com esse servidor de back-end. Para corrigir esta situação, aceda à definição de back-end associada, selecione "não é uma AC bem conhecida" e carregue o certificado da AC de Raiz (. CER). Para identificar e transferir o certificado de raiz, pode seguir os mesmos passos descritos em Erro de correspondência do certificado de raiz fidedigna.

O certificado intermediário NÃO é assinado por uma autoridade de certificação conhecida publicamente.

Mensagem: O certificado intermediário não está assinado por uma autoridade de certificação (CA) conhecida. Verifique se a cadeia de certificados está completa e ordenada corretamente no servidor back-end.

Causa: você escolheu "certificado de autoridade de certificação conhecido" na configuração de back-end, mas o certificado intermediário apresentado pelo servidor de back-end não é assinado por nenhuma autoridade de certificação conhecida publicamente.

Solução: Quando um certificado é emitido por uma Autoridade de Certificação (CA) privada, o certificado da CA raiz de assinatura deve ser carregado na Configuração de Back-end associada do gateway de aplicativo. Isto permite que o seu gateway de aplicação estabeleça uma ligação fidedigna com esse servidor de back-end. Para corrigir isso, entre em contato com sua autoridade de certificação privada para obter o certificado de autoridade de certificação raiz apropriado (. CER) e carregue esse . CER para a configuração de back-end do gateway de aplicativo selecionando "não é uma autoridade de certificação conhecida". Também recomendamos que instale a cadeia completa no servidor de back-end, incluindo o certificado de AC de Raiz, para uma verificação fácil.

Incompatibilidade de certificado raiz confiável (sem certificado raiz no servidor back-end)

Mensagem: O certificado intermediário não assinado por nenhum certificado raiz carregado no gateway de aplicativo. Verifique se a cadeia de certificados está completa e ordenada corretamente no servidor back-end.

Causa: nenhum dos certificados de AC de Raiz carregados para a Definição de Back-end associada assinou o certificado Intermédio instalado no servidor de back-end. O servidor de back-end tem apenas certificados Leaf e Intermédios instalados.

Solução: Um certificado Leaf é assinado por um certificado intermediário, que é assinado por um certificado de autoridade de certificação raiz. Ao utilizar um certificado de uma Autoridade de Certificação (AC) Privada, tem de carregar o certificado de AC de Raiz correspondente para o gateway de aplicação. Contacte a sua AC privada para obter o certificado de AC de Raiz (.CER) adequado e carregue esse ficheiro CER para a Definição de Back-end do gateway de aplicação.

Incompatibilidade de certificado raiz confiável (o certificado raiz está disponível no servidor back-end)

Mensagem: O certificado raiz do certificado do servidor usado pelo back-end não corresponde ao certificado raiz confiável adicionado ao gateway de aplicativo. Certifique-se de adicionar o certificado raiz correto para permitir a lista de back-end.

Causa: este erro ocorre quando nenhum dos Certificados de raiz carregados para a definição de back-end do gateway de aplicação corresponde ao Certificado de raiz presente no servidor de back-end.

Solução: Isso se aplica a um certificado de servidor back-end emitido por uma Autoridade de Certificação (CA) privada ou autoassinado. Identifique e carregue o certificado de AC de Raiz correto para a definição de back-end associada.

Dicas: Para identificar e baixar o certificado raiz, você pode usar qualquer um desses métodos.

  • Usando um navegador: acesse o servidor back-end diretamente (não por meio do Application Gateway) e clique no cadeado do certificado na barra de endereço para visualizar os detalhes do certificado.

    1. Escolha o certificado raiz na cadeia e clique em Exportar. Por padrão, este será um arquivo . Arquivo CRT.
    2. Abra isso. Arquivo CRT.
    3. Vá para a guia Detalhes e clique em "Copiar para arquivo",
    4. Na página Assistente para Exportação de Certificados, clique em Avançar,
    5. Selecione "Base-64 codificado X.509 (. CER) e clique em Seguinte,
    6. Dê um novo nome de arquivo e clique em Avançar,
    7. Clique em Concluir para obter um arquivo . Ficheiro CER.
    8. Carregue este certificado raiz (. CER) da sua autoridade de certificação privada para a configuração de back-end do gateway de aplicativo.

  • Efetuando login no servidor back-end (Windows)

    1. Entre na máquina onde seu aplicativo está hospedado.
    2. Selecione Win + R ou clique com o botão direito do mouse no botão Iniciar e, em seguida, selecione Executar.
    3. Digite certlm.msc e selecione Enter. Você também pode procurar o Gerenciador de Certificados no menu Iniciar.
    4. Localize o certificado, normalmente em Certificados - Computador Local\Pessoal\Certificados, e abra-o.
    5. Selecione o certificado raiz e, em seguida, selecione Exibir certificado.
    6. Nas propriedades do certificado, selecione a guia Detalhes e clique em "Copiar para arquivo",
    7. Na página Assistente para Exportação de Certificados, clique em Avançar,
    8. Selecione "Base-64 codificado X.509 (. CER) e clique em Seguinte,
    9. Dê um novo nome de arquivo e clique em Avançar,
    10. Clique em Concluir para obter um arquivo . Ficheiro CER.
    11. Carregue este certificado raiz (. CER) da sua autoridade de certificação privada para a configuração de back-end do gateway de aplicativo.

A folha deve estar no topo da cadeia.

Mensagem: O certificado Leaf não é o certificado mais alto da cadeia apresentado pelo servidor back-end. Verifique se a cadeia de certificados está ordenada corretamente no servidor back-end.

Causa: O certificado Leaf (também conhecido como Domínio ou Servidor) não está instalado na ordem correta no servidor back-end.

Solução: A instalação do certificado no servidor back-end deve incluir uma lista ordenada de certificados que inclui o certificado folha e todos os seus certificados de assinatura (certificados de CA intermediários e raiz). Esta cadeia tem de começar com o certificado de folha, os certificados Intermédios e, por fim, o certificado da AC de Raiz. Recomendamos que instale a cadeia completa no servidor de back-end, incluindo o certificado de AC de Raiz.

Dado é um exemplo de uma instalação de certificado de servidor juntamente com seus certificados de CA intermediários e raiz, indicados como profundidades (0, 1, 2 e assim por diante) no OpenSSL. Você pode verificar o mesmo para o certificado do seu servidor back-end usando os seguintes comandos OpenSSL.
s_client -connect <FQDN>:443 -showcerts
OU
s_client -connect <IPaddress>:443 -servername <TLS SNI hostname> -showcerts

Screenshot showing typical chain of certificates.

Falha na verificação do certificado

Mensagem: Não foi possível verificar a validade do certificado de back-end. Para descobrir o motivo, verifique o diagnóstico OpenSSL para a mensagem associada ao código de erro {errorCode}

Causa: este erro ocorre quando Gateway de Aplicação não consegue verificar a validade do certificado.

Solução: Para resolver esse problema, verifique se o certificado no servidor foi criado corretamente. Por exemplo, pode utilizar o OpenSSL para verificar o certificado e as propriedades e, em seguida, tentar recarregar o certificado nas definições de HTTP do Gateway de Aplicação.

Estado de funcionamento do back-end: Desconhecido

Atualizações para as entradas DNS do pool de back-end

Mensagem: Não foi possível recuperar o status de integridade do back-end. Isso acontece quando um NSG/UDR/Firewall na sub-rede do gateway de aplicativo está bloqueando o tráfego nas portas 65503-65534 no caso de SKU v1 e nas portas 65200-65535 no caso do SKU v2 ou se o FQDN configurado no pool de back-end não pôde ser resolvido para um endereço IP. Para saber mais visite - https://aka.ms/UnknownBackendHealth.

Causa: Para destinos de back-end baseados em FQDN (Fully Qualified Domain Name), o Application Gateway armazena em cache e usa o último endereço IP em boas condições se não conseguir obter uma resposta para a pesquisa de DNS subsequente. Uma operação PUT em um gateway nesse estado limparia completamente seu cache DNS. Como resultado, não haverá nenhum endereço de destino ao qual o gateway possa chegar.

Resolução: verifique e corrija os servidores DNS para garantir que ele esteja servindo uma resposta para a pesquisa de DNS do FDQN fornecido. Você também deve verificar se os servidores DNS estão acessíveis por meio da Rede Virtual do gateway de aplicativos.

Outras razões

Se a integridade do back-end for mostrada como Desconhecido, a exibição do portal será semelhante à seguinte captura de tela:

Application Gateway backend health - Unknown

Este comportamento pode ocorrer por um ou mais dos seguintes motivos:

  1. O NSG na sub-rede do Application Gateway está bloqueando o acesso de entrada às portas 65503-65534 (v1 SKU) ou 65200-65535 (v2 SKU) da "Internet".
  2. O UDR na sub-rede do Application Gateway é definido como a rota padrão (0.0.0.0/0) e o próximo salto não é especificado como "Internet".
  3. A rota predefinida é anunciada por uma ligação ExpressRoute/VPN a uma rede virtual por BGP.
  4. O servidor DNS personalizado está configurado numa rede virtual que não consegue resolver os nomes de domínio públicos.
  5. O Gateway de Aplicação está num Mau estado de funcionamento.

Solução:

  1. Verifique se o NSG está bloqueando o acesso às portas 65503-65534 (v1 SKU) ou 65200-65535 (v2 SKU) da Internet:

    a. Na guia Visão Geral do Gateway de Aplicativo, selecione o link Rede Virtual/Sub-rede. b. Na guia Sub-redes da sua rede virtual, selecione a sub-rede onde o Application Gateway foi implantado. c. Verifique se algum NSG está configurado. d. Se um NSG estiver configurado, procure esse recurso NSG na guia Pesquisar ou em Todos os recursos. e. Na seção Regras de Entrada, adicione uma regra de entrada para permitir o intervalo de portas de destino 65503-65534 para SKU v1 ou 65200-65535 v2 SKU com a Origem definida como marca de serviço GatewayManager. f. Selecione Salvar e verifique se você pode exibir o back-end como Íntegro. Como alternativa, você pode fazer isso por meio do PowerShell/CLI.

  2. Verifique se o UDR tem uma rota padrão (0.0.0.0/0) com o próximo salto não definido como Internet:

    a. Siga as etapas 1a e 1b para determinar sua sub-rede. b. Verifique se um UDR está configurado. Se houver, procure o recurso na barra de pesquisa ou em Todos os recursos. c. Verifique se há rotas padrão (0.0.0.0/0) com o próximo salto não definido como Internet. Se a configuração for Dispositivo Virtual ou Gateway de Rede Virtual, verifique se o dispositivo virtual ou o dispositivo local pode rotear corretamente o pacote de volta para o destino da Internet sem modificá-lo. Se os testes forem roteados por meio de um dispositivo virtual e modificados, o recurso de back-end exibirá um código de status 200 e o status de integridade do Application Gateway poderá ser exibido como Desconhecido. Isso não indica um erro. O tráfego ainda deve ser roteado através do Application Gateway sem problemas. d. Caso contrário, altere o próximo salto para Internet, selecione Salvar e verifique a integridade do back-end.

  3. Rota padrão anunciada pela conexão ExpressRoute/VPN para a rede virtual através de BGP (Border Gateway Protocol):

    a. Se você tiver uma conexão ExpressRoute/VPN com a rede virtual por BGP e estiver anunciando uma rota padrão, verifique se o pacote é roteado de volta para o destino da Internet sem modificá-lo. Você pode verificar usando a opção Solução de problemas de conexão no portal do Application Gateway. b. Escolha o destino manualmente como qualquer endereço IP roteável pela Internet, como 1.1.1.1. Defina a porta de destino como qualquer coisa e verifique a conectividade. c. Se o próximo salto for gateway de rede virtual, pode haver uma rota padrão anunciada pela Rota Expressa ou VPN.

  4. Se houver um servidor DNS personalizado configurado na rede virtual, verifique se os servidores podem resolver domínios públicos. A resolução de nomes de domínio público pode ser necessária em cenários em que o Application Gateway deve entrar em contato com domínios externos, como servidores OCSP (Online Certificate Status Protocol), ou para verificar o status de revogação do certificado.

  5. Para verificar se o Application Gateway está íntegro e em execução, vá para a opção Integridade do recurso no portal e verifique se o estado está íntegro. Se vir um estado Não Íntegro ou Degradado, contacte o suporte.

  6. Se a Internet e o tráfego privado estiverem passando por um Firewall do Azure hospedado em um hub virtual seguro (usando o Hub WAN Virtual do Azure):

    a. Para garantir que o gateway de aplicativo possa enviar tráfego diretamente para a Internet, configure a seguinte rota definida pelo usuário:

    Prefixo de endereço: 0.0.0.0/0
    Próximo salto: Internet

    b. Para garantir que o gateway de aplicativo possa enviar tráfego para o pool de back-end por meio de um Firewall do Azure no hub WAN Virtual, configure a seguinte rota definida pelo usuário:

    Prefixo do endereço: sub-rede do pool de back-end
    Próximo salto: Endereço IP privado do Firewall do Azure

Próximos passos

Saiba mais sobre o diagnóstico e o registro em log do Application Gateway.