¿Puedes vender esto?

01El encargo

Es común en mi casa que miembros de mi familia, al actualizar celulares o notebooks, me pidan poner a la venta los antiguos para recuperar un poco de dinero con ellos.

Este fue el caso específico de un notebook zenbook del año 2019 que por falta de actualizaciones de windows, polvo y pasta térmica seca ya no funcionaba bien.

En ese momento no sabía exactamente como realizar este tipo de mantenciones. Solo hace un par de años me aventuré en esto y logré revivirlo al abrirlo, limpiarlo, cambiar la pasta térmica y reinstalar el sistema operativo, específicamente con ubuntu server, lo cual, investigando, me abrió un mundo de posibilidades y no solo me permitió empezar un homelab que hasta el día de hoy a seguido creciendo, sino también me obligó a estudiar tecnologías que conocía pero jamas pensé que tendría que implementar (algunas ya he mencionado en otros post), como reglas UFW , VPN por tailscale y también diferentes servicios como SAMBA para la gestión de mis archivos, ssh para las conexiones, jellyfin para mis servicios multimedia, docker y distintos otros servicios que fui agregando y descartando no solo con la intención de aprender, sino también para ir formando en el camino mis reales intenciones para implementar un servidor en casa, lo cual, honestamente no fue claro al inicio mas que por tener un proyecto de fin de semana.

02¿Por qué un servidor propio y no la nube?

Esta es una pregunta trampa, ya que muchos defienden los servicios auto alojados para “alejarse de las manos de las grandes compañías” y otros simplemente lo ven como un buen pasatiempo.

Mi opinión, luego de llevar un par de años en esto cae en el medio, ya que por una parte sí considero importante cuidar a qué cosas le damos y no acceso a las corporaciones de nuestra información personal. También he aprendido que servicios auto alojados en homelabs o servidores privados permiten mucho juego a meter el segmento físico de los equipos, como así mismo de que ciertas funciones son mucho mas efectivas como la seguridad y control del hogar; también que de poder acceder a bóvedas privadas de información que me permiten estar hasta cierto punto mas tranquilo para guardar información personal, como backups de equipos, fotos de viajes y cosas que muchas veces es mejor no compartir por un tema de exposición e incluso poder controlar el tráfico de mi red para detectar ataques externos o crear laboratorios con docker para poder practicar ataques de ciberseguridad en entornos controlados.

No me mal entiendan, sigo usando servicios de la nube porque obviamente son mas accesibles sin tanta necesidad de configuración. El ejemplo mas simple es google con gmail y drive, o mi host de internet donde esta alojada esta web, ya que si lo realizara auto alojado en mi servidor perdería un poco el norte de mi intención con Nabu, el cual es alejarme de los problemas de seguridad que genera el exponer un servidor a la red.

Por otra parte, el problema principal de auto alojar que hoy sufro es la perdida de datos y caídas de servicios que pueda ocurrir si llega a pasarle algo a Nabu, el cual debo estar monitoreando cada tanto porque soy el creador y único técnico que la cuida. Esto es lo que mas me produce satisfacción de tener un homelab, que es una responsabilidad que me permite sentir que tengo el control total del sistema.

03El nombre

Aquí saldrá a la vista mi lado mas geek (muy común en la cultura de un ingeniero informático) que, aunque suene cliché, siempre tendrá relación con videojuegos, películas de ciencia ficción y fantasías que suenan simplemente geniales en papel.

Es por esto que para el nombre de mi servidor pase por muchas ideas, pero como fan de Star Wars empece a buscar nombres relacionados con este universo. Al realizar esto y con un poco de ayuda de la IA llegue al nombre de un Dios mesopotámico llamado Nabu, el cual es el Dios de la escritura. Aquello me pareció perfecto, considerando que el servidor se encargaría de escribir y guardar mi información constantemente.

