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:

1. 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.
2. 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.
3. A resposta do servidor de back-end é enviada de volta ao cliente pelo gateway de aplicativo.
4. 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:

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.
• O AGIC (Controlador de Entrada do Gateway de Aplicativo) não tem suporte e funciona somente com proxy L7 por meio de ouvintes HTTP(S).

Próximas etapas

• Configurar o proxy TCP/TLS do Gateway de Aplicativo do Azure
• Visite as perguntas frequentes