¿Qué es una red virtual de Azure? La mayoría de la gente oye ese término y piensa que es solo otro ajuste que activas al implementar una máquina virtual. Algo que marcas en una casilla y luego olvidas. Pero aquí está la verdad. Una red virtual de Azure no es solo un ajuste. Es la base de todo lo que construyes en Azure. Cada máquina virtual, cada base de datos, cada servicio de aplicaciones, cada función que despliegas, todo reside dentro de él. Si no entiendes cómo funcionan, vas a ciegas. Al final de este episodio entenderás qué es realmente una OVNET, cómo funciona y por qué. Cada recurso que despliegas depende de ella. Cubriremos qué es una OVNET, cómo funcionan las direcciones IP, las subredes, la seguridad, el enrutamiento y cómo conectar OVNETs entre sí. Toma tu café y empecemos. Es una OVNET, la red de nube privada. Comencemos con la definición más simple. Una red virtual de Azure, o OVNET para abreviar, es tu propia red privada dentro de Azure.

Piénsalo como un edificio de oficinas privadas. Solo las personas que tú permites pueden entrar. Tú controlas quién entra por la puerta, a qué piso y quién queda totalmente excluido. Antes de que existieran las OVNETs, las cosas son diferentes. Implementabas una máquina virtual en la nube y básicamente estaba expuesta a internet por defecto. Sin una red privada a su alrededor, cualquiera que conociera la dirección IP puede intentar conectarse. Eso es una empresa de seguridad. ¿Qué cambio? Azure le dio la capacidad de crear espacios de red privados y aislados. Tú defines un límite. Tú decides qué va dentro de. Nada fuera de ese límite puede entrar a menos que tú lo permitas explícitamente. Algo que debes saber desde el principio, tu OVNET vive en una región de Azure específica, no es global. Creas una OVNET en Europa Occidental y ahí es donde se queda. Los recursos en una región diferente no pueden simplemente ser traer.

Necesitarían su propia OVNET o tendrías que conectarlos después. Cuando creas una OVNET, tú mismo defines el espacio de direcciones IP. Azure no lo elige por ti. Tú decides el rango de direcciones IP que usarán tus recursos. Esa es una gran responsabilidad y hablaremos de cómo hacerlo correctamente en la siguiente sección. Aquí está el punto clave. Las OVNET son la base. Cada máquina virtual, cada base de datos, cada función de Azure que despliegas reside dentro de una. Sin una OVNET, tus recursos no tienen contexto de red privada. Solo flotan en la nube sin límites, sin aislamiento, sin seguridad. Entonces, ¿qué significa esto para ti? Si vas a crear algo en Azure, empieza primero con una OVNET. No después de implementar tus recursos, sino antes. Tu OVNET es el terreno sobre el cual vas a construir. No construirás una casa sin comprar el terreno primero. Es la misma idea. Direccionamiento IP y CD, reeligiendo tu espacio de direcciones.

Así que, profundicemos. Cuando creas una OVNET, la primera gran decisión es elegir un rango de IP. Lo haces usando la anotación CD. DDR es la abriatura de Classless Interdomain Routing, pero en realidad solo significa que dices, necesito esta cantidad de direcciones IP. Ay, ¿por qué importa esto? Porque el rango que elijas determina cuántos recursos puedes incluir en tu red virtual. Así es como funciona. CDR usa una barra y un número como 16 o 24. Ese número te indica el tamaño de la espacio de direcciones. Un 16 te da cerca de 65,000 direcciones IP. Eso es mucho. Un 24 te da cerca de 250, lo cual es perfecto para un equipo pequeño o una sola capa de aplicación. Así que, al diseñar tu OVNET, debes pensar en cuántos recursos tendrás y cómo quieres. Agruparlos. Ahora, no puedes elegir cualquier rango de IP. Azure sigue el estándar RFC 1918, que reserva rangos de IP privados para redes internas.

