Planejar e implementar um Gateway de Aplicativo do Azure

Concluído

O Gateway de Aplicativo do Azure é um balanceador de carga de tráfego da Web (camada 7 OSI) que permite que você gerencie o tráfego para seus aplicativos Web. Os balanceadores de carga tradicionais operam na camada de transporte (camada OSI 4 – TCP e UDP) e encaminham o tráfego com base no endereço IP de origem e na porta para um endereço IP de destino e uma porta.

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

Esse tipo de roteamento é conhecido como balanceamento de carga da camada de aplicativo (camada OSI 7). O Gateway de Aplicativo do Azure pode fazer o roteamento baseado em URL e muito mais.

Componentes do Gateway de Aplicativo

Um gateway de aplicativo serve como o único ponto de contato para clientes. Ele distribui o tráfego de aplicativo de entrada entre 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.

Infraestrutura

A infraestrutura do Gateway de Aplicativo inclui 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 VIP (IP virtual) voltado para a Internet.

Um endereço IP público não é necessário para um ponto de extremidade interno que não esteja exposto à Internet. Uma configuração de front-end privado é útil para aplicativos de linha de negócios internos que não são expostos à Internet. Isso também é útil para serviços e camadas em um aplicativo multicamada em um limite de segurança que não estejam expostos à Internet, mas que ainda exigem distribuição de carga round-robin, adesão da sessão ou terminação TLS.

Há suporte para apenas um endereço IP público e um endereço IP privado. Você escolhe o IP de front-end ao criar o gateway de aplicativo.

Observação

O front-end do Gateway de Aplicativo agora dá suporte a endereços IP de pilha dupla (visualização pública). Você pode criar até quatro IPs de front-end. 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 endereço IP público ou usar um IP público existente no mesmo local que o gateway de aplicativo. Para obter mais informações, consulte Endereço IP público estático vs. endereço IP público dinâmico.
• Para um endereço IP privado, você pode especificar um endereço IP privado da sub-rede em que o gateway de aplicativo é criado. Para implantações do SKU do Gateway de Aplicativo v2, um endereço IP estático precisa ser definido ao adicionar um endereço IP privado ao gateway. Para implantações de SKU do Gateway de Aplicativo v1, se você não especificar nenhum endereço IP, um disponível será selecionado automaticamente na sub-rede. O tipo de endereço IP que você selecionar (estático ou dinâmico) não poderá ser alterado posteriormente.

Um endereço IP de front-end é associado a um ouvinte, que verifica as solicitações de entrada no IP de front-end.

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

Regra de entrada:

• Origem: de acordo com suas necessidades
  
• Destino: IPs de front-end 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

Ouvintes

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

Ao criar um gateway de aplicativo usando o portal do Azure, você também escolhe o protocolo e a porta para criar um ouvinte padrão. 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 as solicitações de conexão de entrada. Um ouvinte aceitará 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 anexados a um gateway de aplicativo e eles podem ser usados para o mesmo protocolo.

Depois que um ouvinte detecta 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 dão suporte às portas e aos protocolos a seguir.

Portas

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

SKU	Intervalo de portas com suporte	Exceções
V2	1 a 64999	22
V1	1 a 65502	3389

Protocolos

O Gateway de Aplicativo fornece suporte a quatro protocolos: HTTP, HTTPS, HTTP/2 e WebSocket:

Observação

O suporte ao protocolo HTTP/2 está disponível para os clientes que se conectam apenas os ouvintes do Gateway de Aplicativo. A comunicação para pools de servidores back-end é sempre sobre HTTP/1.1. Por padrão, o suporte HTTP/2 está desabilitado. Você pode optar por habilitá-lo.

• Especifique entre os protocolos HTTP e HTTPS na configuração do ouvinte.
• O suporte para os protocolos WebSockets e http/2 é fornecido nativamente, e o suporte ao WebSocket está habilitado por padrão. Não há nenhuma configuração configurável pelo usuário para habilitar ou desabilitar seletivamente o suporte ao WebSocket. Use Websockets com ouvintes HTTP e HTTPS.

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

Regras de roteamento de solicitação

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

Tipo de regra

Ao criar uma regra, você escolherá entre básica e baseada em caminho.

