Unidad 3.1: Topología y segmentación de VDC

Introducción

La primera decisión real en cualquier arquitectura de IONOS CLOUD no es qué servidor construir, sino en qué red se encuentra cada nivel, porque en esta plataforma la LAN en la que reside un recurso es el elemento principal que determina si es accesible desde internet. Una LAN dentro de un centro de datos virtual es privada hasta que se conecta explícitamente a internet, por lo que la exposición es algo que se añade de forma deliberada, no algo que se elimina posteriormente. Esta unidad establece la topología en la que se insertan todas las construcciones posteriores del módulo: una LAN de borde pública, una LAN de aplicaciones privada y una LAN de datos privada. Comienza con las decisiones de direccionamiento y segmentación, y termina construyendo esa estructura de tres LAN en Data Center Designer para la primera carga de trabajo regulada de FinCorp.

1. La red privada por defecto y el diseño de tres niveles

Una LAN se vuelve pública solo cuando se le adjunta un elemento de acceso a internet; sin esa conexión, la red es privada. Ese comportamiento singular es lo que convierte a la privacidad por defecto en la opción de menor resistencia: deje un nivel en una LAN sin conexión y ya será inalcanzable desde fuera del VDC. El diseño de tres niveles se deriva directamente de esto:

• Una LAN de borde pública transporta únicamente el punto de entrada orientado a internet (el equilibrador de carga de capa 7 en la Unidad 3.3, además de cualquier borde con conmutación por error de IP en la Unidad 3.5).
• Una LAN de aplicaciones privada transporta la computación sin estado o el grupo de nodos de Kubernetes.
• Una LAN de datos privada transporta las bases de datos administradas, la caché y el almacenamiento compartido, y solo es accesible a través del equilibrador interno de capa 4 en la Unidad 3.4.

La razón por la que esta jerarquización es el mecanismo de control, y no una mera comodidad, radica en dónde se aplica el filtrado de la plataforma. Los firewalls a nivel de NIC y los Network Security Groups se adjuntan a las NIC de los servidores únicamente a nivel de VDC; no se aplican al Managed Application Load Balancer, al Managed Network Load Balancer ni a la abstracción del clúster de Managed Kubernetes. Dado que no puede envolver los equilibradores administrados en un grupo de seguridad, no puede depender de una regla de firewall para compensar la colocación de una base de datos en una ruta pública. La propia topología debe realizar el aislamiento. Por lo tanto, la segmentación es la decisión estructural fundamental, y la división en tres LAN es el mínimo que la expresa de manera clara. La Unidad 3.2 añade luego reglas de firewall y NSG como una segunda capa dentro de esa topología, nunca como un sustituto de la misma.

Para FinCorp, la empresa de servicios financieros alemana que gestiona su carga de trabajo bajo las expectativas de RGPD y BSI, este es el contenedor en el que se integra la aplicación regulada. La historia de cumplimiento es sustancialmente más fácil de sostener cuando el nivel de datos es arquitecticamente incapaz de aceptar una conexión entrante desde fuera del VDC, porque el argumento se basa en la topología y no en la corrección de una lista de reglas.

2. Direccionamiento de LAN: la subred /24, el rango reservado y la puerta de enlace

Cada LAN utiliza por defecto una subred /24, que es la unidad de direccionamiento sobre la que se planifica. Dentro de esa /24, el espacio de direcciones no está completamente a disposición del usuario para su asignación:

• Las direcciones .2 a .9 están reservadas para servicios administrados dentro de la LAN /24. No se deben asignar a las propias VM.
• Las direcciones .10 a .255 constituyen el rango desde el cual se asignan las IP de las VM.

Las LAN privadas utilizan los rangos de RFC 1918 (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16). La unidad máxima de transmisión en la LAN es de 1500 bytes; planificar con ese MTU evita sorpresas de fragmentación cuando más adelante se ejecuten túneles cifrados sobre la misma infraestructura en la Unidad 3.6.

La decisión entre direccionamiento estático y DHCP se toma por nivel y por rol. El nivel de aplicaciones puede tolerar DHCP porque sus miembros son intercambiables y sin estado. El nivel de datos y cualquier nodo al que otros recursos dirigen por IP deben mantener una dirección estática, porque un punto de acceso a una base de datos o un destino de un equilibrador de carga que cambia al renovar una concesión es una interrupción a la espera de ocurrir. La medida preventiva práctica consiste en mantener las direcciones asignadas por DHCP y las asignadas de forma estática en partes no superpuestas del rango .10-.255, de modo que una concesión nunca colisione con una dirección fija.

