La lección anterior terminó con una constatación incómoda: todo lo que ha desplegado Contoso Airlines hasta ahora —las VM del motor heredado, el conjunto de escalado de la API, las aplicaciones de App Service y la cuenta de almacenamiento de tarjetas— se comunica por internet. Funciona, pero ninguna arquitectura seria se queda así. Y arreglarlo después es mucho más caro que hacerlo bien desde el principio, porque el espacio de direcciones de una red virtual condiciona todo lo que se conecte a ella durante años.

Por eso toda arquitectura seria empieza por la red. Cambiar el tamaño de una VM cuesta dos minutos; cambiar el rango de direcciones de una red virtual con cien recursos dentro y una VPN contra dos oficinas es un proyecto con corte de servicio.

En esta lección diseñarás y desplegarás la red completa de Contoso: el espacio de direcciones de vnet-contoso-pro con la aritmética CIDR explicada desde cero, sus cuatro subredes, los grupos de seguridad de red que abren solo lo imprescindible, la resolución DNS privada, el emparejamiento entre redes con el patrón hub-and-spoke, la diferencia decisiva entre puntos de conexión de servicio y Azure Private Link, cómo se conecta App Service a la red y por qué nadie debería exponer SSH a internet teniendo Azure Bastion.

Aviso de coste: las redes virtuales, las subredes y los NSG no cuestan nada. Sí cuestan los puntos de conexión privados (por hora y por datos procesados), las IP públicas estáticas y, sobre todo, Azure Bastion, que se factura por hora desde el momento en que existe. Al final tienes la limpieza.

1. Por qué la red va primero
2. Redes virtuales y espacio de direcciones
3. Aritmética CIDR sin dolor
4. Diseño de subredes de vnet-contoso-pro
5. Direcciones reservadas por Azure en cada subred
6. Grupos de seguridad de red (NSG)
7. Etiquetas de servicio y grupos de seguridad de aplicación
8. IP públicas y privadas, estáticas y dinámicas
9. DNS en Azure y zonas DNS privadas
10. Emparejamiento de redes virtuales y hub-and-spoke
11. Puntos de conexión de servicio frente a Azure Private Link
12. Integración de App Service con la red virtual
13. Azure Bastion frente a exponer SSH y RDP
14. Verificación con Network Watcher
15. Topología completa y limpieza
16. Errores Comunes y Consejos
17. Ejercicios
18. Conclusión

Una red virtual (VNet) es tu red privada dentro de Azure: un espacio de direcciones IP aislado y controlado por ti, en el que colocas recursos que se ven entre sí y por el que decides qué entra y qué sale.

Lo que la red determina, y por eso va primero:

Y un aviso sobre lo que no puedes hacer: dos redes con espacios de direcciones solapados no se pueden emparejar ni unir por VPN. Si eliges 10.0.0.0/16 porque es el ejemplo de todos los tutoriales, y tu oficina de Barcelona usa 10.0.0.0/16, has creado un problema que solo se arregla renumerando una de las dos.

Una VNet tiene uno o varios espacios de direcciones en notación CIDR, tomados de los rangos privados de la RFC 1918:

Plan de direccionamiento de Contoso Airlines, decidido por Marta Ríos con la vista puesta en la VPN con las oficinas (lección 02-06):

Observa la disciplina: bloques /16 separados y nada solapado, con hueco reservado entre ellos para crecer. Esto no cuesta nada ahora y evita una migración dolorosa dentro de tres años.

Recuerda por qué la red vive en rg-contoso-red-pro y no junto a las aplicaciones: el criterio de agrupación de la lección 01-05 era ciclo de vida + entorno, y la red sobrevive a muchas generaciones de aplicaciones.

Si CIDR ya te resulta natural, salta al apartado siguiente. Si no, este es el mínimo imprescindible y basta con entender tres ideas.

Idea 1: el número tras la barra son los bits fijos. Una dirección IPv4 tiene 32 bits. En 10.20.1.0/24, los 24 primeros bits son la red (fijos) y los 8 restantes identifican al equipo (variables).

