Mi homelab híbrido 2026: la arquitectura técnica completa

En el post anterior conté la historia de cómo terminé con un homelab híbrido entre Hetzner y mi casa, y por qué abandoné el lab de OpenShift para quedarme con algo mucho más simple. Este post es la otra mitad: cómo queda armado técnicamente hoy, con diagrama, direccionamiento, y el porqué de cada decisión. Es una guía pensada para que la adaptes a tu propio setup, así que todas las direcciones IP y rangos que vas a ver son de ejemplo, no los reales.

Vista general de la arquitectura

Dos sitios, una sola red lógica. En casa vive el hardware que quiero tocar físicamente y lo que necesita estar cerca de mis dispositivos; en Hetzner vive lo que necesito disponible 24/7 sin depender de mi conexión doméstica. Todo se conecta con un túnel WireGuard site-to-site permanente.

Direccionamiento: la primera decisión que hay que tomar bien

Antes de levantar el túnel, decide tus rangos de IP con cuidado. La regla es simple pero se rompe fácil: la red de casa y la red del proveedor no pueden solaparse. Si ambas usan, por ejemplo, 10.0.0.0/24 por defecto (muy común en routers de fábrica), el túnel “funciona” pero el enrutamiento se vuelve ambiguo y vas a perder horas sin saber por qué un paquete no llega.

Lo que a mí me funcionó como esquema mental (con rangos de ejemplo):

• Red de casa: un /16 propio (ej. 10.10.0.0/16), con VLANs como subredes dentro de ese rango.
• Red privada del proveedor: su propio /16 (ej. 10.20.0.0/16), normalmente ya la trae así por defecto.
• Red del túnel en sí: una subred pequeña y dedicada solo para los extremos de la VPN (ej. 172.16.0.0/24), separada de las dos anteriores.

Con eso, cada lado anuncia por WireGuard únicamente las subredes que le interesan al otro, no el rango completo. Menos superficie expuesta y las tablas de rutas se leen mucho más claras cuando algo falla.

Por qué VPN site-to-site y no exponer servicios directamente

La alternativa obvia a todo esto sería abrir puertos y exponer cada servicio a Internet con su propio reverse proxy y TLS. Funciona, pero cambia por completo el modelo de amenaza: cada servicio expuesto es una superficie de ataque independiente que hay que parchear, monitorizar y asegurar por separado.

Con un túnel site-to-site, en cambio, solo hay un punto de entrada entre los dos mundos (la VM de VPN), y todo lo demás vive en red privada, inalcanzable desde fuera aunque tenga un bug. Lo que sí quiero exponer al público lo pongo detrás de un proxy inverso explícito; todo lo demás se queda hablando solo por el túnel.

Por qué separar Servicios de Bases de datos en VMs distintas

Podría meter todo en una sola VM grande, pero separar cómputo stateless (la VM de Servicios, con Docker Compose) de lo que tiene estado (la VM de Bases de datos) tiene ventajas concretas:

• Puedo reiniciar o incluso recrear la VM de Servicios sin tocar los datos.
• Los backups y snapshots de la VM de bases de datos se pueden programar con una política distinta (más frecuente, con verificación de integridad) que los de la VM de servicios.
• Si algo en Servicios se pone a consumir CPU o memoria de forma descontrolada, no compite por recursos con las bases de datos.

Por qué 2 nodos de Kubernetes y no 3

En el post anterior conté cómo el lab de OpenShift se me cayó por la latencia entre dos servidores físicos que, en teoría, estaban en el mismo datacenter. Esa lección cambió cómo pienso el clúster actual: al ser VMs dentro de la misma red privada del proveedor (no hosts físicos distintos), la latencia entre nodos deja de ser un problema real. Con 2 nodos tengo margen para actualizar uno sin caerme del todo, y no necesito la resiliencia de un quórum de 3 para cargas que no son críticas al segundo. Si algún día corro algo que sí lo requiera, escalar a 3 es cuestión de levantar una VM más, no de rediseñar la red.

Casa: por qué mantener hardware físico en vez de irse 100 % cloud

Servidor de virtualización (Home Assistant + DNS)

