Planejar e implementar um Gateway de Aplicativo do Azure

Concluído

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.

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.

Infraestruturas

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 Frontend

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 uma aplicação de múltiplas camadas dentro de uma barreira de segurança que não estão expostos à internet, mas que exigem distribuição de carga round-robin, persistência de sessão ou encerramento de 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.

Observação

O front-end do Application Gateway suporta endereços IP de pilha dupla (pré-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 se utiliza a mesma porta, o gateway de aplicação altera o Destino do fluxo de tráfego de entrada para os endereços IP do frontend do seu gateway.

Regra de entrada:

• Fonte: De acordo com a sua exigência
  
• Destino: Os IPs de entrada, públicos e privados, do seu gateway de aplicação.
• 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 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 solicitações de ligação entrantes. 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.

Portos

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:

Observação

O suporte ao protocolo HTTP/2 está disponível apenas para clientes que se conectam a escutadores do gateway de aplicação. 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. Utilize WebSockets com ouvintes HTTP e HTTPS.

Use um listener HTTPS para terminação de 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 a opção 'baseado em caminho' se quiser rotear solicitações de caminhos de URL específicos para grupos de servidores 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.

Ouvinte

Escolha o ouvinte como alvo de redirecionamento para desviar 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.

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.

Configurações 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.

Afinidade com base no cookie

O Gateway de Aplicativo do Azure usa cookies gerenciados por gateway para manter sessões de usuário. Quando um usuário envia a primeira solicitação para o Application Gateway, ele define um cookie de afinidade na resposta com um valor de hash que contém os detalhes da sessão, de modo que as solicitações subsequentes que carregam o cookie de afinidade sejam roteadas para o mesmo servidor de back-end para manter a aderê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.

Observação

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

O esgotamento de conexão ajuda a remover de forma eficiente os membros do grupo de servidores back-end durante atualizações de serviço planeadas. Aplica-se a instâncias de back-end que são

• explicitamente removido do pool de backend.
  
• 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 as solicitações relacionadas ao cancelamento de registro de instâncias devido à afinidade de sessão gerida pelo gateway, que continuarão a ser encaminhadas para as instâncias em processo 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 de backend no pool de backend com TLS de ponta a ponta habilitado deve ser configurado com um certificado para garantir comunicação segura.

Porto

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á. Este certificado deve ser carregado diretamente no portal de aplicações 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 da requisição

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 backend	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 backend	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/	/anulaçã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 criar uma sonda personalizada para ter um maior controlo sobre o monitoramento da saúde dos seus back-ends.

Observação

A sonda personalizada não monitora o estado de saúde 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 esta configuração possa ser útil em alguns casos, substituir o hostname para ser diferente entre o cliente e o gateway de aplicação e entre o gateway de aplicação e o alvo 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 destas normas, reveja as implicações de tal configuração, tal como discutido com mais detalhe 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:

• Selecione o nome do host a partir do endereço de back-end
  
• Substituição do nome do host

Selecione o nome do host do endereço de backend

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 aplicações, e o back-end depende de um cabeçalho de host específico para resolver o ponto de extremidade correto.

Um exemplo de caso são os serviços multilocatários como sistema de 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 aceder ao seu serviço de aplicações através de um gateway de aplicações por meio de um nome de anfitrião que não esteja explicitamente registado no serviço de aplicações ou através do FQDN do gateway de aplicações, pode substituir o nome de anfitrião na solicitação original pelo nome de anfitrião do serviço de aplicações. 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 aplicação 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.

Grupo de servidores 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 aplicação.

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 aplicação encaminha o tráfego para os servidores saudáveis (determinados pelas sondas de integridade) no pool de backend correspondente.

Sondas de saúde

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 sondas continuam a monitorizar esse servidor não saudável, e o gateway começa a rotear o tráfego para ele mais uma vez assim que as sondas o considerarem saudável.

A sonda por 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 do 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çamento da sub-rede do gateway de aplicação.

Operações de sonda

Um gateway começa a disparar sondas imediatamente após configurar uma Regra, associando-a a uma Definição de Back-end e um Pool de Back-end (e, é claro, ao Ouvinte). 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 ser recebidas são enviadas apenas para os servidores em bom estado. Um servidor back-end é marcado como não íntegro por padrão até que uma resposta de teste bem-sucedida seja recebida.

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. Pode ver isto na página 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.

Observação

O relatório de integridade do servidor é atualizado com base no intervalo de atualização do respetivo teste e não depende da solicitação do utilizador.

Sonda de saúde 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 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 saúde

Propriedade da sonda	Valor	Descrição
URL da sonda	<protocolo>://127.0.0.1:<porta>/	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.
Tempo Esgotado	30	A quantidade de tempo, em segundos, que o gateway de aplicações aguarda uma resposta de teste antes de marcar a sonda como não saudável. Se uma sonda retornar como saudável, o back-end correspondente será marcado imediatamente como saudável.
Limiar não saudável	3	Determina quantas sondas enviar no caso de haver uma falha da sonda de verificação regular. No SKU v1, estas sondas de integridade adicionais são enviadas em rápida sucessão para determinar rapidamente a integridade do back-end e não aguardam pelo intervalo entre sondas. Para o SKU v2, as sondas de integridade aguardam durante o intervalo. O servidor back-end é assinalado como inativo depois que a contagem de falhas nas sondagens consecutivas atinge o limite não saudável.

O teste padrão examina apenas <protocol>://127.0.0.1:<port> para verificar o estado de funcionamento. Se precisares configurar a sonda de integridade para ir para um URL personalizado ou modificar quaisquer outras definições, deverás usar sondas personalizadas.

Sonda de saúde personalizada

As sondas personalizadas permitem um controlo mais granular sobre a monitorização de saúde. Ao usar sondas personalizadas, pode-se configurar um nome de host personalizado, caminho de URL, intervalo de sonda, e quantas respostas com falha aceitar antes de marcar a instância do pool de back-end como não saudável, etc.

Configurações personalizadas da sonda de saúde

A tabela a seguir fornece definições para as propriedades de uma sonda de saúde personalizada.

Propriedade da sonda	Descrição
Nome	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
Anfitrião	Nome do host para enviar a sonda. Na SKU v1, este valor é usado apenas para o cabeçalho do host da solicitação de sondagem. No SKU v2, ele é usado como cabeçalho de host e SNI
Caminho	Caminho relativo da sonda. Um caminho válido começa com '/'
Porto	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 está disponível apenas na SKU v2.
Intervalo	Intervalo da sonda em segundos. Este valor é o intervalo de tempo entre duas sondas consecutivas
Tempo Esgotado	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 não saudável	Contagem de novas tentativas da sonda. O servidor back-end é considerado indisponível depois que a contagem de falhas consecutivas de sondagem atinge o limite crítico.

Correspondência de sonda

Por padrão, uma resposta HTTP(S) com código de status entre 200 e 399 é considerada saudável. Além disso, as sondas de saúde 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 wildcard (*.contoso.com) instalado para servir diferentes subdomínios, pode utilizar uma prova personalizada com um nome de host específico (necessário para SNI) que é aceite para estabelecer uma prova TLS bem-sucedida e reportar esse servidor como saudável. 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 controlo detalhado sobre a sub-rede do Application Gateway através de regras NSG é possível na pré-visualização pública. Mais detalhes podem ser encontrados 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 "Any" e a origem como a tag 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

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 aplicações aceita tráfego de entrada em um ou mais receptores. 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 aplicações web (WAF) estiver em uso, o gateway de aplicação verificará os cabeçalhos da solicitação e o corpo, se estiver presente, em relação às regras do 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 aplicação determina se deve encaminhar todas as solicitações ouvidas no ouvinte para um pool de back-end específico, encaminhar solicitações para diferentes pools de back-end com base no caminho da URL ou redirecionar solicitações para outra porta ou site externo.

Quando o gateway de aplicação seleciona o pool de retaguarda, ele envia a solicitação para um dos servidores de retaguarda saudáveis 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 aplicação usará um algoritmo round-robin para rotear as solicitações entre servidores saudáveis. 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.

Observação

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

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 aplicações usa o seu IP público de 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 aplicação encaminha a solicitação para o servidor back-end, utilizando os 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 aplicações encaminhará a solicitação para o serviço através do 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 tais como a consulta de DNS não receber uma resposta ou o registo deixar de existir, o gateway usa o(s) último(s) endereço(s) IP válido(s). 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 utilizadores de servidores DNS personalizados no local devem garantir a conectividade com o DNS do Azure por meio do Resolvedor Privado de DNS do Azure (recomendado) ou de uma máquina virtual encaminhadora de DNS ao usar uma zona DNS privada para um 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 hífenes (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 aplicação para modificar os cabeçalhos de solicitação e resposta e o URL usando reescrever os cabeçalhos HTTP e o URL ou para modificar o caminho de URI usando uma configuração de alteração de caminho. No entanto, a menos que esteja configurado dessa forma, todas as solicitações de entrada são encaminhadas para o back-end.