En los posts sobre cloud-first y soberanía digital hablé de datos, infraestructura y cognición. Pero antes de hablar de DNS, reverse proxy o identidad hay una pregunta más básica: ¿cómo llegas a tu red desde fuera?

Un homelab sin acceso remoto controlado es una colección de servicios en una LAN que solo existe cuando estás en casa. La VPN (o su equivalente moderno) es la primera capa práctica de soberanía de red: decides quién entra, por qué túnel y bajo qué coordinación.

No escribo esto para decir que debes exponer servicios a internet con port forward y rezar. Escribo para situar OpenVPN, WireGuard y Tailscale en el marco RPS y en el eje puente/ancla, con la misma pregunta de siempre: ¿qué estás pagando cuando eliges?

La pregunta antes del login

Es tentador empezar el homelab por identidad, montar un IdP, federar Google, proteger Grafana con OIDC. Pero la identidad responde a “¿quién eres?”; la VPN responde a “¿estás en mi red?”.

Son capas distintas. Confundirlas lleva a montar Zitadel o Keycloak cuando el problema real era llegar al NAS desde el móvil sin abrir puertos. O a abrir el 443 de todo a internet cuando bastaba un túnel privado.

En un homelab personal, el orden sensato suele ser:

1. Acceso a la red (este post)
2. Resolución de nombres (DNS interno; un post posterior)
3. Terminación TLS y enrutado HTTP (reverse proxy)
4. Identidad de aplicación (IdP, forward auth; ver issue sobre Zitadel)

Saltarse el paso 1 y publicar servicios directamente es piedra de la peor clase: rápido hoy, superficie de ataque mañana.

Dos dimensiones otra vez

Como en identidad o en cloud, conviene separar:

Una VPN puede ser piedra operativa (poca fricción al configurar) y ancla fuerte: si el plano de coordinación no es tuyo. Tailscale es el ejemplo habitual.

OpenVPN: papel histórico

OpenVPN fue durante años la respuesta por defecto al acceso remoto self-hosted. Certificados X.509, topologías tun/tap, archivos .ovpn, renovaciones, a veces un servidor pesado y configuraciones que nadie quiere tocar seis meses después.

En el marco RPS es papel legacy: pagas complejidad inicial y mantenimiento continuo a cambio de un protocolo maduro, ampliamente soportado y entendido por firewalls corporativos. No es elegante. Pero durante mucho tiempo fue realista cuando el fallo (no poder entrar al servidor de backup) era caro.

Hoy sigue apareciendo por inercia: tutoriales antiguos, routers con cliente integrado, empresas que estandarizaron en él hace una década. Mantenerlo por costumbre cuando WireGuard o un mesh moderno cubren tu caso es el mismo patrón que cloud-first: pagar complejidad que el problema ya no pide.

OpenVPN self-hosted en tu VPS o en casa suele ser puente si controlas certificados y configuración: mañana puedes migrar clientes. Pero el coste operativo es alto para un homelab de una persona.

WireGuard: piedra moderna en el protocolo

WireGuard cambió el punto de partida. Diseño mínimo, criptografía actual, implementación en el kernel Linux, código pequeño (escrito en C, con herramientas de usuario en Go) y rendimiento excelente en hardware modesto.

En RPS es piedra en el sentido bueno: hace una cosa, la hace bien, con poco ruido. No te da MagicDNS, panel de administración ni identidad de dispositivos; te da túneles punto a punto o hub-and-spoke con claves estáticas o rotación que tú diseñas.

Ventajas en homelab:

• Footprint mínimo; corre en una Raspberry o en un contenedor sin drama.
• Configuración explícita: sabes qué peer es qué máquina.
• Puente fuerte: protocolo abierto, implementaciones múltiples, sin vendor detrás del túnel en sí.

Coste:

• Tú gestionas IP internas, DNS (si quieres nombres en lugar de IPs), alta disponibilidad y onboarding de cada dispositivo nuevo.
• Sin capa de coordinación, escalar a diez dispositivos es tedioso; a treinta, ya es un mini-proyecto.

WireGuard puro es la opción honesta cuando quieres máximo control y mínima dependencia, y aceptas pagar fricción en cada cliente nuevo.

Tailscale: piedra operativa, ancla en coordinación

Tailscale construye una red mesh sobre WireGuard. Instalas el cliente, autenticas el dispositivo con tu identidad (Google, GitHub, Microsoft, etc.), y de repente tus máquinas se ven entre sí (con MagicDNS, ACLs opcionales, subnet routers, exit nodes) sin abrir puertos en el router.