Cuando leí este nombre me sonó inmediatamente a Naboo, el cual para quien no lo sepa, es el planeta natal de la princesa Padme y del emperador Palpatine en la saga de Star Wars. Además de ser corto, preciso, a la par me sonaba a Jarvis de Iron man tipo “dejame conectarme a Nabu” en caso de necesitarlo.

Es así que nació este compañero que fue y sigue creciendo a través de servicios y nuevos dispositivos que he ido conectando a su al rededor para no solo mejorar sus funciones, si no también probar nuevas configuraciones de arquitectura.

04Qué corría y qué corre actualmente

Actualmente Nabu ya dejó de estar solo en mi ecosistema. Con el tiempo he ido agregando nuevos componentes como un mac m1 que tenía de mis tiempos de universidad, la que hoy sirve para mis laboratorios en docker e inteligencia artificial y me permite correr modelos pequeños, además de una raspberry pi 4 y raspberry pi zero 2 w que uso para generar máquinas vulnerables que ataco desde Nabu, el cual hostea al mismo tiempo un docker con kali linux.

Adicional a estos equipos, también he trabajado con microcontroladores esp32, entre los cuales se comunican con Nabu para cámaras de seguridad (esp32Cam) con grabación tipo CCTV, las que puedo observar en tiempo real desde mi celular a través de Nabu, que levanta un servicio http para poder monitorearlas y grabar dentro de la memoria interna del servidor (Esto es un proyecto mas extenso que tuvo sus propias dificultades, por lo que no profundizaré mucho aquí).

El último upgrade que tengo con este servidor es el uso de un switch para conectar absolutamente todos estos dispositivos, por lo que Nabu, el mac m1, la raspberry pi 4 y mi router lan se comunican directamente a través de este para que Nabu pueda gestionar el tráfico de todos ellos sin tener ruido en medio al usar wifi, permitiendo un ancho de banda mayor tanto para la transferencia de archivos como para el registro de cámaras conectadas al router y que son grabadas en nabu.

Esto no siempre fue así. En un inicio Nabu solo era un notebook con ubuntu server y docker. En ese periodo probé muchas apps y funciones encontradas en foros tipo reddit como SAMBA, Jellyfin, Adguard, Pihole, tailscale, home assistant, tmux, cron, etc. Todas estas fueron trabajadas en docker, pero luego que se fueran agregando nuevas arquitectura al sistema comencé en ese momento a delegar funciones como ya mencioné con docker que se fue al Mac, piHole en una raspberry pi zero 2 w o las máquinas de kali linux en dispositivos USB live con persistencias.

05Uno de los muchos problemas

El camino de implementación tuvo varios obstáculos, entre ellos y los mas importantes que creo tener que mencionar es el acceso externo con tailscale y la interconectividad entre dispositivos con reglas UFW.

Como Nabu funciona como un servidor cerrado desde el cual gestiono el resto de recursos, el primer objetivo fue poder conectarme desde cualquier parte del mundo. Esto con la intención de poder acceder a mis archivos y máquinas por ejemplo si me encontraba de viaje. Es por ello que se tuvo que buscar soluciones y llegué a un servicio gratuito llamado Tailscale, el que te permite generar una red VPN entre tus dispositivos con un switch dentro de la app, posibilitando conectarte o desconectarte de ella, en el cual puedo tener en mis equipos y al encenderlo me conecto a esta red con Nabu como nodo de salida, es decir, puedo elegir o no el pasar mi tráfico a través de Nabu. Lo anterior admite controlar todo lo que entra o sale de la red de forma segura sin tener que preocuparme de fugas de información que puedan tener los equipos entre ellos. Para esto tuve que instalar ssh en nabu y configurarlo con claves de acceso públicas para darle una capa extra de seguridad al acceso.

