Planejar e implementar um Gateway de Aplicativo do Azure

  • 10 minutos

O Gateway de Aplicação do Azure é um balanceador de carga do tráfego da Web (camada OSI 7) que lhe permite gerir o tráfego para as suas aplicações Web. Os balanceadores de carga tradicionais funcionam na camada de transporte (camada OSI 4 - TCP e UDP) e encaminham o tráfego com base no endereço IP de origem e porta, para uma porta e um endereço IP de destino.

O Application Gateway pode tomar decisões de roteamento com base em atributos adicionais de uma solicitação HTTP, por exemplo, caminho de URI ou cabeçalhos de host. Por exemplo, pode encaminhar tráfego com base no URL de origem. Portanto, se /images estiver na URL de entrada, você poderá rotear o tráfego para um conjunto específico de servidores (conhecido como pool) configurado para imagens. Se /video estiver no URL, esse tráfego será roteado para outro pool otimizado para vídeos.

Diagrama mostrando um exemplo de um Gateway de Aplicativo do Azure.

Este tipo de encaminhamento é conhecido como balanceamento de carga da camada de aplicação (camada OSI 7). O Gateway de Aplicação do Azure pode fazer encaminhamento com base no URL e muito mais.

Componentes do Gateway de Aplicação

Um gateway de aplicativo serve como o único ponto de contato para os clientes. Ele distribui o tráfego de entrada de aplicativos em vários pools de back-end, que incluem VMs do Azure, conjuntos de dimensionamento de máquinas virtuais, Serviço de Aplicativo do Azure e servidores locais/externos.

Diagrama mostrando componentes do gateway de aplicativo do Azure.

Infraestrutura

A infraestrutura do Application Gateway inclui a rede virtual, sub-redes, grupos de segurança de rede e rotas definidas pelo usuário.

Endereço IP de front-end

Você pode configurar o gateway de aplicativo para ter um endereço IP público, um endereço IP privado ou ambos. Um IP público é necessário quando você hospeda um back-end que os clientes devem acessar pela Internet por meio de um IP virtual voltado para a Internet (VIP).

Um endereço IP público não é necessário para um ponto de extremidade interno que não está exposto à Internet. Uma configuração de frontend privada é útil para aplicativos internos de linha de negócios que não estão expostos à Internet. Também é útil para serviços e camadas em um aplicativo de várias camadas dentro de um limite de segurança que não estão expostos à Internet, mas que exigem distribuição de carga round-robin, aderência de sessão ou terminação TLS.

Apenas um endereço IP público e um endereço IP privado são suportados. Você escolhe o IP frontend ao criar o gateway de aplicativo.

Nota

O front-end do Application Gateway suporta endereços IP de pilha dupla (visualização pública). Você pode criar até quatro IPs frontend. Dois são endereços IPv4 (públicos e privados) e dois são endereços IPv6 (públicos e privados).

  • Para um endereço IP público, você pode criar um novo endereço IP público ou usar um IP público existente no mesmo local do gateway de aplicativo. Para obter mais informações, consulte Endereço IP público estático versus dinâmico.
  • Para um endereço IP privado, você pode especificar um endereço IP privado da sub-rede onde o gateway de aplicativo é criado. Para implantações de SKU do Application Gateway v2, um endereço IP estático deve ser definido quando você adiciona um endereço IP privado ao gateway. Para implantações de SKU do Application Gateway v1, se você não especificar um endereço IP, um endereço IP disponível será selecionado automaticamente na sub-rede. O tipo de endereço IP selecionado (estático ou dinâmico) não pode ser alterado posteriormente.

Um endereço IP frontend é associado a um ouvinte, que verifica se há solicitações de entrada no IP frontend.

Você pode criar ouvintes privados e públicos com o mesmo número de porta. No entanto, esteja ciente de qualquer grupo de segurança de rede (NSG) associado à sub-rede do Application Gateway. Dependendo da configuração do NSG, você pode precisar de uma regra de permissão de entrada com endereços IP de destino como IPs de frontend públicos e privados do gateway de aplicativo. Quando você usa a mesma porta, o gateway de aplicativo altera o Destino do fluxo de entrada para os IPs front-end do gateway.

Regra de entrada:

  • Fonte: De acordo com a sua exigência
  • Destino: IPs frontend públicos e privados do seu gateway de aplicativo.
  • Porta de destino: de acordo com ouvintes configurados
  • Protocolo: TCP

Regra de saída: Nenhum requisito específico

Serviços de escuta

Um ouvinte é uma entidade lógica que verifica se há solicitações de conexão de entrada usando a porta, o protocolo, o host e o endereço IP. Ao configurar o ouvinte, você deve inserir valores para eles que correspondam aos valores correspondentes na solicitação de entrada no gateway.

Ao criar um gateway de aplicativo usando o portal do Azure, você também cria um ouvinte padrão escolhendo o protocolo e a porta para o ouvinte. Você pode escolher se deseja habilitar o suporte a HTTP2 no ouvinte. Depois de criar o gateway de aplicativo, você pode editar as configurações desse ouvinte padrão (appGatewayHttpListener) ou criar novos ouvintes.