Idea 2: cuantos más bits fijos, más pequeña es la red. Un /24 es más pequeño que un /16. La cuenta es directa: 2^(32 - prefijo) direcciones.

Idea 3: para trocear, se avanza de bloque en bloque. Un /24 cubre 256 direcciones, así que dentro de 10.20.0.0/16 las subredes /24 van saltando de uno en uno en el tercer octeto:

Y si una subred necesita menos, se trocea con prefijos mayores. Dentro de 10.20.250.0/24:

Regla mental que resuelve el 90 % de los casos del día a día: /24 es "un bloque de 256 con el mismo tercer octeto". Planifica con /24 salvo que sepas que necesitas otra cosa, y deja huecos entre subredes para crecer.

Una subred es una porción del espacio de direcciones de la red virtual donde se colocan realmente los recursos. Se segmenta por función, porque la segmentación es lo que permite aplicar reglas distintas a cada capa.

Nombres reservados que hay que respetar al pie de la letra, porque Azure los busca literalmente:

Y una restricción con consecuencias: una subred se puede ampliar, pero no si hay recursos que lo impidan, y no se puede reducir con recursos dentro. Dimensiona con margen.

En una subred /24 no dispones de 256 direcciones ni de 254, sino de 251. Azure reserva cinco en cada subred:

Por tanto, la primera dirección asignable de snet-web es 10.20.1.4. Esto importa cuando dimensionas al límite: una subred /29 tiene 8 direcciones y solo 3 utilizables. Si has planificado «ocho servidores en un /29», no caben.

Un grupo de seguridad de red es una lista de reglas de filtrado con estado que se aplica a una subred o a una NIC. Con estado significa que si permites una conexión de entrada, la respuesta de salida se permite automáticamente; no hay que escribir la regla inversa.

Cada regla tiene:

Todo NSG trae reglas invisibles que no se pueden borrar, solo sobrescribir con prioridades más bajas:

Dos consecuencias que hay que interiorizar:

1. Por defecto, todo el tráfico dentro de la VNet está permitido, aunque sean subredes distintas. La segmentación no es automática: hay que escribirla.
2. Por defecto, todo puede salir a internet. Si quieres impedirlo, hay que denegarlo explícitamente.

La regla denegar-resto-vnet con prioridad 4000 es la pieza clave de la segmentación: se evalúa antes que la regla por defecto 65000 que permitía todo el tráfico interno, pero después que la regla 100 que autoriza a la capa web. El resultado es exactamente lo buscado: snet-app solo escucha a snet-web.

Comprobación de las reglas efectivas, incluidas las invisibles:

Escribir rangos de IP a mano envejece mal: las IP de los servicios de Azure cambian y las de tus máquinas también. Azure ofrece dos abstracciones para no depender de ellas.

Una etiqueta de servicio representa un conjunto de prefijos de IP que Microsoft mantiene actualizado por ti.

Un ASG es una etiqueta lógica que agrupa NIC. En lugar de escribir reglas por rango de IP, escribes reglas entre grupos: «lo que esté en asg-web puede hablar con lo que esté en asg-api». Cuando añades una máquina al grupo, hereda las reglas sin tocar el NSG.

Es la forma de mantener reglas legibles cuando la red crece: se leen como frases del negocio, no como listas de octetos.

Sobre las SKU de IP pública: Standard es la actual (estática siempre, cerrada por defecto —necesita un NSG que permita el tráfico explícitamente— y compatible con zonas). La SKU Basic está retirada. Usa siempre Standard.

Un matiz de salida a internet que confunde a mucha gente: una VM sin IP pública puede seguir saliendo a internet mediante el acceso saliente predeterminado de Azure, con una IP que no controlas y que Microsoft está retirando para las redes nuevas. Para una salida predecible y auditable se usa un NAT Gateway, que da a toda la subred una IP de salida fija y evita el agotamiento de puertos SNAT.

Dentro de una VNet, Azure ofrece resolución DNS automática: las máquinas de la misma red se resuelven por su nombre de host sin que configures nada, a través del servidor virtual 168.63.129.16 (una dirección que aparece en todos los diagnósticos de Azure y conviene reconocer).