Este es el caso más claro para quedarse en casa: Home Assistant necesita hablar por red local con bombillas, sensores y demás dispositivos IoT, muchos de los cuales ni siquiera salen a Internet. Meter eso en la nube significaría abrir túneles hacia cada dispositivo doméstico, justo lo contrario de lo que quiero. Los resolvers DNS locales, por la misma razón: quiero que mi red siga resolviendo nombres aunque el túnel hacia Hetzner esté caído.

Servidor de IA con GPU

Una GPU decente alquilada en la nube se cobra por hora y, si la usas de forma recurrente para experimentar, el costo mensual supera rápido al de comprar el hardware una sola vez. Tenerla en casa también evita mover datasets grandes de un lado a otro cada vez que quiero correr algo.

NAS de backups

El NAS no corre servicios, solo guarda copias: backups de las VMs de casa y una réplica de lo importante que vive en Hetzner. La idea es la regla clásica 3-2-1: al menos tres copias de los datos, en dos medios distintos, con una copia fuera del sitio principal. En mi caso, “fuera del sitio” funciona en ambas direcciones, el NAS respalda Hetzner y, a la vez, es el backup local de lo que vive en casa.

Problemas típicos al montar esto (y cómo diagnosticarlos)

Esta es la parte que ningún proveedor documenta bien, porque depende de la combinación específica de hipervisor, red privada y firewall que uses. Como guía general:

• Todo funciona por ping pero las conexiones reales se cuelgan a medias. Casi siempre es una ruta asimétrica: el tráfico de ida pasa por un camino y el de vuelta por otro, y el firewall descarta el paquete de retorno porque “no reconoce” la conexión. Busca la opción de tu firewall para no filtrar tráfico de retorno en la misma interfaz, o revisa las rutas de ambos lados con una captura de paquetes.
• El DHCP funciona pero el tráfico grande se corta. Sospecha del MTU. Las redes privadas de los proveedores cloud suelen usar un MTU menor a 1500 (por el overhead de su propio encapsulado); si tus VMs siguen en 1500 por defecto, vas a ver fallos intermitentes solo con paquetes grandes. Iguala el MTU de tus interfaces al de la red privada del proveedor.
• La resolución DNS falla solo desde las VMs del proveedor. Algunos proveedores bloquean las consultas DNS salientes hacia resolvers externos como medida antiabuso. Revisa la documentación de tu proveedor y, si aplica, apunta tus VMs a sus resolvers internos.
• Latencia alta entre nodos que deberían estar cerca. Si vas a montar algo sensible a la latencia (un clúster con quórum, por ejemplo) sobre servidores físicos distintos, mide la latencia real entre ellos antes de comprometerte con la arquitectura. “Mismo datacenter” no siempre significa “misma latencia interna”.
• La VPN se cae y no te enteras hasta que algo falla. Monta una alerta simple (un ping periódico entre los dos extremos del túnel) para saber que se cayó antes de que lo notes por un servicio caído.

Recomendaciones si vas a montar algo parecido

• Define tus rangos de IP en un documento antes de tocar nada. Cambiarlos después, con servicios ya corriendo, es mucho más doloroso que planearlo bien desde el inicio.
• Empieza con lo mínimo indispensable (una VPN y un par de VMs) antes de comprometerte con arquitecturas grandes. Es más fácil escalar algo simple que simplificar algo sobredimensionado.
• Separa lo stateful de lo stateless en máquinas distintas, aunque sea al principio solo una VM de cada tipo.
• Todo lo que dependa de tu red local (domótica, DNS local) debería seguir funcionando si se cae el túnel hacia el proveedor. Diseña para ese fallo, no lo ignores.
• Aplica la regla 3-2-1 de backups desde el primer día, no cuando ya perdiste algo.
• Documenta cada solución de red que encuentres. Los problemas de MTU, DNS y rutas asimétricas vuelven a aparecer cada vez que agregas una pieza nueva.

Conclusión

La versión técnica de esta historia es, en el fondo, la misma lección del post anterior: la complejidad debería ganarse su lugar, no asumirse por defecto. Terminé con una arquitectura híbrida bastante más simple de lo que empecé a construir, y cada pieza que quedó (las 5 VMs en Hetzner, los dos servidores físicos, el NAS) está ahí porque resuelve algo concreto que no resolvía mejor en otro sitio.