Como um gateway de aplicativo funciona
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 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.
O DNS do Azure retorna o endereço IP para o cliente, que é o endereço IP de front-end do gateway de aplicativo.
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.
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.
Observação
As regras são processadas na ordem em que estão listadas no portal para a SKU v1.
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.
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.
Observação
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.
Importante
- 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.