Virtual Network

Uma VNet (Virtual Network) na Azure é uma rede virtual que permite a comunicação entre recursos, como máquinas virtuais (VMs), dentro do Azure. É a versão da Azure de uma rede local em uma infraestrutura de nuvem. Se um recurso precisa de um IP local então provavelmente ele estará em uma VNet.

• Isolamento e Segmentação: A VNet é isolada das outras redes na Azure, permitindo que você segmente sua rede e defina sub-redes para separar diferentes partes da sua aplicação. Podemos criar diferentes VNets para separar desenvolvimento e produção por exemplo, inclusive podem ter o mesmo bloco para o CIDR pois são ambientes completamente isolados. Se for preciso comunicar as duas redes é bom que elas tenham CIDR diferentes.

• Conectividade: Você pode conectar VNets a outras redes, como redes locais via VPN, ou a outras VNets na Azure, permitindo uma comunicação segura e escalável.

• Controle de Tráfego: Com VNets, você pode usar Network Security Groups (NSGs) para controlar o tráfego de entrada e saída, aplicando regras de firewall.

• Serviços Integrados: As VNets permitem a integração com serviços da Azure, como Azure Load Balancer, VPN Gateway, e Application Gateway, para criar arquiteturas de rede complexas e seguras.

• DNS: Azure fornece resolução de nomes internos para instâncias VMs e Cloud Services conectadas a uma VNet. Temos a opção de configurar uma VNet para usar nossos próprios servidores DNS em vez de usar a resolução de nomes internos da Azure. É muito usado quando vamos conectar um ambiente on-premise com os serviços que temos na cloud.

• Internet: Toda VNet já possui acesso sem nenhuma configuração extra.

• VNet-To-VNet: É possível comunicar duas VNets com esse recurso mesmo em regiões diferentes. Para facilitar recomendo é bom que cada VNet tenha seu próprio bloco de IPs para evitar conflitos. Ainda sim é possível fazer a comunicação mesmo que tenha o mesmo bloco de IPs, mas será necessário utilizar outras estratégias para tradução de IP como NAT e Peering.

Subnet

Podemos segmentar uma VNet em múltiplas sub-redes e aplicar dentro de cada uma controle de tráfego diferente.

É muito comum dividir uma VNet em 3 subnets:

Subnet Pública:

• Colocamos serviços que aceitam requisições externas, como bastion host por exemplo.
• Aplicamos regras de firewall que permitem comunicação nas portas específicas que usamos
• Geralmente usamos uma faixa de IP menor

Subnet Privada:

• Colocamos nosso serviços, vms, clusters, etc
• Aplicamos regras que somente aceita comunicação vindas da subnet pública
• Maior faixa de IP para escalabilidade.

Subnet Data:

• Muito usada para banco de dados e serviços internos
• Somente aceita comunicação com a subnet privada.
• Faixa de IP restrita

Podemos dividir as subnets em zonas de disponibilidade. Se separamos uma faixa de IP para uma subnet, podemos ao invés de criar uma, criar 2, metade da faixa de IP criamos uma subnet publica A na zona A e uma subnet pública B na zona B. Muito usado quando vamos criar recursos com alta disponibilidade para criar redundância.

Um exemplo clássico é ter 2 subnets privadas para receber os hosts do Kubernetes. Caso uma zona pare somente parte dos nodes irão cair.

Se colocamos um recurso em uma subnet A e outro em uma subnet B e a subnet A e B estão na mesma VNet, a comunicação é garantida não precisando fazer nenhuma regra de roteamento. O que fazemos é controlar a comunicação através de regras que chamamos de security groups.

VPN

Em casos mais avançados como por exemplo conectar a rede on-premise em uma VNet podemos fechar uma VPN nas bordas com o Site-to-Site VPN que utiliza SSL e IPSec. Aplicamos a configuração no roteador da empresa e na VPN e a comunicação fica direta sem precisar de cliente.

Caso precise de uma conexão direta via fibra do seu datacenter com a cloud da Azure é possível contratar o Express Route, nunca usei mas sei que existe.

Network Security Group (NSG) - Filtragem de Tráfego

As VMs e cloud services podem conter regras de filtragem de tráfego (NSG) tanto de entrada quanto de saída, por endereço IP, bloco de IP, porta de origem e porta de destino.

Essas regras funcionam como um firewall embutido.

Roteamento

O roteamento já é pré-configurado, mas é possível substituir o roteamento por suas próprias rotas ou usando rotas BGP através de um gateway de rede.

---

Vamos criar uma vnet com duas subnets uma pública e uma privada.

O serviço que vamos buscar é Virtual Networks e como sempre precisamos sempre definir o grupo de recursos.

Na aba IP Address podemos definir subnets. Vamos deletar o default e criar duas.

A primeira será uma subnet pública com 24 IPs. Observe que na criação foi pedido a criação de um NAT Gateway para que a subnet tenha acesso à Internet.

Vamos entender uma coisa. Se um recurso, uma VM por exemplo tiver um IP público não é necessário um NAT Gateway, por exemplo um load balancer, um bastion host com IP público, etc. Então vamos usar essa subnet pública para esse tipo de recurso, logo não vamos criar um NAT Gateway agora.

Poderíamos até criar agora mesmo um NSG para regras de firewall.

Vamos criar a subnet privada e um gateway, pois nenhum recurso terá IP público, mas precisará sair para Internet. Durante a criação do NAT é necessário um IP público. Crie também um security group para aplicarmos regras depois.

Lembre sempre de usar tags para facilitar a filtragem.

No final temos aquele JSON para usar como template caso necessário, não vou colocar aqui porque é muito grande. É só criar.

E vamos conferir o que temos no nosso resource group.

Obs: Não é possível editar o nome de uma subnet. É necessário destruir e recriar, então muita atenção.

Agora que criamos via portal e sabemos que podemos criar via linha de comando também vamos ser honestos... Nessa altura do campeonato ninguém vai ficar guardando comando de cli para criar recursos.

Quando vamos trabalhar com cloud o ideal é usar Infra as Code. Vamos usar o portal só para conferir e pegar dados, conferir, analisar, mas para criar vamos ter um projeto decente.

Vá no portal e delete completamente o resource group para ver se todos os recursos serão deletados.

Uma coisa importante é que uma subnet abrange todas as zonas de disponibilidade da mesma região, não sendo necessário criar uma subnet para cada AZ como é feito na AWS. Para ter alta disponibilidade basta criar recursos na mesma subnet, mas em diferentes AZs.