Implemente NVAs altamente disponíveis

Este artigo descreve maneiras comuns de implantar um conjunto de dispositivos virtuais de rede (NVAs) para alta disponibilidade no Azure. Um NVA normalmente controla o fluxo de tráfego entre segmentos de rede que têm diferentes níveis de segurança. pt-PT: Por exemplo, pode-se usar um NVA entre uma rede virtual de perímetro e a Internet pública ou para conectar locais externos ao Azure por meio de dispositivos de rede virtual privada (VPN) ou uma WAN (SD-WAN) definida por 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 rotas definidas pelo usuário (UDRs).

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 evitar 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 movimentos 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 encerrar túneis VPN ou 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 de IPsec (Segurança do Protocolo de Internet)
• SD-WAN eletrodomésticos
• Proxies reversos baseados na web que têm funcionalidade de Firewall de Aplicações Web
• Proxies de Internet para restringir quais páginas de Internet podem ser acedidas a partir do Azure
• Balanceadores de carga de camada 7

NVAs nativos do Azure, como o Firewall do Azure e o Gateway de Aplicações do Azure, usam os designs explicados mais adiante neste artigo. Você deve entender essas opções de uma perspetiva de design e para fins de solução de problemas de rede.

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

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

• Tempo de convergência: O tempo que cada design leva para redirecionar o tráfego para longe de uma instância NVA com falha

• Suporte a topologia: As configurações de NVA suportadas por cada opção de design, como clusters NVA ativos/ativos, ativos/em espera ou escaláveis que têm uma unidade extra para redundância

• Simetria de tráfego: Se um design específico força o NVA a executar a conversão de endereços de rede de origem (SNAT) nos pacotes para evitar roteamento assimétrico ou se o design impõe simetria de tráfego por outros meios

Observação

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

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

Visão geral das arquiteturas de alta disponibilidade

Solução	Benefícios	Considerações
Azure Load Balancer	Esta solução suporta configurações ativas/ativas e ativas/em espera, bem como NVAs escalonáveis com bom tempo de convergência.	O NVA precisa fornecer uma porta para as sondas de integridade, especialmente para implantações ativas/em espera. Para dispositivos com monitoração de estado, como firewalls que exigem simetria de tráfego, os fluxos de e para a Internet exigem SNAT.
Azure Route Server	O NVA deve suportar o Border Gateway Protocol (BGP). Esta solução suporta NVAs ativos/ativos, ativos/em espera e de expansão.	A simetria de tráfego requer SNAT nesta solução.
Azure Gateway Load Balancer	A simetria do tráfego é garantida sem SNAT. Os NVAs podem ser compartilhados entre locatários. Esta solução tem um bom tempo de convergência e suporta NVAs ativos/ativos, ativos/em espera e escaláveis.	Esta solução suporta fluxos de e para a Internet e não suporta fluxos de East-West.
Endereço IP privado dinâmico e UDR	O NVA não requer recursos especiais. Esta solução garante um tráfego simétrico.	Esta solução é apenas para projetos ativos/passivos. Tem um tempo de convergência elevado de um a dois minutos.

Balanceador de carga

O design do Balanceador de Carga usa dois balanceadores de carga do Azure para expor um cluster de NVAs ao resto da rede. A abordagem se adequa tanto às NVAs com estado quanto às sem estado.

• Um balanceador de carga interno redireciona o tráfego interno do Azure e das instalações locais para os Aparelhos de Rede Virtuais (NVAs). Esse balanceador de carga interno é configurado com regras de portas de alta disponibilidade para que cada porta TCP (Transmission Control Protocol) e UDP (User Datagram Protocol) seja redirecionada para as instâncias 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 falada. Esses pacotes atravessam um NVA de firewall para controlar o tráfego de e para a internet pública, também conhecido como North-South tráfego.

Este diagrama mostra um hub e dois raios. O hub contém uma sub-rede de gateway e uma sub-rede NVA. A sub-rede do gateway contém uma VPN ou um gateway da Rota Expressa do Azure. A sub-rede NVA contém um balanceador de carga interno do Azure e NVAs. Cada spoke contém um servidor de aplicativo. O Spoke2 tem uma nota que lê a tabela de rotas spoke 0.0.0.0/0 a 10.0.0.36 e desabilita a propagação do gateway. O tráfego de entrada flui da Internet pública para os NVAs por meio do balanceador de carga público do Azure. Em seguida, esse tráfego flui para o servidor de aplicativos no Spoke2. O tráfego de retorno flui desse servidor de aplicativo para os NVAs por meio do balanceador de carga interno do Azure. Este tráfego flui então para a Internet pública.

Baixe um arquivo Visio desta arquitetura.

Para enviar tráfego de extremidades para a Internet pública através dos NVAs, este design utiliza um 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 atravessa um balanceador de carga do Azure diferente. Esse processo ocorre mesmo se o NVA do firewall tiver uma única placa de interface de rede (NIC) para as redes pública e interna, porque 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 for necessária a simetria de tráfego, as instâncias NVA devem executar SNAT para atrair o tráfego de retorno e assegurar essa simetria. A maioria dos firewalls requer simetria de tráfego.

