En mi edificio la conexión a Internet forma parte de los servicios comunes. Además del WiFi disponible en las zonas comunes, cada vivienda tiene una toma Ethernet desde la que puede conectarse directamente a la red general, sin contratar una línea propia ni instalar un módem individual. El sistema es muy cómodo, pero tiene un inconveniente para quienes queremos cacharrear: no puedo administrar el router del edificio. Así que me he comprado uno.
En mi piso de Madrid monté un nodo de Bitcoin, sobre todo para entender mejor cómo funciona la Red. Tras mudarme a México desmonté la infraestructura y me traje parte del hardware:
- una Raspberry Pi 5;
- un SSD de 1 TB;
- un SSD de 2 TB;
- una tarjeta microSD de 64 GB
El SSD de 1 TB, que al principio parecía más que suficiente, terminó quedándose pequeño. La cadena de bloques de Bitcoin ya se acerca a los 800 GB y todavía hay que reservar espacio para los índices y su crecimiento futuro. Por eso compré después el de 2 TB. La Raspberry también ha empezado a mostrar sus límites. Descargar y verificar la cadena completa puede llevar varias semanas y, aunque sigue siendo una máquina muy útil para servicios ligeros, ya no me parece el mejor lugar para concentrar todo el proyecto. He decidido añadir un mini-PC: un MINISFORUM UM870 Slim con un Ryzen 7 8745H, 32 GB de memoria y un SSD interno de 512 GB. Todavía no lo tengo; está de camino. Además de ejecutar Bitcoin Core, quiero utilizarlo para Jellyfin y para probar modelos de lenguaje locales. No pretendo entrenar modelos ni montar un pequeño OpenAI en el salón, sino ejecutar modelos ya existentes y utilizarlos con documentos propios mediante un sistema RAG. Más adelante volveré con detalle sobre cada una de estas piezas.
Antes de instalar nada, sin embargo, necesitaba construir el lugar en el que todas estas máquinas van a convivir: una red local propia.
El nuevo router
He comprado un Steren COM-870+ y he conectado la toma Ethernet de la vivienda a su puerto WAN. El router obtiene automáticamente conexión desde la red del edificio y la utiliza como salida a Internet. Al otro lado crea una red distinta, administrada por mí:
Internet
│
Red compartida del edificio
│
Toma Ethernet de la vivienda
│
Puerto WAN del router propio
│
Red LAN
├── Ordenador
├── Raspberry Pi 5
├── Mini-PC
└── Otros dispositivos
La infraestructura del edificio sigue proporcionando Internet, pero deja de decidir cómo se comunican mis dispositivos. Desde la perspectiva de mi LAN, la red del edificio pasa a formar parte del exterior.
WAN y LAN
El router mantiene dos redes separadas. En la interfaz WAN se comporta como cualquier otro dispositivo conectado al edificio: solicita automáticamente una dirección y utiliza la puerta de enlace que recibe. No necesito configurar PPPoE ni introducir un usuario y una contraseña.
En la interfaz LAN crea una subred privada con un rango distinto al de la red exterior. El propio router actúa como puerta de enlace, servidor DHCP y punto de acceso inalámbrico para todos mis dispositivos. Los equipos de uso cotidiano pueden recibir direcciones automáticamente. Las máquinas del servidor, en cambio, tendrán reservas DHCP para conservar siempre la misma IP. De esta forma podré acceder a la Raspberry y al mini-PC sin tener que buscar cada vez qué dirección les ha asignado el router.
Una red detrás de otra
Al colocar mi router detrás del del edificio aparece una configuración de doble NAT.
El primer router traduce el tráfico entre la red del edificio e Internet. Mi router vuelve a traducirlo entre su interfaz WAN y mi LAN. Esto puede complicar la apertura tradicional de puertos, ya que no controlo el primer router, pero tampoco tengo intención de exponer directamente las máquinas de casa. Los servicios internos permanecerán accesibles únicamente desde la LAN. Para entrar desde fuera podré utilizar Tailscale, Tor o túneles específicos, según el caso. Mi idea es almacenar aquí mi propia web, y para ello podré utilizar Cloudflare Tunnel sin necesidad de abrir puertos en el router del edificio.
El doble NAT no es la solución más elegante, pero me permite construir una red propia sin modificar una infraestructura que no controlo.
La arquitectura del servidor
La Raspberry Pi 5 funcionará como equipo auxiliar de la red. En ella instalaré servicios ligeros que conviene mantener disponibles aunque el servidor principal esté apagado o reiniciándose:
- Pi-hole para filtrar DNS y publicidad;
- Unbound como resolvedor DNS;
- Tailscale para acceder remotamente a la red;
- Uptime Kuma para supervisar los servicios;
- DNS local para identificar las máquinas por su nombre.
El mini-PC concentrará las tareas que requieren más potencia. Tendrá 32 GB de memoria y un SSD interno de 512 GB, que utilizaré para el sistema operativo, Docker, el modelo de lenguaje local y los documentos relacionados con este entorno. El SSD externo de 1 TB estará dedicado a la biblioteca de Jellyfin. El SSD de 2 TB se reservará para Bitcoin Core, la cadena de bloques, chainstate, electrs y un explorador de bloques. Más adelante podría añadir otros servicios relacionados, pero esa parte tendrá su propia entrada.
La arquitectura prevista será, por tanto:
Router
│
├── Raspberry Pi 5
│ ├── Pi-hole
│ ├── Unbound
│ ├── Tailscale
│ ├── Uptime Kuma
│ └── DNS local
│
└── Mini-PC
├── SSD interno de 512 GB
│ ├── Sistema operativo
│ ├── Docker
│ ├── LLM local
│ └── RAG y documentos
│
├── SSD externo de 1 TB
│ └── Jellyfin
│
└── SSD externo de 2 TB
├── Bitcoin Core
├── electrs
└── Explorador de bloques
En la próxima entrada empezaré a configurar la Raspberry Pi y los primeros servicios de red.