Documento actualizado de arquitectura de red del clúster.
Diseñado para entender el modelo, no para memorizar direcciones IP.
El sistema NO es una red plana.
Está dividido en múltiples planos con funciones diferenciadas:
Encima de la segmentación física existen mecanismos lógicos:
El objetivo del diseño es claro:
| VLAN | Red IP | Función |
|---|---|---|
| VLAN 10 | 192.168.0.0/24 | Administración |
| VLAN 20 | 192.168.200.0/22 | Servicios |
| VLAN 30 | 192.168.3.0/24 | Almacenamiento |
| VLAN 40 | 192.168.4.0/24 | Red interna nodos / clúster |
Cada nodo del clúster dispone de múltiples interfaces o subinterfaces:
La VLAN 20 es la red de exposición a clientes y usuarios finales.
El tráfico de almacenamiento nunca circula por la red de servicios.
Sobre las VLAN se construyen bridges para agrupar funciones:
MetalLB publica servicios en el bridge correspondiente.
| Tipo de servicio | Red utilizada |
|---|---|
| Paneles de gestión | br-admin |
| Aplicaciones internas | br-servicios |
| Servicios publicados Internet | br-admin (NAT firewall) |
Esto permite decidir explícitamente en qué plano vive cada aplicación.
El clúster utiliza múltiples IngressClass separadas.
No existe un único punto de entrada.
| IngressClass | Plano de red | Uso principal |
|---|---|---|
| nginx | br-admin | Servicios internos de gestión |
| nginx-srv | br-servicios | Aplicaciones accesibles por VPN |
| nginx-inet | br-admin (expuesto por NAT) | Servicios públicos en Internet |
Beneficios:
Todos los Ingress obtienen certificados automáticamente mediante cert-manager.
Según el caso:
No se gestionan certificados manualmente.
La seguridad TLS es parte del diseño base.
El sistema utiliza un modelo de Split DNS.
| Resolver | Red asociada | Usuarios que lo usan |
|---|---|---|
| coredns-admin | 192.168.0.0/24 | Administración |
| coredns-srv | 192.168.200.0/22 | Usuarios de servicios/VPN |
Esto implica que:
Existe un DNS público externo (Dynu u otro proveedor).
Flujo desde Internet:
El DNS interno nunca es accesible desde Internet.
Ya no existe una única VPN de administración y otra de servicios.
Actualmente existen múltiples instancias de WireGuard, desplegadas por entorno o aplicación.
Ejemplos típicos:
Cada instancia define:
El acceso se define por diseño, no por confianza implícita.
Caso: Usuario de una VPN de servicios accede a una aplicación.
En ningún momento atraviesa el plano de administración.
La seguridad no depende únicamente del firewall.
Se basa en:
Cada capa limita el impacto de un fallo o compromiso.
Después de leer este documento debe comprender:
No se trata de memorizar IPs.
Se trata de entender el modelo arquitectónico.
Arquitectura segmentada por diseño. Seguridad por separación. Control por capas.