Esa resolución automática tiene límites: no funciona entre redes emparejadas ni resuelve nombres de servicios privados. Para eso están las zonas DNS privadas.

Ahora cualquier recurso de la red resuelve motor.interno.contosoairlines.example a 10.20.4.10. Con --registration-enabled true, además, las VM se registran solas al crearse.

Las zonas privadas son imprescindibles para Private Link: son el mecanismo por el que sql-contoso-reservas-pro.database.windows.net deja de resolver a una IP pública y pasa a resolver a una IP de tu subred. Lo vemos ahora.

El DNS público (registrar contosoairlines.example y publicar sus registros al mundo) es Azure DNS, y se trata en la lección 02-06.

El emparejamiento (peering) conecta dos redes virtuales para que se vean como si fueran una sola: tráfico privado por la red troncal de Microsoft, baja latencia, sin puertas de enlace ni internet de por medio.

Características que hay que conocer:

• Funciona dentro de una región y entre regiones (emparejamiento global).
• No es transitivo: si A empareja con B y B con C, A no ve a C. Este es el punto que más sorprende y el que da forma a la topología hub-and-spoke.
• Los espacios de direcciones no pueden solaparse.
• Se factura por datos transferidos en ambas direcciones.
• Hay que crearlo en los dos sentidos: dos comandos, uno por red.

Las dos opciones importantes: --allow-gateway-transit en el concentrador significa «puedes usar mi puerta de enlace VPN», y --use-remote-gateways en el radio significa «la usaré». Gracias a esa pareja, una sola puerta de enlace VPN en el concentrador da conectividad a todos los radios, en lugar de pagar una por red. Es el argumento económico principal del patrón.

Como el emparejamiento no es transitivo, producción y desarrollo no se ven entre sí aunque ambos vean el concentrador. Eso no es una limitación: es exactamente la propiedad de aislamiento que queremos, y sale gratis.

Aquí está la decisión más importante de la lección, y la que resuelve el problema con el que abríamos: la base de datos y la cuenta de almacenamiento de Contoso son accesibles desde internet.

La diferencia práctica que decide: con un punto de conexión de servicio, alguien con la clave de la cuenta de almacenamiento puede seguir accediendo desde cualquier sitio autorizado por el cortafuegos; y las oficinas conectadas por VPN no pueden usarlo. Con un punto de conexión privado, el recurso tiene una IP dentro de tu red, se puede cerrar por completo al mundo y las oficinas llegan por la VPN.

Contoso elige puntos de conexión privados para la base de datos sql-contoso-reservas-pro y para la cuenta sttarjetascontosopro. El coste añadido es pequeño frente a exponer los datos de los pasajeros.

El paso 3 es el que más gente olvida y el que provoca el fallo clásico: creas el punto de conexión privado, cierras el acceso público y la aplicación deja de funcionar, porque sigue resolviendo el nombre a la IP pública que ya está cerrada. Sin la zona DNS privada vinculada, Private Link no sirve de nada.

Comprobación desde una VM de la red:

Las zonas privadas de los servicios que Contoso usará: privatelink.blob.core.windows.net (Storage), privatelink.database.windows.net (SQL, módulo 3), privatelink.vaultcore.azure.net (Key Vault, 04-03) y privatelink.azurewebsites.net (App Service).

Con App Service hay que distinguir dos direcciones, y confundirlas es fuente de horas perdidas.

Detalles prácticos: la integración de salida requiere nivel Basic o superior, la subred delegada es de uso exclusivo de ese plan, y por defecto solo se enruta hacia direcciones privadas (para forzar todo el tráfico de salida por la red se activa WEBSITE_VNET_ROUTE_ALL=1, que es lo que Contoso hace en producción para que la salida sea auditable).

En la lección 02-01 abrimos el puerto 22 a internet con --nsg-rule SSH y avisamos de que era temporal. Ha llegado el momento de hacerlo bien.

Aviso de coste importante: Bastion se factura por hora mientras exista, más el tráfico de salida. En un laboratorio, créalo, úsalo y bórralo el mismo día. En producción, su coste se compara favorablemente con el de gestionar IP públicas y sobrevivir a un incidente por SSH expuesto.

