Redes virtuales y subredes

Una red virtual de Azure (VNet) es una red lógicamente aislada en la nube de Azure que usted define y controla. Es el componente fundamental de las redes de Azure y permite que recursos de Azure, como máquinas virtuales, bases de datos y servicios de aplicaciones, se comuniquen de forma segura entre sí, con Internet y con redes locales. Una VNet está limitada a una única región de Azure y a un espacio de direcciones CIDR IPv4 específico (y, opcionalmente, IPv6) que usted define al crearla.

Al crear una VNet, se asigna un espacio de direcciones mediante la notación CIDR. La notación CIDR (Classless Inter-Domain Routing) especifica tanto la dirección de red como el número de bits utilizados para el prefijo de red. Por ejemplo, 10.0.0.0/16 proporciona 65.536 direcciones IP (desde 10.0.0.0 hasta 10.0.255.255). El espacio de direcciones debe ser un intervalo de IP privadas (10.0.0.0/8, 172.16.0.0/12 o 192.168.0.0/16, según RFC 1918). Elija un espacio de direcciones lo suficientemente grande para dar cabida a todas las subredes previstas y permitir su crecimiento, pero evite que se solape con las redes locales si planea establecer una conexión híbrida.

Una subred divide el espacio de direcciones de la VNet en segmentos de red más pequeños. Cada subred tiene su propio intervalo de IP (un subconjunto del espacio de direcciones de la VNet) y puede contener recursos de distintos tipos. Las subredes cumplen dos objetivos: organización (agrupar recursos relacionados) y aislamiento (aplicar reglas de seguridad diferentes a distintos grupos de recursos). Por ejemplo, puede tener una subred de web-tier (10.0.1.0/24) para servidores web, una subred de app-tier (10.0.2.0/24) para servidores de aplicaciones y una subred de data-tier (10.0.3.0/24) para bases de datos.

Dentro de cada subred, Azure reserva las primeras cuatro direcciones IP y la última para su propio uso. En una subred 10.0.1.0/24: 10.0.1.0 (dirección de red), 10.0.1.1 (puerta de enlace predeterminada), 10.0.1.2 y 10.0.1.3 (reservadas para Azure DNS) y 10.0.1.255 (dirección de difusión). Esto deja 251 IP utilizables en una subred /24. Tenga en cuenta esta reserva al dimensionar las subredes: una subred /28 solo tiene 11 direcciones utilizables (16 menos 5 reservadas).

De forma predeterminada, los recursos dentro de la misma VNet pueden comunicarse entre sí mediante sus direcciones IP privadas, aunque estén en subredes diferentes. No se necesita ninguna configuración adicional para la comunicación dentro de una VNet. Los recursos de VNet diferentes no pueden comunicarse de forma predeterminada; debe conectarlos explícitamente mediante el emparejamiento de VNet. Los recursos de la misma subred comparten el mismo segmento de red, por lo que la comunicación entre ellos sigue la ruta más directa posible dentro de la capa de red definida por software de Azure.

Las máquinas virtuales de una VNet pueden iniciar conexiones salientes a Internet de forma predeterminada; Azure proporciona automáticamente acceso saliente a Internet mediante un servicio NAT administrado. Para el acceso entrante desde Internet, un recurso necesita una dirección IP pública asignada a su interfaz de red o a un equilibrador de carga. A continuación, puede controlar el acceso entrante mediante reglas de Network Security Group (NSG) para especificar exactamente qué puertos y protocolos están permitidos. Una arquitectura habitual sitúa los servidores web en una subred pública con IP públicas y los servidores de aplicaciones en una subred privada accesible únicamente desde la capa web.

De forma predeterminada, Azure gestiona el enrutamiento automáticamente: el tráfico entre subredes permanece dentro de la VNet, el tráfico saliente a Internet se somete a NAT y el tráfico hacia los servicios de Azure utiliza la red troncal de Azure. Puede reemplazar este comportamiento mediante rutas definidas por el usuario (UDR) en una tabla de rutas. Un uso habitual consiste en forzar que todo el tráfico saliente a Internet pase por un Network Virtual Appliance (NVA) o Azure Firewall en una VNet de concentrador para realizar una inspección centralizada. Para aplicarla, debe crear una tabla de rutas, agregar entradas de ruta y asociarla a una o varias subredes.

Algunos servicios de Azure —como Azure App Service (VNet Integration), Azure Kubernetes Service, Azure SQL Managed Instance y Azure Databricks— requieren una subred dedicada delegada a ese servicio. Una subred delegada permite que Azure inserte recursos específicos del servicio (interfaces de red, direcciones IP internas) en esa subred en su nombre. No puede implementar otros tipos de recursos en una subred delegada, ya que está reservada exclusivamente para ese servicio de Azure. Cuando planifique usar servicios que requieren delegación, asigne siempre una subred dedicada con suficiente espacio de direcciones IP.

Procedimientos recomendados clave para diseñar una VNet: Planifique el espacio de direcciones antes de crear la VNet; no podrá cambiarlo sin volver a crear los recursos. Use subredes independientes para cada nivel de la aplicación, con el fin de aplicar políticas de seguridad distintas. Evite superponer los espacios de direcciones con las redes locales si planea conectarse mediante VPN o ExpressRoute. Reserve subredes más grandes para los servicios que necesiten escalar (por ejemplo, los grupos de nodos de AKS). Asigne nombres claros a los recursos (por ejemplo, vnet-prod-eastus-001) para facilitar la administración a gran escala. Una VNet bien diseñada es mucho más fácil de proteger y solucionar que una creada de forma improvisada.

Las VNets de Azure pueden conectarse a redes locales mediante dos mecanismos: VPN Gateway: un túnel IPsec/IKE cifrado a través de la Internet pública, rentable para necesidades de ancho de banda moderadas. Azure ExpressRoute: una conexión privada y dedicada de fibra a través de un proveedor de red asociado, que ofrece mayor ancho de banda, menor latencia y un rendimiento más predecible que una VPN. Para cargas de trabajo confidenciales o escenarios que requieren un ancho de banda garantizado, ExpressRoute es la opción preferida, aunque implica un coste considerablemente mayor y plazos de aprovisionamiento más largos.

El dimensionamiento del espacio de direcciones de una VNet requiere planificar las necesidades actuales y futuras. Un patrón empresarial habitual es el siguiente: Espacio de direcciones de la VNet: /16 (65.536 direcciones). Subredes: /24 por nivel de carga de trabajo (251 direcciones utilizables cada una). Una VNet /16 puede contener 256 subredes /24, más que suficiente para la mayoría de los entornos. Para entornos muy grandes, use una /8 o solicite varios rangos que no se superpongan. Deje siempre margen para el crecimiento: asignar hoy una /24 cuando podría necesitar una /22 el próximo año provocará posteriormente una compleja tarea de reasignación de direcciones.

Compruebe sus conocimientos sobre los conceptos de Microsoft Azure Fundamentals (AZ-900) tratados en esta lección.

En esta lección ha aprendido que una VNet de Azure es una red aislada lógicamente, con un espacio de direcciones CIDR definido y limitada a una sola región; que las subredes dividen la VNet en segmentos para organizarla y aislar las políticas de seguridad; y que Azure reserva 5 direcciones IP por subred, y los recursos de la misma VNet se comunican de forma privada de manera predeterminada, sin configuración adicional. A continuación, exploraremos los grupos de seguridad de red y los grupos de seguridad de aplicaciones para filtrar el tráfico.