Cómo convertí el ZimaCube 2 en un controlador de ingreso de confianza cero para todo mi homelab
Tu homelab tiene una puerta principal. Si eres como la mayoría de los autoalojadores, esa puerta principal es un reenvío de puerto en tu router — y está completamente abierta.
Pasé semanas reconstruyendo el mío. El resultado: una capa de ingreso de nivel producción funcionando completamente en un ZimaCube 2. Sin puertos abiertos en mi router. Sin servidores de origen accesibles públicamente. TLS de extremo a extremo en cada conexión. Todo ello funcionando silenciosamente junto a mi televisor.
Aquí está exactamente cómo lo construí, qué se rompió en el camino y por qué el ZimaCube 2 resultó ser la plataforma perfecta para el trabajo.
El problema con el ingreso tradicional en Homelab
Muchos homelabs todavía se ven así:
- Puerto 443 reenviado en el router → apunta a un proxy inverso
- Puerto 80 reenviado → redirige al 443
- Los servicios son accesibles directamente si conoces la IP
- La infraestructura de origen está a un escaneo de puertos de ser descubierta
Esto crea problemas reales. Puertos de ingreso expuestos públicamente. Servidores de origen accesibles directamente. Interfaces de administración que responden antes de la autenticación. Incluso con HTTPS, la infraestructura sigue siendo visible — y la visibilidad invita al reconocimiento.
Quería un modelo completamente diferente. Algo más cercano a cómo la infraestructura moderna en la nube maneja el ingreso: confianza solo de salida, cero exposición de entrada y túneles cifrados que ocultan el origen.
Por qué el ZimaCube 2
Este tipo de arquitectura exige un conjunto específico de características de hardware. No potencia bruta — confiabilidad, flexibilidad y silencio.
El ZimaCube 2 cumplió con todos los requisitos:
|
Siempre Encendido: Operación silenciosa 24/7. La capa de ingreso debe funcionar continuamente — el diseño térmico del ZC2 permite que lo haga sin dominar la habitación. |
Doble 2.5GbE: Una interfaz para la red perimetral, otra para la interna. La segmentación del tráfico comienza en la capa física, no solo en Docker. | Docker Nativo: Almacenamiento NVMe para una E/S rápida de contenedores. Múltiples redes puente no saturan el sistema. La plataforma fue construida para esto. |
En este punto, el ZimaCube 2 se ha convertido efectivamente en cuatro cosas en una sola máquina: un host Docker, una plataforma de proxy inverso, una capa de ingreso y un dispositivo de infraestructura centralizada. Para el autoalojamiento moderno, esa combinación es extremadamente práctica.
La nueva arquitectura
En lugar de abrir puertos en mi router, el nuevo diseño funciona así:
- Cloudflare Tunnel crea conexiones cifradas solo salientes hacia el edge de Cloudflare
- Nginx Proxy Manager maneja el enrutamiento, terminación SSL y ACLs
- Redes puente Docker segmentan el tráfico edge de las cargas internas
- Reglas NAT de entrada cero — el router no tiene idea de que se está sirviendo algo
Esto inmediatamente se sintió más cercano a la arquitectura moderna de ingreso en la nube que al autoalojamiento tradicional con reenvío de puertos.
Segmentación de red Docker: Edge ≠ Interna
Uno de los cambios más importantes fue separar el tráfico usando redes puente de Docker.
docker network create \
--subnet 172.x.x.x/24 \
edge
La red edge lleva exactamente dos contenedores: Cloudflare Tunnel y Nginx Proxy Manager. Eso es todo. Las aplicaciones viven en redes Docker internas separadas — completamente aisladas de la capa de ingreso.
El ZimaCube 2 maneja esta segmentación de forma limpia. Múltiples redes puente no generan sobrecarga de rendimiento en la plataforma, y el almacenamiento NVMe asegura que el inicio de contenedores y el I/O de red se mantengan rápidos incluso cuando la topología de red se vuelve más compleja.
El problema de TLS que casi me rompe
Esto terminó siendo la lección de ingeniería más interesante de todo el proyecto.
La configuración parecía sencilla al principio. HTTP entre Cloudflare Tunnel y Nginx Proxy Manager funcionó de inmediato:
http://reverse-proxy → ✅ Funciona
Así que habilité HTTPS.
https://reverse-proxy → ❌ Falla
El certificado era válido. La fecha de expiración estaba bien. La cadena de confianza estaba correcta. Todo parecía correcto — y sin embargo HTTPS se negaba a conectar.
El problema real fue la validación del nombre de host TLS.
El certificado fue emitido para mis dominios públicos (example.com, app.example.com). Pero Cloudflare Tunnel se conectaba internamente al proxy inverso — un nombre de host Docker que no coincidía con nada en el certificado. La discrepancia del nombre de host causó que la validación TLS fallara silenciosamente.
La solución: configurar Cloudflare Tunnel con Nombre del Servidor de Origen: example.com mientras se sigue enroutando internamente a https://reverse-proxy:443. Eso preservó el transporte cifrado, la validación adecuada del nombre de host y la verificación completa de TLS — sin desactivar ninguna comprobación de seguridad.
Este es el tipo de lección que solo aprendes construyendo.
ACLs y la lección sobre las rutas del tráfico de infraestructura
Una lección operativa que aprendí muy rápido: los proxies inversos a menudo ven IPs del puente Docker, IPs de túnel y IPs de proxy interno en lugar de la IP original del cliente.
Aprendí esto de la manera difícil cuando accidentalmente me bloqueé fuera de Nginx Proxy Manager.
Configuré un ACL para permitir solo mi subred LAN (192.168.x.x/24). La lógica parecía correcta: solo los dispositivos de mi red doméstica deberían acceder al panel de administración.
NPM en realidad estaba viendo tráfico desde la red del puente Docker. No desde mi LAN. El control de acceso bloqueó todo, incluyéndome a mí.
Agregar la subred de Docker a la lista de permitidos lo resolvió de inmediato. Pero fue un recordatorio muy real de que las rutas del tráfico de infraestructura a menudo son diferentes de lo que asumimos en papel.
Por qué esta arquitectura importa en el ZimaCube 2
Hay una razón por la que esta pila funciona tan bien específicamente en el ZC2:
- Doble 2.5GbE significa que la capa de ingreso tiene ancho de banda dedicado — tu tráfico interno de red no compite con los servicios expuestos a internet
- Almacenamiento NVMe garantiza una red rápida para contenedores — el rendimiento de la red puente no se ve limitado por una E/S de disco lenta
- Funcionamiento silencioso y siempre activo significa que la capa de ingreso funciona 24/7 en un espacio habitable — no en un rack de sótano
- Plataforma nativa Docker con suficiente capacidad para ejecutar el túnel, proxy inverso, motor ACL y todos tus servicios simultáneamente
- Escalabilidad significa que puedes agregar una NIC dedicada o tarjeta aceleradora más adelante si tus necesidades de red crecen
El ZimaCube 2 no solo aloja estos servicios. Es la plataforma adecuada para ellos.
La pila final
Lo que está ejecutándose ahora en el ZimaCube 2:
- Túnel Cloudflare — conexiones cifradas solo salientes, sin puertos abiertos
- Nginx Proxy Manager — proxy inverso, SSL, listas de control de acceso (ACL)
- Redes puente Docker — tráfico segmentado de borde vs. interno
- TLS de extremo a extremo — cifrado desde el cliente hasta el origen, sin texto plano en ningún lugar
- Origen oculto — nada responde en una IP pública
Sigue siendo un homelab. Pero el modelo operativo ahora se parece mucho más a la ingeniería moderna de ingreso que al autoalojamiento tradicional con reenvío de puertos.
La mayor conclusión de este proyecto: el autoalojamiento moderno requiere cada vez más el mismo pensamiento sobre ingreso, redes y límites de confianza que se encuentra en la infraestructura de producción. Y el hardware debe estar a la altura: silencioso, confiable, en red y siempre encendido.
El ZimaCube 2 ofrece exactamente eso.
Construye tu propio homelab de confianza cero con ZimaCube 2 →
Preguntas frecuentes
¿Qué es un túnel de Cloudflare y por qué lo usaría en mi ZimaCube 2?
Un Cloudflare Tunnel crea una conexión cifrada solo de salida desde tu ZimaCube 2 hacia la red de borde de Cloudflare. En lugar de abrir puertos en tu router (lo que expone tu infraestructura a internet), todo el tráfico fluye a través de este túnel cifrado. Tu servidor de origen — el ZimaCube 2 — permanece completamente oculto de la vista pública.
¿Necesito abrir algún puerto en mi router para esta configuración?
No. Ese es el punto. Cloudflare Tunnel solo realiza conexiones salientes. Tu router no necesita ninguna regla de reenvío de puerto. Esto elimina el vector de ataque más común en la red de homelab.
¿Puede el ZimaCube 2 manejar ejecutar un proxy inverso y todos mis servicios al mismo tiempo?
Sí. Michael ZC2 ejecuta Cloudflare Tunnel, Nginx Proxy Manager y más de 10 contenedores Docker simultáneamente — todo mientras mantiene un funcionamiento silencioso y fresco. Los puertos duales 2.5GbE y el almacenamiento NVMe aseguran que la red y la E/S de contenedores no se conviertan en cuellos de botella.
¿Por qué importa la segmentación de red en Docker?
Si todos los contenedores comparten la misma red, un servicio comprometido le da al atacante acceso a todo lo demás. Al colocar solo Cloudflare Tunnel y Nginx Proxy Manager en una red de "borde" (y mantener las aplicaciones en redes internas separadas), creas un límite controlado entre el tráfico público y tus servicios privados.
¿Cuál fue el problema de incompatibilidad del nombre de host TLS?
Cuando Cloudflare Tunnel se conectó a Nginx Proxy Manager internamente usando un nombre de host Docker como reverse-proxy, el certificado TLS — que fue emitido para un dominio público como example.com — no coincidía. La solución fue configurar Cloudflare Tunnel para usar el Nombre del Servidor de Origen correcto mientras se seguía enroutando al nombre de host interno de Docker. Esto preservó el cifrado completo sin desactivar la validación.
¿Cómo se compara el hardware de red del ZimaCube 2 con un NAS estándar para este caso de uso?
La mayoría de los dispositivos NAS para consumidores vienen con un solo puerto Ethernet gigabit. El ZimaCube 2 tiene dos puertos 2.5GbE, lo que significa que puedes dedicar una interfaz al tráfico de borde (Cloudflare + proxy inverso) y la otra a servicios internos. Esta separación a nivel físico es algo que no puedes lograr con hardware de una sola NIC.
Productos recomendados
Centro de Campañas Zima
Más para leer
Cómo prueba SjslTech ZimaOS como sistema operativo de servidor doméstico fácil de usar para principiantes
Descubre cómo ZimaOS convierte el primer arranque en una nube privada práctica con copias de seguridad de las fotos del teléfono y Jellyfin, manteniendo...
Mes Nacional de la Preparación: crea un servidor de información de emergencia sin conexión para tu familia
Prepara la información digital de tu familia para cortes de servicio y emergencias. Aprende a crear un servidor de información sin conexión para mapas,...
Día de Internet: Cómo crear tu propia nube personal
Celebra el Día de Internet 2026 creando tu propia nube personal para archivos, fotos, copias de seguridad, contenido multimedia y aplicaciones autoalojadas. Aprende a...