La gran ventaja: sin tocar el router

La ventaja operativa que más peso tiene en un homelab real no es técnica sino humana: no hace falta redirigir puertos en el router.

Durante años los tutoriales de homelab asumían que sabías entrar en la interfaz del router, crear una regla NAT, apuntar el 443 o el 1194 a la IP de tu servidor y rezar para que tu IP pública no cambiara. Hoy esa operativa es poco familiar para mucha gente, sobre todo para quien llega por primera vez con una Raspberry Pi o un mini PC y quiere ver si el hobby encaja antes de invertir meses.

Pero el problema va más allá de la falta de práctica. Hoy no basta con redirigir puertos. Una parte enorme de conexiones domésticas (fibra y móvil, en España y en buena parte de Europa) está detrás de CG-NAT (Carrier-Grade NAT): tu router no tiene una IPv4 pública propia; comparte dirección con otros clientes del operador. Desde fuera no hay forma fiable de alcanzar tu homelab aunque configures el port forward perfecto.

La salida clásica es llamar a tu compañía y pedir que te saquen del CG-NAT, o que te asignen IPv4 pública. A veces funciona; a veces implica cambiar de tarifa, esperar, discutir con soporte de primer nivel que no sabe lo que es CG-NAT, o descubrir que tu operador simplemente no lo ofrece. Es una fricción desmedida para alguien que solo quiere consultar su NAS desde el tren.

Tailscale (y en general un mesh que negocia salida por relé o por hole punching) evita ese callejón sin entrar. No sustituye la soberanía de tener IP pública; elimina el prerrequisito de tenerla para que el homelab sea útil.

Continuidad del hobby frente a pureza arquitectónica

Personalmente prefiero aceptar la ancla de coordinación de Tailscale a poner en riesgo la continuidad del homelab, sobre todo para recién llegados.

Un homelab al que no puedes acceder desde cualquier sitio pierde la mitad de su utilidad: deja de ser tu nube personal y pasa a ser un aparato que solo existe cuando estás en el salón. La curva de abandono es predecible: frustración, meses sin tocarlo, y esa Raspberry Pi o mini PC acaba en un cajón, hardware sano, proyecto muerto.

Eso no invalida WireGuard manual ni Headscale cuando tengas el contexto y la paciencia. Pero exigir port forwarding o salir del CG-NAT antes de que el hobby demuestre valor es pedir pureza arquitectónica a cambio de probabilidad real de fracaso. En el marco RPS, Tailscale es piedra operativa con ancla consciente; abandonar el homelab por no poder entrar es piedra mal entendida: ahorraste dependencia y perdiste el sistema entero.

MagicDNS, HTTPS y una pila más corta

La segunda gran ventaja aparece cuando empiezas a nombrar y servir cosas, no solo a conectarte.

MagicDNS resuelve los nombres de tus máquinas dentro de la tailnet (minipc.tail12345.ts.net, por ejemplo) sin montar DynDNS, DuckDNS ni un cron que actualice tu IP pública cada vez que el router reinicia. Para acceso entre dispositivos de tu red privada mesh, ese problema desaparece.

Y en cierto grado desaparece también la ceremonia de Certbot, Let’s Encrypt y renovaciones a mano. Tailscale puede emitir certificados TLS válidos para los nombres de tu tailnet (con Let’s Encrypt por debajo, pero gestionado por ellos) de forma que tus servicios responden en HTTPS sin que tú operes la PKI. Combinado con Tailscale Serve (servir HTTP/HTTPS desde el propio nodo), la fricción baja otro escalón.

Eso abre casos que en un homelab clásico parecían overkill montar solo para probar. Por ejemplo, desplegar una PWA en un servidor de casa e instalarla en el navegador del móvil o del portátil sin pelear con certificados autofirmados. Los navegadores exigen un origen seguro para tratar una web como instalable: hace falta HTTPS y un dominio reconocible. No vale la IP de la LAN (192.168.1.50), ni HTTP plano, ni el aviso “tu conexión no es privada” que el usuario medio no sabe aceptar. Con un nombre *.ts.net y TLS gestionado, ese requisito se cumple dentro de la tailnet con poca fricción.

El dominio y el certificado los presta Tailscale, no tú: comodidad operativa (otra cara de la ancla). El día que quieras un dominio propio en internet público, un reverse proxy con Caddy y Let’s Encrypt propio seguirá teniendo sentido; de eso hablaré en un post posterior. Pero para servicios solo tuyos, alcanzables desde tus dispositivos, la combinación MagicDNS + HTTPS de tailnet evita una pila entera que durante años fue el ritual de iniciación del homelab.

