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 homelabs
Muchos homelabs todavía se ven así:
- Puerto 443 redirigido en el router → apunta a un proxy inverso
- Puerto 80 redirigido → redirige a 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 saliente, cero exposición entrante 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: funcionamiento silencioso 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 de borde, 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 diseñada 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 salientes únicamente hacia el borde de Cloudflare
- Nginx Proxy Manager gestiona el enrutamiento, la terminación SSL y las ACL
- Las redes puente de Docker segmentan el tráfico de borde de las cargas de trabajo internas
- Cero reglas NAT entrantes — el router no tiene idea de que se está sirviendo algo
Esto se sintió inmediatamente 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 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 internas Docker 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 arranque 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 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 activé 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 de 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 el Nombre del Servidor de Origen: example.com mientras se sigue enroutando internamente a https://reverse-proxy:443Eso 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 del túnel y IPs del 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 puente Docker. No desde mi LAN. El control de acceso bloqueaba todo, incluyéndome a mí.
Agregar la subred 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 de red interno 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 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
- Expansibilidad significa que puedes agregar una NIC dedicada o una 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
Qué está ejecutando ahora el ZimaCube 2:
- Cloudflare Tunnel — conexiones cifradas solo de salida, sin puertos abiertos
- Nginx Proxy Manager — proxy inverso, SSL, ACLs
- 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 Cloudflare Tunnel 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 un homelab.
¿Puede el ZimaCube 2 manejar la ejecución de 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 entrada/salida 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 correcto del Servidor de Origen mientras se seguía enrutando 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
Desempaquetado del ZimaCube 2 Pro — El primer NAS que se siente como un objeto de diseño
Descubre el ZimaCube 2 Pro: un NAS compacto y premium que redefine el hardware para homelabs. Con un Intel i5, 10GbE, Thunderbolt 4 y...
Por qué reemplacé los servidores en rack con un ZimaCube 2 — La historia de una evolución en el homelab
ZimaCube 2 reemplaza los ruidosos servidores en rack y las limitadas configuraciones de mini PC con un homelab todo en uno y silencioso para...
Ejecutando Docker, CI/CD y más de 10 servicios autoalojados en el ZimaCube 2
Este enfoque comunitario presenta la prueba completa de infraestructura autoalojada de Michael Luckenbill, pionero de ZimaCube 2. Ejecutando más de 10 contenedores Docker, CI/CD...
