Implantar NVAs altamente disponíveis

Azure Active Directory
Firewall
Funções
Gerenciador de Tráfego
Máquinas Virtuais

Este artigo mostra várias opções para implantar um conjunto de NVAs (dispositivos de rede virtual) para alta disponibilidade no Azure. Uma NVA normalmente é usada para controlar o fluxo de tráfego de rede de uma rede de perímetro, também conhecida como DMZ, para outras redes ou sub-redes. Para saber mais sobre a implementação de uma DMZ no Azure, consulte Serviços em nuvem da Microsoft e segurança de rede. O artigo inclui as arquiteturas de exemplo apenas de entrada, apenas de saída e de entrada e saída.

Pré-requisitos: este artigo pressupõe um entendimento básico de redes do Azure, balanceadores de carga do Azure e UDRs (rotas definidas pelo usuário).

Visão geral conceitual da NVA

A figura a seguir ilustra o uso de uma única NVA para entrada e saída do tráfego de rede.

0

Nessa arquitetura, a NVA fornece um limite de rede segura marcando todo tráfego de rede de entrada e saída e passando apenas o tráfego que atende às regras de segurança de rede. No entanto, o fato de que todo o tráfego de rede deve passar pela NVA significa que ela é um ponto único de falha na rede. Se a NVA falhar, não haverá nenhum outro caminho para o tráfego de rede e todas as sub-redes de back-end ficarão indisponíveis.

Uma única NVA poderá ter maior disponibilidade se você usar Premium SSD ou Disco Ultra para todos os discos do sistema operacional e discos de dados. Para atingir metas de disponibilidade ainda maiores, implante mais de uma NVA em um Conjunto de Disponibilidade ou em vários Zonas de Disponibilidade. Para entender o contrato de nível de serviço para VMs individuais e múltiplas, consulte SLA para Máquinas Virtuais. O nível mais alto de tempo de atividade é obtido com várias VMs NVA implantadas em vários Zonas de Disponibilidade

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 Implantação
Load Balancer padrão e portas de HA Equilibra todos os fluxos TCP e UDP Confirme com provedores NVA como usar melhor as portas de HA e para saber quais cenários têm suporte
O recurso de portas de HA está disponível em todas as regiões globais do Azure
Failover rápido para instâncias íntegras com investigações de integridade por instância
Revisar limitações
Clique em Detalhes da Implantação
Entrada com NVAs na camada 7 Todos os nós de NVA estão ativos Requer uma NVA que pode encerrar conexões e usar SNAT
Requer um conjunto separado de NVAs para o tráfego proveniente da Internet e do Azure
Só pode ser usado para tráfego proveniente de fora do Azure
Implantar a arquitetura de entrada da Camada 7
Saída com NVAs na camada 7 Todos os nós de NVA estão ativos Requer uma NVA que pode encerrar conexões e implementa SNAT (conversão de endereços de rede de origem) Implantar a arquitetura de Egress Camada 7
Entrada-saída com NVAs na camada 7 Todos os nós estão ativos
Capaz de lidar com tráfego originado no Azure
Requer uma NVA que pode encerrar conexões e usar SNAT
Requer um conjunto separado de NVAs para o tráfego proveniente da Internet e do Azure
Implantar a arquitetura de entrada/Egress Camada 7
PIP-UDR sem SNAT Conjunto único de NVAs para todo o tráfego
Pode lidar com todo o tráfego (sem limite nas regras de porta)
Não exige configuração de SNAT para solicitações de entrada
Ativo-passivo
Requer um processo de failover
A lógica de investigação e failover é executada fora da rede virtual
Implantar a opção PIP-UDR com NVAs de camada 4 sem arquitetura SNAT

Load Balancer padrão e portas de HA

Você pode usar um Azure Standard Load Balancer portas de ALTA para aplicativos que exigem balanceamento de carga de um grande número de portas. Uma única regra de balanceamento de carga substitui várias regras individuais de balanceamento de carga, uma para cada porta.

