Visão geral do proxy TCP/TLS do Gateway de Aplicativo (versão prévia)
Além dos recursos existentes da Camada 7 (HTTP, HTTPS, WebSockets e HTTP/2), o Gateway de Aplicativo do Azure agora também dá suporte ao proxy de Camada 4 (protocolo TCP e protocolo TLS). Esse recurso está atualmente em visualização pública. Para visualizar esse recurso, confira Registrar-se para versão prévia.
Recursos de proxy TLS/TCP no Gateway de Aplicativo
Como um serviço de proxy reverso, as operações de Camada 4 do Gateway de Aplicativo funcionam de forma semelhante às operações de proxy de Camada 7. Um cliente estabelece uma conexão TCP com o Gateway de Aplicativo, e o próprio Gateway de Aplicativo inicia uma nova conexão TCP com um servidor de back-end 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 de front-end. Isso estabelece a conexão de front-end. Depois 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 de back-end é enviada de volta ao cliente pelo gateway de aplicativo.
- A mesma conexão TCP de front-end é utilizada para solicitações seguintes do cliente, a menos que o tempo limite de inatividade TCP feche essa conexão.
Comparação do Azure Load Balancer com o Gateway de Aplicativo do Azure:
| Product | Tipo |
|---|---|
| Azure Load Balancer | Um balanceador de carga de passagem em que um cliente estabelece diretamente uma conexão com um servidor de back-end selecionado pelo algoritmo de distribuição do Load Balancer. |
| Gateway de Aplicativo do Azure | Encerrando o balanceador de carga em que um cliente estabelece diretamente uma conexão com o Gateway de Aplicativo e uma conexão separada é iniciada com um servidor de back-end selecionado pelo algoritmo de distribuição do Gateway de Aplicativo. |
Recursos
- Use um único ponto de extremidade (IP de front-end) para atender cargas de trabalho HTTP e não HTTP. A mesma implantação de gateway de aplicativo pode dar suporte a protocolos de Camada 7 e Camada 4: HTTP(S), TCP ou TLS. Todos os clientes podem se conectar ao mesmo ponto de extremidade e acessar diferentes aplicativos de back-end.
- Use um domínio personalizado para fazer frente a qualquer serviço de back-end. Com o front-end do SKU do Gateway de Aplicativo V2 como endereços IP públicos e privados, é possível 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 a certificados de uma AC (autoridade de certificação) 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 do 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 Aplicativos, Hubs de Eventos, SQL)
- Recursos remotos, como servidores locais acessíveis por meio de 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 Gateway de Aplicativo, você pode dar suporte a clientes HTTP e não HTTP em um ambiente isolado para aumentar a segurança.
Limitações
- Um gateway de SKU WAF v2 permite a criação de ouvintes e back-ends TLS ou TCP para dar suporte ao tráfego HTTP e não HTTP por meio 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 de tempo limite de drenagem padrão para servidores de back-end é de 30 segundos. No momento, não há suporte para um valor de drenagem definido pelo usuário.
- Atualmente, não há suporte para preservação de IP do cliente.