Tipo de ouvinte

Um ouvinte é uma entidade lógica que verifica se há solicitações de conexão de entrada. Um ouvinte aceita uma solicitação se o protocolo, a porta, o nome do host e o endereço IP associados à solicitação corresponderem aos mesmos elementos associados à configuração do ouvinte.

Antes de usar um gateway de aplicativo, você deve adicionar pelo menos um ouvinte. Pode haver vários ouvintes conectados a um gateway de aplicativo e eles podem ser usados para o mesmo protocolo.

Depois que um ouvinte deteta solicitações de entrada de clientes, o gateway de aplicativo roteia essas solicitações para membros no pool de back-end configurado na regra.

Os ouvintes suportam as seguintes portas e protocolos.

Portas

Uma porta é onde um ouvinte escuta a solicitação do cliente. Você pode configurar portas para SKUs v1 e v2 conforme abaixo.

SKU Intervalo de portas suportado Exceção(ões)
V2 1 a 64999 22
V1 1 a 65502 3389

Protocolos

O Application Gateway suporta quatro protocolos: HTTP, HTTPS, HTTP/2 e WebSocket:

Nota

O suporte ao protocolo HTTP/2 está disponível apenas para clientes que se conectam a ouvintes do gateway de aplicativo. A comunicação com pools de servidores back-end é sempre via HTTP/1.1. Por padrão, o suporte a HTTP/2 está desativado. Você pode optar por ativá-lo.

  • Especifique entre os protocolos HTTP e HTTPS na configuração do ouvinte.
  • O suporte para WebSockets e protocolos HTTP/2 é fornecido nativamente, e o suporte a WebSocket é habilitado por padrão. Não existe qualquer definição configurável pelo utilizador para ativar ou desativar seletivamente o suporte de WebSocket. Use WebSockets com ouvintes HTTP e HTTPS.

Use um ouvinte HTTPS para terminação TLS. Um ouvinte HTTPS descarrega o trabalho de criptografia e descriptografia para seu gateway de aplicativo, para que seus servidores Web não sejam sobrecarregados pela sobrecarga.

Pedir regras de encaminhamento

Ao criar um gateway de aplicativo usando o portal do Azure, você cria uma regra padrão (regra1). Esta regra vincula o ouvinte padrão (appGatewayHttpListener) ao pool de back-end padrão (appGatewayBackendPool) e às configurações HTTP de back-end padrão (appGatewayBackendHttpSettings). Depois de criar o gateway, você pode editar as configurações da regra padrão ou criar novas regras.

Tipo de regra