O diagrama a seguir mostra como usar o mesmo design de balanceador de carga para inspecionar o tráfego entre o Azure e redes locais, ou tráfego East-West , que envolve apenas um balanceador de carga interno. Você também pode usar este método para enviar tráfego entre satélites através das NVAs.

Este diagrama mostra um hub e dois raios. O hub contém uma sub-rede de gateway e uma sub-rede NVA. A sub-rede do gateway contém um gateway VPN ou ExpressRoute. A sub-rede NVA contém um balanceador de carga interno do Azure e NVAs. Cada spoke contém um servidor de aplicativo. O Spoke2 tem uma nota que lê a tabela de rotas spoke 0.0.0.0/0 a 10.0.0.36 e desabilita a propagação do gateway. O tráfego de entrada flui do local para os NVAs por meio do gateway VPN ou ExpressRoute e, em seguida, do balanceador de carga interno do Azure. Em seguida, esse tráfego flui para o servidor de aplicativos no Spoke2. O tráfego de retorno flui desse servidor de aplicativo para os NVAs por meio do balanceador de carga interno do Azure. Em seguida, esse tráfego flui para o local por meio do gateway VPN ou ExpressRoute.

Nos diagramas anteriores, o spoke1 não conhece o alcance do spoke2. Portanto, o 0.0.0.0/0 UDR envia o tráfego destinado ao spoke2 para o balanceador de carga interno do Azure do 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 única 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 NVA para ambas as direções. Se um projeto NVA com NIC duplas tiver um balanceador de carga interno para cada direção de comunicação, o SNAT garante a simetria do tráfego. O diagrama de North-South anterior fornece um exemplo desse design.

Nesse design, os NVAs de NIC dupla devem determinar para onde enviar respostas para as verificações de integridade do balanceador de carga. O Balanceador de Carga sempre usa o mesmo endereço IP da fonte para as verificações de integridade, que é 168.63.129.16. O NVA deve enviar essas respostas de verificação de integridade de volta através da 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 através da mesma NIC.

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

Esta configuração suporta as configurações ativa/ativa e ativa/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 atualmente na função ativa.

Balanceadores de carga de camada 7

Um design específico 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 pode ser considerado um NVA em si.

Nesse cenário, os NVAs exigem apenas um balanceador de carga interno para o tráfego dos sistemas de trabalho. Dispositivos Dual-NIC às vezes usam esta abordagem para evitar problemas de roteamento com as verificações de estado do balanceador de carga do Azure. Esse design suporta apenas os protocolos de Camada 7 que o balanceador de carga de Camada 7 suporta, que normalmente é HTTP e HTTPS.

O NVA deve lidar com o tráfego de entrada para protocolos que o balanceador de carga Layer-7 não suporta. O NVA também pode gerir o tráfego de saída. Para obter mais informações, consulte Firewall e Application Gateway para redes virtuais.

Servidor de Rotas

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

Este diagrama mostra um hub e dois raios. O hub contém uma sub-rede de gateway, uma sub-rede NVA e uma sub-rede do Servidor de Rotas. A sub-rede do gateway contém um gateway VPN ou ExpressRoute. A sub-rede NVA contém dois NVAs. A sub-rede do Route Server contém o Route Server. Cada spoke contém um servidor de aplicativo. O Spoke2 tem uma nota que lê as rotas efetivas faladas 0.0.0.0/0 a 10.0.0.37 e 0.0.0.0/0 a 10.0.0.38. O tráfego de entrada flui da Internet pública para NVA1 através do balanceador de carga público do Azure. Em seguida, esse tráfego flui para o servidor de aplicativos no Spoke2. Retorna fluxos de tráfego deste servidor de aplicativo para NVA1 e, em seguida, para a Internet pública. A adjacência BGP conecta NVA1, NVA2 e Route Server. O NVA2 e o Route Server estão conectados via eBGP.

No diagrama anterior, cada instância NVA se conecta ao Route Server via BGP. Esse design não requer uma tabela de rotas nas sub-redes spoke porque o Route Server programa as rotas anunciadas pelos NVAs. 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 NVA para cada fluxo de tráfego. Portanto, você deve incluir SNAT neste design se você precisar de simetria de tráfego.

Este método de inserção suporta as configurações ativo/ativo e ativo/em espera. Em uma configuração ativa/ativa, todos os NVAs anunciam as mesmas rotas para o Route Server. Em uma configuração ativa/standby, um NVA anuncia rotas com um caminho de Sistema Autônomo (AS) mais curto do que o outro. O Route Server suporta um máximo de oito adjacências BGP. Portanto, se você usar um cluster de expansão de NVAs ativos, esse design oferece suporte a um máximo de oito instâncias de NVA.

Esta 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 Route Server tem temporizadores keepalive padrão definidos para 60 segundos e temporizadores de tempo de espera definidos para 180 segundos. Os NVAs podem negociar valores mais baixos de temporizador durante o processo de estabelecimento da adjacência BGP. Definir esses temporizadores muito baixos pode levar a instabilidades BGP.

Esse design se adapta aos NVAs que precisam interagir com o roteamento do Azure. Os exemplos incluem NVAs SD-WAN ou IPsec, que normalmente têm um bom suporte a BGP. Esses NVAs precisam aprender os prefixos configurados nas redes virtuais do Azure ou anunciar determinadas rotas em ligações privadas ExpressRoute. Esses tipos de dispositivos geralmente são sem estado, portanto, a simetria do tráfego não é um problema e o SNAT não é necessário.

Experimente agora o Balanceador de Carga de Gateway

O Gateway Load Balancer fornece uma maneira de inserir NVAs no caminho de dados sem a necessidade de rotear o tráfego usando UDRs. Para máquinas virtuais que expõem suas cargas de trabalho por meio de um balanceador de carga do Azure ou de 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 exporem o aplicativo por meio de um balanceador de carga do Azure.

Este diagrama mostra uma rede virtual NVA e uma rede virtual de aplicativo. A rede virtual NVA contém Gateway Load Balancer e NVAs. A rede virtual do aplicativo contém um servidor Web. O fluxo de usuários vai da Internet para o servidor Web por meio de um balanceador de carga padrão público do Azure. O fluxo controlado pelo Balanceador de Carga de Gateway vai do balanceador de carga padrão público do Azure para o Balanceador de Carga de Gateway e, em seguida, para os NVAs. Esse fluxo inverte as direções e vai dos NVAs para o Balanceador de Carga do Gateway e, em seguida, para o balanceador de carga padrão público do Azure.

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

• Este método não requer SNAT para garantir simetria de tráfego.

• Você pode usar os mesmos NVAs para inspecionar o tráfego de e para diferentes redes virtuais, o que fornece multilocação da perspetiva do NVA.

• 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.

• UDRs não são necessários na rede virtual de carga de trabalho, o que também simplifica a configuração.

Você pode utilizar a injeção de serviço através do Gateway Load Balancer para o tráfego de entrada em um balanceador de carga público do Azure, o tráfego de retorno associado e o tráfego de saída do Azure. East-West o tráfego entre máquinas virtuais do Azure não pode usar o Balanceador de Carga de Gateway para integração de NVA.

No cluster NVA, os testes de verificação de integridade do balanceador de carga do Azure detetam falhas em instâncias NVA individuais, o que fornece um tempo de convergência rápido de 10 a 15 segundos.

Endereço IP público dinâmico e gerenciamento UDR

O objetivo deste design é ter uma configuração que funcione sem redundância de NVA e possa ser modificada em caso de interrupção do NVA. O diagrama a seguir mostra como um endereço IP público do Azure se associa a um NVA ativo (NVA1 no diagrama). Os UDRs nas ramificações usam o endereço IP do NVA que está ativo (10.0.0.37) como o próximo salto.

Este diagrama mostra um hub e dois raios. O hub contém uma sub-rede de gateway e uma sub-rede NVA. A sub-rede do gateway contém um gateway VPN ou ExpressRoute. A sub-rede NVA contém dois NVAs. NVA1 é rotulado como ativo e NVA2 é rotulado como em espera. Cada spoke contém um servidor de aplicativo. O Spoke2 tem uma nota que lê a tabela de rotas spoke 0.0.0.0/0 a 10.0.0.37 e desabilita a propagação do gateway. O tráfego de entrada flui da Internet para NVA1 através de um endereço IP público. Esse tráfego flui para Spoke2. O tráfego de retorno flui de Spoke2 para NVA1 e, em seguida, para a internet.

Se o NVA ativo ficar indisponível, o NVA em espera chamará a API do Azure para remapear o endereço IP público e os UDRs de integração para si mesmo, ou assumir o controle do endereço IP privado. Essas chamadas de API podem levar vários minutos para serem eficazes. Este design fornece o pior tempo de convergência entre as opções neste artigo.

Este design suporta apenas configurações ativas/standby, o que pode levar a problemas de escalabilidade. Se você precisar aumentar a largura de banda suportada por seus NVAs, deverá aumentar a escala de ambas as instâncias.

Este design não requer SNAT para garantir simetria de tráfego porque apenas um NVA está ativo a qualquer momento.

Contribuidores

A Microsoft mantém este artigo. Os seguintes colaboradores escreveram este artigo.

Principais autores:

• Keith Mayer | Arquiteto Principal de Soluções em Nuvem
• Telmo Sampaio | Gerente Principal de Engenharia de Serviços
• Jose Moreno - Brasil | Engenheiro Principal

Para ver perfis não públicos do LinkedIn, inicie sessão no LinkedIn.

Próximo passo

• Redes de perímetro

Recurso relacionado

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