Partilhar via

Cenário de dispositivo virtual

  • Artigo

Um cenário comum entre os maiores clientes do Azure é a necessidade de fornecer um aplicativo de duas camadas exposto à Internet e, ao mesmo tempo, permitir o acesso à camada traseira a partir de um datacenter local. Este artigo orienta você por um cenário que usa tabelas de rotas, um gateway VPN e dispositivos virtuais de rede para implantar um ambiente de duas camadas que atenda aos seguintes requisitos:

  • Uma aplicação Web deve ser acessível apenas a partir da Internet pública.
  • Um servidor Web que hospeda o aplicativo deve ser capaz de acessar um servidor de aplicativos back-end.
  • Todo o tráfego da Internet para o aplicativo Web deve passar por um dispositivo virtual de firewall. Este dispositivo virtual é usado apenas para tráfego de Internet.
  • Todo o tráfego que vai para o servidor de aplicativos deve passar por um dispositivo virtual de firewall. Esse dispositivo virtual é usado para acesso ao servidor back-end e para acesso vindo da rede local por meio de um gateway VPN.
  • Os administradores devem ser capazes de gerenciar os dispositivos virtuais de firewall a partir de seus computadores locais usando um terceiro dispositivo virtual de firewall usado exclusivamente para fins de gerenciamento.

Este exemplo é um cenário de rede de perímetro padrão (também conhecido como DMZ) com uma DMZ e uma rede protegida. Você pode construir esse cenário no Azure usando NSGs (grupos de segurança de rede), dispositivos virtuais de firewall ou uma combinação de ambos.

A tabela a seguir mostra alguns dos prós e contras para NSGs e dispositivos virtuais de firewall.

Item Prós Contras
NSG Sem custos.
Integrado no acesso baseado em função do Azure.
Capacidade de criar regras em modelos do Azure Resource Manager.		 A complexidade pode variar em ambientes maiores.
Firewall Controle total sobre o plano de dados.
Gerenciamento central através do console de firewall.		 Custo do dispositivo de firewall.
Não integrado com o acesso baseado em função do Azure.

A solução a seguir usa dispositivos virtuais de firewall para implementar um cenário de rede de perímetro (DMZ)/rede protegida.

Considerações

Você pode implantar o ambiente anterior no Azure usando os recursos disponíveis hoje:

  • Rede virtual: uma rede virtual do Azure atua de forma semelhante a uma rede local. Você pode segmentá-lo em uma ou mais sub-redes para fornecer isolamento de tráfego e separação de preocupações.
  • Dispositivo virtual: vários parceiros fornecem dispositivos virtuais no Azure Marketplace para usar nos três firewalls descritos anteriormente.
  • Tabelas de rotas: as tabelas de rotas são usadas pela rede do Azure para controlar o fluxo de pacotes em uma rede virtual. Você pode aplicar essas tabelas de rotas a sub-redes. Você pode aplicar uma tabela de rotas ao GatewaySubnet, que encaminha todo o tráfego que entra na rede virtual do Azure de uma conexão híbrida para um dispositivo virtual.
  • Encaminhamento de IP: por padrão, o mecanismo de rede do Azure encaminha pacotes para placas de interface de rede virtual (NICs) somente se o endereço IP de destino do pacote corresponder ao endereço IP da NIC. Se uma tabela de rotas definir que um pacote deve ser enviado para um dispositivo virtual específico, o mecanismo de rede do Azure descartará esse pacote. Para garantir que o pacote seja entregue a uma VM (neste caso, um dispositivo virtual) que não seja o destino real do pacote, habilite o encaminhamento IP para o dispositivo virtual.
  • Grupos de segurança de rede: O exemplo a seguir não usa NSGs, mas você pode usar NSGs aplicados às sub-redes ou NICs nesta solução. Os NSGs filtram ainda mais o tráfego de entrada e saída dessas sub-redes e NICs.

Diagrama que mostra a conectividade IPv6.