Ao criar uma regra, você escolhe entre básico e baseado em caminho.

  • Escolha básico se quiser encaminhar todas as solicitações no ouvinte associado (por exemplo, blog.contoso.com/*) para um único pool de back-end.
  • Escolha com base em caminho se quiser rotear solicitações de caminhos de URL específicos para pools de back-end específicos. O padrão de caminho é aplicado apenas ao caminho da URL, não aos seus parâmetros de consulta.

Ouvinte associado

Associe um ouvinte à regra para que a regra de roteamento de solicitação associada ao ouvinte seja avaliada para determinar o pool de back-end para o qual rotear a solicitação.

Pool de back-end associado

Associe à regra o pool de back-end que contém os destinos de back-end que atendem às solicitações recebidas pelo ouvinte.

  • Para uma regra básica, apenas um pool de back-end é permitido. Todas as solicitações no ouvinte associado são encaminhadas para esse pool de back-end.
  • Para uma regra baseada em caminho, adicione vários pools de back-end que correspondam a cada caminho de URL. As solicitações que correspondem ao caminho de URL inserido são encaminhadas para o pool de back-end correspondente. Além disso, adicione um pool de back-end padrão. As solicitações que não correspondem a nenhum caminho de URL na regra são encaminhadas para esse pool.

Configuração HTTP de back-end associada

Adicione uma configuração HTTP de back-end para cada regra. As solicitações são roteadas do gateway de aplicativo para os destinos de back-end usando o número da porta, o protocolo e outras informações especificadas nessa configuração.

Para uma regra básica, apenas uma configuração HTTP de back-end é permitida. Todas as solicitações no ouvinte associado são encaminhadas para os destinos de back-end correspondentes usando essa configuração HTTP.

Para uma regra baseada em caminho, adicione várias configurações HTTP de back-end que correspondam a cada caminho de URL. As solicitações que correspondem ao caminho da URL nessa configuração são encaminhadas para os destinos de back-end correspondentes usando as configurações HTTP que correspondem a cada caminho de URL. Além disso, adicione uma configuração HTTP padrão. As solicitações que não correspondem a nenhum caminho de URL nesta regra são encaminhadas para o pool de back-end padrão usando a configuração HTTP padrão.

Configuração de redirecionamento

Se o redirecionamento estiver configurado para uma regra básica, todas as solicitações no ouvinte associado serão redirecionadas para o destino. Trata-se de um redirecionamento global . Se o redirecionamento for configurado para uma regra baseada em caminho, somente as solicitações em uma área específica do site serão redirecionadas. Um exemplo é uma área de carrinho de compras indicada por /cart/*. Trata-se de um redirecionamento baseado em caminhos.

Serviço de Escuta

Escolha ouvinte como destino de redirecionamento para redirecionar o tráfego de um ouvinte para outro no gateway. Essa configuração é necessária quando você deseja habilitar o redirecionamento HTTP-to-HTTPS. Ele redireciona o tráfego do ouvinte de origem que verifica as solicitações HTTP de entrada para o ouvinte de destino que verifica as solicitações HTTPS de entrada. Você também pode optar por incluir a cadeia de caracteres de consulta e o caminho da solicitação original na solicitação encaminhada para o destino de redirecionamento.

Captura de tela mostrando um exemplo da página de definições de configuração de redirecionamento.

Sítio externo

Escolha site externo quando quiser redirecionar o tráfego no ouvinte associado a essa regra para um site externo. Você pode optar por incluir a cadeia de caracteres de consulta da solicitação original na solicitação encaminhada para o destino de redirecionamento. Não é possível encaminhar o caminho para o site externo que estava na solicitação original.

Rescrever cabeçalhos HTTP e URL

Usando regras de reescrita, você pode adicionar, remover ou atualizar cabeçalhos de solicitação e resposta HTTP(S), bem como parâmetros de caminho de URL e cadeia de caracteres de consulta à medida que os pacotes de solicitação e resposta se movem entre o cliente e os pools de back-end por meio do gateway de aplicativo.

Os cabeçalhos e parâmetros de URL podem ser definidos como valores estáticos ou para outros cabeçalhos e variáveis de servidor. Isso ajuda em casos de uso importantes, como extrair endereços IP de clientes, remover informações confidenciais sobre o back-end, adicionar mais segurança e assim por diante.

Definições de HTTP

O gateway de aplicativo roteia o tráfego para os servidores back-end usando a configuração especificada aqui. Depois de criar uma configuração HTTP, você deve associá-la a uma ou mais regras de roteamento de solicitação.

O Gateway de Aplicativo do Azure usa cookies gerenciados por gateway para manter sessões de usuário. Quando um utilizador envia o primeiro pedido para o Gateway de Aplicação, define um cookie de afinidade na resposta com um valor hash que contém os detalhes da sessão, pelo que os pedidos subsequentes que transportam o cookie de afinidade serão encaminhados para o mesmo servidor de back-end para manter a persistência.

Esse recurso é útil quando você deseja manter uma sessão de usuário no mesmo servidor e quando o estado da sessão é salvo localmente no servidor para uma sessão de usuário. Se o aplicativo não puder lidar com a afinidade baseada em cookies, você não poderá usar esse recurso. Para usá-lo, certifique-se de que os clientes suportam cookies.

Nota

Algumas verificações de vulnerabilidade podem sinalizar o cookie de afinidade do Application Gateway porque os sinalizadores Secure ou HttpOnly não estão definidos. Essas verificações não levam em conta que os dados no cookie são gerados usando um hash unidirecional. O cookie não contém nenhuma informação do usuário e é usado exclusivamente para roteamento.

Drenagem de ligação

A drenagem da conexão ajuda você a remover normalmente os membros do pool de back-end durante as atualizações de serviço planejadas. Aplica-se a instâncias de back-end que são

  • explicitamente removido do pool de back-end,
  • removidos durante operações de expansão, ou
  • notificados como insalubres pelas sondas de saúde.

Você pode aplicar essa configuração a todos os membros do pool de back-end habilitando a Drenagem de Conexões na Configuração de Back-end. Ele garante que todas as instâncias de cancelamento de registro em um pool de back-end não recebam novas solicitações/conexões enquanto mantém as conexões existentes até o valor de tempo limite configurado. Isso também é verdade para conexões WebSocket.

Tipo de configuração Valor
Valor padrão quando a Drenagem de Conexão não está habilitada na Configuração de Back-end 30 segundos
Valor definido pelo usuário quando a Drenagem de Conexão está habilitada na Configuração de Back-end 1 a 3600 segundos

A única exceção a isso são solicitações vinculadas para cancelamento de registro de instâncias devido à afinidade de sessão gerenciada pelo gateway e continuarão a ser encaminhadas para as instâncias de cancelamento de registro.

Protocolo

O Application Gateway suporta HTTP e HTTPS para rotear solicitações para os servidores back-end. Se você escolher HTTP, o tráfego para os servidores back-end não será criptografado. Se a comunicação não criptografada não for aceitável, escolha HTTPS.

Essa configuração combinada com HTTPS no ouvinte oferece suporte a TLS de ponta a ponta. Isso permite que você transmita com segurança dados confidenciais criptografados para o back-end. Cada servidor back-end no pool de back-end que tem TLS de ponta a ponta habilitado deve ser configurado com um certificado para permitir uma comunicação segura.

Porta

Essa configuração especifica a porta onde os servidores back-end escutam o tráfego do gateway de aplicativo. Você pode configurar portas que variam de 1 a 65535.

Certificado raiz confiável

Se você selecionar HTTPS como o protocolo de back-end, o Application Gateway exigirá um certificado raiz confiável para confiar no pool de back-end para SSL de ponta a ponta. Por padrão, a opção Usar certificado de autoridade de certificação conhecido está definida como Não. Se você planeja usar um certificado autoassinado ou um certificado assinado por uma Autoridade de Certificação interna, deverá fornecer ao Gateway de Aplicativo o certificado público correspondente que o pool de back-end usará. Esse certificado deve ser carregado diretamente no Application Gateway em . Formato CER.

Se você planeja usar um certificado no pool de back-end assinado por uma Autoridade de Certificação pública confiável, pode definir a opção Usar certificado de CA conhecido como Sim e ignorar o carregamento de um certificado público.

Tempo limite do pedido

Essa configuração é o número de segundos que o gateway de aplicativo aguarda para receber uma resposta do servidor back-end.

Substituir caminho de back-end

Essa configuração permite configurar um caminho de encaminhamento personalizado opcional para usar quando a solicitação for encaminhada para o back-end. Qualquer parte do caminho de entrada que corresponda ao caminho personalizado no campo de caminho de back-end de substituição é copiada para o caminho encaminhado. A tabela a seguir mostra como esse recurso funciona:

Quando a configuração HTTP é anexada a uma regra básica de roteamento de solicitação:

Pedido original Substituir caminho de back-end Solicitação encaminhada para back-end
/Casa/ /substituição/ /substituição/home/
/home/secondhome/ /substituição/ /substituição/home/secondhome/

Quando a configuração HTTP é anexada a uma regra de roteamento de solicitação baseada em caminho:

Pedido original Regra de caminho Substituir caminho de back-end Solicitação encaminhada para back-end
/pathrule/home/ /pathrule* /substituição/ /substituição/home/
/pathrule/home/secondhome/ /pathrule* /substituição/ /substituição/home/secondhome/
/Casa/ /pathrule* /substituição/ /substituição/home/
/home/secondhome/ /pathrule* /substituição/ /substituição/home/secondhome/
/pathrule/home/ /pathrule/início* /substituição/ /substituição/
/pathrule/home/secondhome/ /pathrule/início* /substituição/ /substituição/secondhome/
/pathrule/ /pathrule/ /substituição/ /substituição/

Usar sonda personalizada

Essa configuração associa uma sonda personalizada a uma configuração HTTP. Você pode associar apenas um teste personalizado a uma configuração HTTP. Se você não associar explicitamente uma sonda personalizada, a sonda padrão será usada para monitorar a integridade do back-end. Recomendamos que você crie uma sonda personalizada para maior controle sobre o monitoramento de integridade de seus back-ends.

Nota

O teste personalizado não monitora a integridade do pool de back-end, a menos que a configuração HTTP correspondente esteja explicitamente associada a um ouvinte.

Configurando o nome do host

O Application Gateway permite que a conexão estabelecida com o back-end use um nome de host diferente daquele usado pelo cliente para se conectar ao Application Gateway. Embora essa configuração possa ser útil em alguns casos, substituir o nome do host para ser diferente entre o cliente e o gateway de aplicativo e o gateway de aplicativo para o destino de back-end deve ser feito com cuidado.

Na produção, é recomendável manter o nome do host usado pelo cliente para o gateway de aplicativo como o mesmo nome de host usado pelo gateway de aplicativo para o destino de back-end. Isso evita possíveis problemas com URLs absolutos, URLs de redirecionamento e cookies vinculados ao host.

Antes de configurar o Application Gateway que se desvia disso, revise as implicações de tal configuração, conforme discutido com mais detalhes no Centro de arquitetura: Preservar o nome de host HTTP original entre um proxy reverso e seu aplicativo Web de back-end.

Há dois aspetos de uma configuração HTTP que influenciam o cabeçalho HTTP do Host usado pelo Application Gateway para se conectar ao back-end:

  • Escolha o nome do host no endereço de back-end
  • Substituição do nome do host

Escolha o nome do host do endereço de back-end

Esse recurso define dinamicamente o cabeçalho do host na solicitação como o nome do host do pool de back-end. Ele usa um endereço IP ou FQDN.

Esse recurso ajuda quando o nome de domínio do back-end é diferente do nome DNS do gateway de aplicativo, e o back-end depende de um cabeçalho de host específico para resolver para o ponto de extremidade correto.

Um exemplo de caso são os serviços multilocatários como back-end. Um serviço de aplicativo é um serviço multilocatário que usa um espaço compartilhado com um único endereço IP. Assim, um serviço de aplicativo só pode ser acessado por meio dos nomes de host configurados nas configurações de domínio personalizadas.

Por padrão, o nome de domínio personalizado é example.azurewebsites.net. Para acessar seu serviço de aplicativo usando um gateway de aplicativo por meio de um nome de host que não esteja explicitamente registrado no serviço de aplicativo ou por meio do FQDN do gateway de aplicativo, você pode substituir o nome do host na solicitação original pelo nome de host do serviço de aplicativo. Para fazer isso, habilite a configuração de escolha do nome do host no endereço de back-end.

Para um domínio personalizado cujo nome DNS personalizado existente é mapeado para o serviço de aplicativo, a configuração recomendada não é habilitar o nome de host de seleção do endereço de back-end.

Substituição do nome do host

Esse recurso substitui o cabeçalho do host na solicitação de entrada no gateway de aplicativo pelo nome do host especificado.

Por exemplo, se www.contoso.com for especificado na configuração Nome do host , a solicitação original *https://appgw.eastus.cloudapp.azure.com/path1será alterada para *https://www.contoso.com/path1 quando a solicitação for encaminhada para o servidor back-end.

Conjunto de back-end

Você pode apontar um pool de back-end para quatro tipos de membros de back-end: uma máquina virtual específica, um conjunto de dimensionamento de máquina virtual, um endereço IP/FQDN ou um serviço de aplicativo.

Depois de criar um pool de back-end, você deve associá-lo a uma ou mais regras de roteamento de solicitação. Você também deve configurar testes de integridade para cada pool de back-end no gateway de aplicativo. Quando uma condição de regra de roteamento de solicitação é atendida, o gateway de aplicativo encaminha o tráfego para os servidores íntegros (conforme determinado pelas sondas de integridade) no pool de back-end correspondente.

Sondas do estado de funcionamento

O Gateway de Aplicativo do Azure monitora a integridade de todos os servidores em seu pool de back-end e interrompe automaticamente o envio de tráfego para qualquer servidor que considere não íntegro. Os testes continuam a monitorar esse servidor não íntegro e o gateway começa a rotear o tráfego para ele mais uma vez assim que os testes o detetam como íntegro.

O teste padrão usa o número da porta da Configuração de back-end associada e outras configurações predefinidas. Você pode usar Sondas Personalizadas para configurá-las à sua maneira.

Comportamento das sondas

Endereço IP de origem

O endereço IP de origem dos testes depende do tipo de servidor back-end:

  • Se o servidor no pool de back-end for um ponto de extremidade público, o endereço de origem será o endereço IP público de front-end do gateway de aplicativo.
  • Se o servidor no pool de back-end for um ponto de extremidade privado, o endereço IP de origem será do espaço de endereço da sub-rede do gateway de aplicativo.

Operações de sonda

Um gateway começa a disparar testes imediatamente após configurar uma Regra, associando-a a uma Configuração de Back-end e Pool de Back-end (e ao Ouvinte, é claro). A ilustração mostra que o gateway investiga independentemente todos os servidores do pool de back-end. As solicitações de entrada que começam a chegar são enviadas apenas para os servidores íntegros. Um servidor back-end é marcado como não íntegro por padrão até que uma resposta de teste bem-sucedida seja recebida.

Diagrama mostrando um exemplo de operações de investigação de integridade do gateway de aplicativo do Azure.

Os testes necessários são determinados com base na combinação exclusiva do Servidor de Back-end e da Configuração de Back-end. Por exemplo, considere um gateway com um único pool de back-end com dois servidores e duas configurações de back-end, cada um com números de porta diferentes. Quando essas configurações distintas de back-end são associadas ao mesmo pool de back-end usando suas respetivas regras, o gateway cria testes para cada servidor e a combinação da configuração de back-end. Você pode visualizar isso na página Integridade do back-end.

Captura de tela mostrando um exemplo das configurações de integridade do back-end.

Além disso, todas as instâncias do gateway de aplicativo investigam os servidores back-end independentemente uns dos outros.

Nota

O relatório de integridade do back-end é atualizado com base no intervalo de atualização do respetivo teste e não depende da solicitação do usuário.

Sonda de integridade padrão

Um gateway de aplicativo configura automaticamente uma sonda de integridade padrão quando você não configura nenhuma configuração de teste personalizada. O comportamento de monitoramento funciona fazendo uma solicitação HTTP GET para os endereços IP ou FQDN configurados no pool de back-end. Para testes padrão, se as configurações http de back-end estiverem definidas para HTTPS, o teste usará HTTPS para testar a integridade dos servidores de back-end.

Por exemplo: você configura seu gateway de aplicativo para usar servidores de back-end A, B e C para receber tráfego de rede HTTP na porta 80. O monitoramento de integridade padrão testa os três servidores a cada 30 segundos para obter uma resposta HTTP íntegra com um tempo limite de 30 segundos para cada solicitação. Uma resposta HTTP saudável tem um código de status entre 200 e 399. Nesse caso, a solicitação HTTP GET para o teste de integridade se parece com http://127.0.0.1/. Consulte também Códigos de resposta HTTP no Application Gateway.

Se a verificação de teste padrão falhar para o servidor A, o gateway de aplicativo interromperá o encaminhamento de solicitações para esse servidor. O teste padrão ainda continua a verificar o servidor A a cada 30 segundos. Quando o servidor A responde com êxito a uma solicitação de uma investigação de integridade padrão, o gateway de aplicativo começa a encaminhar as solicitações para o servidor novamente.

Configurações padrão da sonda de integridade

Propriedade da sonda Valor Descrição
URL da sonda <protocolo>://127.0.0.1:<port>/ O protocolo e a porta são herdados das configurações HTTP de back-end às quais a sonda está associada
Intervalo 30 A quantidade de tempo, em segundos, para aguardar antes que a próxima sonda de integridade seja enviada.
Limite de Tempo Excedido 30 A quantidade de tempo, em segundos, que o gateway de aplicativo aguarda uma resposta de teste antes de marcar a sonda como não íntegra. Se um teste retornar como íntegro, o back-end correspondente será imediatamente marcado como íntegro.
Limiar com funcionamento incorreto 3 Governa quantas sondas enviar no caso de haver uma falha da sonda de integridade regular. No SKU v1, esses testes de integridade adicionais são enviados em rápida sucessão para determinar a integridade do back-end rapidamente e não esperar pelo intervalo de teste. Para o SKU v2, as sondas de integridade aguardam o intervalo. O servidor back-end é marcado para baixo depois que a contagem de falhas de teste consecutivas atinge o limite não íntegro.

O teste padrão examina apenas protocol<>://127.0.0.1:<port> para determinar o status de integridade. Se você precisar configurar o teste de integridade para ir para uma URL personalizada ou modificar quaisquer outras configurações, deverá usar testes personalizados.

Sonda de integridade personalizada

As sondas personalizadas permitem que você tenha um controle mais granular sobre o monitoramento de integridade. Ao usar testes personalizados, você pode configurar um nome de host personalizado, caminho de URL, intervalo de teste e quantas respostas com falha aceitar antes de marcar a instância do pool de back-end como não íntegra, etc.

Configurações personalizadas da sonda de integridade

A tabela a seguir fornece definições para as propriedades de uma investigação de integridade personalizada.

Propriedade da sonda Descrição
Name Nome da sonda. Esse nome é usado para identificar e fazer referência ao teste nas configurações HTTP de back-end.
Protocolo Protocolo usado para enviar a sonda. Isso tem que corresponder ao protocolo definido nas configurações HTTP de back-end às quais está associado
Host Nome do host para enviar a sonda. Na SKU v1, esse valor é usado apenas para o cabeçalho do host da solicitação de teste. No SKU v2, ele é usado como cabeçalho de host e SNI
Caminho Caminho relativo da sonda. Um caminho válido começa com '/'
Porta Se definido, ele é usado como a porta de destino. Caso contrário, ele usa a mesma porta que as configurações HTTP às quais está associado. Esta propriedade só está disponível na v2 SKU
Intervalo Intervalo da sonda em segundos. Este valor é 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 consecutivas de teste atinge o limite não íntegro

Correspondência de sonda

Por padrão, uma resposta HTTP(S) com código de status entre 200 e 399 é considerada íntegra. Além disso, as sondas de integridade personalizadas oferecem suporte a dois critérios de correspondência. Os critérios de correspondência podem ser usados para, opcionalmente, modificar a interpretação padrão do que torna uma resposta saudável.

Os critérios de correspondência são os seguintes:

  • Correspondência de código de status de resposta HTTP - Critério de correspondência de sonda para aceitar códigos de resposta http especificados pelo usuário ou intervalos de códigos de resposta. Códigos de status de resposta separados por vírgulas individuais ou um intervalo de códigos de status são suportados.
  • Correspondência de corpo de resposta HTTP - Critério de correspondência de teste que examina o corpo da resposta HTTP e corresponde a uma cadeia de caracteres especificada pelo usuário. A correspondência procura apenas a presença da cadeia de caracteres especificada pelo usuário no corpo da resposta e não é uma correspondência de expressão regular completa. A correspondência especificada deve ter 4090 caracteres ou menos.

Os critérios de correspondência podem ser especificados usando o New-AzApplicationGatewayProbeHealthResponseMatch cmdlet.

Por exemplo:

Azure PowerShell

$match = New-AzApplicationGatewayProbeHealthResponseMatch -StatusCode 200-399




$match = New-AzApplicationGatewayProbeHealthResponseMatch -Body "Healthy"

Os critérios de correspondência podem ser anexados à configuração da sonda usando um -Match operador no PowerShell.

Casos de uso de sonda personalizada

  • Se um servidor back-end permitir acesso apenas a usuários autenticados, as sondas do gateway de aplicativo receberão um código de resposta 403 em vez de 200. Como os clientes (usuários) são obrigados a autenticar-se para o tráfego ao vivo, você pode configurar o tráfego de teste para aceitar 403 como uma resposta esperada.
  • Quando um servidor back-end tem um certificado curinga (*.contoso.com) instalado para servir subdomínios diferentes, você pode usar uma sonda personalizada com um nome de host específico (necessário para SNI) que é aceito para estabelecer uma sonda TLS bem-sucedida e relatar esse servidor como íntegro. Com "substituir nome de host" na Configuração de back-end definida como NO, os diferentes nomes de host de entrada (subdomínios) serão passados como estão para o back-end.

Considerações sobre o NSG (grupo de segurança de rede)

O controle de grão fino sobre a sub-rede do Application Gateway por meio de regras NSG é possível na visualização pública. Estão disponíveis mais detalhes aqui.

Com a funcionalidade atual existem algumas restrições:

Você deve permitir o tráfego de entrada da Internet nas portas TCP 65503-65534 para a SKU do Application Gateway v1 e nas portas TCP 65200-65535 para a SKU v2 com a sub-rede de destino como Qualquer e origem como marca de serviço GatewayManager. Este intervalo de portas é necessário para a comunicação da infraestrutura do Azure.

Além disso, a conectividade de saída com a Internet não pode ser bloqueada e o tráfego de entrada proveniente da marca AzureLoadBalancer deve ser permitido.

Como funciona um gateway de aplicativo

Diagrama mostrando um exemplo de como um gateway de aplicativo do Azure funciona.

Como um gateway de aplicativo aceita uma solicitação

  1. Antes de enviar uma solicitação para um gateway de aplicativo, ele resolve o nome de domínio do gateway de aplicativo usando um servidor DNS (Sistema de Nomes de Domínio). O Azure controla a entrada DNS porque todos os gateways de aplicativos estão no domínio azure.com.
  2. O DNS do Azure retorna o endereço IP para o cliente, que é o endereço IP frontend do gateway de aplicativo.
  3. O gateway de aplicativo aceita tráfego de entrada em um ou mais ouvintes. Um ouvinte é uma entidade lógica que verifica se há solicitações de conexão. Ele é configurado com um endereço IP frontend, protocolo e número de porta para conexões de clientes ao gateway de aplicativo.
  4. Se um firewall de aplicativo Web (WAF) estiver em uso, o gateway de aplicativo verificará os cabeçalhos de solicitação e o corpo, se presente, em relação às regras WAF. Essa ação determina se a solicitação é uma solicitação válida ou uma ameaça à segurança. Se a solicitação for válida, ela será roteada para o back-end. Se a solicitação não for válida e o WAF estiver no modo de Prevenção, ela será bloqueada como uma ameaça à segurança. Se estiver no modo de Deteção, a solicitação será avaliada e registrada, mas ainda encaminhada para o servidor de back-end.

O Gateway de Aplicativo do Azure pode ser usado como um balanceador de carga de aplicativo interno ou como um balanceador de carga de aplicativo voltado para a Internet. Um gateway de aplicativo voltado para a Internet usa endereços IP públicos. O nome DNS de um gateway de aplicativo voltado para a Internet pode ser resolvido publicamente para seu endereço IP público. Como resultado, gateways de aplicativos voltados para a Internet podem rotear solicitações de clientes da Internet.

Os gateways de aplicativos internos usam apenas endereços IP privados. Se você estiver usando uma zona DNS personalizada ou privada, o nome de domínio deverá ser resolvido internamente para o endereço IP privado do Application Gateway. Portanto, os balanceadores de carga internos só podem rotear solicitações de clientes com acesso a uma rede virtual para o gateway de aplicativo.

Como um gateway de aplicativo roteia uma solicitação

Se uma solicitação for válida e não for bloqueada pelo WAF, o gateway de aplicativo avaliará a regra de roteamento de solicitação associada ao ouvinte. Essa ação determina para qual pool de back-end encaminhar a solicitação.

Com base na regra de roteamento de solicitações, o gateway de aplicativo determina se todas as solicitações no ouvinte devem ser roteadas para um pool de back-end específico, encaminhadas solicitações para diferentes pools de back-end com base no caminho da URL ou redirecionam solicitações para outra porta ou site externo.

Quando o gateway de aplicativo seleciona o pool de back-end, ele envia a solicitação para um dos servidores back-end íntegros no pool (y.y.y.y). A integridade do servidor é determinada por uma sonda de integridade. Se o pool de back-end contiver vários servidores, o gateway de aplicativo usará um algoritmo round-robin para rotear as solicitações entre servidores íntegros. Isso equilibra a carga das solicitações nos servidores.

Depois que o gateway de aplicativo determina o servidor back-end, ele abre uma nova sessão TCP com o servidor back-end com base nas configurações HTTP. As configurações HTTP especificam o protocolo, a porta e outras configurações relacionadas ao roteamento necessárias para estabelecer uma nova sessão com o servidor back-end.

A porta e o protocolo usados nas configurações HTTP determinam se o tráfego entre o gateway de aplicativo e os servidores back-end é criptografado (realizando assim TLS de ponta a ponta) ou não está criptografado.

Nota

As regras são processadas na ordem em que estão listadas no portal para v1 SKU.

Quando um gateway de aplicativo envia a solicitação original para o servidor back-end, ele respeita qualquer configuração personalizada feita nas configurações HTTP relacionadas à substituição do nome do host, caminho e protocolo. Essa ação mantém a afinidade de sessão baseada em cookies, drenagem de conexão, seleção de nome de host do back-end e assim por diante.

Se o pool de back-end:

  • É um ponto de extremidade público, o gateway de aplicativo usa seu IP público frontend para alcançar o servidor. Se não houver um endereço IP público frontend, um será atribuído para a conectividade externa de saída.
  • Contém um FQDN resolúvel internamente ou um endereço IP privado, o gateway de aplicativo roteia a solicitação para o servidor back-end usando seus endereços IP privados de instância.
  • Contém um ponto de extremidade externo ou um FQDN resolúvel externamente, o gateway de aplicativo roteia a solicitação para o servidor back-end usando seu endereço IP público frontend. Se a sub-rede contiver pontos de extremidade de serviço, o gateway de aplicativo encaminhará a solicitação para o serviço por meio de seu endereço IP privado. A resolução DNS é baseada em uma zona DNS privada ou servidor DNS personalizado, se configurado, ou usa o DNS padrão fornecido pelo Azure. Se não houver um endereço IP público frontend, um será atribuído para a conectividade externa de saída.

Resolução DNS do servidor de back-end

Quando o servidor de um pool de back-end é configurado com um FQDN (Nome de Domínio Totalmente Qualificado), o Application Gateway executa uma pesquisa de DNS para obter o(s) endereço(s) IP(s) do nome de domínio. O valor IP é armazenado no cache do gateway de aplicativos para permitir que ele atinja os destinos mais rapidamente ao atender solicitações de entrada.

O Application Gateway retém essas informações armazenadas em cache pelo período equivalente ao TTL (tempo de vida) desse registro DNS e executa uma nova pesquisa de DNS quando o TTL expira. Se um gateway detetar uma alteração no endereço IP para sua consulta DNS subsequente, ele começará a rotear o tráfego para esse destino atualizado. Em caso de problemas como a pesquisa de DNS não receber uma resposta ou o registro não existir mais, o gateway continuará a usar o(s) último(s) endereço(s) IP em boas condições. Isso garante um impacto mínimo no caminho de dados.

  • Ao usar servidores DNS personalizados com a Rede Virtual do Application Gateway, é crucial que todos os servidores sejam idênticos e respondam consistentemente com os mesmos valores de DNS.
  • Os usuários de servidores DNS personalizados locais devem garantir a conectividade com o DNS do Azure por meio do Resolvedor Privado de DNS do Azure (recomendado) ou da VM de encaminhador DNS ao usar uma zona DNS Privada para ponto de extremidade Privado.

Alterações ao pedido

O gateway de aplicativo insere seis cabeçalhos adicionais para todas as solicitações antes de encaminhar as solicitações para o back-end. Esses cabeçalhos são x-forwarded-for, x-forwarded-port, x-forwarded-proto, x-original-host, x-original-url e x-appgw-trace-id. O formato do cabeçalho x-forwarded-for é uma lista separada por vírgulas de IP:port.

Os valores válidos para x-forwarded-proto são HTTP ou HTTPS. X-forwarded-port especifica a porta onde a solicitação chegou ao gateway de aplicativo. X-original-host header contém o cabeçalho de host original com o qual a solicitação chegou. Esse cabeçalho é útil na integração do site do Azure, onde o cabeçalho do host de entrada é modificado antes que o tráfego seja roteado para o back-end. Se a afinidade de sessão estiver habilitada como uma opção, ela adicionará um cookie de afinidade gerenciado pelo gateway.

X-appgw-trace-id é um guid exclusivo gerado pelo gateway de aplicativo para cada solicitação de cliente e apresentado na solicitação encaminhada para o membro do pool de back-end. O guid consiste em 32 caracteres alfanuméricos apresentados sem traços (por exemplo: ac882cd65a2712a0fe1289ec2bb6aee7). Esse guid pode ser usado para correlacionar uma solicitação recebida pelo gateway de aplicativo e iniciada a um membro do pool de back-end por meio da propriedade transactionId nos Logs de Diagnóstico.

Você pode configurar o gateway de aplicativo para modificar cabeçalhos de solicitação e resposta e URL usando Reescrever cabeçalhos HTTP e URL ou para modificar o caminho de URI usando uma configuração de substituição de caminho. No entanto, a menos que configurado para fazer isso, todas as solicitações de entrada são intermediadas por proxy para o back-end.