Configurar Tailscale en Linux: VPN Mesh sin Abrir Puertos para Sysadmins

Por qué Tailscale en 2026: el problema que resuelve

Si administras un homelab, manejas servidores remotos detrás de CGNAT o quieres evitar exponer puertos en tu firewall, ya sabes el dolor de cabeza: configurar WireGuard a mano entre 3 nodos, mantener listas de IPs, sincronizar claves públicas y rezar para que ningún peer se caiga. Tailscale automatiza todo eso construyendo una red mesh sobre WireGuard, con un plano de control que negocia las claves por ti y nodos que se descubren entre sí sin tocar el router.

La promesa es directa: instalas el cliente, te autenticas con tu proveedor (Google, GitHub, Microsoft, Okta, OIDC propio), y cada equipo obtiene una IP del rango 100.x.x.x reachable desde cualquier otro nodo del tailnet. No abres puertos, no configuras NAT inverso, no mantienes una PKI casera. Para sysadmins que manejan infraestructura dispersa (clouds, VPS, Raspberry Pi en casa, laptops en movimiento) es un cambio radical frente a OpenVPN o WireGuard pelado.

Si ya tienes una red WireGuard armada, tal vez no quieras migrar. Pero si estás partiendo de cero, o si el homelab se te complicó con cinco túneles punto a punto, Tailscale vale los cinco minutos de setup que toma.

Cómo funciona Tailscale por dentro (sin la magia negra)

Tailscale NO es un fork de WireGuard ni un reemplazo del protocolo: es una capa de orquestación encima. Cada nodo corre el daemon tailscaled, que monta una interfaz tailscale0 con un handshake WireGuard estándar. La diferencia está en cómo se distribuye la configuración de claves: en vez de que tú copies publickey + endpoint a cada peer, Tailscale usa un control server (llamado coordination server o headscale si lo auto-hospedas) que firma nodos vía OAuth/OIDC y reparte la lista de peers autorizados a cada cliente cada pocos minutos.

Cuando dos nodos quieren comunicarse, Tailscale intenta primero una conexión directa WireGuard sobre UDP. Si los dos están detrás de NAT simétrico o CGNAT (típico en redes móviles, hotspots y muchos ISP residenciales), esa conexión falla. En ese momento entra el DERP (Designated Encrypted Relay for Packets): un servidor de relay sobre HTTPS/TLS que actúa de puente temporal mientras NAT traversal sigue intentando el camino directo. Todo el tráfico por DERP va cifrado WireGuard extremo a extremo: el relay NO puede leer tus paquetes.

Resultado práctico: tu laptop en un café de Bogotá habla con tu servidor en casa sin que abras un solo puerto, sin IP pública dinámica, sin DynDNS, sin STUN manual.

Instalar Tailscale en Linux paso a paso

El método oficial soporta las distribuciones mainstream (Ubuntu, Debian, RHEL, Fedora, CentOS, Arch, openSUSE, Raspberry Pi OS, Amazon Linux) con un instalador universal:

curl -fsSL https://tailscale.com/install.sh | sh

El script detecta tu distro, agrega el repositorio estable de Tailscale (pkgs.tailscale.com) e instala los paquetes tailscale y tailscale-archive-keyring. Funciona idéntico en Debian 12/13, Ubuntu 24.04, Fedora 41/42, RHEL 9 y similares. En Arch y derivadas el paquete vive en los repos oficiales:

sudo pacman -S tailscale

Después de instalar, habilita e inicia el daemon con systemd (en distros que usan el instalador viene preconfigurado):

sudo systemctl enable --now tailscaled
sudo systemctl status tailscaled

El servicio tailscaled monta la interfaz tailscale0 y queda esperando autenticación. NO inicia el cliente todavía: el paso de auth es interactivo y requiere un navegador o un auth key pregenerado para nodos headless.

Conectar y verificar: el primer nodo

Para levantar el cliente en una máquina con navegador, basta con:

sudo tailscale up

El daemon imprime una URL de un solo uso tipo https://login.tailscale.com/a/abc123. La abres en el navegador, te autenticas con tu identity provider (Google, GitHub, Microsoft, etc.) y confirmas que el equipo se una al tailnet. Inmediatamente, tailscale up termina y el equipo ya tiene su IP 100.x.x.x. Para ver el estado y los peers visibles:

tailscale ip        # muestra la IP 100.x del nodo
tailscale status    # lista de peers conectados + latencias
tailscale ping homelab   # prueba conectividad con otro nodo por nombre