Tienes tres opciones. El rango 10.x.x es el más grande, dándote mucho espacio para crecer. El rango 172.16.x es un poco más pequeño, pero sigue siendo útil. Y el rango 192.68.x es el que probablemente tienes en casa en tu router. Aquí está el detalle. El espacio de direcciones de tu OVNET no puede superponerse con ninguna otra red a la que planes conectarte. Este es un error común. Muchas personas eligen un rango que les resulta familiar solo para descubrir después que entre en conflicto con su red corporativa. Así que, si la red de tu oficina usa 10.0.0.0.16, no uses ese mismo rango en Azure. Si intentas conectarlas más tarde, chocarán y el tráfico no sabrá a dónde ir. Déjame darte un ejemplo concreto. Imagina que estás construyendo una configuración híbrida, donde Azure se conecta a tu centro de datos local y tu centro de datos usa 10.0.0.0.0.0.1.16. Si creas una OVNET con el mismo rango, tendrás dos redes peleando por las mismas IP.

Piénsalo. Dos redes que usan el mismo rango de IP no pueden comunicarse correctamente. Es como dos casas con la misma dirección. El correo se confunde. Ese es un problema que no querrá resolver que ya haya ocurrido. Así que planea contratación y elige un rango. Y aquí tienes un consejo de planificación. Elige un rango más grande de lo que crees que vas a necesitar. Quizás pienses que solo necesitas una 24 ahora, pero a medida que tu aplicación crezca, desearás tener una 16. No puedes cambiarla fácilmente. Una vez que tu VNET está creada y has desplegado recursos, cambiar el espacio de direcciones es complicado. Es posible, pero no es algo que quieras hacer en un sistema en vivo. Así que date espacio para crecer. ¿Qué significa esto para ti? Piensa en el espacio de direcciones de tu VNET como si compraras un terreno. Pues sigue suficiente para el crecimiento futuro. Si crees que necesitas un terreno pequeño, compra uno mediano.

Te lo agradecerás más tarde. Esa es la idea principal. Planifica tu espacio de direcciones pensando en el crecimiento futuro. Subredes dividiendo tu red. Entonces ya tienes tu VNET y has elegido tu espacio de direcciones. Ahora qué, no simplemente volques todo en un solo gran grupo. Ahí es donde entran las subredes. Las subredes son uno de los bloques fundamentales de tu VNET. Te permiten organizar y asegurar tus recursos. Una subred es una sección más pequeña del espacio de direcciones de tu VNET. Si tu VNET es el edificio, las subredes son las habitaciones individuales. No pondrías tu sala de servidores, tu recepción y tu sala de descanso en el mismo espacio abierto, ¿verdad? La misma idea aplica. Es un concepto simple, pero marca una gran diferencia en cómo gestionas tu red. Diferentes recursos van en diferentes subredes. Tus servidores web van en una subred, tus bases de datos en otra y la lógica de tu aplicación en una tercera.

¿Por qué? Dos razones. Seguridad y organización. Hablemos primero de seguridad, porque suele ser lo más importante. ¿Seguridad? Si alguien entra en tu servidor web, no querrás que tengan acceso directo a tu base de datos. Las subredes separadas crean una barrera. El atacante tendría que cruzar ese límite y tú puedes controlar exactamente que lo cruza. También puedes usar grupos de seguridad de red para controlar el tráfico entre subredes. Ese es tema para otro video, pero vale la pena saber que las subredes son la base de esa seguridad. Organización en segundo lugar. Cuando todo tiene su lugar, gestionarlo es más fácil. ¿Sabes qué subred contiene tus recursos de front-end y cuál alberga tus datos de back-end? Puedes aplicar políticas y reglas a toda la subred a la vez, en lugar de configurar cada recurso individualmente. Eso ahorra tiempo y reduce errores. Pero aquí hay un detalle que toma la gente desprevenida.