HAPortsArch

Implantar a arquitetura de portas de ha

O suporte para portas de HA e opções de implantação varia de acordo com o fornecedor do parceiro NVA. Consulte a documentação Load Balancer portas de ha & Standard e a documentação específica da NVA para obter suporte, limitações e detalhes de implantação.

Entrada com NVAs na camada 7

A figura a seguir mostra uma arquitetura de alta disponibilidade que implementa uma DMZ de entrada por atrás de um balanceador de carga voltado para a Internet. Essa arquitetura é projetada para fornecer conectividade a cargas de trabalho do Azure para o tráfego da camada 7, como HTTP ou HTTPS:

1

A vantagem dessa arquitetura é que todas as NVAs estão ativas e, se uma falhar, o balanceador de carga direciona o tráfego de rede para a outra NVA. Ambas NVAs encaminham o tráfego para o balanceador de carga interno, portanto, desde que uma NVA esteja ativa, o tráfego continuará a fluir. As NVAs são necessárias para terminar o tráfego SSL destinado a VMs da camada da Web. Essas NVAs não podem ser estendidas para lidar com o tráfego local porque este requer outro conjunto dedicado de NVAs com suas próprias rotas de rede.

Implantar a arquitetura de entrada da Camada 7

Use o comando a seguir para criar um grupo de recursos para a implantação. Clique no botão Experimentar para usar um shell inserido.

az group create --name ha-nva-l7i --location eastus

Execute o comando a seguir para implantar a arquitetura de exemplo de entrada da Camada 7.

az deployment group create --resource-group ha-nva-l7i \
    --template-uri https://raw.githubusercontent.com/mspnp/samples/master/solutions/ha-nva/azuredeploy.json \
    --parameters deployIngressAppGatewayWebLoadBalancer=true deployEgressLoadBalancerNva=false

Para obter informações detalhadas e opções de implantação adicionais, consulte os modelos Azure Resource Manager ARM usados para implantar essa solução.

Saída com NVAs na camada 7

A arquitetura anterior pode ser expandida para fornecer uma DMZ de saída para solicitações originadas na carga de trabalho do Azure. A arquitetura a seguir é projetada para fornecer alta disponibilidade de NVAs na DMZ para o tráfego de camada 7, como HTTP ou HTTPS:

2

Nessa arquitetura, todo o tráfego originado no Azure é direcionado para um balanceador de carga interno por meio da configuração de proxy do sistema operacional. O balanceador de carga distribui solicitações de saída entre um conjunto de NVAs. Essas NVAs direcionam o tráfego para a Internet usando os endereços IP públicos individuais.

Implantar a arquitetura de Egress Camada 7

Use o comando a seguir para criar um grupo de recursos para a implantação. Clique no botão Experimentar para usar um shell inserido.

az group create --name ha-nva-l7e --location eastus

Execute o comando a seguir para implantar a arquitetura de exemplo Egress Camada 7.

az deployment group create --resource-group ha-nva-l7e \
    --template-uri https://raw.githubusercontent.com/mspnp/samples/master/solutions/ha-nva/azuredeploy.json \
    --parameters deployIngressAppGatewayWebLoadBalancer=false deployEgressLoadBalancerNva=true

Para obter informações detalhadas e opções de implantação adicionais, consulte os modelos Azure Resource Manager ARM usados para implantar essa solução.

Entrada/Egress com NVAs de camada 7

Nas duas arquiteturas anteriores, havia uma DMZ separada para entrada e saída. A arquitetura a seguir demonstra como criar uma DMZ que pode ser usada tanto para entrada quanto saída para o tráfego da camada 7, como HTTP ou HTTPS:

3