Alternativa más barata para administración puntual: az ssh vm con Microsoft Entra ID y la extensión correspondiente, o un simple túnel a través de una VPN de punto a sitio, que es justamente lo que Marta Ríos usará desde casa (lección 02-06).

Cuando algo no conecta, adivinar es caro. Network Watcher te dice exactamente qué regla está bloqueando qué.

test-ip-flow es la herramienta que hay que usar antes de tocar ninguna regla: te dice el nombre de la regla que decide, con lo que dejas de cambiar cosas al azar. Y los registros de flujo de NSG, que envían a Log Analytics todo lo permitido y denegado, son la base del análisis que verás en la lección 07-02.

Limpieza de lo que factura:

Comprobación de gasto residual: az network public-ip list --query "[?ipConfiguration==null]" -o table y az network private-endpoint list -o table.

• Usar 10.0.0.0/16 porque es el ejemplo del tutorial. Es el rango que usa media internet corporativa; el día que montes la VPN con la oficina, se solapará. Planifica el direccionamiento antes de crear nada.
• Dimensionar las subredes al límite. Azure reserva 5 direcciones por subred y ampliar con recursos dentro es problemático. Deja margen.
• Olvidar los nombres obligatorios. GatewaySubnet y AzureBastionSubnet se escriben exactamente así; con cualquier otro nombre, el servicio no se despliega.
• Suponer que las subredes están aisladas por defecto. La regla AllowVnetInBound permite todo el tráfico interno. La segmentación hay que escribirla.
• Confundir el orden de prioridades. Se evalúa de menor a mayor y la primera coincidencia gana. Una regla Deny con prioridad 100 anula un Allow con prioridad 200.
• Escribir rangos de IP donde cabe una etiqueta de servicio. Las IP de los servicios de Azure cambian; las etiquetas se actualizan solas.
• Esperar que el emparejamiento sea transitivo. No lo es. En hub-and-spoke, los radios no se ven entre sí (y normalmente eso es lo que quieres).
• Crear el emparejamiento en un solo sentido. Queda en estado Initiated y no funciona hasta que existe el enlace inverso.
• Crear un punto de conexión privado sin su zona DNS privada. El nombre sigue resolviendo a la IP pública y, al cerrar el acceso público, la aplicación deja de funcionar. Es el fallo número uno de Private Link.
• Dejar Azure Bastion encendido en un laboratorio. Se factura por hora aunque no lo uses.
• Depurar conectividad a base de probar reglas. az network watcher test-ip-flow te da la regla culpable en un comando.
• Consejo: documenta el plan de direccionamiento en un fichero del repositorio junto a los scripts. La red es la parte de la arquitectura que más gente necesita consultar y menos gente recuerda.
• Consejo: aplica los NSG a subredes, no a NIC individuales, salvo excepciones justificadas. Las reglas por NIC se olvidan y crean agujeros invisibles.

Contoso abre una tercera oficina en Sevilla y quiere además una red virtual para pruebas de carga, aislada de producción.

1. Asigna espacios de direcciones a la oficina de Sevilla y a la nueva red vnet-contoso-pruebas, coherentes con el plan existente y sin solapamientos.
2. Divide vnet-contoso-pruebas en tres subredes /24 con nombres coherentes con la nomenclatura del curso.
3. ¿Cuántas direcciones utilizables tiene cada subred /24? ¿Y una /27?
4. Explica por qué no puedes usar 10.20.0.0/16 para la red de pruebas.

Escribe las reglas de NSG (con prioridades) que cumplan exactamente esta política para vnet-contoso-pro:

1. snet-web acepta 443 desde internet y nada más.
2. snet-app acepta 8080 solo desde snet-web; ningún otro tráfico interno.
3. snet-datos acepta 1433 solo desde snet-app.
4. snet-gestion no acepta nada desde internet; solo administración desde Bastion.
5. snet-app puede salir hacia Azure SQL de West Europe, pero no hacia el resto de internet.