Azure reserva cinco direcciones IP en cada subred para sus propios fines internos, como enrutamiento y DNS. Así que si creas una subred con un rango 24 que te da 256 direcciones, en realidad solo obtienes 256 utilizables. Es un inconveniente común. Planeas para 256, pero solo obtienes 256. Así que siempre añade un poco más al dimensionar tu subred. La buena noticia es que puedes añadir subredes después de crear la OVNET. No estás limitado a la que configuraste durante la creación. Así que si te das cuenta de que necesitas una subred separada para herramientas de gestión o sistemas de monitoreo, añádela después. No hay problema. Pero sigue siendo mejor planificarla desde el principio. Añadir subredes después es posible, pero podrías tener que mover recursos, lo cual puede ser disruptivo. Pero aquí está la mejor práctica. Usa subredes separadas para los diferentes niveles de tu aplicación desde el inicio.

Piensa en la arquitectura de aplicación. Normalmente tienes un nivel frontal que maneja solicitudes de usuario y un nivel de backend, que procesa lógica de negocio y un nivel de datos que almacena información. Cada uno de estos debería tener su propia subred. No esperes a estar en producción para darte cuenta de que necesitas separar las cosas. Eso es mucho más difícil cuando los recursos ya están desplegados. ¿Qué significa esto para ti? Las subredes son la forma en que mantienes tu red organizada y segura. Son como las habitaciones en tu edificio. Planifícalas pronto y dale a cada nivel de tu aplicación su propio espacio. Así es como mantienes tu red limpia y segura. IP es pública frente a privadas. ¿Quién puede ver qué? Hablemos de direcciones IP porque no todas las direcciones IP son iguales. Cuando despliegas un recurso dentro de una UBnet, obtiene una dirección IP privada por defecto.

Esa es la dirección que usa para comunicarse con otros recursos dentro de la UBnet. Piénsalo como una extensión teléfono y que interno. Solo las personas dentro del edificio pueden alcanzar. Las IPs privadas solo son accesibles desde dentro de la UBnet o desde redes conectadas a ella. Si estás en casa con tu laptop, no puedes alcanzar una IP privada en Azure. Está en Internet. Está dentro de tu red privada. Entonces, que un recurso sea alcanzable desde Internet. Le asignas una dirección IP pública. Esa es la dirección visible para el mundo exterior, como tener un número de teléfono público en lugar de una extensión interna. Aquí está lo fundamental. Las IPs públicas son opcionales. Las asignas explícitamente porque Azure nunca le da tus recursos a una IP pública a menos que lo pidas. Eso es por diseño. Lo predeterminado debe ser privado y lo público debe ser una elección deliberada. Aquí es donde muchos principiantes cometen un error.

Le dan IPs públicas a todo. Su servidor web, su base de datos, su API de backend. Todos obtienen una. Eso es un riesgo de seguridad. Tu base de datos no necesita ser alcanzable desde Internet y tampoco tu API de backend. Solo los recursos de Frontend con los que interactúan los usuarios deberían tener IP públicas. Las IP públicas vienen en dos variantes, estáticas y dinámicas. Una IP pública estática permanece igual aunque detengas y reinicies el recurso. Una IP pública dinámica puede cambiar. Si ejecutas una aplicación de producción, probablemente necesites IP estáticas para que tus usuarios siempre te encuentren. Si estás probando algo, una dinámica podría ser suficiente. También puedes usar algo llamado prefijo de IP pública que te permite reservar un bloque de direcciones. En lugar de crearlas una por una, reservas un rango y luego asignas direcciones individuales de ese rango. Es útil si sabes que necesitarás varias IP públicas para un proyecto.

¿Qué significa esto para ti? Las IP privadas son opción segura por efecto. Son como la extensión telefónica interna. Las IP públicas son una elección deliberada que haces solo cuando necesitas que algo sea accesible desde fuera. Cuando las necesites, piensa si requieres una estática o dinámica si un prefijo tiene sentido. Grupos de seguridad de red que controlan el tráfico. Ya tienes tu VNED, tus subredes y tus direcciones IP organizadas. ¿Pero cómo controlas realmente qué tráfico entra y sale? Ahí es donde entran los grupos de seguridad de red. Un NSG es el guardián que controla qué tráfico entra y sale de tus recursos. Piénsalo como el portero de un club que revise identificaciones. Mira la lista de invitados y rechaza a quién no debería estar ahí. Cada fragmento de tráfico que intenta llegar a tu recurso debe pasar primero por este portero. Los NSG funcionan con reglas. Cada regla indica permitir o denegar basándose en cuatro elementos.