Para un homelab personal es piedra operativa: el problema de “quiero entrar desde el móvil” se resuelve en minutos. No montas PKI. No editas wg0.conf a mano por cada portátil.

Pero el plano de coordinación (quién emite las claves, quién mantiene el mapa de la red) vive en servidores de Tailscale Inc., salvo que uses un plan que te permita self-host del control plane (no es el caso típico del homelab gratuito).

Eso es ancla consciente:

• Dependes de su servicio de coordinación y de sus políticas.
• MagicDNS y los nombres *.ts.net son convenientes (y evitan DynDNS y, en la tailnet, buena parte del baile con Certbot), pero no son tu DNS soberano; son un atajo que funciona mientras aceptes el modelo.
• La autenticación inicial del dispositivo suele pasar por un proveedor social o SSO externo, otra capa de delegación que conviene nombrar.

No lo digo para demonizar Tailscale. Lo uso en mi propio homelab como capa de acceso antes de montar identidad de aplicación con Zitadel. Es la decisión correcta cuando el coste de no tener acceso remoto supera al coste de delegar coordinación. Pero es ancla: conviene saberlo.

Headscale: tijeras con puente

Headscale es una reimplementación abierta del servidor de coordinación de Tailscale. Misma idea (mesh sobre WireGuard), pero tú operas el plano de control.

En RPS es tijeras: máximo potencial de soberanía dentro del modelo mesh (sin depender de los servidores de coordinación de Tailscale Inc.), a cambio de más complejidad y más riesgo operativo. Actualizas el servidor, depuras por qué un nodo no se registra, te responsabilizas de backups y disponibilidad. Es construir tu propia plataforma de coordinación manteniendo el protocolo y el cliente que ya conoces.

En reversibilidad sigue siendo puente: el túnel sigue siendo WireGuard estándar; recuperas independencia del SaaS sin abandonar el modelo mental del mesh. Pero el precio en tiempo y atención es de tijeras, no de papel.

Tiene sentido cuando la ancla de Tailscale deja de ser aceptable (por política, jurisdicción o principio) y ya validaste que el mesh te aporta valor. Saltar a Headscale el primer día, sin haber tenido acceso remoto estable, suele ser tijeras mal aplicadas: complejidad de plataforma propia antes de que el hobby demuestre para qué sirve.

Comparación en una tabla

Puentes, anclas y exposición pública

Abrir puertos en el router (443 de Plex, 8123 de Home Assistant, lo que sea) es exposición directa, no una VPN. Y en muchos hogares ni siquiera es viable sin salir antes del CG-NAT. A veces se combina con Cloudflare Tunnel u otros relays; el patrón es el mismo: tu servicio queda alcanzable desde internet sin que el visitante pase por tu red privada.

Eso puede ser piedra legítima para un servicio concreto. Pero como estrategia por defecto para todo el homelab reproduce el cloud-first en miniatura: comodidad ahora, superficie de ataque y dependencia de terceros (DNS, CDN, certificados) después.

Una VPN o mesh privado no sustituye al reverse proxy ni al IdP. Te da perímetro: primero entras a la red, luego resuelves nombres, luego autenticas aplicaciones.

Cuándo subir de piedra a papel (o a tijeras)

Quédate en WireGuard manual o Tailscale cuando:

• Eres una persona o un hogar, pocos dispositivos, sin requisitos de compliance.
• El problema es llegar a casa, no segmentar una empresa.

Pasa a Headscale (tijeras) cuando:

• La ancla de coordinación de Tailscale deja de ser aceptable y quieres el mesh sin el SaaS.
• Ya tienes acceso remoto funcionando y el siguiente paso es soberanía del plano de control, no aprender VPN desde cero.
• Aceptas operar, actualizar y depurar el servidor de coordinación tú mismo.

Reserva otras tijeras (topologías híbridas serias, múltiples sitios, routing entre VLANs, exit nodes con política, integración con identidad corporativa) cuando el homelab deja de ser hobby y se convierte en infraestructura que otros dependen.

Lo que viene después

Este post nombra la capa de acceso. Los siguientes bajarán al resto de la pila que prometí en cloud-first: DNS, reverse proxy e identidad. El acceso con Tailscale (o WireGuard) no resuelve “¿cómo se llama este servicio?” ni “¿quién puede hacer login en Grafana?”; solo responde “¿estoy en la red donde vive Grafana?”.

La pregunta es quién coordina tu red, qué anclas aceptas y cuándo la piedra de un mesh gestionado es más honesta que las tijeras de un IdP que aún no necesitas.