Por otra parte tenemos la conexión entre dispositivos, lo que surge a raíz de los laboratorios simulados que hice a partir de Nabu y que muchas veces debían simular máquinas que no tienen acceso directo a otras y están bloqueadas por firewall para no ser vistas por nadie mas que ciertos accesos, poniendo así a prueba máquinas y laboratorios que me permiten practicar el movimiento lateral entre servicios. Es por esto que comencé a colocar reglas UFW (de las cuales en su momento no tenía ni la menor idea que existían), para empezar a bloquear accesos entre máquinas, solo pasando por Nabu, generando así cadenas de acceso que podría ir mutando y generando nuevos laboratorios.

Estas implementaciones de por sí tuvieron sus propios desafíos, pero el tema que no pude solucionar enseguida y me obligó a buscar soluciones fue la pelea entre las dos tarjetas de red. Hoy Nabu funciona con dos interfaces. Una hacia mi red LAN privada, donde viven los laboratorios y las cámaras y otra hacia la red del ISP. Al principio las dos competían por la salida por defecto, porque el router de la LAN también ofrecía su propia puerta de enlace por DHCP. El resultado fue que mi homelab estuvo un buen periodo sin acceso desde el exterior: Tailscale simplemente no llegaba a Nabu, porque el tráfico intentaba salir por la interfaz equivocada, la que no tiene internet. La solución no estaba en el firewall, sino un paso antes, en la configuración de red. Con netplan le indiqué a la interfaz de la LAN que tomara su dirección IP normalmente, pero que no instalara una ruta por defecto. Así quedó una sola salida a internet, la del ISP, y Tailscale volvió a funcionar. La interfaz de la LAN siguió haciendo su trabajo dentro de la red aislada, pero dejó de pelear por algo que no le correspondía. Donde sí entró UFW fue después, para decidir qué servicio se ve por cuál interfaz. No es lo mismo resolver por dónde sale el tráfico que resolver quién puede tocar cada servicio: lo primero es enrutamiento, lo segundo es firewall, y me costó un rato entender que estaba mezclando dos capas distintas.

06To do list

Es cierto que este proyecto es mucho mas extenso que lo que se puede explicar en un post como este, no solo por las tecnologías usadas, si no también por las muchas cosas que se me pueden pasar por alto al ser el único individuo configurándolos, pero aún así soy consciente de que hay mejoras claras pendientes, no solo a nivel hardware, si no también de cosas básicas (y muy importantes) en este caso como backups en caso de que la memoria de Nabu muera o que algún sistema se rompa. Esto es lo mas urgente en mi lista y como es un proyecto de bajo costo, sigo buscando opciones para solucionarlo.

El tema de fuentes de energía en caso de cortes de luz es algo que no me urge, ya que actualmente al ser equipos de sobremesa como notebooks los que tienen la información, en caso de cortes de luz la energía de los propios equipos me dan tiempo a guardar cambios y apagarlos correctamente.

07Esto me enseñó

Si algo me enseñó Nabu es que un servidor casero no se diseña de entrada, se va formando en el camino. Yo no sabía para qué lo quería cuando le instalé Ubuntu Server: solo quería ver si el notebook todavía servía para algo. El propósito fue apareciendo con el uso, probando servicios que después saqué, delegando funciones a otros equipos cuando el proyecto creció y descubriendo que la mitad de las cosas que instalé por curiosidad no las necesitaba. Esa parte, la de sacar en vez de agregar, terminó siendo tan importante como la otra. Lo segundo es menos cómodo: Tener tu propia nube significa que la disponibilidad deja de ser algo que viene incluido y pasa a ser una decisión tuya. Nadie va a reiniciar un servicio caído a las tres de la mañana, nadie tiene una copia de tus archivos por si el disco muere y cuando algo se rompe no hay a quién escribirle. Eso, que suena a desventaja, es justamente lo que me obligó a aprender redes de verdad, a entender por qué el tráfico salía por donde no debía y a preocuparme de respaldos antes de necesitarlos. Ningún curso me habría enseñado eso tan rápido como un homelab que dejó de responder mientras yo estaba lejos de casa.