• Escolha Básico se desejar encaminhar todas as solicitações no ouvinte associado (por exemplo, blog.contoso.com/*) para um só pool de back-end.
  
• Escolha "Baseado em caminho" se desejar rotear as solicitações de caminhos de URL específicos para pools de back-end específicos. O padrão de caminho é aplicado somente 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-ends para o qual a solicitação será roteada.

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 correspondem 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 de HTTP de back-end associado

Adicione uma configuração de 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 na configuração.

Para uma regra básica, apenas uma configuração de 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 de HTTP.

Para uma regra baseada em caminho, adicione várias configurações de HTTP de back-end que correspondem 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 de HTTP que correspondem a cada caminho de URL. Além disso, adicione uma configuração de HTTP padrão. As solicitações que não correspondem a nenhum caminho de URL nessa regra são encaminhadas para o pool de back-end padrão usando a configuração de 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. Esse é o redirecionamento global. Se o redirecionamento estiver 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 que é denotada por /cart/*. Esse é o redirecionamento baseado em caminho.

Ouvinte

Escolha o ouvinte como o 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 de HTTP para 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 que é encaminhada para o destino de redirecionamento.

Site externo

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

Reescrever cabeçalhos HTTP e URL

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

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

Configurações de HTTP

O gateway de aplicativo vai rotear o tráfego para os servidores de back-end usando a configuração que você especificar aqui. Depois de criar uma configuração de HTTP, você deve associá-la a pelo menos uma regra de roteamento de solicitação.

Afinidade baseada em cookie

O Gateway de Aplicativo do Azure usa cookies gerenciados pelo gateway para manter as sessões de usuário. Quando um usuário envia a primeira solicitação ao Gateway de Aplicativo, um cookie de afinidade é definido na resposta com um valor de hash que contém os detalhes da sessão, para que as solicitações subsequentes que tenham o cookie de afinidade sejam roteadas para o mesmo servidor de back-end para manter a adesão.

Esse recurso é útil para manter uma sessão de usuário no mesmo servidor e quando o estado de sessão é salvo localmente no servidor para uma sessão de usuário. Esse recurso não poderá ser usado se o aplicativo não puder lidar com a afinidade baseada em cookie. Para usá-lo, certifique-se de que os clientes dão suporte a cookies.

Observação

Algumas verificações de vulnerabilidade podem sinalizar o cookie de afinidade do Gateway de Aplicativo porque os sinalizadores Secure ou HttpOnly não estão definidos. Tais verificações não consideram que os dados no cookie são gerados usando um hash único. O cookie não contém nenhuma informação do usuário e é usado puramente para roteamento.

Descarregamento de conexão

O esvaziamento de conexões ajuda você a remover membros de um 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,
  
• removido durante operações de redução horizontal ou
• relatadas como não íntegras pelas investigações de integridade.

É possível aplicar essa configuração a todos os membros de um pool de back-end habilitando o esvaziamento 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, mantendo as conexões existentes até o valor de tempo limite configurado. Isso também é verdadeiro para conexões WebSocket.

Tipo de Configuração	Valor
Valor padrão quando o esvaziamento de conexões não está habilitado na configuração de back-end	30 segundos
Valor padrão quando o esvaziamento de conexões não está habilitado na configuração de back-end	Um a 3600 segundos

A única exceção são as solicitações limitadas às instâncias de cancelamento de registro devido à afinidade de sessão gerenciada por gateway, que vão continuar a ser encaminhadas para as instâncias de cancelamento de registro.

Protocolo

O Gateway de Aplicativo dá suporte a HTTP e a HTTPS para solicitações de roteamento para os servidores de back-end. Se você escolher HTTP, o tráfego para os servidores de back-end não é criptografado. Se não for possível usar a comunicação não criptografada, escolha HTTPS.

Essa configuração combinada com HTTPS no ouvinte dá suporte ao TLS de ponta a ponta. Isso permite que você transmita os dados confidenciais criptografados com segurança para o back-end. Cada servidor no pool de back-end com 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 em que os servidores de back-end escutam o tráfego do gateway de aplicativo. Você pode configurar portas que variam entre 1 e 65535.

Certificado raiz confiável

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

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

Tempo limite da solicitação

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

Substituir caminho de back-end

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

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

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

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

Solicitação original	Regra de caminho	Substituir caminho de back-end	Solicitação encaminhada para o back-end
/pathrule/home/	/pathrule*	/override/	/override/home/
/pathrule/home/secondhome/	/pathrule*	/override/	/override/home/secondhome/
/home/	/pathrule*	/override/	/override/home/
/home/secondhome/	/pathrule*	/override/	/override/home/secondhome/
/pathrule/home/	/pathrule/home*	/override/	/override/
/pathrule/home/secondhome/	/pathrule/home*	/override/	/override/secondhome/
/pathrule/	/pathrule/	/override/	/override/

Usar investigação personalizada

Essa configuração associa a investigação personalizada a uma configuração de HTTP. Somente uma investigação personalizada pode ser associada a uma configuração de HTTP. Se você não associar explicitamente uma investigação personalizada, a investigação padrão vai ser usada para monitorar a integridade do back-end. Recomendamos a criação de uma investigação personalizada para um maior controle do monitoramento de integridade dos back-ends.

Observação

A investigação personalizada não vai monitorar a integridade do pool de back-end, a menos que a configuração de HTTP correspondente esteja explicitamente associada a um ouvinte.

Configurando o nome do host

Gateway de Aplicativo permite que a conexão estabelecida com o back-end use um nome de host diferente daquele usado pelo cliente para se conectar ao Gateway de Aplicativo. 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 entre o gateway de aplicativo e o destino de back-end deve ser feito com cuidado.

Em produção, é recomendável manter o nome do host usado pelo cliente em direção ao 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 absolutas, URLs de redirecionamento e cookies associados ao host.

Antes de configurar um Gateway de Aplicativo que se desvia desses parâmetros, analise as implicações dessa configuração, conforme discutido mais detalhadamente no Centro de Arquitetura: Preserve o nome do host HTTP original entre um proxy reverso e o aplicativo Web de back-end.

Há dois aspectos de uma configuração HTTP que influenciam o cabeçalho HTTP do host que é usado pelo Gateway de Aplicativo para se conectar ao back-end:

• Escolher o nome de host por meio do endereço de back-end
  
• Substituir o nome do host

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

Essa funcionalidade define dinamicamente o cabeçalho de host na solicitação para o nome do host do pool de back-end. Ele usa um endereço IP ou um 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 caso de exemplo são serviços multilocatário como o back-end. Um serviço de aplicativo é um serviço multilocatário que usa um espaço compartilhado com um único endereço IP. Portanto, um serviço de aplicativo só pode ser acessado por meio dos nomes de host que são definidos nas configurações do domínio personalizado.

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

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

Substituir o nome do host

Essa funcionalidade substitui o cabeçalho de host na solicitação de entrada no gateway de aplicativo pelo nome do host que você deseja especificar.

Por exemplo, se www.contoso.com for especificado na configuração de 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 de back-end.

Pool 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áquinas virtuais, um endereço IP/um FQDN ou um serviço de aplicativo.

Depois de criar um pool de back-end, você precisará associá-lo a uma ou mais regras de roteamento de solicitação. Você também precisa configurar investigações 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 investigações de integridade) no pool de back-end correspondente.

Investigações de integridade

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. As investigações 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 as investigações o detectam como íntegro.

A investigação padrão usa o número da porta da Configuração de Back-end associada e outras configurações predefinidas. Você pode usar investigações personalizadas para configurá-los do seu jeito.

Comportamento de investigações

Endereço IP de origem

O endereço IP de origem das investigações 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 investigação

Um gateway começa a disparar investigações imediatamente após você configurar uma Regra, associando-a a uma Configuração de Back-end e a um 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 investigação bem-sucedida seja recebida.

As investigações necessários são determinados com base na combinação exclusiva da Configuração de Servidor de Back-end e 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 de back-end distintas são associadas ao mesmo pool de back-end usando suas respectivas regras, o gateway cria investigações para cada servidor e a combinação da configuração de back-end. Você pode exibir isso na página de integridade do back-end.

Além disso, todas as instâncias do gateway de aplicativo examinam os servidores back-end independentemente umas das outras.

Observação

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

Investigação de integridade padrão

Um Application Gateway configura automaticamente uma investigação de integridade padrão quando você não define nenhuma configuração de investigação personalizada. O comportamento de monitoramento funciona com uma solicitação HTTP GET para os endereços IP ou o FQDN configurados no pool de back-end. Para investigações padrão, se as configurações de HTTP de back-end estão configuradas para HTTPS, a investigação usa HTTPS para testar a integridade dos servidores back-end.

Por exemplo: você configura o gateway de aplicativo para usar os servidores back-end A, B e C para receber o 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 de HTTP íntegra tem um código de status entre 200 e 399. Nesse caso, a solicitação HTTP GET para a investigação de integridade se parece com http://127.0.0.1/. Consulte também códigos de resposta HTTP no Gateway de Aplicativo.

Se a investigação de verificação padrão falhar para o servidor A, o gateway de aplicativo para de encaminhar solicitações a esse servidor. A investigação 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 da investigação de integridade padrão

Propriedades da investigação	Valor	Descrição
URL de investigação	<protocol>://127.0.0.1:<port>/	O protocolo e a porta são herdados das configurações HTTP de back-end às quais a investigação está associada
Intervalo	30	A quantidade de tempo em segundos a esperar antes da próxima investigação de integridade é enviada.
Tempo limite	30	A quantidade de tempo em segundos o gateway de aplicativo aguarda uma resposta de investigação antes da marcação da investigação como não íntegro. Se uma investigação é retornada como íntegra, o back-end correspondente será imediatamente marcado como íntegro.
Limite não íntegro	3	Controla quantas investigações enviar caso ocorra uma falha da investigação de integridade regular. Na SKU v1, essas investigações de integridade adicionais são enviadas em sucessão rápida para determinar a integridade do back-end rapidamente e não é preciso esperar o intervalo de investigação. No caso do SKU v2, as investigações de integridade esperam o intervalo. O servidor back-end é marcado após a contagem de falhas de investigação consecutivas atingir o limite de não íntegro.

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

Investigação de integridade personalizada

Investigações personalizadas permitem que você tenha um controle mais granular sobre o monitoramento de integridade. Ao usar investigações personalizadas, você pode configurar um nome do host personalizado, um caminho de URL, um intervalo de investigação, o número de respostas com falha que serão aceitas antes de marcar a instância do pool de back-end como não íntegra etc.

Configurações da investigação de integridade personalizada

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

Propriedades da investigação	Descrição
Nome	O nome da investigação. Esse nome é usado para identificar a investigação nas configurações de HTTP de back-end e se referir a ela.
Protocolo	O protocolo usado para enviar a investigação. Isso deve corresponder ao protocolo definido nas configurações HTTP de back-end ao qual está associado
Host	O nome do host para enviar a investigação. Na SKU v1, esse valor é usado somente para o cabeçalho de host da solicitação de investigação. No SKU v2, ele é usado como cabeçalho de host e SNI
Caminho	O caminho relativo da investigação. Um caminho válido começa com "/"
Porta	Se definida, ela será usada como a porta de destino. Caso contrário, ele usará a mesma porta que as configurações HTTP às quais está associado. Essa propriedade só está disponível na SKU v2
Intervalo	Intervalo de investigação em segundos. Este valor é 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 como inativo após a contagem de falhas de investigação consecutivas atingir o limite de não íntegro

Correspondência de investigação

Por padrão, uma resposta HTTP(S) com código de status entre 200 e 399 é considerada íntegra. As investigações de integridade personalizadas também fornecem suporte a dois critérios correspondentes. Critérios de correspondência podem ser utilizados para, opcionalmente, mudar a interpretação padrão do que constitui uma resposta íntegra.

A seguir estão os critérios de correspondência:

• Correspondência de código de status de resposta HTTP - Critério de correspondência de teste para aceitar o código de resposta HTTP ou intervalos de códigos de resposta especificados pelo usuário. Códigos de status de resposta separados por vírgulas individuais ou um intervalo de código de status têm suporte.
  
• Correspondência do corpo da resposta HTTP - Critério de correspondência da análise 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 de uma 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 cmdlet New-AzApplicationGatewayProbeHealthResponseMatch.

Por exemplo:

PowerShell do Azure

$match = New-AzApplicationGatewayProbeHealthResponseMatch -StatusCode 200-399

$match = New-AzApplicationGatewayProbeHealthResponseMatch -Body "Healthy"

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

Casos de uso de investigação personalizada

• Se um servidor back-end permitir acesso apenas a usuários autenticados, as investigações 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 em tempo real, você pode configurar o tráfego de investigação para aceitar 403 como uma resposta esperada.
• Quando um servidor back-end tem um certificado curinga (*.contoso.com) instalado para atender a diferentes subdomínios, você pode usar uma investigação personalizada com um nome de host específico (necessário para SNI) que é aceito para estabelecer uma investigação TLS bem-sucedida e relatar esse servidor como íntegro. Com "substituir nome de host" na Configuração de back-end definida como NÃO, 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 granularidade sobre a sub-rede do Gateway de Aplicativo por meio de regras NSG é possível na visualização pública. Encontre mais detalhes aqui.

Com a funcionalidade atual, existem algumas restrições:

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

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

Como um gateway de aplicativo funciona

Como um gateway de aplicativo aceita uma solicitação

1. Antes que um cliente envie 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 aplicativo 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 de front-end do gateway de aplicativo.
   
3. O gateway de aplicativo aceita o tráfego de entrada em um ou mais ouvintes. Um ouvinte é uma entidade lógica que verifica as solicitações de conexão. Ele é configurado com um endereço IP de front-end, um protocolo e um número de porta para conexões de clientes com o gateway de aplicativo.
   
4. Se um WAF (firewall do aplicativo Web) estiver em uso, o gateway de aplicativo verificará os cabeçalhos de solicitação e o corpo, se estiver presente, com base nas regras de 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 WAF estiver no modo Prevenção, ela será bloqueada como uma ameaça à segurança. Se estiver no modo Detecção, a solicitação será avaliada e registrada em log, mas ainda será 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 publicamente resolvido para seu endereço IP público. Como resultado, os gateways de aplicativo voltados para a Internet podem rotear solicitações de cliente da Internet.

Os gateways de aplicativo internos usam apenas endereços IP privados. Se você estiver usando uma zona de DNS privado, o nome de domínio deverá ser resolvido internamente para o endereço IP privado do Gateway de Aplicativo. 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ção, o gateway de aplicativo determina se todas as solicitações no ouvinte devem ser roteada para um pool de back-back específico, se as solicitações devem ser roteada para pools de back-back diferentes com base no caminho da URL ou se as solicitações devem ser redirecionadas para outra porta ou site externo.

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

Depois que o gateway de aplicativo determina o servidor de 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 que são necessárias para estabelecer uma nova sessão com o servidor de back-end.

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

Observação

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

Quando um gateway de aplicativo envia a solicitação original para o servidor de back-end, ele respeitou 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 cookie, o descarregamento de conexão, a seleção de nome do 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 de front-end para alcançar o servidor. Se não houver um endereço IP público de front-end, um será atribuído à conectividade externa de saída.
• Contém um FQDN solucionável internamente ou um endereço IP privado, o gateway de aplicativo rotea a solicitação para o servidor back-end usando seus endereços IP privados em instância.
• Contém um ponto de extremidade externo ou um FQDN solucionável internamente, o gateway de aplicativo rotea a solicitação para o servidor back-end usando seus endereços IP públicos de front-end. Se a sub-rede contiver pontos de extremidade de serviço, o gateway de aplicativo roteará 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 em um servidor DNS personalizado, se configurado, ou usa o DNS padrão fornecido pelo Azure. Se não houver um endereço IP público de front-end, um será atribuído à conectividade externa de saída.

Resolução DNS do servidor back-end

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

O Gateway de Aplicativo mantém essas informações armazenadas em cache para o período equivalente à TTL (tempo de vida útil) desse registro DNS e executa uma nova pesquisa de DNS quando o TTL expira. Se um gateway detectar uma alteração no endereço IP para sua consulta DNS subsequente, ele começará a rotear o tráfego para este destino atualizado. No 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 conhecido(s). Isso garante um impacto mínimo no caminho de dados.

• Ao usar servidores DNS personalizados com a Rede Virtual do Gateway de Aplicativo, é crucial que todos os servidores sejam idênticos e respondam consistentemente com os mesmos valores 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 do encaminhador DNS ao usar uma zona DNS privada para ponto de extremidade privado.

Modificações na solicitação

Um gateway de aplicativo insere seis cabeçalhos adicionais em todas as solicitações antes de encaminhá-las ao 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:porta.

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. O cabeçalho X-original-host 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 de host de entrada é modificado antes do tráfego é roteado para o back-end. Se a afinidade de sessão estiver habilitada como uma opção, ela adicionará um cookie de afinidade gerenciado por 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 iniciado para 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 URL e cabeçalhos de solicitação e resposta usando Reescrever cabeçalhos HTTP e URL, ou para modificar o caminho do URI usando uma configuração de substituição de caminho. No entanto, a menos que esteja configurado para fazer isso, todas as solicitações de entrada serão feitas por proxy para o back-end.