Muchos laboratorios caseros / home lab / servidor casero terminan acumulando hardware potente que apenas se usa a pleno rendimiento. Sin embargo, a veces el componente más determinante de toda la infraestructura no es el servidor con más núcleos ni el NAS con más bahías, sino una placa diminuta que llevaba meses camino del trastero. Este es el caso de un usuario que rescató una Raspberry Pi Zero original, la más modesta de toda la familia, y acabó convirtiéndola en la pieza que mantiene accesible el resto de su red desde fuera de casa. El motivo no fue capricho técnico, sino una limitación muy común entre los operadores actuales: la imposibilidad de abrir puertos en el router debido al CGNAT. La solución pasó por instalar Tailscale directamente en el sistema operativo, sin depender de contenedores, y configurar la placa como enrutador de subred. El resultado es una lección clara sobre proporcionalidad: no todo servicio doméstico necesita hardware sobrado, y a veces el componente más barato del cajón es el que evita más quebraderos de cabeza.

El problema de fondo: cuando el router no puede abrir puertos

El origen de todo esto es una limitación cada vez más habitual entre los operadores de banda ancha: el Carrier-Grade NAT, conocido como CGNAT. Se trata de una capa adicional de traducción de direcciones que el propio proveedor añade en su red para repartir un número reducido de direcciones IPv4 públicas entre cientos o miles de clientes. En la práctica, el router doméstico ya no recibe una IP pública propia, sino una dirección interna del operador, normalmente dentro del rango reservado 100.64.0.0/10 según especifica la RFC 6598. Esto significa que abrir un puerto en el router para exponer un servicio hacia Internet deja de tener efecto, porque el tráfico nunca llega a atravesar una única IP controlable por el usuario. Quien depende de servicios autoalojados —desde un gestor de contraseñas hasta un servidor multimedia— se encuentra con un obstáculo estructural, no con un simple error de configuración. La alternativa tradicional pasa por contratar por una pequeña cuota mensual que te saquen del CGNAT o  alquilar una máquina en la nube con IP pública fija y usarla como pasarela para un servidor WireGuard, lo cual añade coste mensual y una pieza más que mantener. El protagonista de esta historia, como nos cuenta aquí, decidió evitar ese gasto recurriendo a una red superpuesta que no depende de tener IP pública en ningún extremo.

Tailscale sin contenedores: por qué compilar en lugar de usar Docker

La primera aproximación fue la habitual en cualquier laboratorio casero: desplegar los servicios mediante contenedores Docker. Sin embargo, la memoria disponible en esta placa —apenas 512 MB de RAM— hizo que el enfoque no resultara viable para un uso continuado, ya que el motor de contenedores añade una sobrecarga que en equipos tan limitados se nota de inmediato. La solución pasó por instalar Tailscale de forma nativa, compilando o instalando el paquete directamente sobre el sistema operativo en lugar de depender de una imagen. Esta vía redujo el consumo de memoria y permitió que el servicio funcionase de forma estable las veinticuatro horas del día. Tailscale se apoya en el protocolo WireGuard para establecer túneles cifrados punto a punto entre dispositivos, y su documentación oficial detalla cómo cualquier nodo de la red puede actuar como enrutador de subred, es decir, como pasarela que anuncia rutas hacia una red física completa sin necesidad de instalar el cliente en cada dispositivo. Tras registrar el equipo en la consola de Tailscale, los comandos empleados fueron relativamente sencillos: activar la aceptación de rutas con sudo tailscale set --accept-routes y anunciar el segmento local con sudo tailscale set --advertise-routes=192.168.0.0/24. A partir de ese momento, cualquier otro dispositivo del mismo tailnet —la red virtual que forma el conjunto de equipos con Tailscale instalado— puede alcanzar toda la red doméstica como si estuviera físicamente conectado a ella, sin necesidad de exponer un solo puerto hacia el exterior ni depender de la IP pública del router.

La protagonista: una Raspberry Pi Zero que nadie echaba de menos

Conviene detenerse en el hardware que hace posible todo esto, porque su modestia es precisamente el argumento central de la historia. La Raspberry Pi Zero original monta un procesador Broadcom BCM2835 de un solo núcleo a 1 GHz, acompañado de 512 MB de RAM LPDDR2, sin apenas margen para tareas exigentes. Se trata de la misma familia de silicio que estrenó la Raspberry Pi original, aunque con el reloj ligeramente elevado. Su consumo es minúsculo: entre 0,5 y 0,7 vatios en condiciones normales, lo que equivale a unos 100-140 mA a 5,09 V, una cifra que permite mantenerla encendida de forma permanente sin que suponga un gasto eléctrico apreciable. Salió al mercado en 2015 con un precio de lanzamiento de apenas 5 dólares, y aunque hoy resulta más difícil de encontrar a ese importe, sigue siendo la placa más económica de todo el catálogo de la fundación. Frente a ella, la Raspberry Pi Zero 2 W ofrece un salto notable en potencia gracias a su procesador de cuatro núcleos, pero el encarecimiento reciente de la memoria RAM ha hecho que su precio se dispare, dejando a la Zero original como una opción más razonable para cargas ligeras como esta. Para un servicio que apenas mueve paquetes de enrutamiento y mantiene un túnel cifrado activo, la diferencia de rendimiento entre ambas apenas se nota, mientras que la diferencia de precio sí.

Reflexiones adicionales

Esta historia deja varias enseñanzas aplicables a cualquier laboratorio casero, por modesto que sea. La primera es que el hardware sobrante rara vez está realmente obsoleto; simplemente estaba asignado a la tarea equivocada. La segunda es que conviene revisar qué procesos consumen más recursos de los necesarios: sustituir un contenedor por un binario instalado de forma nativa puede marcar la diferencia entre un servicio estable y uno que se reinicia constantemente por falta de memoria. La tercera, quizá la más práctica para quienes sufren restricciones de CGNAT en España, es que no siempre hace falta contratar una IP pública adicional o depender de un proveedor externo: una red superpuesta bien configurada puede resolver el acceso remoto sin coste recurrente. Conviene matizar que este tipo de montaje no sustituye a una solución de alta disponibilidad; si la placa falla, el acceso remoto a la red doméstica se pierde hasta que se repare o sustituya, así que quien dependa de ello de forma crítica debería contemplar un plan de respaldo, aunque sea tan sencillo como guardar una segunda tarjeta microSD con la configuración ya lista. En cualquier caso, el ejemplo sirve como recordatorio de que en un laboratorio doméstico no siempre gana la placa más cara, sino la que mejor encaja con la tarea concreta que tiene que resolver.