Este artigo explica as opções mais comuns para implantar um conjunto de NVAs (Network Virtual Appliances) 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 Rede Virtual de Zona Desmilitarizada (DMZ) e a Internet pública.
Há uma série de padrões de design em que os NVAs são usados 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 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, se forem consideradas como pertencentes a diferentes níveis de segurança. (Por exemplo, se o Azure hospedar a DMZ e no local 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 aplicativos 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 os Dispositivos Virtuais de Rede de primeira parte do Azure, como o Firewall do Azure e o Gateway de Aplicativo do Azure, usam os designs explicados posteriormente neste artigo. Compreender essas opções é fundamental tanto do ponto de vista do design quanto na solução de problemas de rede.
A primeira pergunta a ser respondida é por que a alta disponibilidade para dispositivos virtuais de rede é necessária. A razão é porque 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 programadas e não programadas podem e ocasionalmente derrubarão instâncias NVA (como qualquer outra máquina virtual no Azure ou em qualquer outra nuvem). As instâncias são derrubadas mesmo se esses NVAs estiverem configurados com Discos Gerenciados Premium para fornecer um SLA de instância única no Azure. Assim, aplicativos altamente disponíveis exigirão pelo menos um segundo NVA que possa garantir conectividade.
Pré-requisitos: Este artigo pressupõe uma compreensão básica da rede do Azure, dos Balanceadores de Carga do Azure e dos UDRs (Roteamento de Tráfego de Rede Virtual ).
Ao escolher a melhor opção para implantar um Dispositivo Virtual de Rede em uma VNet do Azure, o aspeto mais importante a considerar é 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 o NVA no Azure. Se o fornecedor de NVA oferecer diferentes alternativas como opções de design suportadas para um NVA, estes fatores podem influenciar a decisão:
- Tempo de convergência: quanto tempo leva em cada projeto para desviar o tráfego de uma instância NVA com falha?
- Suporte a topologia: quais configurações NVA cada opção de projeto suporta? Clusters NVA ativos/ativos, ativos/em espera, escaláveis com redundância n+1?
- Simetria de tráfego: um design específico força o NVA a executar o SNAT (Source Network Address Translation) nos pacotes para evitar roteamento assimétrico? Ou a simetria do tráfego é imposta por outros meios?
As seções a seguir no documento descreverão as arquiteturas mais comuns usadas para integrar NVAs em uma rede Hub e Spoke.
Nota
Este artigo é focado em designs Hub & Spoke. A WAN virtual não é coberta, uma vez que a WAN virtual é muito mais prescritiva sobre como os NVAs são implantados, dependendo se um NVA específico é suportado nos hubs de WAN virtual. Consulte Dispositivos virtuais de rede no hub WAN virtual para obter mais informações.
Visão geral das arquiteturas HA
As arquiteturas seguintes descrevem os recursos e a configuração necessários para NVAs de elevada disponibilidade:
| Solução | Benefícios | Considerações |
|---|---|---|
| Balanceador de Carga do Azure | Suporta NVAs ativos/ativos, ativos/em espera e escaláveis. Muito bom tempo de convergência | O NVA precisa fornecer uma porta para as sondas de integridade, especialmente para implantações ativas/em espera. Os fluxos de/para a Internet requerem SNAT para simetria |
| Azure Route Server | O NVA precisa suportar BGP. Suporta NVAs ativos/ativos, ativos/em espera e escaláveis. | A simetria de tráfego requer SNAT |
| Balanceador de carga de gateway | Simetria de tráfego garantida sem SNAT. Os NVAs podem ser compartilhados entre locatários. Muito bom tempo de convergência. Suporta NVAs ativos/ativos, ativos/em espera e escaláveis. | Suporta fluxos de/para a Internet, sem fluxos Leste-Oeste |
| Alterando PIP/UDR | Nenhum recurso especial exigido pelo NVA. Garante um tráfego simétrico | Apenas para projetos ativos/passivos. Alto tempo de convergência de 1-2 minutos |
Design do balanceador de carga
Este design usa dois Balanceadores de Carga do Azure para expor um cluster de NVAs ao resto da rede:
- Um Balanceador de Carga interno é usado para redirecionar o tráfego interno do Azure e local para os NVAs. Este balanceador de carga interno é configurado com regras de portas HA, para que cada porta TCP/UDP seja redirecionada para as instâncias NVA.
- Um balanceador de carga público expõe os NVAs à Internet. Como as portas 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 aplicativos em uma VNet spoke seguiriam:
Transfira um ficheiro do Visio desta arquitetura.
O mecanismo para enviar tráfego de raios para a Internet pública através dos NVAs é uma rota definida pelo usuário para 0.0.0.0/0 com o próximo salto o endereço IP interno do balanceador de carga.
Para o tráfego entre o Azure e a Internet pública, cada direção do fluxo de tráfego atravessará um Balanceador de Carga do Azure diferente (o pacote de entrada por meio do ALB público e o pacote de saída pelo ALB interno). Como consequência, se a simetria de tráfego for necessária, a Conversão de Endereço de Rede de Origem (SNAT) precisará ser executada pelas instâncias NVA para atrair o tráfego de retorno e evitar 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 raios através dos NVAs é exatamente o mesmo, portanto, nenhum diagrama adicional é fornecido. Nos diagramas de exemplo acima, como spoke1 não sabe sobre o intervalo do spoke2, o UDR enviará tráfego endereçado 0.0.0.0/0 a spoke2 para o Azure Load Balancer interno 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 pelo Balanceador de Carga do Azure interno: quando ambas as direções de um fluxo de tráfego atravessam o mesmo Balanceador de Carga do Azure, a mesma instância NVA será escolhida.
O Azure Load Balancer tem um tempo de convergência muito bom em caso de interrupções individuais de NVA. Como os testes de integridade podem ser enviados a cada 5 segundos e são necessárias 3 testes com falha para declarar uma instância de back-end fora de serviço, 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. No entanto, para configurações ativas/em espera, as instâncias NVA precisam oferecer uma porta TCP/UDP ou um ponto de extremidade HTTP que não responda aos testes de integridade do Balanceador de Carga, a menos que a instância esteja na função ativa.
Usando balanceadores de carga L7
Um caso particular desse design é a substituição do 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 como um NVA por conta própria). Nesse caso, os NVAs exigirão apenas um Load Balancer interno na frente deles, já que o tráfego do Application Gateway será originado de dentro da VNet, e a assimetria de tráfego não é uma preocupação.
O NVA deve receber tráfego de entrada para protocolos não suportados pelo seu balanceador de carga Layer-7, além de potencialmente todo o tráfego de saída. Para obter mais detalhes sobre essa configuração ao usar o Firewall do Azure como NVA e o Gateway de Aplicativo do Azure como proxy reverso da Web de Camada 7, consulte Firewall e Gateway de Aplicativo para redes virtuais.
Azure Route Server
O Azure Route Server é um serviço que permite que um NVA interaja com o Azure SDN por meio do BGP (Border Gateway Protocol). Não apenas os NVAs aprenderão quais prefixos IP existem nas VNets do Azure, mas também poderão injetar rotas nas tabelas de rotas efetivas das máquinas virtuais no Azure.
No diagrama acima, cada instância NVA é emparelhada sobre BGP com o Servidor de Rotas do Azure. Nenhuma tabela de rotas é necessária nas sub-redes faladas, pois o Azure Route Server programará as rotas anunciadas pelos 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 NVA para cada fluxo de tráfego. Como consequência, SNAT é uma obrigação neste projeto se a simetria de tráfego é um requisito.
Esse método de inserção dá suporte a ativo/ativo (todos os NVAs anunciam as mesmas rotas para o Servidor de Rotas do Azure), bem como ativo/em espera (um NVA anuncia rotas com um caminho AS mais curto do que o outro). O Azure Route Server suporta um máximo de 8 adjacências BGP. Portanto, se estiver usando um cluster de expansão de NVAs ativos, esse design suportará um máximo de 8 instâncias de NVA.
O tempo de convergência é bastante rápido nesta configuração, e será influenciado pelos temporizadores keepalive e holdtime da adjacência BGP. Enquanto o Servidor de Rotas do Azure tem temporizadores keepalive e holdtime padrão (60 segundos e 180 segundos, respectivamente), os NVAs podem negociar temporizadores mais baixos durante o estabelecimento de adjacência BGP. Definir esses temporizadores muito baixos pode levar a instabilidades BGP.
Esse design é a opção mais comum para NVAs que precisam interagir com o roteamento do Azure, por exemplo, NVAs de terminação de VPN que precisam aprender os prefixos configurados nas redes virtuais do Azure ou anunciar determinadas rotas em emparelhamentos privados da Rota Expressa.
Experimente agora o Balanceador de Carga de Gateway
O Balanceador de Carga do Gateway do Azure é uma nova maneira de inserir NVAs no caminho de dados sem a necessidade de direcionar o tráfego com Rotas Definidas pelo Usuário. 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, 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 Balanceador de Carga do Azure:
Uma das principais vantagens deste método de injeção de NVA é que a Tradução de Endereço de Rede de Origem (SNAT) não é necessária para garantir a simetria do tráfego. Outro benefício desta opção de design é que os mesmos NVAs podem ser usados para inspecionar o tráfego de/para diferentes VNets, alcançando assim a multilocação da perspetiva NVA. Nenhum emparelhamento de VNet é necessário entre a VNet NVA e a(s) VNet(s) 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 Balanceador de Carga de Gateway pode ser usada para fluxos de entrada atingindo um Balanceador de Carga público do Azure (e seu tráfego de retorno), bem como para fluxos de saída originários do Azure. O tráfego Leste-Oeste entre máquinas virtuais do Azure não pode aproveitar o Balanceador de Carga de Gateway para injeção de NVA.
No cluster NVA, as sondas de verificação de integridade do Balanceador de Carga do Azure serão usadas para detetar falhas de instância NVA individuais, alcançando um tempo de convergência muito rápido (10 a 15 segundos).
Alterando PIP-UDR
A ideia por trás deste design é ter a configuração que seria necessária sem redundância NVA, e modificá-lo no caso de o NVA sofrer com o tempo de inatividade. O diagrama abaixo mostra como um endereço IP público do Azure está associado ao NVA ativo (NVA1), e as rotas definidas pelo usuário nos raios têm o endereço IP do NVA ativo como próximo salto (10.0.0.37).
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 as Rotas definidas pelo usuário faladas para si mesmo (ou mover o endereço IP privado também). Essas chamadas de API podem levar alguns minutos para serem eficazes, e é por isso que esse design oferece o pior tempo de convergência de todas as opções neste documento.
Outra limitação desse design é que apenas configurações ativas/standby são suportadas, o que pode levar a problemas de escalabilidade: se você precisar aumentar a largura de banda suportada por seus NVAs, a única opção com esse design é escalar ambas as instâncias.
Um benefício desse design é que nenhuma SNAT (Source Network Address Translation) é necessária para garantir a simetria do tráfego, uma vez que há apenas um NVA ativo em um determinado momento.
Contribuidores
Este artigo é mantido pela Microsoft. Foi originalmente escrito pelos seguintes contribuidores.
Principais autores:
- Keith Mayer - Brasil | Arquiteto Principal de Soluções na Nuvem
- Telmo Sampaio - Portugal | Gerente Principal de Engenharia de Serviços
Para ver perfis não públicos do LinkedIn, inicie sessão no LinkedIn.
Próximos passos
- Saiba como implementar uma rede híbrida segura usando o Firewall do Azure.
- Redes de perímetro - Cloud Adoption Framework
- Cloud DMZ - Estrutura de adoção de nuvem