Neste exemplo, uma assinatura contém os seguintes itens:

  • Dois grupos de recursos (não mostrados no diagrama):

    • ONPREMRG: Contém todos os recursos necessários para simular uma rede local.
    • AZURERG: Contém todos os recursos necessários para o ambiente de rede virtual do Azure.

  • Uma rede virtual chamada onpremvnet é segmentada e usada para imitar um datacenter local:

    • onpremsn1: Uma sub-rede que contém uma máquina virtual (VM) executando uma distribuição Linux para imitar um servidor local.
    • onpremsn2: Uma sub-rede que contém uma VM executando uma distribuição Linux para imitar um computador local usado por um administrador.

  • Um dispositivo virtual de firewall é nomeado OPFW em onpremvnet. É usado para manter um túnel para azurevnet.

  • Uma rede virtual nomeada azurevnet é segmentada da seguinte forma:

    • azsn1: Uma sub-rede de firewall externa usada exclusivamente para o firewall externo. Todo o tráfego da Internet entra através desta sub-rede. Esta sub-rede contém apenas uma NIC ligada à firewall externa.
    • azsn2: Uma sub-rede front-end que hospeda uma VM em execução como um servidor Web acessado pela Internet.
    • azsn3: Uma sub-rede back-end que hospeda uma VM executando um servidor de aplicativos back-end acessado pelo servidor Web front-end.
    • azsn4: Uma sub-rede de gerenciamento usada exclusivamente para fornecer acesso de gerenciamento a todos os dispositivos virtuais de firewall. Esta sub-rede contém apenas uma NIC para cada dispositivo virtual de firewall usado na solução.
    • GatewaySubnet: Uma sub-rede de conexão híbrida do Azure que é necessária para o Azure ExpressRoute e o Gateway de VPN do Azure para fornecer conectividade entre redes virtuais do Azure e outras redes.

  • Três dispositivos virtuais de firewall estão na azurevnet rede:

    • AZF1: Um firewall externo exposto à Internet pública usando um recurso de endereço IP público no Azure. Você precisa garantir que você tenha um modelo do Azure Marketplace ou diretamente do seu fornecedor de dispositivo que implanta um dispositivo virtual de três NIC.
    • AZF2: Um firewall interno usado para controlar o tráfego entre azsn2 e azsn3. Esse firewall também é um dispositivo virtual de três NICs.
    • AZF3: Um firewall de gerenciamento acessível aos administradores do datacenter local e conectado a uma sub-rede de gerenciamento usada para gerenciar todos os dispositivos de firewall. Você pode encontrar modelos de dispositivo virtual de duas NIC no Azure Marketplace. Você também pode solicitar um diretamente ao fornecedor do seu aparelho.

Tabelas de rotas

Vincule cada sub-rede no Azure a uma tabela de rotas para definir como o tráfego iniciado nessa sub-rede é roteado. Se nenhuma rota definida pelo usuário (UDRs) for definida, o Azure usará rotas padrão para permitir que o tráfego flua de uma sub-rede para outra. Para entender melhor as tabelas de rotas e o roteamento de tráfego, consulte Roteamento de tráfego de rede virtual do Azure.

Para garantir que a comunicação seja feita por meio do dispositivo de firewall adequado, com base no último requisito listado anteriormente, você deve criar a seguinte tabela de rotas em azurevnet.

Azgwudr

Nesse cenário, o único tráfego que flui do local para o Azure é usado para gerenciar os firewalls conectando-se ao AZF3, e esse tráfego deve passar pelo firewall interno, AZF2. Apenas uma rota é necessária na GatewaySubnet, como mostrado aqui:

Destino Próximo salto Explicação
10.0.4.0/24 10.0.3.11 Permite que o tráfego local alcance o firewall AZF3de gerenciamento.

azsn2udr

Destino Próximo salto Explicação
10.0.3.0/24 10.0.2.11 Permite o tráfego para a sub-rede back-end que hospeda o servidor de aplicativos através AZF2do .
0.0.0.0/0 10.0.2.10 Permite que todos os outros tráfegos sejam encaminhados através AZF1do .

azsn3udr

Destino Próximo salto Explicação
10.0.2.0/24 10.0.3.10 Permite que o azsn2 tráfego flua de um servidor de aplicativos para o servidor Web através AZF2do .

Você também precisa criar tabelas de rotas para as sub-redes para onpremvnet imitar o datacenter local.

onpremsn1udr

Destino Próximo salto Explicação
192.168.2.0/24 192.168.1.4 Permite que o tráfego passe OPFWpelo onpremsn2 .

onpremsn2udr

Destino Próximo salto Explicação
10.0.3.0/24 192.168.2.4 Permite o tráfego para a sub-rede back-end no Azure através OPFWdo .
192.168.1.0/24 192.168.2.4 Permite que o tráfego passe OPFWpelo onpremsn1 .

Reencaminhamento IP

