Virtual Network

Una VNet (Virtual Network) en Azure es una red virtual que permite la comunicación entre recursos, como máquinas virtuales (VMs), dentro de Azure. Es la versión de Azure de una red local en una infraestructura de nube. Si un recurso necesita una IP local entonces probablemente estará en una VNet.

• Aislamiento y Segmentación: La VNet es aislada de las otras redes en Azure, permitiendo que segmentes tu red y definas subredes para separar diferentes partes de tu aplicación. Podemos crear diferentes VNets para separar desarrollo y producción por ejemplo, inclusive pueden tener el mismo bloque para el CIDR pues son ambientes completamente aislados. Si es preciso comunicar las dos redes es bueno que ellas tengan CIDR diferentes.

• Conectividad: Puedes conectar VNets a otras redes, como redes locales vía VPN, o a otras VNets en Azure, permitiendo una comunicación segura y escalable.

• Control de Tráfico: Con VNets, puedes usar Network Security Groups (NSGs) para controlar el tráfico de entrada y salida, aplicando reglas de firewall.

• Servicios Integrados: Las VNets permiten la integración con servicios de Azure, como Azure Load Balancer, VPN Gateway, y Application Gateway, para crear arquitecturas de red complejas y seguras.

• DNS: Azure proporciona resolución de nombres internos para instancias VMs y Cloud Services conectadas a una VNet. Tenemos la opción de configurar una VNet para usar nuestros propios servidores DNS en lugar de usar la resolución de nombres internos de Azure. Es muy usado cuando vamos a conectar un ambiente on-premise con los servicios que tenemos en la cloud.

• Internet: Toda VNet ya posee acceso sin ninguna configuración extra.

• VNet-To-VNet: Es posible comunicar dos VNets con este recurso incluso en regiones diferentes. Para facilitar recomiendo que cada VNet tenga su propio bloque de IPs para evitar conflictos. Aun así es posible hacer la comunicación incluso que tenga el mismo bloque de IPs, pero será necesario utilizar otras estrategias para traducción de IP como NAT y Peering.

Subnet

Podemos segmentar una VNet en múltiples subredes y aplicar dentro de cada una control de tráfico diferente.

Es muy común dividir una VNet en 3 subnets:

Subnet Pública:

• Colocamos servicios que aceptan requisiciones externas, como bastion host por ejemplo.
• Aplicamos reglas de firewall que permiten comunicación en los puertos específicos que usamos
• Generalmente usamos una franja de IP menor

Subnet Privada:

• Colocamos nuestros servicios, vms, clusters, etc
• Aplicamos reglas que solamente acepta comunicación provenientes de la subnet pública
• Mayor franja de IP para escalabilidad.

Subnet Data:

• Muy usada para base de datos y servicios internos
• Solamente acepta comunicación con la subnet privada.
• Franja de IP restringida

Podemos dividir las subnets en zonas de disponibilidad. Si separamos una franja de IP para una subnet, podemos en lugar de crear una, crear 2, mitad de la franja de IP creamos una subnet pública A en la zona A y una subnet pública B en la zona B. Muy usado cuando vamos a crear recursos con alta disponibilidad para crear redundancia.

Un ejemplo clásico es tener 2 subnets privadas para recibir los hosts de Kubernetes. Caso una zona pare solamente parte de los nodes caerán.

Si colocamos un recurso en una subnet A y otro en una subnet B y la subnet A y B están en la misma VNet, la comunicación es garantizada no necesitando hacer ninguna regla de enrutamiento. Lo que hacemos es controlar la comunicación a través de reglas que llamamos security groups.

VPN

En casos más avanzados como por ejemplo conectar la red on-premise en una VNet podemos cerrar una VPN en los bordes con el Site-to-Site VPN que utiliza SSL e IPSec. Aplicamos la configuración en el router de la empresa y en la VPN y la comunicación queda directa sin necesitar de cliente.

Caso necesite una conexión directa vía fibra de tu datacenter con la cloud de Azure es posible contratar el Express Route, nunca usé pero sé que existe.

Network Security Group (NSG) - Filtrado de Tráfico

Las VMs y cloud services pueden contener reglas de filtrado de tráfico (NSG) tanto de entrada como de salida, por dirección IP, bloque de IP, puerto de origen y puerto de destino.

Esas reglas funcionan como un firewall embebido.

Enrutamiento

El enrutamiento ya es preconfigurado, pero es posible sustituir el enrutamiento por sus propias rutas o usando rutas BGP a través de un gateway de red.

---

Vamos a crear una vnet con dos subnets una pública y una privada.

El servicio que vamos a buscar es Virtual Networks y como siempre necesitamos siempre definir el grupo de recursos.

En la pestaña IP Address podemos definir subnets. Vamos a eliminar el default y crear dos.

La primera será una subnet pública con 24 IPs. Observe que en la creación fue pedido la creación de un NAT Gateway para que la subnet tenga acceso a Internet.

Vamos a entender una cosa. Si un recurso, una VM por ejemplo tuviera una IP pública no es necesario un NAT Gateway, por ejemplo un load balancer, un bastion host con IP pública, etc. Entonces vamos a usar esa subnet pública para ese tipo de recurso, luego no vamos a crear un NAT Gateway ahora.

Podríamos incluso crear ahora mismo un NSG para reglas de firewall.

Vamos a crear la subnet privada y un gateway, pues ningún recurso tendrá IP pública, pero necesitará salir a Internet. Durante la creación del NAT es necesaria una IP pública. Cree también un security group para aplicarmos reglas después.

Recuerde siempre usar tags para facilitar el filtrado.

Al final tenemos aquel JSON para usar como template caso necesario, no voy a colocar aquí porque es muy grande. Solo hay que crear.

Y vamos a verificar lo que tenemos en nuestro resource group.

Obs: No es posible editar el nombre de una subnet. Es necesario destruir y recrear, entonces mucha atención.

Ahora que creamos vía portal y sabemos que podemos crear vía línea de comandos también vamos a ser honestos... A esta altura del campeonato nadie va a quedarse guardando comando de cli para crear recursos.

Cuando vamos a trabajar con cloud lo ideal es usar Infra as Code. Vamos a usar el portal solo para verificar y obtener datos, verificar, analizar, pero para crear vamos a tener un proyecto decente.

Vaya al portal y elimine completamente el resource group para ver si todos los recursos serán eliminados.

Una cosa importante es que una subnet abarca todas las zonas de disponibilidad de la misma región, no siendo necesario crear una subnet para cada AZ como es hecho en AWS. Para tener alta disponibilidad basta crear recursos en la misma subnet, pero en diferentes AZs.