Como funciona um gateway de aplicativo
Este artigo explica como um gateway de aplicativo aceita solicitações de entrada e as roteia para o back-end.
Como um gateway de aplicativo aceita uma solicitação
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.
O DNS do Azure retorna o endereço IP para o cliente, que é o endereço IP frontend do gateway de aplicativo.
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.
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.
Nota
As regras são processadas na ordem em que estão listadas no portal para v1 SKU.
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.
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.
Nota
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 resolví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.
Importante
- Ao usar servidores DNS personalizados com a Rede Virtual do Application Gateway, é importante que todos os servidores respondam consistentemente com os mesmos valores de DNS. Quando uma instância do seu Application Gateway emite uma consulta DNS, ela usa o valor do servidor que responde primeiro.
- 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 de uma 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.