Tabelas de rotas e encaminhamento de IP são recursos que você pode usar em combinação para permitir que dispositivos virtuais controlem o fluxo de tráfego em uma rede virtual do Azure. Um dispositivo virtual nada mais é do que uma VM que executa um aplicativo usado para lidar com o tráfego de rede de alguma forma, como um firewall ou um dispositivo de conversão de endereços de rede.

Essa VM de dispositivo virtual deve ser capaz de receber tráfego de entrada que não é endereçado a si mesmo. Para permitir que uma VM receba tráfego endereçado a outros destinos, você deve habilitar o encaminhamento de IP para a VM. Essa configuração é uma configuração do Azure, não uma configuração no sistema operacional convidado. Seu dispositivo virtual ainda precisa executar algum tipo de aplicativo para lidar com o tráfego de entrada e roteá-lo adequadamente.

Para saber mais sobre o encaminhamento de IP, consulte Roteamento de tráfego de rede virtual do Azure.

Como exemplo, imagine que você tenha a seguinte configuração em uma rede virtual do Azure:

  • A sub-rede onpremsn1 contém uma VM chamada onpremvm1.
  • A sub-rede onpremsn2 contém uma VM chamada onpremvm2.
  • Um dispositivo virtual chamado OPFW está conectado a onpremsn1 e onpremsn2.
  • Um UDR vinculado a onpremsn1 especifica que todo o tráfego a onpremsn2 ser enviado para OPFW.

Neste ponto, se onpremvm1 tentar estabelecer uma conexão com onpremvm2o , o UDR será usado e o tráfego será enviado para OPFW como o próximo salto. O destino real do pacote não está sendo alterado. Ainda diz que onpremvm2 é o destino.

Sem o encaminhamento de IP habilitado para OPFW, a lógica de rede virtual do Azure descarta os pacotes porque permite que apenas pacotes sejam enviados para uma VM se o endereço IP da VM for o destino do pacote.

Com o encaminhamento de IP, a lógica de rede virtual do Azure encaminha os pacotes para OPFWo , sem alterar seu endereço de destino original. OPFW deve manipular os pacotes e determinar o que fazer com eles.

Para que o cenário anterior funcione, você deve habilitar o encaminhamento IP nas NICs para OPFW, AZF1, AZF2e AZF3 que são usadas para roteamento (todas as NICs, exceto as vinculadas à sub-rede de gerenciamento).

Regras da firewall

Conforme descrito anteriormente, o encaminhamento de IP garante apenas que os pacotes sejam enviados para os dispositivos virtuais. Seu aparelho ainda precisa decidir o que fazer com esses pacotes. No cenário anterior, você precisa criar as seguintes regras em seus aparelhos.

OPFW

OPFW representa um dispositivo local que contém as seguintes regras:

  • Rota: Todo o tráfego para 10.0.0.0/16 (azurevnet) deve ser enviado através do túnel ONPREMAZURE.
  • Política: Permitir todo o tráfego bidirecional entre port2 e ONPREMAZURE.

AZF1

AZF1 representa um dispositivo virtual do Azure que contém a seguinte regra:

Política: Permitir todo o tráfego bidirecional entre port1 e port2.

AZF2

AZF2 representa um dispositivo virtual do Azure que contém a seguinte regra:

Política: Permitir todo o tráfego bidirecional entre port1 e port2.

AZF3

AZF3 representa um dispositivo virtual do Azure que contém a seguinte regra:

Rota: Todo o tráfego para 192.168.0.0/16 (onpremvnet) deve ser enviado para o endereço IP do gateway do Azure (ou seja, 10.0.0.1) através port1do .

Grupos de segurança de rede

Nesse cenário, os NSGs não estão sendo usados. No entanto, você pode aplicar NSGs a cada sub-rede para restringir o tráfego de entrada e saída. Por exemplo, você pode aplicar as seguintes regras NSG à sub-rede de firewall externo.

Entrada

  • Permita todo o tráfego TCP da Internet para a porta 80 em qualquer VM na sub-rede.
  • Negar todo o outro tráfego da Internet.

Saída

Negar todo o tráfego para a Internet.

Etapas de alto nível

Para implantar esse cenário, execute estas etapas:

  1. Entre na sua assinatura do Azure.

  2. Se você quiser implantar uma rede virtual para imitar a rede local, implante os recursos que fazem parte do ONPREMRG.

  3. Implante os recursos que fazem parte do AZURERG.

  4. Implante o túnel de onpremvnet até .azurevnet

  5. Depois que todos os recursos forem provisionados, entre e onpremvm2 execute ping 10.0.3.101 para testar a conectividade entre onpremsn2 e azsn3.