El tráfico interno entre LAN en el mismo VDC se transmite a un máximo de 6000 Mbps, y la ruta del firewall de la NIC está calificada para un rendimiento de 6 Gbps, por lo que el límite de segmentación no constituye un cuello de botella de rendimiento para el tráfico este-oeste entre los niveles de aplicaciones y de datos.

3. IPv4 públicos reservados y el modelo de IPv6

Un borde público requiere una dirección estable. Una dirección IPv4 reservada está vinculada a una región: solo puede utilizarse en la región del centro de datos donde se reservó, y aunque diferentes IPs de un mismo bloque reservado pueden servir a diferentes redes, esto solo ocurre dentro de la misma región. Reservar una IP requiere el privilegio Reserve IP Blocks, por lo que solo los propietarios de contratos, los administradores o los usuarios a quienes se les haya concedido dicho privilegio pueden realizarlo; todos los demás tienen acceso de solo lectura a la gestión de IPs. Un bloque IPv4 reservado se factura a un precio de 5,00 EUR por cada 30 días por dirección. Las IPs no pueden devolverse de forma individual, solo como bloque y solo cuando ninguna de las direcciones del mismo esté en uso, y si devuelve una IP estática, no podrá reservar esa misma dirección nuevamente después.

Debe reservar la IP pública antes de crear el recurso que la consumirá. El equilibrador de carga de capa 7 de la Unidad 3.3, el VPN Gateway y el NAT Gateway de la Unidad 3.6, y el borde con conmutación por error de IP de la Unidad 3.5, todos esperan que ya exista una IPv4 pública reservada; aprovisionar primero el recurso consumidor y buscar una dirección después es la causa más común de trabajo repetitivo evitable en la consola.

IPv6 sigue una asignación jerárquica en lugar de una reserva por dirección. Un VDC recibe un /56 público, cada LAN con IPv6 habilitado toma un /64 (elegido de ese /56 o asignado automáticamente), y cada NIC recibe un /80. Un VDC puede tener hasta 256 LAN con IPv6 habilitado, y la plataforma admite la operación dual-stack. Un límite es importante en la etapa de topología: los servicios de red gestionados (Application Load Balancer, Network Load Balancer, NAT Gateway, IP Failover y Managed Kubernetes) son solo IPv4, por lo que un diseño orientado a IPv6 aún termina su borde gestionado en IPv4.

Recorrido de implementación de DCD

Construirá la topología de tres LAN de FinCorp: una LAN de borde pública, una LAN de aplicaciones privada y una LAN de datos privada, con una NIC de servidor en cada nivel y una dirección IPv4 pública reservada lista para el borde. Esto materializa la decisión de segmentación de la Sección 1 antes de que cualquier construcción de cómputo, seguridad o equilibrador se implemente sobre ella.

Objetivo de construcción: Construir la topología de tres LAN con NICs y una IP pública reservada.

Pasos (en Data Center Designer):

1. Abra el VDC de FinCorp creado en la Unidad 2.1 (reutilícelo; no cree una nueva región). La región ya está fija y las reservas de IP se vincularán a ella.
2. Vaya a Menú > Network Services > IP Management y seleccione Reserve IP Blocks. Reserve un bloque IPv4 público en la misma región que el VDC. No puede elegir una dirección específica; recibirá una (o más) del pool. Esta es la futura dirección de borde, reservada primero.
3. En el Workspace, coloque el servidor del nivel de aplicaciones y el servidor del nivel de datos. Cada servidor obtiene una NIC que asignará a una LAN en los próximos pasos.
4. Cree la LAN de aplicaciones privada: arrastre una LAN al workspace (o conecte la NIC del servidor de aplicaciones a una nueva LAN) y déjela sin conexión a internet para que permanezca privada. Mantenga el prefijo /24 por defecto.
5. Cree la LAN de datos privada de la misma manera, como una segunda LAN privada, y conecte la NIC del servidor del nivel de datos a ella. No la conecte a internet.
6. Cree la LAN de borde pública conectando el elemento Internet Access a una nueva LAN. Esta es la única LAN que se enfrenta a internet; resérvela para el equilibrador de borde y la NIC de conmutación por error de IP que se construirán en unidades posteriores.
7. En cada NIC, configure la direccionamiento por nivel: una dirección estática del rango .10-.255 para la NIC del nivel de datos (para que el punto de acceso de la base de datos sea estable), y DHCP aceptable para la NIC de aplicaciones intercambiable. Mantenga .2-.9 libre para servicios gestionados.
8. Provisione los cambios. La forma de tres LAN ahora existe con la IP pública reservada y los niveles segmentados.

Errores comunes:

