Problema

Los entusiastas de homelab suelen iniciar con un único nodo físico y, con el tiempo, añaden más servicios hasta que el hardware original se queda corto. Cuando el crecimiento implica múltiples ubicaciones físicas (por ejemplo, una laptop en casa y varios PCs en otro país), aparecen tres retos recurrentes:

  1. Gestión centralizada: Necesidad de controlar VMs/LXCs desde una única consola sin saltar de red en red.
  2. Resolución de nombres: Mantener subdomains coherentes (p.ej. nextcloud.home.example.com) cuando los servicios se despliegan en diferentes rangos de IP.
  3. Seguridad y conectividad: Garantizar que el tráfico entre sitios sea privado, fiable y que el acceso remoto siga siendo sencillo.

Si se ignoran, el homelab se vuelve una colección de máquinas aisladas, difícil de monitorizar y propensa a fallos de DNS o de acceso.

Causa

Los síntomas típicos (latencia alta, DNS que no resuelve, necesidad de abrir puertos en cada router) provienen de combinaciones habituales:

  • Redes aisladas: Cada sitio tiene su propio rango LAN (192.168.x.0/24) sin ruta entre ellos. Sin túnel, los servicios sólo son accesibles localmente.
  • DNS estático: Usar registros A fijos en Cloudflare o en un servidor interno obliga a actualizar manualmente cada cambio de IP pública o de NAT.
  • Acceso remoto ad‑hoc: Conexiones SSH directas o port‑forwarding disperso generan superficies de ataque y dificultan la automatización.
  • Falta de orquestación: Cada nodo ejecuta su propio Proxmox o Docker sin coordinación, lo que lleva a duplicación de configuraciones y a pérdida de visibilidad global.

Solución

Una arquitectura basada en Tailscale (o cualquier solución de WireGuard‑based mesh) combinada con DNS dinámico y un reverse proxy centralizado resuelve los tres problemas a la vez. El flujo recomendado es:

  1. Crear una red mesh con Tailscale

    • Instala el cliente Tailscale en cada nodo (laptop, PCs, servidores).
    • Habilita subnet routes para los rangos LAN locales que quieras exponer (p.ej. 192.168.10.0/24 en la casa, 192.168.20.0/24 en la oficina).
    • Marca un nodo como exit node opcional si deseas salir a internet a través de la red de confianza.

  2. Unificar la resolución DNS

    • Usa Cloudflare DNS con un registro CNAME que apunte a un subdomain gestionado por Tailscale Magic DNS.
    • Configura *.home.example.com como CNAME a *.ts.net (el dominio asignado por Tailscale).
    • En cada contenedor/VM, registra su nombre interno en el archivo /etc/hosts o en el DNS interno de Tailscale (tailscale up --advertise-routes=... --accept-dns=true).

  3. Centralizar el reverse proxy

    • Mantén Nginx Proxy Manager (NPM) o Traefik en un nodo que siempre esté online (por ejemplo, la laptop).
    • Cada nuevo servicio registra su backend mediante una etiqueta Docker (traefik.http.routers.<service>.rule=Host(\service.home.example.com`)`).
    • El proxy se comunica con los backends a través de la IP de Tailscale, por lo que la ubicación física es irrelevante.

  4. Orquestar VMs/LXCs con Proxmox en modo cluster opcional

    • Si la latencia entre sitios lo permite (≤ 50 ms), crea un cluster Proxmox usando la red Tailscale como interfaz de clúster.
    • De lo contrario, mantén clusters independientes y usa Ansible o Terraform para aplicar configuraciones idénticas en ambos lados.

  5. Automatizar la creación de subdomains

    • Un pequeño script (Python/Bash) que invoque la API de Cloudflare para crear/actualizar registros A/CNAME cada vez que despliegues un nuevo contenedor.
    • Integra el script en el pipeline CI/CD de tu homelab (GitHub Actions, GitLab CI) para que el DNS nunca quede desincronizado.

Paso a paso de la configuración básica

1. Instalación de Tailscale

# En cada nodo (Ubuntu/Debian)
curl -fsSL https://tailscale.com/install.sh | sh
sudo tailscale up --accept-dns=true --advertise-routes=192.168.10.0/24,192.168.20.0/24

El primer nodo que ejecuta tailscale up sin --advertise-routes será el control node (el que gestiona la UI). Marca el nodo que siempre está encendido como exit node si lo deseas:

sudo tailscale up --exit-node=<IP_TAILSCALE_DEL_NODO>

2. Configuración de DNS en Cloudflare

  1. Accede a Cloudflare → DNS.
  2. Crea un registro CNAME llamado *.home.example.com → *.ts.net.
  3. En Network → DNS habilita Proxy status para ocultar la IP real.

3. Nginx Proxy Manager (Docker)

docker run -d \
  --name npm \
  -p 80:80 -p 443:443 \
  -v /opt/npm/data:/data \
  -v /opt/npm/letsencrypt:/etc/letsencrypt \
  jc21/nginx-proxy-manager

En la UI de NPM, crea un Proxy Host para cada servicio:

  • Domain Names: service.home.example.com
  • Scheme: http (o https si el backend lo soporta)
  • Forward Hostname / IP: 100.101.102.103 (IP Tailscale del backend)
  • Forward Port: 8080 (puerto del contenedor)

4. Script de creación de DNS (Bash)

#!/usr/bin/env bash
# Parámetros: $1 = subdomain, $2 = IP interna (Tailscale)
CF_API="https://api.cloudflare.com/client/v4"
ZONE_ID="YOUR_ZONE_ID"
TOKEN="YOUR_API_TOKEN"

curl -s -X POST "$CF_API/zones/$ZONE_ID/dns_records" \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  --data '{
    "type":"CNAME",
    "name":"'"$1"'.home.example.com",
    "content":"'"$2"'.ts.net",
    "ttl":1,
    "proxied":true
  }'

