Tailscale es una VPN que usa WireGuard como capa de transporte cifrado pero delega todo lo que hace difícil a WireGuard puro —el intercambio de claves, el descubrimiento de peers, la gestión de IPs— a un plano de control centralizado que Tailscale opera en la nube. El resultado es que conectar dos máquinas en redes distintas, detrás de NAT, sin IP pública, tarda menos de dos minutos.
WireGuard puro es excelente, pero exige que tú gestiones manualmente las claves públicas de cada peer, sus endpoints y sus rangos de IP permitidos. Si tienes tres máquinas ya es incómodo; con veinte es un problema de operaciones. Tailscale resuelve esto con un modelo de coordinación centralizada: cada nodo genera su par de claves WireGuard localmente (la privada nunca sale del nodo), publica la pública al servidor de coordinación de Tailscale, y ese servidor distribuye la información necesaria para que los nodos se conecten directamente entre sí mediante hole punching STUN/TURN. El tráfico de datos viaja cifrado punto a punto entre nodos WireGuard, sin pasar por los servidores de Tailscale, salvo cuando el NAT traversal falla y se necesita un relay DERP.
Usas Tailscale cuando necesitas acceso seguro entre máquinas distribuidas —desarrolladores conectándose a servidores de staging, acceso a bases de datos en redes privadas desde casa, infraestructura multi-cloud— sin querer mantener una PKI ni un servidor WireGuard dedicado. Lo que se rompe si lo configuras mal es principalmente el modelo de seguridad: si no restringes acceso con ACLs en la consola de Tailscale (que usan su lenguaje HuJSON), por defecto todos los nodos de tu tailnet pueden hablar entre sí. Para entornos con más de un par de personas, eso importa.
Instalación y configuración en Debian Bookworm
El escenario: tienes un servidor en un VPS (vps-prod) y tu portátil de trabajo (laptop-dev). Quieres que el portátil llegue a una red privada 192.168.10.0/24 que sólo es accesible desde el VPS, y que ambos resuelvan sus nombres de máquina con Magic DNS.
# ── En ambas máquinas ────────────────────────────────────────────────── # El script oficial añade el repositorio APT de Tailscale y lo instala. # Equivalente a añadir manualmente /etc/apt/sources.list.d/tailscale.list # más la clave GPG correspondiente. curl -fsSL https://tailscale.com/install.sh | sh # Verificar que el daemon está activo (systemd unit: tailscaled.service) systemctl status tailscaled # ── En el portátil (laptop-dev) ──────────────────────────────────────── # Autentica el nodo contra tu cuenta Tailscale. # Abre una URL en el navegador para completar el OAuth. tailscale up # Comprobar la IP asignada en la red Tailscale (rango 100.64.0.0/10, # espacio de direcciones CGNAT que Tailscale usa para la tailnet) tailscale ip -4 # Verificar conectividad y latencia con el otro nodo por nombre de host. # Magic DNS resuelve "vps-prod" sin sufijo adicional dentro de la tailnet. tailscale ping vps-prod # ── En el VPS (vps-prod) ─────────────────────────────────────────────── # Activar este nodo como subnet router para exponer 192.168.10.0/24. # --advertise-routes anuncia la ruta; hay que aprobarla en la consola web. tailscale up --advertise-routes=192.168.10.0/24 # Habilitar el reenvío de paquetes en el kernel (necesario para el router). # Tailscale lo advierte si no está activo; sin esto las rutas no funcionan. echo 'net.ipv4.ip_forward = 1' | tee /etc/sysctl.d/99-tailscale.conf sysctl -p /etc/sysctl.d/99-tailscale.conf # ── De vuelta en el portátil ─────────────────────────────────────────── # Aceptar las rutas anunciadas por el subnet router. # Sin --accept-routes el cliente las ignora aunque estén aprobadas en la consola. tailscale up --accept-routes # Ahora puedes alcanzar hosts en la red privada del VPS directamente. # El tráfico va: laptop → túnel WireGuard → vps-prod → 192.168.10.x ping 192.168.10.5 # Inspeccionar el estado completo: peers, IPs, rutas activas, relay vs directo tailscale status
[Ubuntu]: El script install.sh detecta la distribución y añade el repositorio correcto automáticamente. En Ubuntu el proceso es idéntico.
Qué está pasando en cada paso
El script de instalación no es magia: añade https://pkgs.tailscale.com/stable/debian bookworm main a APT, importa la clave GPG de Tailscale y ejecuta apt-get install tailscale. Puedes hacerlo manualmente si tu política de seguridad prohíbe ejecutar scripts de curl como root.
tailscale up sin argumentos es el caso más simple: el nodo se registra en tu tailnet personal, recibe una IP del bloque 100.64.0.0/10 (CGNAT, RFC 6598), y desde ese momento es accesible por nombre desde cualquier otro nodo de la misma cuenta. El nombre que usa Magic DNS es el hostname del sistema en el momento del registro, legible en tailscale status.
Magic DNS funciona porque tailscaled registra un servidor DNS local que escucha en 100.100.100.100 (la IP especial de Tailscale) y lo inyecta como resolvedor mediante /etc/resolv.conf o mediante el stub resolver de systemd-resolved, dependiendo de lo que encuentre en el sistema. En Debian Bookworm con systemd-resolved activo, Tailscale usa resolvectl para registrar un split-DNS que sólo resuelve nombres de la tailnet contra ese servidor. Los nombres externos siguen yendo a tu DNS habitual.
--advertise-routes en el VPS le dice al plano de control “este nodo puede enrutar paquetes hacia 192.168.10.0/24“. Pero publicar no es suficiente: un administrador debe aprobar la ruta en la consola web de Tailscale (o con tailscale set --advertise-routes si usas un auth key con permisos). Esto es una decisión de diseño deliberada —evitar que cualquier nodo comprometido pueda anunciar rutas arbitrarias sin supervisión.
--accept-routes en el cliente es el otro lado del mismo mecanismo. Por defecto, Tailscale ignora las rutas anunciadas por otros nodos a menos que el cliente las acepte explícitamente. Si ping 192.168.10.5 no funciona desde el portátil, el primer lugar donde mirar es si tailscale status muestra la ruta con el prefijo [accepted] o simplemente la lista sin ese estado.
tailscale status es la herramienta de diagnóstico principal: muestra si la conexión entre dos nodos es directa (WireGuard punto a punto tras hole punching exitoso) o pasa por un relay DERP, qué rutas están activas y qué nodos están online. Una conexión que usa relay en lugar de conexión directa no es un fallo —el tráfico sigue cifrado con WireGuard— pero la latencia será mayor. tailscale ping --until-direct vps-prod fuerza el intento de establecer una conexión directa y te dice cuánto tardó en lograrlo.
La diferencia fundamental con WireGuard manual es que aquí no tocas ningún fichero de configuración de WireGuard. La interfaz tailscale0 existe en el sistema, wg show puede listar los peers activos, pero Tailscale gestiona esa interfaz por completo. Si intentas editar /etc/wireguard/tailscale0.conf directamente, tailscaled lo sobreescribirá en el próximo ciclo. El punto de configuración son las ACLs en la consola web y los flags de tailscale up, no los ficheros de WireGuard.