Implantar NVAs altamente disponíveis

2025-06-10

Este artigo descreve maneiras comuns de implantar um conjunto de NVAs (dispositivos virtuais de rede) para alta disponibilidade no Azure. Uma NVA normalmente controla o fluxo de tráfego entre segmentos de rede que têm diferentes níveis de segurança. Por exemplo, você pode usar uma NVA entre uma rede virtual de rede de perímetro e a Internet pública ou para conectar locais externos ao Azure por meio de vpn (rede virtual privada) ou dispositivos WAN (SD-WAN) definidos pelo software.

Este artigo pressupõe que você tenha uma compreensão básica da rede do Azure, dos balanceadores de carga do Azure, do roteamento de tráfego de rede virtual e das UDRs (rotas definidas pelo usuário).

Muitos padrões de design usam NVAs para inspecionar o tráfego entre diferentes zonas de segurança. Esses padrões podem usar NVAs para as seguintes finalidades:

Para inspecionar o tráfego de saída de máquinas virtuais para a Internet e impedir a exfiltração de dados.
Para inspecionar o tráfego de entrada da Internet para máquinas virtuais e evitar ataques.
Para filtrar o tráfego entre máquinas virtuais no Azure para evitar movimentações laterais de sistemas comprometidos.
Para filtrar o tráfego entre sistemas locais e máquinas virtuais do Azure, especialmente se pertencerem a diferentes níveis de segurança. Por exemplo, o Azure hospeda a rede de perímetro, enquanto o ambiente local hospeda os aplicativos internos.
Para terminar a VPN ou os túneis SD-WAN de locais externos, como redes locais ou outras nuvens públicas.

Você pode adicionar os seguintes NVAs a um design do Azure usando os padrões neste artigo:

Firewalls de rede
Proxies reversos de camada 4
Pontos de extremidade de VPN IPsec (Segurança de Protocolo de Internet)
SD-WAN eletrodomésticos
Proxies reversos baseados em web que têm função de firewall de aplicação web
Proxies de Internet para restringir quais páginas da Internet podem ser acessadas a partir do Azure
Balanceadores de carga de camada 7

As NVAs nativas do Azure, como o Firewall do Azure e o Gateway de Aplicativo do Azure, usam os designs explicados posteriormente neste artigo. Você deve entender essas opções de uma perspectiva de design e para fins de solução de problemas de rede.

As NVAs geralmente exigem alta disponibilidade porque controlam a comunicação entre segmentos de rede. Se as NVAs ficarem indisponíveis, o tráfego de rede não poderá fluir e os aplicativos param de funcionar. Interrupções agendadas e não programadas ocasionalmente desligam instâncias de NVA, semelhantes a outras máquinas virtuais no Azure ou em outras nuvens. As instâncias de NVA poderão ser desligadas mesmo se você configurá-las com SSDs Premium do Azure, que fornecem um contrato de nível de serviço de instância única no Azure. Aplicativos de alta disponibilidade exigem pelo menos dois NVAs para ajudar a garantir a conectividade.

Quando você escolhe a melhor opção para implantar uma NVA em uma rede virtual do Azure, o aspecto mais importante é se o fornecedor de NVA avaliou e validou seu design. O fornecedor também deve fornecer a configuração de NVA necessária para integrar a NVA ao Azure. Se o fornecedor NVA fornecer várias opções de design com suporte, considere os seguintes fatores para tomar sua decisão:

Tempo de convergência: O tempo que leva cada design para redirecionar o tráfego para longe de uma instância NVA com falha
Suporte à topologia: As configurações de NVA que cada opção de design dá suporte, como clusters NVA ativos/ativos/em espera ou de expansão que têm uma unidade extra para redundância
Simetria de tráfego: Se um design específico força a NVA a executar a Conversão de Endereços de Rede de Origem (SNAT) nos pacotes para evitar o roteamento assimétrico ou se o design impõe simetria de tráfego por outros meios

Observação

Este artigo se concentra em designs hub-and-spoke. Este artigo não aborda a WAN Virtual do Azure porque ela tem diretrizes mais prescritivas para implantar NVAs, dependendo se um hub de Wan Virtual dá suporte a uma NVA específica. Para obter mais informações, consulte NVAs em um hub de WAN Virtual.