Ejecuta el script después de lanzar un nuevo contenedor:

./add_dns.sh immich 100.101.102.104

Cuándo aplicar esta solución

Aplica cuando:

  • Tienes al menos dos nodos en redes distintas y necesitas acceso transparente entre ellos.
  • Deseas exponer servicios bajo subdomains sin abrir puertos en cada router.
  • Quieres centralizar la gestión de certificados y reverse proxy.
  • La latencia entre sitios es aceptable para la administración remota (≤ 100 ms).

No aplica si:

  • Solo dispones de una única ubicación física; la complejidad extra de Tailscale no se justifica.
  • Necesitas rendimiento de red de más de 1 Gbps entre nodos (WireGuard puede ser limitante en hardware muy antiguo).
  • Tu ISP bloquea tráfico UDP/4500, impidiendo la creación del túnel WireGuard.

Código

# Configuración completa de un nodo Proxmox para usar la red Tailscale como interfaz de clúster
apt-get update && apt-get install -y tailscale
systemctl enable tailscaled
tailscale up --accept-dns=true --advertise-routes=192.168.20.0/24

# Añadir el nodo al cluster (ejecutar en el nodo maestro)
pvecm add <IP_TAILSCALE_DEL_NUEVO_NODO>

Verificación

  1. Conectividad Tailscale
    • En cualquier nodo, ejecuta tailscale status. Deberías ver todas las máquinas con sus IP 100.x.x.x.
  2. Resolución DNS
    • dig immich.home.example.com @1.1.1.1. El ANSWER SECTION debe devolver un CNAME que apunte a la IP Tailscale del backend.
  3. Acceso vía proxy
    • Abre https://immich.home.example.com en el navegador. El certificado debe ser válido (Let’s Encrypt) y la página debe cargar sin saltar a la IP pública.
  4. Failover
    • Desconecta la red local del nodo secundario y verifica que el proxy sigue respondiendo (el tráfico sigue fluyendo por Tailscale).

Notas adicionales

  • Persistencia de rutas: Añade --advertise-routes a tailscale up en /etc/default/tailscaled para que sobreviva a reinicios.
  • Seguridad: Usa ACL de Tailscale para limitar qué máquinas pueden acceder a cada subred. Por ejemplo, permite que solo el nodo de gestión acceda a la LAN de la oficina.
  • Monitoreo: Integra Uptime Kuma o Prometheus con métricas de tailscaled (/metrics endpoint) para detectar caídas de túnel.
  • Backup de DNS: Exporta la zona de Cloudflare periódicamente (cloudflare-cli zones export) para evitar pérdida de registros al crear muchos subdomains.
  • Escalabilidad: Si el número de servicios supera 50, considera migrar a Traefik con su dynamic configuration en lugar de NPM, pues maneja mejor grandes cantidades de rutas.

Con esta arquitectura, puedes añadir PCs en cualquier parte del mundo, asignarles subdomains coherentes y seguir gestionando todo desde tu laptop principal, sin abrir puertos innecesarios y manteniendo una capa de seguridad basada en VPN y DNS controlado. La clave está en centralizar la capa de red (Tailscale) y la capa de enrutamiento HTTP (reverse proxy), dejando que los nodos individuales se enfoquen exclusivamente en ejecutar los contenedores o VMs que realmente necesitas.