La IP de origen, la IP de destino, el puerto y el protocolo. Así puedes permitir tráfico de la IP de mi oficina en el puerto 443 o denegar todo tráfico de internet en el puerto 22. Ese tipo de control. Ahora, aquí hay una característica potente. Puedes adjuntar un NSG a una subred o directamente a la interfaz de red de una sola máquina virtual. Si lo adjuntas a una subred, ese NSG se aplica a todo lo que hay dentro. Cada máquina virtual, cada base de datos, cada recurso. Es una política general. Si lo adjuntas a la interfaz de red de una máquina virtual específica, solo se aplica a esa máquina. Incluso puedes hacer ambas cosas. Un NSG a nivel de subred para reglas generales y uno a nivel de NIC para excepciones. Las reglas predeterminadas que crea Azure son bastante sensadas. Permiten todo el tráfico dentro de la OINET para que sus recursos puedan comunicarse entre sí. Y denegan todo el tráfico desde internet, por lo que nada externo puede llegar a sus recursos a menos que usted lo permita explícitamente.

Es un buen punto de partida. Permítame darles un ejemplo. Digamos que administre una máquina virtual Linux y necesita conectarse a ella mediante SSH. Crearía una regla de NSG que permita tráfico entrante en el puerto 22, pero no querrá permitir SSH desde cualquier lugar. Eso es buscarse por él. Así que lo restringe a su propia dirección IP, de modo que solo usted pueda acceder por SSH y todos los demás queden bloqueados. La misma idea aplica para RDP en el puerto 3389 en máquinas Windows. ¿Qué significa esto para usted? Los NSG son su primera línea de defensa y lo mejor de todo son gratuitos. No hay costo adicional por usarlos, así que no hay excusa para no configurarlas. Cada subred y cada recurso deberían tener un NSG asociado. Comience denegando todo y solo abra lo que necesite. Tablas de rutas y enrutamiento dirigiendo el tráfico. Ahora hablemos de enrutamiento, porque una vez que haya decidido qué tráfico está permitido, debe decidir a dónde va realmente.

Aquí está la cuestión. Azure crea rutas del sistema automáticamente para cada Supra. No tiene que hacer nada. Piénselo como un GPS predeterminado que conoce las rutas básicas. Tráfico dentro de la UNED, tráfico a UNEDs vinculadas, tráfico a Internet. Todo funciona desde el primer momento, pero a veces el GPS predeterminado no lo lleva a donde quiere ir. Es ahí cuando necesita rutas definidas por el usuario UDR. Estas le permiten anular las rutas del sistema de Azure y tomar el control de la ruta que sigue el tráfico. ¿Cómo funciona? Te crea una tabla de rutas. Agrega su rutas persona. Luego asocia esa tabla de rutas a una subred. A partir de ese momento, el tráfico que sale de esa subred sigue sus reglas en lugar de las predeterminadas. Permítame darles un ejemplo concreto. Digamos que desea que todo el tráfico de Internet desde su UNED pase primero por un firewall o un firewall. Quizás necesite inspeccionarlo, registrarlo o bloquear sitios maliciosos.

