Red base en OCI: VCN, subredes, gateways y control de tráfico

La red inicial de una tenencia en Oracle Cloud Infrastructure (OCI) tiende a convertirse en la base de las aplicaciones, bases de datos e integraciones que llegan después. Si sus subredes y reglas se crean sólo para que la primera máquina responda, las incorporaciones posteriores heredan accesos que nadie aprobó de forma explícita.

Este artículo propone diseñar esa red a partir de los flujos que el negocio necesita: qué componente recibe tráfico público, cuál llama a servicios externos y cuál accede a información interna. Con ese mapa, cada decisión sobre la VCN, los gateways y las reglas de seguridad tiene una justificación verificable. Al final se incluye un procedimiento de validación.

Direccionamiento y responsabilidades

Una Virtual Cloud Network (VCN) es una red privada configurable dentro de una región de OCI. Sus subredes organizan los recursos y usan rangos de direcciones expresados en notación CIDR. La guía de VCN y subredes describe estas relaciones y el alcance de cada subred.

Antes de asignar un rango, conviene compararlo con las redes de oficinas, centros de datos y otras nubes que podrían conectarse en el futuro. Una superposición de rangos complica después el enrutamiento privado y es costosa de corregir. Reservar espacio para crecer es razonable; anticipar permisos de comunicación no lo es.

La red también necesita responsables: quién administra las rutas, quién aprueba los accesos de una aplicación y quién atiende los incidentes de conectividad. Una convención de nombres (por ejemplo, produccion-aplicacion-privada) ayuda si el equipo la comparte, pero debe acompañarse de un inventario de propietarios. Una regla antigua no debería depender de encontrar a quien la creó.

Un esquema inicial pequeño y documentado es suficiente: una zona para la entrada pública y otra para los componentes internos, con ambientes separados según sus necesidades de aislamiento. El diseño de red debe coordinarse con el de compartimentos y políticas IAM, porque modificar una ruta requiere permisos de gestión, no sólo conocimiento técnico.

Subredes públicas y privadas

Una subred privada impide que sus recursos tengan direcciones IP públicas; una subred pública lo permite. Pertenecer a una subred pública no basta, sin embargo, para que un servidor sea accesible desde internet: se requieren la dirección adecuada, una ruta válida y reglas que permitan el tráfico, como explica la documentación del Internet Gateway.

En una aplicación web, el punto de entrada público puede ubicarse en una subred y los servidores internos en otra privada. El recorrido hacia la base de datos debe responder al funcionamiento de la aplicación; el acceso directo desde internet por comodidad operativa no tiene justificación. Esta disposición es una referencia que se ajusta a cada servicio.

El acceso administrativo se diseña por separado del acceso de usuarios. Debe quedar documentado desde qué red autorizada se administran las máquinas y qué mecanismo se usa para alcanzar recursos privados. Una necesidad de soporte ocasional no justifica abrir de forma permanente los puertos de administración a cualquier origen.

Un gateway por cada tipo de destino

Cada gateway resuelve un destino distinto. El Internet Gateway conecta la VCN con internet cuando el resto de la configuración lo permite. El NAT Gateway permite que recursos sin IP pública inicien conexiones hacia internet y reciban las respuestas, sin aceptar conexiones entrantes iniciadas desde fuera; sus condiciones están en la guía de NAT Gateway.

El Service Gateway ofrece acceso privado a servicios Oracle compatibles dentro de Oracle Services Network. No es una salida general hacia internet: sus rutas usan destinos de servicio específicos. La disponibilidad regional y los servicios cubiertos se verifican en Access to Oracle Services: Service Gateway.

Para conectar redes corporativas se evalúa un Dynamic Routing Gateway (DRG) junto con la conexión que corresponda. Oracle documenta su uso con túneles Site-to-Site VPN, circuitos virtuales FastConnect y conexiones entre redes. Según la guía de DRG, crear el gateway no establece por sí solo el recorrido: hacen falta los attachments y sus tablas de rutas.

Como criterio, los gateways se crean a partir de la lista de destinos y no antes. Un servidor que descarga paquetes de repositorios públicos sale por NAT; uno que accede a un servicio Oracle compatible, por Service Gateway; uno que llama a un sistema privado de la organización, por el DRG, con sus rutas de retorno documentadas.

Rutas y reglas: dos controles independientes

Una ruta establece por dónde viaja un paquete hacia un destino; una regla de seguridad establece qué tráfico puede pasar. Son controles independientes. Agregar una regla de puerto no corrige un gateway ausente, y agregar una ruta no concede acceso a una aplicación.

La herramienta recomendada es una tabla de flujos con origen, destino, protocolo, puerto y responsable del servicio. Para cada fila se identifican la tabla de rutas que interviene y el control de seguridad que autoriza la comunicación, incluido el retorno cuando el recorrido atraviesa redes de otro equipo.

Dos ejemplos de dependencias. Una subred privada con salida a internet necesita una ruta hacia el NAT Gateway y permisos de salida acordes con el uso. El acceso a servicios Oracle exige que el destino de servicio y el gateway seleccionado correspondan. A ambos se suma el DNS: una ruta correcta no sirve si el nombre resuelve hacia un endpoint distinto del previsto.

En un diagnóstico conviene modificar un componente a la vez, en este orden: destino resuelto, recorrido y permisos de red y del sistema operativo. Así se conserva la evidencia de qué cambio corrigió la falla y se evita acumular reglas que nadie sabe si son necesarias.

Grupos de seguridad de red por función

Las listas de seguridad aplican sus reglas a las interfaces de todos los recursos de una subred. Los Network Security Groups (NSG) agrupan interfaces que comparten requisitos de seguridad, aunque no coincidan con la subred completa, como describe la guía de grupos de seguridad de red.

Una organización por función (entrada web, aplicación, base de datos) es un buen punto de partida. Cuando el servicio lo admite, una regla puede usar otro NSG de la misma VCN como origen o destino, de modo que la política expresa una relación entre funciones y no una lista de direcciones individuales que hay que mantener.

Los permisos de listas de seguridad y NSG se combinan: un NSG restrictivo no anula una autorización amplia en la lista de la subred. Explicar por qué un paquete pasa exige revisar ambos. La documentación de reglas de seguridad detalla esta evaluación y la diferencia entre reglas stateful y stateless.

Con reglas stateful, OCI sigue la conexión y permite las respuestas correspondientes; con reglas stateless, los permisos deben definirse en ambos sentidos. Mezclar los dos tipos sobre el mismo tráfico requiere análisis previo. El firewall del sistema operativo es una tercera capa que puede bloquear una conexión que OCI ya autorizó. Si el endpoint usa atributos de Zero Trust Packet Routing (ZPR), sus políticas son una condición adicional a las de NSG y listas de seguridad.

Validación de los flujos aprobados

Antes de entregar la red a los equipos de aplicación, cada recorrido se prueba desde el componente que realmente iniciará la llamada. Una prueba desde una estación de trabajo valida un origen distinto y puede dar una falsa confirmación. Las pruebas negativas (accesos que deben ser denegados) son tan importantes como las positivas.

• Los rangos CIDR no se superponen con las redes que se conectarán.
• Cada recurso con IP pública tiene una justificación registrada.
• Cada destino está asociado a su gateway y a su tabla de rutas.
• Los permisos efectivos de listas de seguridad y NSG están revisados en conjunto.
• DNS y firewall del sistema operativo están validados desde el origen real.
• Las pruebas aceptadas y el responsable de futuros cambios quedan registrados.

Xterra Engine diseña y valida redes base en OCI a partir del inventario de flujos, antes de que lleguen las primeras cargas de trabajo.