As seções a seguir descrevem arquiteturas comuns que você pode usar para integrar NVAs a uma rede hub-and-spoke.

Visão geral das arquiteturas de alta disponibilidade

Solução	Benefícios	Considerações
Azure Load Balancer	Essa solução dá suporte a configurações ativas/ativas e ativas/em espera e NVAs de expansão com um bom tempo de convergência.	A NVA precisa fornecer uma porta para as investigações de integridade, especialmente para implantações ativas/em espera. Para dispositivos com estado, como firewalls que exigem simetria de tráfego, os fluxos de e para a internet requerem SNAT.
Servidor de Rota do Azure	A NVA deve dar suporte ao PROTOCOLO BGP (Border Gateway Protocol). Essa solução dá suporte a NVAs ativas/ativas/em espera e de expansão.	A simetria de tráfego requer SNAT nesta solução.
Azure Gateway Load Balancer	A simetria de tráfego é garantida sem SNAT. NVAs podem ser compartilhadas entre locatários. Essa solução tem um bom tempo de convergência e oferece suporte a NVAs em configurações ativa/ativa, ativa/em espera e de expansão.	Essa solução dá suporte a fluxos de e para a Internet e não dá suporte a fluxos de East-West.
Endereço IP privado dinâmico e UDR	A NVA não requer recursos especiais. Essa solução garante o tráfego simétrico.	Essa solução é apenas para designs ativos/passivos. Tem um tempo de convergência alto de um a dois minutos.

Balanceador de carga

O design do Load Balancer usa dois balanceadores de carga do Azure para expor um cluster de NVAs ao restante da rede. A abordagem atende a NVAs com estado e sem estado.

Um balanceador de carga interno redireciona o tráfego interno do Azure e do ambiente local para os NVAs. Esse balanceador de carga interno é configurado com regras de portas de alta disponibilidade para que todas as portas TCP (Protocolo de Controle de Transmissão) e UDP (Protocolo de Datagrama de Usuário) sejam redirecionadas para as instâncias de NVA.
Um balanceador de carga público expõe os NVAs à Internet. As portas de alta disponibilidade são para tráfego de entrada, portanto, cada porta TCP/UDP precisa ser aberta em uma regra de balanceamento de carga dedicada.

O diagrama a seguir mostra a sequência de saltos que os pacotes levam da Internet para um servidor de aplicativos em uma rede virtual spoke. Esses pacotes atravessam uma NVA de firewall para controlar o tráfego de e para a Internet pública, também chamado como tráfego North-South.

Baixe um arquivo do Visio dessa arquitetura.

Para enviar tráfego de spokes para a Internet pública por meio dos NVAs, esse design usa uma UDR para 0.0.0.0/0. O próximo salto é o endereço IP do balanceador de carga interno.

Para o tráfego entre o Azure e a Internet pública, cada direção do fluxo de tráfego cruza um balanceador de carga do Azure diferente. Esse processo ocorre mesmo se o firewall NVA tiver uma NIC (placa de interface de rede) única para as redes públicas e internas, pois o pacote de entrada passa pelo balanceador de carga público do Azure e o pacote de saída passa pelo balanceador de carga interno do Azure. Ambas as direções do fluxo passam por diferentes balanceadores de carga. Portanto, se você precisar de simetria de tráfego, as instâncias NVA deverão executar o SNAT para atrair o tráfego de retorno e garantir a simetria do tráfego. A maioria dos firewalls exige simetria de tráfego.

O diagrama a seguir mostra como usar o mesmo design do balanceador de carga para inspecionar o tráfego entre redes do Azure e redes locais ou East-West tráfego, que envolve apenas um balanceador de carga interno. Você também pode usar esse método para enviar tráfego entre spokes por meio dos NVAs.

Nos diagramas anteriores, spoke1 não tem conhecimento do intervalo do spoke2. Portanto, a UDR envia o tráfego 0.0.0.0/0 destinado ao spoke2 para o balanceador de carga interno do Azure da NVA.