• Reservar la IP pública después de construir el consumidor. Resérvela primero; el equilibrador, la pasarela o el grupo de conmutación por error espera que exista.
• Asignar una VM al rango de servicio gestionado .2-.9 o al espacio de pasarela .1/.2, lo cual colisiona con la direccionamiento de la plataforma.
• Conectar la LAN de datos a internet "solo para probar", lo cual invalida todo el argumento de segmentación en el que se basa la historia de cumplimiento.
• Colocar un borde de conmutación por error de IP o un equilibrador de carga en la misma LAN pública y esperar que un NSG lo proteja; los equilibradores gestionados no pueden envolver en un grupo de seguridad, por lo que la seguridad del nivel de datos debe provenir de estar en una LAN privada.
• Reservar la IP en la región incorrecta; una IPv4 reservada está vinculada a la región y no es utilizable en otro lugar.

Estudio de caso empresarial (FinCorp)

El servicio de FinCorp orientado al cliente y sujeto a regulación es la carga de trabajo que fundamenta este módulo. Su requisito es claro: los clientes acceden a un punto de acceso público HTTPS, pero los datos de las cuentas nunca deben ser alcanzables desde internet. La decisión de diseño consiste en expresar esto como topología, no como un conjunto de reglas. La LAN de borde público albergará más adelante el equilibrador de capa 7 en la dirección IPv4 reservada; el nivel de aplicaciones ejecuta la lógica de negocio en una LAN privada con NICs intercambiables asignadas mediante DHCP; y el clúster relacional se encuentra en una LAN de datos privada con una dirección estática, atendida únicamente por el equilibrador interno de capa 4 construido en la Unidad 3.4. Dado que la LAN de datos nunca está conectada a internet, FinCorp puede argumentar ante sus auditores que la base de datos no puede aceptar una conexión externa por construcción, independientemente de que una regla de firewall sea correcta en un día dado. Cada construcción posterior en este módulo se adjunta a esta forma exacta.

Resumen

La capa de red en la que se encuentra un recurso es el control principal sobre su exposición en IONOS CLOUD, ya que una LAN es privada hasta que se conecta explícitamente a internet y porque los equilibradores de carga administrados y el clúster de Kubernetes no pueden estar envueltos en un cortafuegos o grupo de seguridad. Esto convierte a la segmentación, expresada como la topología de tres niveles (borde público, aplicación privada, datos privados), en la decisión de aislamiento fundamental. La direccionamiento se planifica en torno al /24 predeterminado, con el rango de servicios administrados .2-.9 reservado y direcciones estáticas fijadas para cualquier nodo direccionado por IP. Una dirección IPv4 pública reservada está vinculada a una región, tiene un costo de 5,00 EUR por 30 días, requiere el privilegio Reserve IP Blocks y debe reservarse antes de la estructura de borde que la consume; IPv6 se asigna de forma jerárquica como /56 por VDC, /64 por LAN y /80 por NIC.

Puntos clave:

• Una LAN es privada hasta que se adjunta un elemento de acceso a internet, por lo que la privacidad por defecto es la norma y la exposición se añade de forma deliberada.
• Los cortafuegos de NIC y los NSG se vinculan únicamente a las NIC de los servidores, nunca a la abstracción del ALB/NLB administrado ni al clúster de Kubernetes, por lo que la topología es el control real de aislamiento.
• El /24 de la LAN reserva .2-.9 para servicios administrados y asigna IPs de VM desde .10-.255; la direccionamiento estática corresponde a cualquier nodo direccionado por IP, mientras que el DHCP se aplica en niveles intercambiables.
• Una IPv4 reservada está vinculada a una región, se factura a 5,00 EUR por 30 días, requiere el privilegio Reserve IP Blocks y debe reservarse antes de la estructura de borde que la consume.
• IPv6 es jerárquico (/56 por VDC, /64 por LAN, /80 por NIC, hasta 256 LAN con IPv6 habilitado), pero los servicios de red administrados son solo IPv4.

Terminología importante:

• Bloque IPv4 reservado: una dirección pública estática (o bloque) vinculada a una región, reservada en IP Management, devoluble solo como bloque completo y solo cuando no esté en uso.
• Rango de servicios administrados (.2-.9): las direcciones /24 por LAN reservadas para servicios administrados por la plataforma, que nunca deben asignarse a VM de clientes.
• Doble pila: operación simultánea de IPv4 e IPv6 en una LAN; tenga en cuenta que los servicios de red administrados siguen siendo solo IPv4.

Lectura adicional

• Unidad 3.2: Seguridad de red: Firewall y grupos de seguridad (la capa de reglas dentro de esta topología).
• Unidad 3.4: Equilibrio de carga - Capa 4 (el equilibrador interno frente a la LAN de datos).
• Unidad 3.6: Conectividad híbrida (las pasarelas que se conectan a los bordes y a las rutas de salida).