A nuvem está mudando a forma como a infraestrutura é projetada, incluindo o design de firewalls, porque a rede não é mais física ou em LANs virtuais. Nem todas as funcionalidades de uma rede física estão disponíveis numa rede virtual (VNet). Isto inclui a utilização de endereços IP flutuantes ou tráfego de difusão, o que influencia a implementação de arquiteturas HA. Os balanceadores de carga para Aplicações Virtuais de Rede (NVAs) podem/têm de ser implementados de uma determinada forma para alcançarem uma arquitetura de elevada disponibilidade (HA) numa rede virtual. Este guia apresenta uma abordagem estruturada para a conceção de firewalls HA (FWs) no Azure através de aplicações virtuais de terceiros.
Opções para conceber NVAs de elevada disponibilidade
Ao implementar arquiteturas HA, existem algumas opções para proporcionar ativação pós-falha:
- Tabelas de rotas gerenciadas pela API do Azure: essa opção usa duas tabelas de rotas, uma ativa e outra passiva para alternar o IP do gateway ativo para todos os serviços executados em uma rede virtual/sub-rede.
- IP flutuante gerenciado pela API do Azure: essa opção usa um endereço IP secundário nos FWs que pode ser movido entre um FW ativo e um FW em stand-by.
- Balanceador de Carga gerenciado: essa opção usa um Balanceador de Carga do Azure para atuar como o IP do gateway para a sub-rede, que encaminha o tráfego para o FW ativo. Pode até encaminhar o tráfego ativo-ativo para proporcionar um verdadeiro balanceamento de carga.
O problema das duas primeiras opções é que a ativação pós-falha é lenta. O FW deve instruir o failover, que é essencialmente uma "reconfiguração" dos serviços do Azure por meio de uma nova implantação. Consoante a rapidez com que a implementação é concluída, os fluxos de tráfego serão reduzidos durante alguns minutos. Além disso, não permite uma configuração ativa-ativa em que ambos os firewalls estejam operando ao mesmo tempo.
É por isso que a terceira opção é a preferida. O tempo de inatividade é minimizado, uma vez que o balanceador de carga pode efetuar a ativação pós-falha quase instantaneamente na firewall em espera (no modo ativo-passivo) ou simplesmente remover a carga da firewall falhada (ativa-ativa). Mas você não pode simplesmente usar balanceadores de carga como "gateways padrão", pois eles afetam o fluxo de tráfego e os pacotes TCP precisam ser stateful.
Firewalls de dois lados
A imagem seguinte começa com duas FWs (FW-1 e FW-2), com um balanceador de carga externo e um servidor de back-end S1.
Esta arquitetura é uma configuração simples, usada para tráfego de entrada. Um pacote atinge o balanceador de carga, que escolhe a FW de destino a partir da sua configuração. A firewall escolhida envia o tráfego para o servidor de back-end (Web). Se o FW-1 tiver o SNAT habilitado, o servidor S1 verá o tráfego que vem do IP interno do FW-1, então ele também enviará a resposta ao pacote para o FW-1. A ativação pós-falha pode ocorrer rapidamente na FW-2 neste cenário. Para o tráfego de saída, poderíamos adicionar outro balanceador de carga no lado interno. Quando o servidor S1 inicia o tráfego, o mesmo princípio será aplicado. O tráfego atinge o LB interno (iLB), que escolhe um firewall que, em seguida, traduz NAT para resolução externa:
Firewalls de três lados
Problemas surgem quando adicionamos outra interface ao firewall, e você precisa desativar a tradução NAT entre zonas internas . Nesse caso, consulte Sub-rede-B e Sub-rede-C:
O balanceamento de carga do encaminhamento L3 entre as zonas internas (Sub-rede-B e Sub-rede-C) será feito sem NAT. Essa configuração torna-se mais clara olhando para os fluxos de tráfego, incluindo os balanceadores de carga em uma exibição diferente. O diagrama abaixo mostra a vista onde os Balanceador de Carga internos [iLB] estão associados a um NIC específico nas FWs:
Com o tráfego L3 (sem NAT), o S2 verá o endereço IP S1 como o endereço de origem. O S2 enviará então o tráfego de retorno da sub-rede B (à qual pertence o S1-IP) para o iLB na Subnet-C. Como o iLB na Subnet-B e o iLB na Subnet-C não sincronizam seus estados de sessão, dependendo do algoritmo de balanceamento de carga, o tráfego pode acabar no FW-2. FW-2 por padrão não sabe nada sobre o pacote inicial (verde), então ele vai descartar a conexão.
Alguns fornecedores de firewall tentam manter um estado de conexão entre os firewalls, mas eles precisariam de sincronização quase instantânea para estarem atualizados sobre os estados de conexão. Contacte o seu fornecedor de firewall para verificar se recomendam esta configuração.
A melhor forma de lidar com este problema é eliminá-lo. No exemplo acima, esta solução significa eliminar Subnet-C, o que nos leva às vantagens das VNets virtualizadas.
Isolar anfitriões numa sub-rede com Grupos de Segurança de Rede
Quando existem duas VMs numa única sub-rede, pode aplicar um NSG que isola o tráfego entre ambas. Por padrão, o tráfego dentro de uma rede virtual é totalmente permitido. Adicionar uma regra Recusar tudo no NSG permite isolar todas as VMs entre si.
As VNets utilizam os mesmos routers de back-end (virtuais)
As VNet/sub-redes usam um único sistema de roteador back-end do Azure e, como tal, não há necessidade de especificar um IP de roteador para cada sub-rede. O destino da rota pode estar em qualquer lugar na mesma VNET ou mesmo fora.
Com as redes virtualizadas, pode controlar as rotas em cada sub-rede. Estas rotas também podem apontar para um único IP noutra sub-rede. Na imagem acima, este seria o iLB na Sub-rede-D, que efetua o balanceamento de carga das duas firewalls. À medida que o S1 inicia o tráfego (verde), ele terá balanceamento de carga para, por exemplo, FW-1. Em seguida, a FW-1 irá ligar ao S2 (ainda verde). S2 enviará o tráfego de resposta para o IP de S1 (como NAT está desativado). Devido às tabelas de rotas, o S2 usa o mesmo IP iLB como seu gateway. O iLB pode corresponder o tráfego à sessão inicial, por isso sempre apontará esse tráfego de volta para FW-1. Em seguida, o FW-1 envia-o para o S1, estabelecendo um fluxo de tráfego síncrono.
Para que essa configuração funcione, o FW precisa ter uma tabela de rotas (internamente) apontando Subnet-B e Subnet-C para sua sub-rede GW padrão. Essa sub-rede GW é o primeiro IP logicamente disponível no intervalo de sub-redes nessa VNET.
Impacto nos serviços de proxy inverso
Quando você implanta um serviço de proxy reverso, normalmente ele estaria atrás do FW. Em vez disso, você pode colocá-lo em linha com o FW e realmente rotear o tráfego através do FW. A vantagem dessa configuração é que o serviço de proxy reverso veria o IP original do cliente de conexão:
Para essa configuração, as tabelas de rotas na Subnet-E precisam apontar Subnet-B e Subnet-C através do balanceador de carga interno. Alguns serviços de proxy reverso têm firewalls integrados que permitem remover o FW todos juntos neste fluxo de rede. Os firewalls integrados apontam do proxy reverso diretamente para os servidores Subnet-B/C.
Neste cenário, será necessário o SNAT também no proxy inverso para evitar o fluxo do tráfego de retorno e recusado pelas FWs na Sub-rede-A.
VPN/ER
O Azure fornece serviços VPN/ER ativados por BGP/altamente disponíveis através dos Gateways de Rede Virtual do Azure. A maioria dos arquitetos guarda-os para as ligações de back-end ou não direcionadas à Internet. Essa configuração significa que a tabela de roteamento também precisa acomodar as sub-redes por trás dessas conexões. Embora não haja uma grande diferença na conectividade sub-rede-B/C, há no design do tráfego de retorno, completando o quadro:
Nesta arquitetura, o tráfego que atinge a FW, por exemplo, da Sub-rede-B para a Sub-rede-X, seria enviado para o iLB que, por sua vez, o envia para qualquer uma das firewalls. A rota interna dentro da FW enviará o tráfego de volta para a Sub-rede-GW (primeiro IP disponível na Sub-rede-D). Não é necessário enviar o tráfego diretamente para o próprio dispositivo Gateway, pois outra rota na Subnet-D terá uma rota para Subnet-X apontando-a para o Virtual Network Gateway. A Rede do Azure tratará do encaminhamento real.
O tráfego de retorno proveniente da Subnet-X será encaminhado para o iLB na Subnet-D. O GatewaySubnet também terá uma rota personalizada que aponta Subnet-B-C para o iLB. A sub-rede-D não é através do iLB. Esta será tratada como um encaminhamento inter-VNET normal.
Embora não esteja no diagrama, faria sentido que a Sub-rede-B/C/D/Gateway também incluísse uma rota para a Sub-rede-A a apontá-la para o iLB. Esse arranjo evita o roteamento VNET "regular" para ignorar os FWs. A Sub-rede-A é apenas outra sub-rede na VNET de acordo com a pilha de rede do Azure. Ele não tratará a Subnet-A de forma diferente, embora você a trate como DMZ/Internet/etc.
Resumo
Em suma, a forma como trata as firewalls nas suas redes no local (físicas/baseadas em VLAN), com tantas interfaces (virtuais ou físicas) não é a mesma como faria no Azure. Se for necessário, ainda pode (até certo ponto), mas existem melhores formas de garantir que consegue minimizar o tempo de inatividade: ter implementações ativas-ativas e tabelas de rotas limpas.
Pode encontrar mais informações sobre a utilização de balanceadores de carga como gateways para todo o tráfego em Descrição geral de elevada disponibilidade.
Contribuidores
Este artigo é mantido pela Microsoft. Foi originalmente escrito pelos seguintes contribuidores.
Autor principal:
- Roelf Zomerman - Brasil | Arquiteto de Soluções Cloud Sênior
Próximos passos
Saiba mais sobre as tecnologias de componentes:
- What is Azure Load Balancer? (O que é o Balanceador de Carga do Azure?)
- O que é a Rede Virtual do Azure?
- O que é um Gateway de VPN?
Recursos relacionados
Explore arquiteturas relacionadas: