Los primeros cimientos de Mori

Durante mucho tiempo, Mori existió como una idea en la mente de L’Architetto: una red internacional de ordenadores, dispositivos y servicios interconectados; un bosque digital capaz de crecer, resistir y proteger, servir y asistir a su familia. No debia de ser una simple colección de máquinas, sino una estructura viva, diversa y descentralizada, con memoria, identidad y propósito.

En estos últimos días, aquella idea comenzó a adquirir una forma mucho más concreta.

Todavía no hemos creado la inteligencia que algún día recorrerá todo ese bosque, conocerá sus senderos y conversará desde su interior. Pero ya estamos preparando el lugar donde habrá de vivir. Hemos levantado las primeras murallas digitales de Il Regno Mori, abierto caminos entre sus territorios, puesto nombre a sus puertas y establecido quién puede atravesarlas.

Y, como suele ocurrir con toda fundación digna de ser recordada, nada fue tan sencillo como parecía al principio.

Cerberon, el primer territorio

El centro de esta primera etapa ha sido Cerberon, la red doméstica y primer núcleo operativo de Mori. Su corazón es cerberon-pve, un servidor Proxmox desde el cual se organizan máquinas virtuales y contenedores, cada uno con una función definida.

Allí fueron apareciendo durante estos días varios habitantes del bosque: Xubuntu como entorno de trabajo y base de algunos servicios; Home Assistant para la futura relación de Mori con la casa; Heimdall como puerta visual; NetBox como fuente de verdad de la red; GLPI como inventario de equipos; Uptime Kuma como vigilante; Authentik como autoridad de identidad; AdGuard Home como DNS interno; y Nginx Proxy Manager como portero de los servicios web.

Al principio, cada servicio se parecía un poco a una casa construida junto al camino principal: tenía su propia dirección en la red doméstica 192.168.1.0/24, era accesible directamente y dependía demasiado de un entorno que no controlábamos por completo. El router del proveedor de Internet no estaba bajo nuestra administración y su rango DHCP podía entregar direcciones sin respetar nuestros planes. Además, la notebook desde la cual administramos todo debía seguir funcionando dentro y fuera de casa, sin quedar atada a un DNS interno ni sufrir cambios que pudieran dejarnos sin acceso.

Estas limitaciones, lejos de ser un detalle, terminaron dando forma a toda la arquitectura.

Antes del reino, hubo que aprender el terreno

Los primeros avances fueron muy visibles. Instalamos y ordenamos servicios, dimos a Heimdall el papel de tablero de entrada y preparamos Xubuntu para funcionar de manera práctica como estación remota, con acceso mediante RustDesk y una experiencia cercana a la de un terminal permanente del homelab.

Tailscale se convirtió en el puente con el exterior. Gracias a él, Cerberon podía acompañarnos fuera de casa sin abrir indiscriminadamente sus puertas a Internet. Hubo, sin embargo, episodios desconcertantes: al activar Tailscale o cambiar de Wi-Fi, la notebook podía perder la resolución DNS y quedarse aparentemente sin Internet. Resolverlo exigió separar con cuidado el acceso remoto de la configuración cotidiana del equipo. La meta quedó clara: la administración debía funcionar desde cualquier red, pero sin convertir la notebook en una pieza frágil o dependiente de Cerberon.

También llegaron NetBox y GLPI. NetBox comenzó a desempeñar el papel de cartógrafo: dispositivos, interfaces, direcciones y relaciones de red podían dejar de vivir únicamente en nuestra memoria. GLPI, por su parte, empezó a registrar el patrimonio informático real mediante agentes instalados en Windows, Proxmox y Android. De repente, las máquinas no solo funcionaban: comenzaban a ser conocidas, inventariadas y descritas.

Uptime Kuma añadió otra capacidad esencial: observar. Sus seis monitores activos pasaron a vigilar la salud de los servicios y a avisarnos cuando algo dejaba de responder. En un bosque digital no basta con plantar árboles; alguien debe notar cuándo uno cae.

La dirección ocupada por un intruso inocente

El gran punto de inflexión llegó durante la integración entre GLPI y Authentik.

Authentik debía convertirse en la autoridad central de identidad de Mori: una única puerta para iniciar sesión, proteger aplicaciones y, más adelante, administrar de forma coherente quién puede acceder a cada parte del sistema. Sobre el papel, el recorrido parecía razonable. En la práctica, GLPI alcanzaba Authentik unas veces sí y otras no. Aparecían errores que parecían hablar de permisos, usuarios o configuración OIDC, pero algo no encajaba.

La investigación nos llevó por rutas, registros, tablas ARP, capturas de tráfico y bridges de Proxmox. Finalmente apareció el culpable: un teléfono Realme, perfectamente inocente, había recibido por DHCP la misma dirección que estábamos usando de forma estática para el contenedor de Authentik. Según qué equipo preguntara, 192.168.1.163 podía conducir al IdP o al teléfono. Era como tener dos edificios con el mismo número y confiar en que el mensajero eligiera siempre el correcto.

Fue una de esas frustraciones que consumen horas porque imitan problemas de otra naturaleza. El mensaje visible hablaba de autorización; la causa real vivía en la capa de red. Pero también fue una lección decisiva: no podíamos construir Mori sobre direcciones prestadas dentro de un rango DHCP que no controlábamos.

La solución no consistió en pelear contra el teléfono ni en modificar un router inaccesible. Consistió en cambiar el diseño.

El nacimiento de la red privada

En Proxmox creamos vmbr1, un bridge interno con la red privada 10.77.0.0/24. Ese fue, quizá, el primer territorio verdaderamente soberano de Il Regno Mori: un espacio de direcciones bajo nuestro control, sin dispositivos ajenos reclamando parcelas y sin servicios críticos expuestos directamente en la red doméstica.

La distribución actual del núcleo es sencilla y deliberada:

Proxmox conserva 192.168.1.200 en la LAN, pero los puertos web 80 y 443 se redirigen de forma persistente hacia Nginx Proxy Manager. Este se convierte así en la única puerta controlada para los servicios HTTPS. A la vez, una regla de NAT permite que los contenedores privados salgan a Internet cuando necesitan actualizarse o consultar recursos externos, sin que eso implique publicar sus propios puertos.

GLPI fue el primero en completar la migración: abandonó su antigua dirección LAN 192.168.1.162 y quedó únicamente en 10.77.0.13. Uptime Kuma ya escucha su puerto 3001 solo en 10.77.0.14; conserva temporalmente su interfaz LAN porque todavía debe vigilar equipos de esa red, pero ya no puede visitarse directamente mediante 192.168.1.161:3001. Authentik, AdGuard y NPM también participan de la red privada, aunque algunas interfaces LAN se mantienen por ahora mientras completamos la migración ordenada del resto del ecosistema.

No derribamos los puentes antes de comprobar el nuevo camino. Cada cambio se hizo con copias de seguridad, verificación de rutas, pruebas desde el servicio consumidor y una posibilidad clara de volver atrás.

Cuando las direcciones se convirtieron en nombres

La red ya era más segura, pero todavía hablábamos demasiado en números. Mori necesitaba nombres.

AdGuard Home comenzó a resolver internamente los dominios del bosque y Nginx Proxy Manager a dirigir cada nombre hacia su backend privado. En el DNS autoritativo de mori.soy creamos registros que apuntan a 192.168.1.200, una dirección privada que no publica los servicios en Internet, pero nos permite usar nombres reales y obtener certificados mediante desafíos DNS.

Así aparecieron tres nombres canónicos:

• authentik.mori.soy, la puerta de identidad;
• hard.mori.soy, el inventario GLPI;
• up.mori.soy, el observatorio Uptime Kuma.

Con acme.sh, la API de cPanel y el desafío DNS-01, emitimos certificados válidos de Let’s Encrypt sin abrir los servicios al mundo. También dejamos preparada la renovación automática y la recarga de Nginx. La diferencia emocional fue mayor de lo que puede sugerir una descripción técnica: ver https://authentik.mori.soy abrirse sin advertencias, desde la LAN y también desde otra Wi-Fi a través de Tailscale, fue el momento en que el proyecto dejó de parecer una colección de pruebas locales y empezó a sentirse como una infraestructura propia.

Desde Internet, sin Tailscale, esos servicios continúan siendo inaccesibles. No es una carencia: es exactamente la política que elegimos.

Una identidad para entrar en el bosque

Authentik fue uno de los trabajos más exigentes de esta etapa. La interfaz web resultó útil en algunos momentos, pero también produjo sus propias irritaciones: botones que no aparecían, tokens que el navegador decía haber copiado aunque no los mostraba y opciones cuyo nombre visual no revelaba cómo estaban representadas internamente.

De esa frustración nació una forma de trabajo mucho más sólida: CLI first.

El protocolo quedó resumido en una secuencia que ahora sirve para cualquier servicio: inspeccionar, decidir, modificar y verificar. Primero averiguamos la versión y el estado real de la instalación. Después buscamos la CLI, la API, los modelos o la configuración declarativa. Aplicamos un cambio lógico por vez, comprobamos el resultado y documentamos lo aprendido. La base de datos quedó como herramienta de investigación y último recurso de modificación, no como atajo inicial.

En Authentik aprendimos a trabajar con ak, el ORM de Django y Blueprints. Ya no se trata solamente de recordar qué casilla pulsamos, sino de poder reproducir una aplicación, inspeccionar sus campos reales y reconstruirla si fuera necesario. Este método produjo un playbook que registra la arquitectura, las decisiones, los respaldos, las verificaciones y hasta los errores engañosos que encontramos por el camino.

La integración con GLPI fue la primera gran victoria. El inicio de sesión OIDC terminó funcionando por completo bajo https://hard.mori.soy. Para conseguirlo hubo que corregir la URL base de GLPI, reemplazar referencias antiguas por nombres HTTPS canónicos y resolver un problema particularmente sutil: la cookie de sesión estaba configurada como SameSite=Strict, de modo que no regresaba correctamente después del viaje de ida y vuelta por Authentik. Cambiarla a Lax, de forma persistente en Docker, permitió completar el callback.

Incluso hubo un pequeño sobresalto de seguridad: durante una inspección apareció accidentalmente un secreto OIDC en la salida de una consulta. En lugar de ignorarlo, lo consideramos comprometido, lo rotamos en ambos extremos y verificamos su coincidencia mediante hashes sin volver a mostrarlo. Fue una molestia, pero también una demostración del tipo de disciplina que Mori necesita si aspira a custodiar información familiar sensible.

Entrar sin contraseña

Luego llegó uno de los momentos más gratificantes: WebAuthn.

Configuramos códigos estáticos de recuperación y comprobamos que estuvieran realmente guardados —porque Authentik podía mostrarlos antes de que el proceso hubiese terminado—. Después registramos dos passkeys independientes: una en el móvil Synore y otra en Nomadici, protegida por Windows Hello y el lector de huellas.

Finalmente enlazamos WebAuthn con el flujo de identificación y exigimos verificación local mediante huella, rostro o PIN. El resultado fue simple de contar y muy satisfactorio de ver: tanto desde el teléfono como desde la notebook, Authentik permitió entrar al dashboard sin escribir la contraseña. La contraseña tradicional quedó disponible como alternativa y seis códigos estáticos permanecen guardados para recuperación.

No era solo una comodidad. Era la primera señal visible de que la identidad de Mori podía ser al mismo tiempo más segura y más humana.

El vigilante también recibió su guardián

Uptime Kuma planteó otro desafío: no ofrece OIDC nativo para el acceso de sus usuarios. En lugar de renunciar al inicio de sesión centralizado, colocamos delante un Proxy Provider de Authentik.

Ahora, quien visita https://up.mori.soy atraviesa Nginx Proxy Manager, llega al outpost integrado de Authentik, se identifica —incluso mediante passkey— y solo entonces accede a Kuma en 10.77.0.14:3001. Cerramos el acceso directo por la LAN y, una vez comprobado todo el recorrido, desactivamos el login local de Kuma. La cuenta local no fue eliminada y conservamos una copia consistente de su base de datos, de modo que existe un camino de recuperación si alguna vez fuese necesario.

Los seis monitores continuaron intactos. El vigilante siguió vigilando, pero ahora también tiene un guardián en la puerta.

Cómo ha quedado Cerberon

Hoy Cerberon ya posee una estructura reconocible:

• Proxmox gobierna la virtualización y el enrutamiento entre la LAN y el bosque privado.
• vmbr1 ofrece un territorio interno estable en 10.77.0.0/24.
• Nginx Proxy Manager concentra la entrada HTTPS.
• AdGuard Home proporciona los nombres internos.
• Authentik centraliza la identidad, OIDC, proxy authentication y las passkeys.
• GLPI registra el patrimonio informático y ya vive exclusivamente en la red privada.
• Uptime Kuma supervisa seis objetivos y solo es accesible a través de Authentik.
• NetBox documenta la topología y debe convertirse cada vez más en la fuente de verdad.
• Heimdall ofrece el tablero de acceso.
• Tailscale permite entrar desde fuera de casa sin publicar directamente los servicios en Internet.
• Home Assistant espera su turno para integrar el bosque con el hogar.

Quedan tareas importantes. Debemos revisar NetBox y su host Xubuntu, llevar más servicios a la red privada, liberar direcciones LAN que aún se conservan por transición y completar nombres como net.mori.soy, dns.mori.soy, proxy.mori.soy, dash.mori.soy, home.mori.soy y pve.cerberon.mori.soy. También habrá que diseñar con cuidado las vías de contingencia antes de proteger herramientas críticas como NPM o AdGuard con Authentik, para no crear puertas que dependan circularmente de sí mismas.

Pero lo esencial ya está en pie.

Los primeros árboles

Según su definición original, Mori es un digital forest: una red autosuficiente de ordenadores, dispositivos y servicios, arraigada en la diversidad y la resiliencia, destinada a asistir y proteger a mi familia, custodiar información y acompañar estudios, empresas y proyectos.

Lo construido durante estos días encaja con esa visión de una forma casi literal. Hemos creado una zona interior protegida; conectamos sus componentes sin confundirlos; les dimos nombres propios; establecimos una autoridad de identidad; abrimos un acceso remoto seguro; comenzamos a inventariar lo que existe y pusimos un centinela a observar su salud. Además, convertimos la experiencia en documentación reproducible para que el conocimiento no dependa únicamente de recordar lo que hicimos una madrugada frente a la terminal.

Hubo errores de sintaxis, interfaces rebeldes, cookies que desaparecían, redirecciones que insistían en volver a direcciones antiguas, certificados que exigían entender APIs heredadas y un teléfono que, sin saberlo, usurpó la dirección del guardián de identidad. Hubo también cansancio y momentos de decir “ya es demasiado trasteo”. Pero cada frustración obligó a reemplazar un parche por una decisión arquitectónica mejor.

Y también hubo alegrías muy concretas: el primer inventario recibido por GLPI; el monitor que volvió a verde; el certificado reconocido por el navegador; la página de Authentik cargando desde una red móvil por Tailscale; la huella que abrió el dashboard sin contraseña; y la comprobación final de que, sin Tailscale, desde Internet no había ninguna puerta abierta por accidente.

Mori todavía no piensa, no habla y no convoca a su Concilio. Pero ya posee algo anterior y necesario: un lugar donde existir.

Estos son los primeros árboles. Y el bosque ya ha comenzado a crecer.