Nesta arquitetura, as NVAs processam solicitações de entrada do gateway de aplicativo. As NVAs também processam solicitações de saída de VMs de carga de trabalho no pool de back-end do balanceador de carga. Como o tráfego de entrada é roteado com um gateway de aplicativo e o tráfego de saída é roteado com um balanceador de carga, os NVAs são responsáveis por manter a afinidade de sessão. Ou seja, o gateway de aplicativo mantém um mapeamento de solicitações de entrada e saída para que ele possa encaminhar a resposta correta para o solicitante original. No entanto, o balanceador de carga interno não tem acesso aos mapeamentos de gateway de aplicativo e usa sua própria lógica para enviar respostas para as NVAs. É possível que o balanceador de carga possa enviar uma resposta para uma NVA que não recebeu a solicitação do gateway de aplicativo inicialmente. Nesse caso, as NVAs devem se comunicar e transferir a resposta entre elas para que a NVA correta possa encaminhar a resposta para o gateway de aplicativo.

Observação

Você também pode resolver o problema de roteamento assimétrico garantindo que as NVAs executem a SNAT (conversão de endereços de rede de origem) de entrada. Isso substituiria o IP de origem original do solicitante por um dos endereços IP da NVA usada no fluxo de entrada. Isso garante que você possa usar várias NVAs por vez, preservando ainda a simetria de rota.

Implantar a arquitetura de entrada/Egress Camada 7

Use o comando a seguir para criar um grupo de recursos para a implantação. Clique no botão Experimentar para usar um shell inserido.

az group create --name ha-nva-l7ie --location eastus

Execute o comando a seguir para implantar a arquitetura de exemplo de entrada/Egress Camada 7.

az deployment group create --resource-group ha-nva-l7ie \
    --template-uri https://raw.githubusercontent.com/mspnp/samples/master/solutions/ha-nva/azuredeploy.json

Para obter informações detalhadas e opções de implantação adicionais, consulte os modelos Azure Resource Manager ARM usados para implantar essa solução.

Opção PIP-UDR com NVAs de camada 4 sem SNAT

Essa arquitetura usa duas máquinas virtuais do Azure para hospedar o firewall de NVA em uma configuração ativo-passivo que dá suporte ao failover automático, mas não exige SNAT (Conversão de endereço de rede de origem).

5

Essa solução foi projetada para clientes do Azure que não conseguem configurar o SNAT para solicitações de entrada em seus firewalls de NVA. O SNAT oculta o endereço IP de origem do cliente original. Se você precisa registrar os IPs originais ou usá-los dentro de outros componentes de segurança em camadas por trás de seus NVAs, essa solução oferecerá uma abordagem básica.

O failover de entradas da tabela UDR é automatizado por um conjunto de endereços de próximo salto definido como o endereço IP de uma interface na máquina de virtual do firewall de NVA ativa. A lógica de failover automatizado é hospedada em um aplicativo de funções que você cria usando o Azure Functions. O código de failover é executado como uma função sem servidor dentro do Azure Functions. A implantação é conveniente, econômica e fácil de manter e personalizar. Além disso, o aplicativo de funções é hospedado dentro do Azure Functions, portanto, não tem dependências da rede virtual. Se as alterações na rede virtual afetarem os firewalls de NVA, o aplicativo de função continuará executando de forma independente. O teste também é mais preciso, pois ocorre fora da rede virtual usando a mesma rota que as solicitações de entrada do cliente.

Para verificar a disponibilidade do firewall de NVA, o código do aplicativo de função o investiga usando uma de duas maneiras:

  • Monitorando o estado das máquinas virtuais do Azure que hospedam o firewall de NVA.

  • Testando se há uma porta aberta no firewall para o servidor Web de back-end. Para essa opção, a NVA deve expor um soquete por meio de PIP para teste do código do aplicativo de função.

Escolha o tipo de investigação que você deseja usar quando ao configurar o aplicativo de funções.

Implantar a opção PIP-UDR com NVAs de camada 4 sem arquitetura SNAT

Essa implantação requer várias etapas de implantação e configuração manual. Para obter detalhes, consulte o GitHub repositório .

Próximas etapas