Para o tráfego entre redes locais e o Azure ou entre máquinas virtuais do Azure, a simetria de tráfego é garantida em NVAs de NIC único pelo balanceador de carga interno do Azure. Quando ambas as direções de um fluxo de tráfego atravessam o mesmo balanceador de carga do Azure, o balanceador de carga seleciona a mesma instância de NVA para ambas as direções. Se um design NVA de NIC dupla tiver um balanceador de carga interno para cada direção de comunicação, o SNAT garantirá a simetria do tráfego. O diagrama de North-South anterior fornece um exemplo desse design.

Nesse design, NVAs de NIC dupla devem determinar onde enviar respostas para as verificações de integridade do balanceador de carga. O Load Balancer sempre usa o mesmo endereço IP como fonte para as verificações de integridade, que é 168.63.129.16. A NVA deve enviar essas respostas de verificação de integridade de volta pela mesma interface na qual foram recebidas. Esse processo normalmente requer várias tabelas de roteamento em um sistema operacional porque o roteamento baseado em destino envia as respostas pela mesma NIC.

O balanceador de carga do Azure tem um tempo de convergência eficiente em interrupções de NVA individuais. Você pode enviar investigações de integridade a cada cinco segundos e são necessárias três investigações com falha para declarar uma instância de back-end fora de serviço. Portanto, geralmente leva de 10 a 15 segundos para que o balanceador de carga do Azure converga o tráfego para uma instância de NVA diferente.

Essa configuração dá suporte a configurações ativas/ativas e ativas/em espera. Para configurações ativas/em espera, as instâncias NVA precisam fornecer uma porta TCP ou UDP ou um ponto de extremidade HTTP que responda apenas às sondas de integridade do balanceador de carga para a instância que está atualmente na função ativa.

Balanceadores de carga de camada 7

Um design específico voltado para dispositivos de segurança substitui o balanceador de carga público do Azure por um balanceador de carga de camada 7, como o Gateway de Aplicativo do Azure, que em si pode ser considerado uma NVA.

Nesse cenário, as NVAs precisam apenas de um balanceador de carga interno para o tráfego dos sistemas de trabalho. Os dispositivos Dual-NIC às vezes usam essa abordagem para evitar problemas de roteamento com as verificações de integridade do balanceador de carga do Azure. Esse design dá suporte apenas aos protocolos de Camada 7 aos quais o balanceador de carga de Camada 7 dá suporte, que normalmente é HTTP e HTTPS.

A NVA deve lidar com o tráfego de entrada para protocolos aos quais o balanceador de carga de Camada 7 não dá suporte. A NVA também poderia lidar com o tráfego de saída. Para obter mais informações, consulte Firewall e Gateway de Aplicativo para redes virtuais.

Servidor de Rota

O Servidor de Rota é um serviço que permite que uma NVA interaja com a rede definida pelo software do Azure por meio do BGP. As NVAs aprendem quais prefixos de endereço IP existem em redes virtuais do Azure. Eles também podem injetar rotas nas tabelas de rotas efetivas de máquinas virtuais no Azure.

No diagrama anterior, cada instância de NVA se conecta ao Servidor de Rota via BGP. Este design não requer uma tabela de rotas nas sub-redes spoke, pois o Servidor de Rotas programa as rotas que os NVAs anunciam. Se duas ou mais rotas forem programadas nas máquinas virtuais do Azure, elas usarão o roteamento de vários caminhos de custo igual para escolher uma das instâncias de NVA para cada fluxo de tráfego. Portanto, você deve incluir o SNAT nesse design se precisar de simetria de tráfego.

Esse método de inserção dá suporte a configurações ativas/ativas e ativas/em espera. Em uma configuração ativa/ativa, todos os NVAs anunciam as mesmas rotas para o Servidor de Roteamento. Em uma configuração ativo/em espera, uma NVA anuncia rotas com um caminho de sistema autônomo (AS) mais curto do que a outra. O Servidor de Rota dá suporte a no máximo oito adjacências BGP. Portanto, se você usar um cluster de expansão de NVAs ativos, esse design oferecerá suporte a no máximo oito instâncias de NVA.

