Este artigo detalha a nova capacidade de proxy Layer 4 (TCP/TLS) do Azure Application Gateway. A principal conclusão é que essa funcionalidade centraliza o tráfego de ingresso para aplicações que não utilizam HTTP, reduzindo a complexidade operacional. Ao permitir TLS pass-through e oferecer suporte a Proxy Protocol v1, essa solução nativa simplifica a arquitetura multi-protocolo, facilitando a modernização de workloads legadas e a integração com Kubernetes no Azure sem depender de soluções de terceiros ou NVAs.
Por que o Proxy TCP/TLS é relevante?
Arquiteturas de nuvem modernas focam excessivamente em HTTP/HTTPS, porém, boa parte do ecossistema corporativo ainda depende de pilhas de tecnologia tradicionais. Sistemas financeiros, plataformas de mensageria e middleware legados frequentemente utilizam:
- Protocolos TCP proprietários
- Sistemas de transação financeira
- Protocolos de comunicação cliente-servidor seguros
Historicamente, para expor essas aplicações com segurança e escalabilidade, times de engenharia recorriam a Network Virtual Appliances (NVAs), balanceadores de carga de hardware ou proxies reversos customizados. O gerenciamento descentralizado destas soluções aumenta drasticamente a complexidade operacional. O novo proxy L4 do Azure Application Gateway atua como um facilitador, permitindo a padronização do ingress management sem elevar a carga de manutenção.
Entendendo a diferença: Layer 7 vs. Layer 4
Layer 7 (HTTP/HTTPS)
É o domínio da inteligência de aplicação. Aqui, o roteamento é baseado em header, URL, afinidade de sessão (cookies) e, claro, a proteção do Web Application Firewall.
Layer 4 (TCP/TLS)
O foco aqui é a infraestrutura de conexão. O roteamento ocorre em nível de porta e encaminhamento de pacotes. É a escolha correta para aplicações robustas onde a sensibilidade ao conteúdo da mensagem em nível de aplicação não é necessária no ingress, mas a centralização do tráfego é indispensável.
Capabilities essenciais e pontos de atenção
- TLS Pass-Through: O tráfego permanece criptografado entre o cliente e o backend. Isso é vital para conformidade em mercados regulados, onde o gerenciamento de certificados deve ser feito diretamente pela aplicação, eliminando o overhead de terminação no proxy.
- Proxy Protocol v1: Sem suporte, o destino final veria apenas o IP do Gateway. Com o v1, você mantém a visibilidade total da origem (Source IP e Port), garantindo que seu sistema de logs e auditoria permaneça operacional.
- Integração com Kubernetes: O fato de integrar-se nativamente com o AKS permite que você trate serviços de banco, streaming e mensageria como membros de um backend pool, otimizando o deployment no cluster.
Considerações para engenharia e operações
Ao migrar para essa arquitetura, foque nos seguintes pontos:
- Compatibilidade: Antes de habilitar o Proxy Protocol, verifique se suas aplicações backend possuem suporte para parsear esse header.
- Observabilidade: Conexões TCP são, frequentemente, de longa duração (long-lived). Monitore o status dessas conexões e o tempo de timeout.
- Testes de Carga: Valide o comportamento de auto-scaling no backend; o gerenciamento de conexões L4 pode ter implicações diferentes do tráfego HTTP stateless.
Para deploy em larga escala, certifique-se de que sua estratégia de disaster recovery contempla a replicação das configurações do App Gateway em topologias multi-região.
Perguntas Frequentes
- Como o L4 difere do L7 no Azure Application Gateway?
O L7 foca em inteligência de aplicação (URL routing, WAF), enquanto o L4 trata de conexões em nível de transporte, lidando com o encaminhamento de pacotes TCP e pass-through de TLS sem inspecionar o conteúdo da carga útil. - Por que usar o Proxy Protocol v1?
Ele é essencial para preservar os dados originais do cliente (como IP de origem e porta) na camada de rede, garantindo que suas aplicações backend recebam essa informação, crucial para logs e auditorias de segurança. - Essa funcionalidade suporta Kubernetes?
Sim, o Application Gateway pode integrar-se diretamente ao Azure Kubernetes Service (AKS) como um backend pool, permitindo que serviços TCP (como message brokers ou bancos de dados) sejam expostos com políticas de tráfego centralizadas.
Artigo originalmente publicado em Azure Updates - Latest from Azure Charts.