La ruta del sistema predeterminada envía el tráfico de Internet directamente a ese fuente. Eso no es lo que usted quiere, así que crea una ruta que indique que cualquier tráfico dirigido a 0.0.0.0, lo cual significa cualquier lugar en Internet, debe ir al firewall en su lugar. Eso es una ruta del usuario. Las tablas de rutas utilizan algo llamado Próximo Santo. Es el destino al que se envía el tráfico a continuación. Este tiene algunas opciones. Puede enviarlo a un dispositivo virtual como un firewall. Puede enviarlo a una puerta de enlace de red virtual, que es como se conecta a redes locales. Puede enviarlo directamente a Internet o puede enviarlo a NON, lo que básicamente descarta el tráfico. Lo fundamental es entender que el embrutamiento es como usted controla la ruta que toma el tráfico a través de su red. Las rutas del sistema son un buen valor predeterminado, pero no siempre son adecuadas para su situación.

Si necesita que el tráfico pase por un punto de inspección, una puerta enlace específica, o que se bloquee por completo, necesita rutas definidas por el usuario. ¿Qué significa eso para usted? El enrutamiento es común indicar al tráfico a dónde ir, y usted tiene el poder de anular los valores predeterminados de Azure cuando sea necesario. Comience con las rutas del sistema, entienda lo que hacen y luego agregue rutas personalizadas cuando su arquitectura lo exige. Emparejamiento de UvNet conectando red Hasta ahora hemos hablado de una sola UvNet, un edificio, una red privada. ¿Pero qué sucede cuando tiene múltiples UvNets? Quizás tiene una para su entorno de producción y otra para pruebas, o tal vez ejecuta aplicaciones en diferentes regiones de Azure. De forma predeterminada, estas UvNets están completamente aisladas, no comunicarse entre sí. Son como edificios separados sin caminos entre ellos.

Allá es donde entra en juego el emparejamiento. El tráfico entre UvNets emparejadas permanece en la red troncal de Microsoft. Nunca toca la red pública de internet. Eso significa baja latencia, gran ancho de banda y ninguna exposición a amenazas externas. ¿Qué hay algo que sorprende a la gente? El emparejamiento también funciona entre regiones. Eso se llama emparejamiento grupo. Puede tener una UvNet en Europa Occidental emparejada con una UvNet en el sudeste asiático, y el tráfico entre ellas permanece en la red privada de Microsoft. Sin puertas de enlace de VPN y sin IPs públicas son una conexión privada directa. Pero hay una regla que absolutamente no puede romper. Las UvNets emparejadas deben tener espacios de direcciones que no se suponen. Si ambas UvNets intentan usar el rango 10.0.0.0.16, no se pueden emparejar. Las direcciones IP entrarían en conflicto y Azure no sabría a qué red pertenece un paquete.

Entonces, recuerde ese consejo de planificación anterior sobre elegir su espacio de direcciones cuidadosamente. Esa es la razón. Si cree que podría emparejar UvNets más adelante, asegúrese de que sus rangos no se superpongan desde el principio. Ahora, aquí hay un detalle que confunde a la gente. El emparejamiento no es tránsito. ¿Qué significa eso? Supongamos que la UvNet A está emparejada con la UvNet B y la UvNet B está emparejada con la UvNet C. La UvNet A no llega automáticamente a la UvNet C a través de B. No están conectadas. Cada emparejamiento es un enlace directo entre exactamente dos UvNets. Si quiere que A se comunique con C necesita un emparejamiento separado entre A y C. Entonces, ¿cómo manejar esto a gran escala? Utiliza una arquitectura de Hub & Spoke. Una UvNet central, el Hub, se conecta mediante piling con muchas otras UvNets, lo supongo. El Hub puede contener servicios compartidos como un firewall, una puerta enlace VPN o herramientas de monitoreo.

Los Spokes contienen sus cargas de trabajo individual. Cada Spoke se conecta directamente con el Hub, pero los Spokes no se conectan en sí. Si un Spoke necesita comunicarse con otro, el tráfico pasa a través del Hub. Esto mantiene el orden y le brinda un lugar central para aplicar políticas de seguridad. ¿Qué significa esto para usted? El Piring, la forma de construir redes que abarcan múltiples UvNets y regiones, es el puente de sus edificios. Planifique sus espacios de direcciones para que no se superpongan. Recuerde que el Piring no es transitivo y considere un diseño Hub & Spoke cuando empiece a crecer más allá de una sola UvNet. ¿Cómo se conecta todo el panorama general? Así que demos un paso atrás y veamos cómo encajan estas piezas. Ahí es donde recibe el verdadero poder. Usted comienza con una uvNet. Es su espacio privado en ASU. Piense en ello como su terreno. Dentro de ese terreno usted crea subredes.