Essa configuração tem um tempo de convergência rápido. Os temporizadores keepalive e holdtime da adjacência BGP influenciam o tempo de convergência. O Servidor de Rotas tem temporizadores keepalive padrão definidos como 60 segundos e temporizadores de tempo de espera definidos como 180 segundos. Mas os NVAs podem negociar temporizadores menores durante o estabelecimento de conexão BGP. Definir esses temporizadores muito baixo pode levar a instabilidades bgp.

Esse design atende aos NVAs que precisam interagir com o roteamento do Azure. Exemplos incluem SD-WAN ou NVAs IPsec, que normalmente têm bom suporte a BGP. Esses NVAs precisam aprender os prefixos configurados em redes virtuais do Azure ou anunciar determinadas rotas por meio de emparelhamentos privados do ExpressRoute. Esses tipos de dispositivos geralmente são sem estado, portanto, a simetria de tráfego não é um problema e o SNAT não é necessário.

Balanceador de Carga para Gateway

O Gateway Load Balancer fornece uma maneira de inserir NVAs no caminho de dados sem a necessidade de rotear o tráfego usando Rotas Definidas pelo Usuário (UDRs). Para máquinas virtuais que expõem suas cargas de trabalho por meio de um balanceador de carga do Azure ou um endereço IP público, você pode redirecionar o tráfego de entrada e saída de forma transparente para um cluster de NVAs localizado em uma rede virtual diferente. O diagrama a seguir mostra o caminho que os pacotes seguem para o tráfego de entrada da Internet pública se as cargas de trabalho expõem o aplicativo por meio de um balanceador de carga do Azure.

Esse método de injeção de NVA fornece os seguintes benefícios:

Esse método não requer SNAT para garantir a simetria do tráfego.
Você pode usar as mesmas NVAs para inspecionar o tráfego de e para diferentes redes virtuais, o que fornece multilocação da perspectiva das NVAs.
O emparelhamento de rede virtual não é necessário entre a rede virtual NVA e as redes virtuais de carga de trabalho, o que simplifica a configuração.
As UDRs não são necessárias na rede virtual da carga de trabalho, o que também simplifica a configuração.

Você pode usar a injeção de serviço por meio do Gateway Load Balancer para tráfego de entrada para um balanceador de carga público do Azure, seu tráfego de retorno e tráfego de saída do Azure. East-West O tráfego entre máquinas virtuais do Azure não pode utilizar o Gateway Load Balancer para injeção de NVA.

No cluster NVA, as sondagens de verificação de integridade do balanceador de carga do Azure detectam falhas em instâncias individuais de NVA, proporcionando um tempo de convergência rápido de 10 a 15 segundos.

Gerenciamento de UDR e endereço IP público dinâmico

O objetivo deste planejamento é ter uma instalação que funcione sem redundância de NVA e possa ser modificada caso a NVA enfrente uma interrupção. O diagrama a seguir mostra como um endereço IP público do Azure é associado a uma NVA (NVA1 ativa no diagrama). As UDRs nos spokes utilizam o endereço IP da NVA ativa (10.0.0.37) como próximo salto.

Se a NVA ativa ficar indisponível, a NVA em espera chamará a API do Azure para remapear o endereço IP público e as UDRs de spoke para si mesma ou tomar controle do endereço IP privado. Essas chamadas à API podem levar vários minutos para serem eficazes. Esse design fornece o pior tempo de convergência entre as opções deste artigo.

Esse design dá suporte apenas a configurações ativas/em espera, o que pode levar a problemas de escalabilidade. Se você precisar aumentar a largura de banda que seus NVAs dão suporte, deverá ampliar ambas as instâncias.

Esse design não exige que o SNAT garanta a simetria do tráfego porque apenas uma NVA está ativa a qualquer momento.

Contribuidores

A Microsoft mantém este artigo. Os colaboradores a seguir escreveram este artigo.

Autores principais:

Keith Mayer | Arquiteto principal de soluções de nuvem
Telmo Sampaio | Gerente de Engenharia de Serviço principal
José Moreno | Engenheiro principal

Para ver perfis não públicos no LinkedIn, entre no LinkedIn.

Próxima etapa

Redes de perímetro

Implementar uma rede híbrida segura usando o Firewall do Azure