Si vas a instalar Tailscale en un servidor sin navegador (Raspberry Pi headless, VPS, NAS), necesitas un auth key reusable que generas en console.tailscale.com/admin/settings/keys y pasas como argumento:

sudo tailscale up --authkey=tskey-auth-XXXXXXXXXXXX --hostname=mi-servidor

El flag --hostname define el nombre con que aparecerá en el tailnet y en MagicDNS (más sobre eso en seguida). Para producción en servidores críticos, también conviene desactivar la expiración de claves (key expiry) desde la consola web o vía flag:

sudo tailscale up --authkey=tskey-auth-XXX --hostname=srv-prod --accept-routes

--accept-routes permite que el nodo acepte rutas de subred anunciadas por otros peers (las subnet routes) y las inyecte en su tabla de rutas locales. Sin ese flag, el nodo solo habla directo con peers mesh, no llega a la LAN detrás de un subnet router.

Funciones que cambian el homelab

Una vez que tienes dos o tres nodos conectados, Tailscale desbloquea features que en WireGuard pelado te costarían horas de configuración.

MagicDNS: olvídate de las IPs 100.x

MagicDNS viene activado por defecto en tailnets creados después de octubre de 2022. Cada nodo recibe un FQDN del estilo mi-servidor.tu-tailnet.ts.net, y Tailscale añade el dominio ts.net como search domain en /etc/resolv.conf. Resultado: ssh mi-servidor resuelve igual que ssh 100.123.45.67. Si MagicDNS está desactivado en tu tailnet, lo activas desde la consola web en DNS → Enable MagicDNS.

Tailscale SSH: SSH público, pero a través del tailnet

Tailscale SSH te deja usar el cliente SSH del sistema operativo (openssh) pero con la autenticación delegada al control plane de Tailscale. Para activarlo en un nodo:

sudo tailscale set --ssh

Después, cualquier peer puede hacer ssh usuario@mi-servidor y la llave WireGuard del tailnet actúa como autenticación de capa 3, sin necesidad de exponer el puerto 22 al público ni mantener authorized_keys. Útil para laptops que viajan: si el peer está autorizado en el ACL, el SSH funciona; si no, el intento ni sale del equipo.

Subnet routers: llega a toda tu LAN sin instalar cliente en cada device

¿Tienes impresoras, cámaras IP, switches, DVRs u otros equipos donde NO puedes instalar Tailscale? Un nodo Linux con dos interfaces puede actuar de subnet router, anunciando rutas para que el resto del tailnet llegue a esos dispositivos:

sudo tailscale up --advertise-routes=192.168.1.0/24,10.0.0.0/24 --accept-routes

Luego apruebas esas rutas en la consola (Machines → Edit route settings → Approve). Desde cualquier peer del tailnet, ssh 192.168.1.50 ahora viaja por la mesh, sale por el subnet router y llega a tu cámara IP. Túnel transparente a una LAN completa sin tocar un solo device.

Exit nodes: enruta TODO el tráfico por un nodo

Si quieres usar tu servidor de casa como VPN tradicional para que tu laptop en un hotel aparezca con IP residencial, declaras el nodo como exit node:

sudo tailscale up --advertise-exit-node

Apruebas en la consola y luego en el cliente remoto:

sudo tailscale up --exit-node=mi-servidor

Todo el tráfico del laptop sale ahora por tu servidor. Cero configuración de iptables/nftables en tu lado: Tailscale configura el forwarding y masquerading automáticamente.

Tailscale Funnel y Serve: exponer sin abrir puertos

Para servicios que quieres compartir con el mundo (un blog personal, una API en una Raspberry Pi, una instancia de Home Assistant), tailscale funnel crea un endpoint en https://tu-nodo.ts.net que Tailscale expone públicamente a través de sus relays TLS. NO abres puertos en el router, NO configuras certificados (Tailscale los emite vía Let’s Encrypt automáticamente):

sudo tailscale funnel 8080

Tu servicio en localhost:8080 queda accesible en https://tu-nodo.tailnet.ts.net. Si solo quieres compartir dentro del tailnet (sin acceso público), usa tailscale serve en lugar de funnel.

Precios y límites reales del plan Personal

Tailscale sigue siendo gratis para uso personal: hasta 6 usuarios en un mismo tailnet, dispositivos ilimitados por usuario, todas las funciones mesh, MagicDNS, SSH, subnet routers, exit nodes, ACLs y ACL grants incluidos. El plan Personal NO tiene fecha de caducidad: es gratis indefinidamente mientras seas un usuario individual (no comercial).

