Este artigo explica as opções mais comuns para implantar um conjunto de NVAs (Dispositivos Virtuais de Rede) para alta disponibilidade no Azure. Um NVA é normalmente usado para controlar o fluxo de tráfego entre segmentos de rede classificados com diferentes níveis de segurança, por exemplo, entre uma DMZ (Rede Virtual de Zona Desmilitarizada) e a Internet pública.
Há vários padrões de design em que as NVAs são usadas para inspecionar o tráfego entre diferentes zonas de segurança, por exemplo:
- Para inspecionar o tráfego de saída de máquinas virtuais para a Internet e impedir a exfiltração dos 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, a fim de evitar movimentações laterais de sistemas comprometidos.
- Para filtrar o tráfego entre sistemas locais e máquinas virtuais do Azure, se eles forem considerados pertencentes a diferentes níveis de segurança. (Por exemplo, se o Azure hospedar a DMZ e localmente os aplicativos internos.)
Há muitos exemplos de NVAs, como firewalls de rede, proxies reversos de Camada 4, pontos de extremidade VPN IPsec, proxies reversos baseados na Web com funcionalidade de firewall de aplicativo Web, proxies da Internet para restringir quais páginas da Internet podem ser acessadas do Azure, balanceadores de carga de Camada 7 e muitos outros. Todos eles podem ser inseridos em um design do Azure com os padrões descritos neste artigo. Até mesmo dispositivos virtuais de rede próprios do Azure, como o Firewall do Azure e o Gateway de Aplicativo do Azure, usam os designs explicados posteriormente neste artigo. Entender essas opções é fundamental tanto do ponto de vista do design quanto da solução de problemas de rede.
A primeira pergunta a ser respondida é por que a alta disponibilidade para dispositivos virtuais de rede é necessária. O motivo é que esses dispositivos controlam a comunicação entre segmentos de rede. Se eles não estiverem disponíveis, o tráfego de rede não poderá fluir e os aplicativos deixarão de funcionar. Interrupções agendadas e não agendadas podem e vão ocasionalmente reduzir as instâncias de NVA (como qualquer outra máquina virtual no Azure ou em qualquer outra nuvem). As instâncias serão derrubadas mesmo se essas NVAs estiverem configuradas com Premium Managed Disks para fornecer um SLA de instância única no Azure. Portanto, aplicativos altamente disponíveis exigirão pelo menos uma segunda NVA que possa garantir a conectividade.
Pré-requisitos: Este artigo pressupõe uma compreensão básica da rede do Azure, do Azure Load Balancers e de UDRs (Roteamento de Tráfego de Rede Virtual).
Ao escolher a melhor opção para implantar uma Máquina Virtual de Rede em uma VNet do Azure, o aspecto mais importante a ser considerado é se o fornecedor de NVA examinou e validou esse design específico. O fornecedor também deve fornecer a configuração de NVA necessária para integrar a NVA no Azure. Se o fornecedor de NVA oferecer alternativas diferentes como opções de design com suporte para uma NVA, estes fatores poderão influenciar a decisão:
- Tempo de convergência: quanto tempo leva em cada design para afastar o tráfego de uma instância de NVA com falha?
- Suporte à topologia: a quais configurações de NVA cada opção de design dá suporte? Clusters de NVA ativos/ativos, ativos/em espera e escalonados com redundância n+1?
- Simetria de tráfego: um design específico força a NVA a executar a SNAT (Conversão de Endereços de Rede de Origem) nos pacotes para evitar o roteamento assimétrico? Ou a simetria de tráfego é imposta por outros meios?
As seções a seguir no documento descreverão as arquiteturas mais comuns usadas para integrar NVAs a uma rede hub-spoke.
Observação
Este artigo é focado em designs Hub & Spoke. O WAN Virtual não é abordado, pois é muito mais prescritivo sobre como as NVAs são implantadas, dependendo se há suporte para uma NVA específica nos hubs de WAN Virtual. Confira Dispositivos Virtuais de Rede no hub de WAN Virtual para obter mais informações.
Visão geral das arquiteturas de HA
As arquiteturas a seguir descrevem os recursos e a configuração necessários para NVAs altamente disponíveis:
| Solução | Benefícios | Considerações |
|---|---|---|
| Azure Load Balancer | Dá suporte a NVAs ativas/ativas, ativas/em espera e de expansão. Tempo de convergência muito bom | A NVA precisa fornecer uma porta para as investigações de integridade, especialmente para implantações ativas/em espera. Fluxos de/para a Internet exigem SNAT para simetria |
| Servidor de Rota do Azure | A NVA precisa dar suporte ao BGP. Dá suporte a NVAs ativas/ativas, ativas/em espera e de expansão. | A simetria de tráfego requer SNAT |
| Balanceador de Carga para Gateway | Simetria de tráfego garantida sem SNAT. As NVAs podem ser compartilhadas entre locatários. Tempo de convergência muito bom. Dá suporte a NVAs ativas/ativas, ativas/em espera e de expansão. | Dá suporte a fluxos de/para a Internet, sem fluxos de East-West |
| Alteração de PIP/UDR | Nenhum recurso especial exigido pela NVA. Garante um tráfego simétrico | Somente para designs ativos/passivos. Tempo de convergência alta de 1 a 2 minutos |
Design do Load Balancer
Esse design usa dois Azure Load Balancers para expor um cluster de NVAs ao restante da rede:
- Um Load Balancer interno é usado para redirecionar o tráfego interno do Azure e local para as NVAs. Esse balanceador de carga interno é configurado com regras de Portas de HA, de modo que cada porta TCP/UDP seja redirecionada para as instâncias de NVA.
- Um Load Balancer público expõe as NVAs à Internet. Como as portas de HA são para tráfego de entrada, cada porta TCP/UDP individual precisa ser aberta em uma regra de balanceamento de carga dedicada.
O diagrama a seguir descreve a sequência de saltos que os pacotes da Internet para um servidor de aplicativo em uma VNet spoke seguiriam:
Baixe um Arquivo Visio dessa arquitetura.
O mecanismo para enviar tráfego de spokes para a Internet pública por meio das NVAs é uma rota definido pelo usuário para 0.0.0.0/0 com o próximo salto do endereço IP interno do Load Balancer.
Para o tráfego entre o Azure e a Internet pública, cada direção do fluxo de tráfego atravessará um Azure Load Balancer diferente (o pacote de entrada por meio do ALB público e o pacote de saída por meio do ALB interno). Como consequência, se a simetria de tráfego for necessária, a SNAT (Conversão de Endereços de Rede de Origem) precisará ser executada pelas instâncias de NVA para atrair o tráfego retornado e evitar a assimetria de tráfego.
Esse design também pode ser usado para inspecionar o tráfego entre o Azure e as redes locais:
O mecanismo para enviar tráfego entre spokes por meio de NVAs é exatamente o mesmo, portanto, nenhum diagrama adicional é fornecido. Nos diagramas de exemplo acima, uma vez que o spoke1 não sabe sobre o intervalo do spoke2, a UDR 0.0.0.0/0 enviará o tráfego endereçado ao spoke2 para o Azure Load Balancer interno 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 pela Azure Load Balancer interna: quando ambos os sentidos de um fluxo de tráfego atravessam o mesmo Azure Load Balancer, a mesma instância de NVA será escolhida.
O Azure Load Balancer tem um tempo de convergência muito bom em caso de interrupções individuais de NVA. Como as investigações de integridade podem ser enviadas 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, geralmente leva de 10 a 15 segundos para o Azure Load Balancer convergir o tráfego para uma instância diferente de NVA.
Essa configuração dá suporte a configurações ativas/ativas e ativas/em espera. No entanto, para configurações ativas/em espera, as instâncias de NVA precisam oferecer uma porta TCP/UDP ou um ponto de extremidade HTTP que não responda às investigações de integridade do Load Balancer, a menos que a instância esteja na função ativa.
Usar balanceadores de carga L7
Um caso específico desse design é substituir o Load Balancer público do Azure por um balanceador de carga de Camada 7, como o Gateway de Aplicativo do Azure (que pode ser considerado uma NVA por conta própria). Nesse caso, as NVAs exigirão apenas um Load Balancer interno à sua frente, uma vez que o tráfego do Gateway de Aplicativo será proveniente de dentro da VNet, e a assimetria de tráfego não é uma preocupação.
A NVA deve estar usando o tráfego de entrada para protocolos não compatíveis com o balanceador de carga de Camada 7, além de potencialmente todo o tráfego de saída. Para obter mais detalhes sobre essa configuração ao usar Firewall do Azure como NVA e Gateway de Aplicativo do Azure como proxy reverso da Web da Camada 7, confira Firewall e Gateway de Aplicativo para redes virtuais.
Servidor de Rota do Azure
O Servidor de Rota do Azure é um serviço que permite que uma NVA interaja com o SDN do Azure por meio do BGP (Border Gateway Protocol). Não apenas as NVAs saberão quais prefixos IP existem nas VNets do Azure, mas poderão injetar rotas nas tabelas de rotas efetivas das máquinas virtuais no Azure.
No diagrama acima, cada instância de NVA é emparelhada por BGP com o Servidor de Rota do Azure. Nenhuma tabela de rotas é necessária nas sub-redes spoke, pois o Servidor de Rota do Azure programará as rotas anunciadas pelas NVAs. Se duas ou mais rotas forem programadas nas máquinas virtuais do Azure, elas usarão o ECMP (Equal Cost MultiPathing) para escolher uma das instâncias de NVA para cada fluxo de tráfego. Como consequência, o SNAT será obrigatório nesse design se a simetria de tráfego for um requisito.
Esse método de inserção dá suporte a ativo/ativo (todos os NVAs anunciam as mesmas rotas para o Servidor de Rota do Azure), bem como ativo/em espera (uma NVA anuncia rotas com um caminho AS mais curto que o outro). O Servidor de Rota do Azure dá suporte a um máximo de oito adjacências de BGP. Portanto, se estiver usando um cluster de expansão de NVAs ativos, esse design dará suporte a no máximo oito instâncias de NVA.
O tempo de convergência é muito rápido nessa configuração e será influenciado pelos temporizadores keepalive e holdtime da adjacência de BGP. Embora o Servidor de Rota do Azure tenha temporizadores keepalive e holdtime padrão (60 segundos e 180 segundos, respectivamente), as NVAs podem negociar temporizadores inferiores durante o estabelecimento de adjacência de BGP. Definir esses temporizadores muito baixos pode levar a instabilidades de BGP.
Esse design é a opção mais comum para NVAs que precisam interagir com o roteamento do Azure, por exemplo, NVAs de encerramento de VPN que precisam aprender os prefixos configurados em VNets do Azure ou anunciar determinadas rotas por emparelhamentos privados do ExpressRoute.
Balanceador de Carga para Gateway
O Gateway do Azure Load Balancer é uma nova maneira de inserir NVAs no caminho de dados sem a necessidade de orientar o tráfego com Rotas definidos pelo usuário. Para Máquinas Virtuais que expõem suas cargas de trabalho por meio de um Azure Load Balancer ou um endereço IP público, o tráfego de entrada e saída pode ser redirecionado de forma transparente para um cluster de NVAs localizado em uma VNet diferente. O diagrama a seguir descreve o caminho que os pacotes seguem para o tráfego de entrada da Internet pública, caso as cargas de trabalho exponham o aplicativo por meio de um Azure Load Balancer:
Uma das principais vantagens desse método de injeção de NVA é que a SNAT (Conversão de Endereços de Rede de Origem) não é necessária para garantir a simetria do tráfego. Outro benefício dessa opção de design é que as mesmas NVAs podem ser usadas para inspecionar o tráfego de/para VNets diferentes, obtendo assim multilocatário da perspectiva da NVA. Nenhum emparelhamento de VNet é necessário entre a VNet NVA e as VNets de carga de trabalho e nenhuma rota definida pelo usuário é necessária na VNet de carga de trabalho, o que simplifica drasticamente a configuração.
A injeção de serviço com o gateway do Load Balancer pode ser usada para fluxos de entrada atingindo um Load Balancer público do Azure (e seu tráfego de retorno), bem como para fluxos de saída originários do Azure. O tráfego East-West entre máquinas virtuais do Azure não pode aproveitar o gateway do Load Balancer para injeção de NVA.
No cluster NVA, as sondagens de verificação de integridade do Azure Load Balancer serão usadas para detectar falhas de instância de NVA individuais, alcançando um tempo de convergência muito rápido (10 a 15 segundos).
Alteração de PIP-UDR
A ideia por trás desse design é ter a configuração que seria necessária sem redundância de NVA e modificá-la caso a NVA sofra com tempo de inatividade. O diagrama a seguir mostra como um endereço IP público do Azure está associado à NVA (NVA1) ativa e as rotas definidas pelo usuário nos spokes têm o endereço IP da NVA ativa como próximo salto (10.0.0.37).
Se a NVA ativa ficar indisponível, o NVA em espera chamará a API do Azure para remapear o endereço IP público e as Rotas definidas pelo usuário para si mesmo (ou mover o endereço IP privado também). Essas chamadas à API podem levar alguns minutos para serem efetivas, razão pela qual esse design oferece o pior tempo de convergência de todas as opções neste documento.
Outra limitação desse design é que há suporte apenas para configurações ativas/em espera, o que pode levar a problemas de escalabilidade: se você precisar aumentar a largura de banda com suporte de suas NVAs, a única opção com esse design será escalar as duas instâncias.
Um benefício desse design é que nenhuma SNAT (Conversão de Endereços de Rede de Origem) é necessária para garantir a simetria do tráfego, pois há apenas uma NVA ativa em um determinado momento.
Colaboradores
Esse artigo é mantido pela Microsoft. Ele foi originalmente escrito pelos colaboradores a seguir.
Principais autores:
- Keith Mayer - Brasil | Arquiteto Principal de Soluções em Nuvem
- Telmo Sampaio - Portugal | Gerente Principal de Engenharia de Serviços
Para ver perfis não públicos do LinkedIn, entre no LinkedIn.
Próximas etapas
- Saiba como implementar uma rede híbrida segura usando o Firewall do Azure.
- Redes de Perímetro – Cloud Adoption Framework
- DMZ de nuvem – Cloud Adoption Framework