Cuando creas máquinas virtuales en Azure, lo más común es que queden aisladas del exterior. Aquí aprenderás a configurar una máquina virtual pública en Azure para acceder a ella vía escritorio remoto (RDP) o SSH, abriendo los puertos correctos y asociando una dirección IP pública. Es una guía práctica para quienes están empezando con redes en la nube.

¿Qué necesitas para exponer una VM al exterior en Azure?

Para que tu máquina virtual deje de estar encerrada en una red interna, necesitas combinar varios recursos que trabajan juntos. No basta con asignar una IP, también debes definir quién entra y quién sale.

Estos son los componentes que vas a desplegar desde el script comandos.sh [00:48]:

• Un grupo de recursos que agrupe todo.
• Una red virtual (VNet) con su subred.
• Una dirección IP pública, que es la novedad respecto a despliegues anteriores.
• Un Network Security Group (NSG) con reglas específicas.
• La máquina virtual asociada a todos estos elementos.

¿Qué es un Network Security Group en Azure? Es un conjunto de políticas que controla qué tráfico entra y sale de tu red. Funciona como el cadenero de un bar: decide quién pasa y quién no [01:25].

¿Cómo se configuran las reglas del NSG para permitir RDP y HTTPS?

Un NSG sin reglas no sirve de mucho. Las reglas son las que abren los puertos específicos que tu VM necesita para recibir conexiones desde internet.

En el script se crean reglas dentro del grupo de seguridad ya existente [01:50]. Cada regla define:

• Un nombre descriptivo, por ejemplo Permitir acceso por escritorio remoto.
• El protocolo, normalmente TCP.
• Una prioridad numérica que ordena la evaluación.
• El puerto a abrir: 443 para HTTPS, 80 para HTTP web y 3389 para RDP.

Una vez creadas las reglas, asocias el NSG con la subred [02:30]. Así, cualquier recurso desplegado dentro de esa subred hereda automáticamente las políticas. Es una manera limpia de separar la configuración de seguridad de la configuración de cómputo.

¿Por qué usar Windows Server para esta demo?

La elección de Windows Server 2019 es puramente visual: ver un escritorio remoto cargando es más ilustrativo que una consola SSH [02:48]. La VM se crea con az vm create, indicando usuario, password, la VNet, la subred, la IP pública y el NSG asociado.

Después hay que abrir los puertos también a nivel de la VM con az vm open-port, pasando los tres puertos en el parámetro --port [03:35].

¿Cómo instalar IIS sin entrar a la máquina virtual?

Aquí aparece un truco muy útil: puedes instalar software en la VM sin abrir una sesión remota. Se hace con az vm extension, ejecutando un comando de PowerShell que instala la característica de Web Server (IIS) directamente desde el script [03:50].

Esto significa que tu despliegue queda completamente automatizado. Lanzas el script con bash comandos.sh y, al terminar, tu VM ya tiene IIS configurado y listo para responder peticiones HTTP.

¿Para qué sirve az vm extension? Permite ejecutar scripts o instalar software dentro de la VM como parte del despliegue, sin necesidad de conectarte manualmente. Ideal para automatizar configuraciones iniciales.

¿Cómo conectarte por RDP y verificar que el servidor web funciona?

Una vez completado el despliegue, vas al portal de Azure y entras al grupo de recursos público. Notarás un componente extra que antes no estaba: la dirección IP pública [04:35].

En la sección Conectar de la VM, Azure te ofrece comprobar el acceso. Si el portal evalúa las reglas y te marca accesible, descargas el archivo RDP, haces doble clic e ingresas las credenciales (en la demo, el password es amoaprender) [05:05].

Una vez dentro:

• En el panel del servidor aparece IIS confirmando la instalación [05:55].
• Abres Edge y escribes localhost para ver la página de bienvenida.
• Desde tu equipo local, usas la IP pública con el puerto 80 y obtienes el mismo IIS publicado [06:20].

¿Por qué importa abrir tanto HTTP como RDP?

Porque cada puerto cumple una función distinta. RDP (3389) te permite administrar la máquina, mientras que HTTP (80) y HTTPS (443) exponen los servicios web a usuarios finales. Configurar ambos desde el inicio te ahorra volver a tocar reglas después.

¿Qué diferencia este enfoque de un scale set con application gateway?

Este ejercicio resulta bastante más entendible con una sola máquina virtual que con una arquitectura monumental con application gateway y scale sets detrás [06:50]. No es que uno sea mejor que otro, son escenarios distintos:

• Una VM pública sirve para pruebas, demos o servicios pequeños.
• Un scale set con balanceadores aplica para arquitecturas con alta demanda y escalado horizontal.

Lo recomendable, una vez que dominas este flujo en Windows, es repetir el ejercicio con Linux y SSH. Cambia el sistema operativo, el puerto (22 en lugar de 3389) y el método de autenticación, pero la lógica del NSG y la IP pública es exactamente la misma.

¿Ya intentaste replicarlo con Linux? Cuéntame en los comentarios qué retos encontraste al cambiar de sistema operativo.