El plan siguiente, Standard, cuesta $8 USD por usuario por mes y habilita SSO para empresas, mayor control de ACLs, funciones de auditoría, logs centralizados y soporte oficial. El plan Enterprise añade controles administrativos granulares, integración con IdP corporativos y cumplimiento. Para equipos de sysadmins que manejan infraestructura de cliente, el plan Personal deja de alcanzar cuando superas 6 personas: ahí toca evaluar Standard o migrar a Headscale (control server open source) si quieres mantener todo self-hosted.

Troubleshooting común en Linux

Estos son los tropiezos más frecuentes cuando arrancas con Tailscale, en orden de lo más habitual a lo más raro.

tailscaled entra en restart loop: falta el módulo tun

Tailscale requiere el módulo tun del kernel para crear la interfaz virtual. En kernels modernos viene compilado dentro, pero en algunos VPS, contenedores LXC restrictivos y derivados de RHEL con sparse en estaciones anda:

sudo modprobe tun
echo tun | sudo tee /etc/modules-load.d/tun.conf

Si modprobe tun devuelve error de módulo no encontrado, revisa que tu kernel tenga CONFIG_TUN=y o =m. Reinicia el nodo si actualizaste el kernel y el módulo no se cargó.

Key expiry te dejó el nodo offline

Por defecto, las claves de nodo expiran cada 180 días para forzar re-autenticación. Para servidores de producción que NO quieres re-autenticar manualmente, desactívalo desde Machines → ⋯ → Disable key expiry. Si ya expiró:

sudo tailscale up --force-reauth

MagicDNS no resuelve nombres del tailnet

Verifica que tu tailnet tenga MagicDNS activo (DNS → Enable MagicDNS en la consola) y que tu distro esté aceptando el DNS de Tailscale:

tailscale set --accept-dns=true
cat /etc/resolv.conf | grep ts.net

Si usas systemd-resolved con resolvectl, asegúrate de que 100.100.100.100 (el resolver interno de Tailscale) figure como upstream.

Logs centralizados que NO quieres

Por defecto, Tailscale envía logs de conectividad al control server (NO el tráfico, solo metadata de sesiones). Para desactivarlo en nodos paranoicos:

sudo tailscale set --no-logs-no-support

Advertencia oficial: con logs desactivados, Tailscale NO te puede dar soporte técnico. Es un trade-off válido para homelabs, problemático para producción empresarial.

Cuándo NO vale la pena Tailscale

Tailscale brilla en escenarios small-to-medium: homelabs, equipos distribuidos de hasta 30-40 nodos, infraestructura de un solo sysadmin o un equipo chico. Para redes con cientos de nodos, requisitos de cumplimiento estricto (PCI-DSS, HIPAA) o necesidad de auditoría detallada, los planes comerciales empiezan a sentirse limitados y conviene evaluar opciones con logging centralizado nativo (Cloudflare Zero Trust, Cisco Duo, ZScaler). Tampoco es buena elección si quieres aprender WireGuard de verdad: Tailscale abstrae tanto el protocolo que no te enseña cómo funcionan los túneles UDP, el handshake de claves ni el NAT traversal.

Si necesitas todo self-hosted por motivos de soberanía, Headscale corre el control server en tu infra y reemplaza el SaaS de Tailscale. Y si prefieres un competidor open source end-to-end sin coordination server propietario, NetBird cumple un rol similar con su propia implementación del control plane.

Resumen: 30 minutos para tener tu tailnet

Si todavía estás peleando con claves públicas WireGuard, tablas de routing manuales y reenvío de puertos, Tailscale te devuelve esas tardes. Cinco comandos y tienes una mesh entre tu servidor, tu laptop y tu Raspberry Pi: curl ... install.sh | sh, systemctl enable tailscaled, tailscale up, tailscale status, tailscale ping otro-nodo. El plan Personal sigue siendo gratis para seis personas, suficiente para el 90% de los homelabs y los equipos de sysadmins pequeños.

Para profundizar en cómo se compara con alternativas y en qué contextos cada una gana, te recomiendo:

Preguntas frecuentes

Lee también

• Guía Fedora 44: Novedades, Instalación y Upgrade para Sysadmins Linux
• Configura VLANs en Linux con nmcli: Guía paso a paso para sysadmins
• Protege tu SSH: Guía esencial para configurar Fail2ban en Linux
• Guía Definitiva: Configura Kubernetes con kubeadm en Ubuntu para Sysadmins Linux
• Configura Prometheus y Grafana: Guía DevOps para SysAdmins Linux