A nuvem está mudando a maneira como a infraestrutura é projetada, inclusive o design dos e firewalls, pois a rede não é mais física e nem está em LANs virtuais. Nem todos os recursos de uma rede física estão disponíveis em uma VNet (rede virtual). Isso inclui o uso de endereços IP flutuantes ou tráfego de difusão e influencia a implementação de arquiteturas HA. Os balanceadores de carga para NVAs (soluções de virtualização de rede) podem/devem ser implementados de uma determinada maneira para obter uma arquitetura HA (de alta disponibilidade) em uma rede virtual. Este guia apresenta uma abordagem estruturada para a criação de FWs (firewalls) de HA no Azure usando soluções de virtualização de terceiros.
Opções para a criação de NVAs de alta disponibilidade
Ao implantar arquiteturas HA, existem algumas opções para fornecer failover:
- Tabelas de rotas gerenciadas pela API do Azure: essa opção usa duas tabelas de rotas, uma ativa e uma passiva, para alternar o IP do gateway ativo para todos os serviços em execução em uma VNet/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 de espera.
- Gerenciado pelo Load Balancer: essa opção usa um Azure Load Balancer que atua como o IP de gateway para a sub-rede e que, em seguida, encaminha o tráfego para o FW ativo. Ele pode até encaminhar o tráfego ativo-ativo para fornecer balanceamento de carga real.
O problema com as duas primeiras opções é que o failover em si é lento. O FW deve instruir o failover, que é essencialmente uma "reconfiguração" dos serviços do Azure por meio de uma nova implantação. Dependendo da velocidade em que a implantação for concluída, os fluxos de tráfego ficarão inativos por vários minutos. Além disso, ele não permite uma configuração ativo-ativo, em que ambos firewalls operam ao mesmo tempo.
Por isso, a terceira opção é a mais adotada. O tempo de inatividade é minimizado, pois o balanceador de carga pode fazer failover quase instantaneamente para o firewall de espera (em ativo-passivo) ou apenas remover a carga do firewall com falha (em ativo-ativo). Mas você não pode simplesmente usar os balanceadores de carga como "gateways padrão", pois eles afetam o fluxo do tráfego e os pacotes TCP precisam estar com estado.
Firewalls de duas pernas
A imagem a seguir começa a com dois FWs (FW-1 e FW-2), com um balanceador de carga externo e um servidor back-end S1.
Essa arquitetura tem uma configuração simples, usada para o tráfego de entrada. Um pacote atinge o balanceador de carga, que escolhe o FW de destino de sua configuração. Em seguida, o firewall escolhido envia o tráfego para o servidor back-end (Web). Se o FW-1 tiver o SNAT habilitado, o servidor S1 verá o tráfego proveniente do IP interno do FW-1 e também enviará a resposta ao pacote para o FW-1. O failover pode ocorrer rapidamente ao 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 iniciar o tráfego, o mesmo princípio se aplicará. O tráfego chega ao iLB (LB interno), que escolhe um firewall que executará a conversão do NAT para resolução externa:
Firewalls de três pernas
Os problemas surgem quando adicionamos outra interface ao firewall e você precisa desabilitar a conversão do NAT entre zonas internas. Nesse caso, confira a Sub-rede B e a Sub-rede C:
O roteamento L3 entre as zonas internas (Sub-rede-B e Sub-rede-C) terá suas cargas balanceadas sem NAT. Essa configuração fica mais clara examinando os fluxos de tráfego, incluindo os balanceadores de carga, em uma exibição diferente. O diagrama abaixo mostra a exibição em que os iLBs [balanceadores de carga internos] são vinculados a um NIC específico nos FWs:
Com o tráfego de L3 (sem NAT), S2 verá o endereço IP de S1 como o endereço IP de origem. S2, então, enviará o tráfego de retorno da sub-rede B (à qual o IP de S1 pertence) ao iLB na Sub-rede C. Como o iLB na Sub-rede B e o iLB na Sub-rede C não sincronizam seus estados de sessão, dependendo do algoritmo de balanceamento de carga, o tráfego poderia terminar no FW-2. O FW-2, por padrão, não sabe nada sobre o pacote inicial (verde) e, portanto, removerá a conexão.
Alguns fornecedores de firewall tentam manter um estado de conexão entre os firewalls, mas eles precisariam ter uma sincronização quase instantânea para permanecerem atualizados com os estados de conexão. Verifique com seu fornecedor de firewall se eles recomendam essa configuração.
A melhor maneira de lidar com esse problema é eliminá-lo. No exemplo acima, essa solução significa eliminar a Sub-rede C, o que nos leva às vantagens das VNets virtualizadas.
Isolar hosts em uma sub-rede com Grupos de Segurança de Rede
Quando há duas VMs em uma única sub-rede, você pode aplicar um NSG que isole o tráfego entre os dois. Por padrão, o tráfego dentro de uma VNet é permitido completamente. Ao adicionar uma regra Negar todos no NSG, todas as VMs são isoladas umas das outras.
As VNets usam os mesmos roteadores de back-end (virtuais)
A VNet/sub-redes usam um só sistema de roteador de back-end do Azure e, portanto, não é necessário especificar um IP de roteador para cada sub-rede. O destino da rota pode ser qualquer lugar da mesma VNET ou mesmo fora dela.
Com as redes virtualizadas, você pode controlar as rotas em cada sub-rede. Essas rotas também podem apontar para um único IP em outra sub-rede. Na imagem acima, essa seria a iLB na Sub-rede-D, que equilibra a carga dos dois firewalls. Conforme S1 iniciar o tráfego (verde), ele terá a carga balanceada para, por exemplo, FW-1. O FW-1 então se conectará a S2 (ainda verde). S2 enviará o tráfego de resposta ao IP de S1 (pois a NAT está desabilitada). Devido às tabelas de rotas, S2 usa o mesmo IP de iLB que seu gateway. O iLB pode fazer a correspondência do tráfego com a sessão inicial e, portanto, sempre apontará esse tráfego de volta para FW-1. FW-1, por sua vez, o envia para S1, estabelecendo um fluxo de tráfego síncrono.
Para que essa configuração funcione, FW precisa ter uma tabela de rotas (internamente) apontando a Sub-rede B e A Sub-rede C para o GW da sub-rede padrão. Esse GW da sub-rede é o primeiro IP disponível logicamente no intervalo de sub-redes nessa VNET.
Impacto nos serviços de proxy reverso
Quando você implanta um serviço de proxy reverso, ele normalmente estaria atrás do FW. Em vez disso, você pode colocá-lo em linha com o FW e rotear o tráfego por meio do FW. A vantagem dessa configuração é que o serviço de proxy reverso veria o IP original do cliente que está se conectando:
Para essa configuração, as tabelas de rotas na Sub-rede E precisam apontar a Sub-rede B e a Sub-rede C por meio do balanceador de carga interno. Alguns serviços de proxy reverso têm firewalls internos que permitem remover completamente o FW nesse fluxo de rede. Os firewalls internos apontam do proxy reverso diretamente para os servidores da Sub-rede B/C.
Nesse cenário, o SNAT será necessário no proxy reverso também para evitar que o tráfego de retorno flua e seja negado pelos FWs para a Sub-rede-A.
VPN/ER
O Azure fornece serviços VPN/ER habilitados para BGP e altamente disponíveis por meio dos gateways da Rede Virtual do Azure. A maioria dos arquitetos os mantém para conexões de back-end ou conexões não voltadas para a 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 da conectividade da Sub-rede B/C, há sim no design do tráfego de retorno; concluindo a imagem:
Nessa arquitetura, o tráfego que está atingindo o FW de, por exemplo, Sub-rede-B para Sub-rede-X, seria enviado para o iLB, que por sua vez o enviaria para o firewall. A rota interna dentro do FW enviará o tráfego de volta para a Sub-rede-GW (primeiro IP disponível na Sub-rede-D). Você não precisa enviar o tráfego diretamente para o dispositivo de gateway em si, pois outra rota na Sub-rede-D terá uma rota para a Sub-rede- X apontando para o Gateway de Rede Virtual. A Rede do Azure cuidará do roteamento em si.
O tráfego de retorno proveniente da Sub-rede X será encaminhado para o iLB na Sub-rede D. A Sub-rede do Gateway também terá uma rota personalizada que aponta a Sub-rede B/C para o iLB. A Sub-rede D não passa pelo iLB. Isso será tratado como roteamento inter-VNET regular.
Embora não esteja no desenho, faria sentido que a Sub-rede-B/C/D/Gateway também incluísse uma rota para a Sub-rede-A, apontando-a para o iLB. Essa opção evita o roteamento de VNET "regular" para ignorar os FWs. Isso ocorre porque a Sub-rede-A é apenas outra sub-rede na VNET, de acordo com a pilha de rede do Azure. Ela não tratará a Sub-rede A de maneira diferente, embora você a trate como DMZ/Internet/etc.
Resumo
Em suma, a maneira como você trata os firewalls em redes locais (baseadas em VLAN/físicas), com tantas interfaces (virtuais ou físicas) não é a mesma como você os trataria no Azure. Se necessário, você ainda pode (até certo ponto) fazê-lo, mas há maneiras melhores de garantir que você possa minimizar o tempo de inatividade de failover; ter implementações de ativo-ativo e limpar tabelas de roteamento.
Para mais informações sobre como usar balanceadores de carga como gateways para todo o tráfego podem ser encontradas em Visão geral das portas de alta disponibilidade.
Colaboradores
Esse artigo é mantido pela Microsoft. Ele foi originalmente escrito pelos colaboradores a seguir.
Autor principal:
- Roelf Zomerman - Brasil | Arquiteto de Soluções Cloud Sênior
Próximas etapas
Saiba mais sobre as tecnologias dos componentes:
Recursos relacionados
Explorar arquiteturas relacionadas:
- Implementar uma rede híbrida segura
- Conexão híbrida
- Ampliar uma rede local usando uma VPN
- Escolha entre o emparelhamento de rede virtual e gateways de VPN
- Solucionar problemas de uma conexão VPN híbrida
- Topologia de rede hub-spoke no Azure
- Conectar servidores autônomos usando o Adaptador de Rede do Azure