Describe, con los comandos correspondientes, los pasos para que sql-contoso-reservas-pro deje de ser accesible desde internet y solo se llegue desde snet-app:

1. Preparar la subred.
2. Crear el punto de conexión privado.
3. Configurar la resolución DNS.
4. Cerrar el acceso público.
5. Verificar que la resolución devuelve una IP privada.

Explica además qué pasaría si te saltases el paso 3.

Solución 1:

1. Direccionamiento coherente con el plan existente:

2. Subredes:

3. Una /24 tiene 256 direcciones, menos las 5 que reserva Azure: 251 utilizables. Una /27 tiene 32, menos 5: 27 utilizables.

4. Porque 10.20.0.0/16 ya es el espacio de vnet-contoso-pro. Dos redes con rangos solapados no se pueden emparejar ni conectar por VPN, y el enrutamiento sería ambiguo. Aunque hoy no fueras a emparejarlas, reutilizar el rango cierra esa puerta para siempre.

Solución 2:

Detalle del punto 5: la regla de salida a SQL debe tener prioridad menor (200) que la denegación general (4000), o el tráfico legítimo quedaría bloqueado.

Solución 3:

Si te saltas el paso 3, el punto de conexión privado existe y tiene su IP, pero el nombre sql-contoso-reservas-pro.database.windows.net sigue resolviendo a la IP pública. En cuanto ejecutes el paso 4, la aplicación intentará conectarse a esa IP pública ya cerrada y fallará con un error de conexión agotada, sin ninguna pista que apunte al DNS. Es la avería más frecuente y más desconcertante de Private Link.

Ya tienes la tercera pata de la plataforma. Sabes por qué la red va primero y qué decisiones quedan congeladas durante años. Manejas los espacios de direcciones privados, la aritmética CIDR suficiente para trocear una /16 en subredes sin solapamientos, y conoces las cinco direcciones que Azure reserva en cada subred. Has diseñado y desplegado vnet-contoso-pro con snet-web, snet-app, snet-datos, snet-gestion y las subredes de nombre obligatorio AzureBastionSubnet y GatewaySubnet. Escribes reglas de NSG entendiendo las prioridades y las reglas por defecto —incluida la más peligrosa, AllowVnetInBound, que hace que la segmentación no sea automática—, y usas etiquetas de servicio y grupos de seguridad de aplicación para que las reglas no dependan de listas de IP. Distingues IP públicas y privadas, estáticas y dinámicas, con su efecto en la factura. Sabes cómo funciona la resolución DNS de Azure y para qué sirven las zonas DNS privadas. Entiendes el emparejamiento y su falta de transitividad, que es justo lo que da forma al patrón hub-and-spoke y permite pagar una sola puerta de enlace VPN. Y has tomado la decisión que más protege los datos de los pasajeros: puntos de conexión privados con su zona DNS para la base de datos y la cuenta de almacenamiento, en lugar de puntos de conexión de servicio. Además, has conectado App Service a la red, has sustituido el SSH expuesto por Azure Bastion y sabes diagnosticar con Network Watcher en vez de adivinar.

Queda una pieza para cerrar el módulo, y es la que conecta Azure con el mundo real de Contoso Airlines. Las oficinas de Barcelona y Palma siguen fuera de esta red: su personal no llega a los recursos privados que acabas de blindar, el sistema de facturación heredado sigue viviendo en local, y Marta Ríos no puede administrar nada desde casa sin exponer algo. Al mismo tiempo, un cliente que compra un billete desde Sudamérica sufre la latencia de cruzar el Atlántico en cada petición hasta West Europe.

En la última lección del módulo, Conectividad híbrida y entrega global, resolvemos ambos extremos: VPN de punto a sitio para Marta y de sitio a sitio para las oficinas, con sus puertas de enlace y su despliegue por CLI; ExpressRoute y cuándo justifica su precio; Azure Virtual WAN como evolución del hub-and-spoke híbrido; y la entrega global del sitio con Azure Front Door, Azure CDN y Traffic Manager, incluido el coste de la salida de datos que sorprende a todo el mundo la primera vez que lee una factura.