Visão geral do proxy TCP/TLS do Application Gateway (Visualização)
Além dos recursos existentes da Camada 7 (HTTP, HTTPS, WebSockets e HTTP/2), o Gateway de Aplicativo do Azure agora também oferece suporte ao proxy de Camada 4 (protocolo TCP) e TLS (Transport Layer Security). Esta funcionalidade está atualmente em pré-visualização pública. Para pré-visualizar esta funcionalidade, consulte Registar na pré-visualização.
Recursos de proxy TLS/TCP no Application Gateway
Como um serviço de proxy reverso, as operações de Camada 4 do Application Gateway funcionam de forma semelhante às operações de proxy de Camada 7. Um cliente estabelece uma conexão TCP com o Application Gateway e o próprio Application Gateway inicia uma nova conexão TCP com um servidor back-end a partir do pool de back-end. A figura a seguir mostra a operação típica.
Fluxo do processo:
- Um cliente inicia uma conexão TCP ou TLS com o gateway de aplicativo usando o endereço IP e o número da porta do ouvinte frontend. Isso estabelece a conexão frontend. Uma vez que a conexão é estabelecida, o cliente envia uma solicitação usando o protocolo de camada de aplicativo necessário.
- O gateway de aplicativo estabelece uma nova conexão com um dos destinos de back-end do pool de back-end associado (formando a conexão de back-end) e envia a solicitação do cliente para esse servidor de back-end.
- A resposta do servidor back-end é enviada de volta ao cliente pelo gateway de aplicativo.
- A mesma conexão TCP frontend é usada para solicitações subsequentes do cliente, a menos que o tempo limite de ociosidade TCP feche essa conexão.
Comparando o Azure Load Balancer com o Azure Application Gateway:
| Produto | Type |
|---|---|
| Balanceador de Carga do Azure | Um balanceador de carga de passagem em que um cliente estabelece diretamente uma conexão com um servidor back-end selecionado pelo algoritmo de distribuição do Balanceador de Carga. |
| Gateway de Aplicação do Azure | Balanceador de carga de encerramento em que um cliente estabelece diretamente uma conexão com o Application Gateway e uma conexão separada é iniciada com um servidor back-end selecionado pelo algoritmo de distribuição do Application Gateway. |
Funcionalidades
- Use um único ponto de extremidade (IP frontend) para servir cargas de trabalho HTTP e não HTTP. A mesma implantação de gateway de aplicativo pode suportar protocolos de Camada 7 e Camada 4: HTTP(S), TCP ou TLS. Todos os seus clientes podem se conectar ao mesmo endpoint e acessar diferentes aplicativos de back-end.
- Use um domínio personalizado para fazer frente a qualquer serviço de back-end. Com o frontend para o SKU do Application Gateway V2 como endereços IP públicos e privados, você pode configurar qualquer nome de domínio personalizado para apontar seu endereço IP usando um registro de endereço (A). Além disso, com a terminação TLS e o suporte para certificados de uma autoridade de certificação (CA) privada, você pode garantir uma conexão segura no domínio de sua escolha.
- Use um servidor back-end de qualquer local (Azure ou local). Os back-ends para o gateway de aplicativo podem ser:
- Recursos do Azure, como máquinas virtuais IaaS, conjuntos de dimensionamento de máquinas virtuais ou PaaS (Serviços de Aplicativo, Hubs de Eventos, SQL)
- Recursos remotos, como servidores locais acessíveis via FQDN ou endereços IP
- Com suporte para um gateway somente privado. Com o suporte a proxy TLS e TCP para implantações privadas do Application Gateway, você pode oferecer suporte a clientes HTTP e não HTTP em um ambiente isolado para maior segurança.
Limitações
- Um gateway SKU WAF v2 permite a criação de ouvintes e back-ends TLS ou TCP para suportar tráfego HTTP e não HTTP através do mesmo recurso. No entanto, ele não inspeciona o tráfego em ouvintes TLS e TCP em busca de explorações e vulnerabilidades.
- O valor padrão de tempo limite de drenagem para servidores back-end é de 30 segundos. No momento, um valor de drenagem definido pelo usuário não é suportado.
- A preservação de IP do cliente não é suportada no momento.
- O Application Gateway Ingress Controller (AGIC) não é suportado e funciona apenas com proxy L7 através de ouvintes HTTP(S).