Esas son sus habitaciones. Una para servidores web, otra para bases de datos, otra para herramientas mixtas. Cada subrede obtiene su propio bloque de direcciones extraído del espacio de direcciones de lado. Luego usted añade seguridad. Los grupos de seguridad de red se vinculan a su subrede. Controlan qué tráfico tiene permitido entrar y salir. Su subrede web permite tráfico desde Internet por el puerto 4403. Su subrede de base de datos solo permite tráfico desde la subrede web por el puerto 1433. El portero en cada puerta sabe exactamente a quién dejar pasar. Continuación, usted configura el ruta. Quizás quiera que todo el tráfico de Internet saliente pase por un firewall para su inspección. Crea una tabla de rutas, añade una ruta personalizada y la vincula a su subrede. Ahora, el tráfico sigue la ruta que usted diseñó en lugar de la predeterminada diaria. Y finalmente, conecta todo. Conecta su UBnet mediante Peering con otras UBnets.

Quizás una UBnet Hub que contenga su firewall y servicio compartido. Ahora, su aplicación abarca múltiples redes, pero todo funciona como un sistema conectado. Aquí llega el momento de redes. Ninguna de esas piezas funciona de forma exacta. Una UBnet sin subredes es solo un espacio vacío. Las subredes sin NSG están completamente abiertas. El enrutamiento sin un diseño claro envía el tráfico al lugar equivocado. Peering sin planificación crea conflicto de direcciones. Son un sistema. Cada pieza depende de las demás. Permítame darle un ejemplo concreto. Imagina una aplicación web. Sus servidores web residen en una subred pública con un NSG que permite tráfico HTTPS desde Internet. Sus servidores de aplicaciones residen en una subred privada que solo acepta tráfico de la subred web. Tu base de datos reside en otra subred privada que solo acepta tráfico de la subred de la aplicación. Una tabla de rutas fuerza todo el tráfico saliente a través de un firewall en la red virtual central para su registro e inspección.

Todo el conjunto está conectado con tu red corporativa para que tu equipo interno pueda administrarlo. Ese es el valor real, no una sola funcionalidad. Es como funcionan todos juntos. Hace 20 años comprabas servidores separados, configurabas routers físicos y administrabas firewalls por dispositivo. Todo era manual, lento y costoso. Azure te ofrece todo esto como un servicio. Lo defines con unos pocos clics o un script y simplemente funciona. ¿Qué significa esto para ti? Una vez que ves cómo encajan estas piezas, las redes de Azure se vuelven predecibles. Estás adivinando, estás diseñando. Cuando algo falla, sabes exactamente dónde buscar porque entiendes el sistema. Esto es lo que quiero que te lleves de este episodio. Primero, el paso más importante que puedes dar. Crea una red virtual con un espacio de direcciones bien planificado antes de implementar nada. Esa única decisión afecta a todo lo que viene después.

Segundo, usa subreds para separar tus niveles de aplicación. Servidores web, servidores de aplicaciones, bases de datos, dale a cada uno su propio espacio. Y tercero, comienza con los NSG. Son gratuitos, son potentes y mejoran drásticamente tu seguridad desde el primer día. Tu red virtual es la base de todo lo que construyes en Azure. Hazlo bien y todo lo demás será más fácil. Hazlo mal y pasarás todo el tiempo luchando contra tu red. Suscríbete en tu plataforma de podcast favorita y comparte esto con alguien que esté comenzando su viaje en Azure. Deja un comentario si algo te resultó útil. Nos vemos en el próximo episodio. ¡Gracias!