- 11/16/2019
- 4 minutos para ler
-
-
a -
j -
D -
s -
v -
+2
-
Este artigo explica como um gateway de aplicação aceita pedidos recebidos e os encaminha para o backend.
Como um gateway de aplicação aceita uma solicitação
- >
Antes de um cliente enviar uma solicitação para um gateway de aplicação, ele resolve o nome de domínio do gateway de aplicação usando um servidor DNS (Domain Name System). O Azure controla a entrada DNS porque todos os gateways de aplicação estão no domínio azure.com.
-
O DNS Azure devolve o endereço IP ao cliente, que é o endereço IP frontend do gateway de aplicação.
-
O gateway de aplicação aceita tráfego de entrada em um ou mais ouvintes. Um ouvinte é uma entidade lógica que verifica os pedidos 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 aplicação.
-
Se um firewall de aplicação web (WAF) estiver em uso, o gateway de aplicação verifica os cabeçalhos de requisição e o corpo, se presente, em relação às regras WAF. Esta ação determina se a solicitação é válida ou se é uma ameaça à segurança. Se a solicitação for válida, ela é roteada para o backend. Se a solicitação não for válida e o WAF estiver no modo de prevenção, é bloqueado como uma ameaça à segurança. Se estiver no modo Detecção, o pedido é avaliado e registrado, mas ainda assim encaminhado para o servidor backend.
Azure Application Gateway 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 aplicação voltado para a Internet usa endereços IP públicos. O nome DNS de um gateway de aplicação voltada para a Internet é resolúvel publicamente para o seu endereço IP público. Como resultado, os gateways de aplicações voltadas para a Internet podem encaminhar pedidos de clientes a partir da Internet.
Os gateways de aplicações internas utilizam apenas endereços IP privados. Se você estiver usando uma zona DNS personalizada ou privada, o nome do domínio deve ser resolvido internamente para o endereço IP privado do Application Gateway. Portanto, os balanceadores de carga internos só podem encaminhar solicitações de clientes com acesso a uma rede virtual para o gateway de aplicação.
Como um gateway de aplicação encaminha uma solicitação
Se uma solicitação é válida e não bloqueada pelo WAF, o gateway de aplicação avalia a regra de roteamento de solicitações que está associada ao ouvinte. Esta ação determina qual pool back end encaminha a solicitação para.
Baseada na regra de roteamento de solicitação, o gateway de aplicação determina se todas as solicitações no ouvinte devem ser encaminhadas para um pool back end específico, rotear solicitações para diferentes pools back end com base no caminho URL, ou redirecionar solicitações para outra porta ou site externo.
Nota
Regras são processadas na ordem em que são listadas no portal para a v1 SKU.
Quando o gateway de aplicação seleciona o pool de backend, ele envia a solicitação para um dos servidores backend saudáveis no pool (y.y.y.y). A saúde do servidor é determinada por uma sonda de saúde. Se o pool backend contém vários servidores, o gateway da aplicação usa um algoritmo round-robin para encaminhar as requisições entre servidores saudáveis. Esta carga equilibra as requisições nos servidores.
Após o gateway da aplicação determinar o servidor back end, ele abre uma nova sessão TCP com o servidor back end baseado em configurações HTTP. As configurações HTTP especificam o protocolo, porta e outras configurações relacionadas ao roteamento que são 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 da aplicação e os servidores back end é criptografado (realizando assim TLS de ponta a ponta) ou se não é criptografado.
Quando um gateway de aplicação envia o pedido original para o servidor back end, ele honra qualquer configuração personalizada feita nas configurações HTTP relacionadas à sobreposição do nome da máquina, caminho e protocolo. Esta ação mantém afinidade de sessão baseada em cookies, drenagem da conexão, seleção do nome da máquina do backend, e assim por diante.
>Nota
Se o backend pool:
- for um endpoint público, o gateway da aplicação usa seu IP público frontend para alcançar o servidor. Se não houver um endereço IP público frontend, um é 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 backend usando seu endereço IP privado de instância.
- Contém um endpoint externo ou um FQDN resolúvel externamente, o gateway de aplicação encaminha a solicitação para o servidor backend usando seu endereço IP público frontend. A resolução DNS é baseada em uma zona DNS privada ou servidor DNS personalizado, se configurado, ou utiliza o DNS padrão fornecido pelo Azure. Se não houver um endereço IP público frontend, um é atribuído para a conectividade externa de saída.
Modificações para a solicitação
Um gateway de aplicação insere quatro cabeçalhos adicionais para todas as solicitações antes de encaminhar as solicitações para o backend. Estes cabeçalhos são x-forwarded-for, x-forwarded-proto, x-forwarded-port, e x-original-host. O formato para cabeçalho x-forwarded-for é uma lista separada por vírgula 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 alcançou o gateway da aplicação. X-original-host header contém o cabeçalho original do host com o qual a requisição chegou. Este cabeçalho é útil na integração do website Azure, onde o cabeçalho do host de entrada é modificado antes do tráfego ser roteado para o backend. Se a sessão affinity estiver ativada como opção, então ele adiciona um cookie de affinity gerenciado pelo gateway.
Você pode configurar o gateway do aplicativo para modificar os cabeçalhos de requisição e resposta e o URL usando Rewrite HTTP headers e URL ou para modificar o caminho URI usando uma configuração de path-override. Entretanto, a menos que configurado para fazer isso, todas as solicitações de entrada são proxied para o backend.
Aprenda sobre os componentes do gateway de aplicativos