WireGuard y Tailscale VPN en un VPS Linux

19 min de lectura·Matthieu·securitydebianubuntulinuxheadscalevpntailscalewireguard|

Configura WireGuard desde cero o despliega Tailscale para acceso VPN gestionado en Ubuntu 24.04 y Debian 12, con prevención de fugas DNS, refuerzo con PreSharedKey y una comparación neutral que incluye Headscale.

Esta guía cubre dos enfoques para el acceso VPN a un VPS Linux: WireGuard (manual, control total) y Tailscale (gestionado, listo para usar). Ambos usan el protocolo WireGuard por debajo. La diferencia está en quién gestiona las claves, el enrutamiento y la coordinación.

Elige la sección que se ajuste a tu situación, o lee las tres partes para tomar una decisión informada.

Requisitos previos:

  • Un VPS con Ubuntu 24.04 o Debian 12 (funciona en un VPS de Virtua Cloud)
  • Acceso SSH con un usuario no root con sudo
  • Un firewall configurado y activo
  • Una máquina local (Linux, macOS o Windows) como cliente VPN

¿Por qué conectarte por VPN a tu VPS Linux?

Cada servicio expuesto en una IP pública es un objetivo. Los bots de fuerza bruta SSH encuentran servidores nuevos en minutos. Los puertos de bases de datos, paneles de administración y endpoints de API se escanean constantemente. Una VPN te permite mantener las interfaces de gestión fuera de internet.

El principio es directo: vincula los servicios sensibles a la dirección de la interfaz VPN en lugar de 0.0.0.0. Solo los dispositivos con claves VPN válidas pueden acceder a ellos. Internet nunca ve que estos puertos existen.

Casos de uso comunes:

  • Acceso de administración sin SSH público. Vincula sshd a la IP de WireGuard. Se acabó el puerto 22 expuesto al mundo. Fail2ban se vuelve opcional cuando no hay nada que atacar por fuerza bruta.
  • Túnel hacia APIs privadas de inferencia IA. ¿Ejecutas Ollama o un endpoint LLM privado en tu VPS? Ponlo detrás de la VPN. Sin necesidad de API gateway ni gestión de tokens para acceso interno.
  • Red mesh multi-cloud. Conecta nodos VPS de distintos proveedores (Virtua, Hetzner, OVH) en una red privada. Los servicios se comunican por túneles cifrados sin endpoints públicos.
  • Cifrado del tráfico en redes no confiables. Enruta todo el tráfico a través del VPS cuando trabajes desde cafeterías o WiFi de hoteles. Tu ISP y el operador de la red local solo ven paquetes WireGuard cifrados.

El modelo de amenazas importa. Si solo accedes a tu VPS desde una IP fija de oficina, las reglas de firewall pueden ser suficientes. Pero si trabajas desde múltiples ubicaciones, usas varios dispositivos o gestionas un equipo con diferentes niveles de acceso, una VPN es la solución más limpia.

¿Cómo se instala WireGuard en Ubuntu 24.04 o Debian 12?

WireGuard es un protocolo VPN integrado en el kernel de Linux desde la versión 5.6. Usa Curve25519 para el intercambio de claves, ChaCha20 para el cifrado y tiene unas 4.000 líneas de código (frente a las más de 100.000 de OpenVPN). Instálalo con apt, genera pares de claves, escribe un archivo de configuración e inicia el túnel. Todo el proceso lleva menos de 10 minutos.

Instala WireGuard en el servidor:

sudo apt update && sudo apt install wireguard wireguard-tools -y

El paquete wireguard proporciona el módulo del kernel. El paquete wireguard-tools proporciona las utilidades de espacio de usuario wg y wg-quick.

¿Cómo se generan las claves WireGuard y se configura el servidor?

WireGuard usa pares de claves asimétricos (uno por peer) más una clave precompartida opcional para defensa post-cuántica. Genera un par de claves del servidor, un par del cliente y una clave precompartida compartida entre ambos. La clave precompartida (PreSharedKey) añade una capa de cifrado simétrico sobre el intercambio Curve25519 de WireGuard. Si un futuro ordenador cuántico rompe el intercambio de claves asimétrico, la clave precompartida simétrica sigue protegiendo el túnel.

En el servidor, genera las claves con un umask restrictivo para que los archivos se creen con permisos 600:

umask 077
wg genkey | sudo tee /etc/wireguard/server_private.key | wg pubkey | sudo tee /etc/wireguard/server_public.key
wg genpsk | sudo tee /etc/wireguard/psk.key

ls -la /etc/wireguard/

-rw------- 1 root root   45 Mar 19 10:01 psk.key
-rw------- 1 root root   45 Mar 19 10:01 server_private.key
-rw------- 1 root root   45 Mar 19 10:01 server_public.key

Los tres archivos tienen permisos 600 (lectura/escritura solo para el propietario). La clave privada y la clave precompartida nunca deben salir del servidor.

En tu máquina local (el cliente), genera su propio par de claves:

umask 077
wg genkey | tee client_private.key | wg pubkey > client_public.key

Necesitas la clave pública del cliente en el servidor y la clave pública del servidor en el cliente. La clave precompartida va en ambos lados. Nunca transfieras claves privadas.

Habilitar el reenvío de IP

El servidor necesita enrutar tráfico para los clientes VPN. Habilita el reenvío de IPv4 e IPv6:

echo 'net.ipv4.ip_forward = 1' | sudo tee /etc/sysctl.d/99-wireguard.conf
echo 'net.ipv6.conf.all.forwarding = 1' | sudo tee -a /etc/sysctl.d/99-wireguard.conf
sudo sysctl -p /etc/sysctl.d/99-wireguard.conf

net.ipv4.ip_forward = 1
net.ipv6.conf.all.forwarding = 1

Usar un archivo en /etc/sysctl.d/ es preferible a editar /etc/sysctl.conf directamente. Sobrevive a actualizaciones de paquetes y deja claro qué ajustes pertenecen a cada servicio.

Archivo de configuración del servidor

Identifica la interfaz de red pública de tu servidor:

ip route show default

default via 203.0.113.1 dev eth0 proto static metric 100

En este ejemplo, la interfaz es eth0. La tuya podría ser ens3, ens18 u otra. Usa lo que aparezca después de dev.

Crea la configuración del servidor:

sudo nano /etc/wireguard/wg0.conf

[Interface]
Address = 10.66.66.1/24, fd42:42:42::1/64
ListenPort = 51820
PrivateKey = <contenido de /etc/wireguard/server_private.key>
PostUp = nft add table ip wireguard; nft add chain ip wireguard forward { type filter hook forward priority 0 \; policy accept \; }; nft add rule ip wireguard forward iifname "wg0" accept; nft add table ip nat; nft add chain ip nat postrouting { type nat hook postrouting priority 100 \; }; nft add rule ip nat postrouting oifname "eth0" masquerade
PostDown = nft delete table ip wireguard; nft delete table ip nat

[Peer]
PublicKey = <contenido de client_public.key>
PresharedKey = <contenido de /etc/wireguard/psk.key>
AllowedIPs = 10.66.66.2/32, fd42:42:42::2/128

Reemplaza eth0 en las líneas PostUp/PostDown con el nombre real de tu interfaz.

Qué hace cada sección:

  • Address: la IP VPN asignada a este servidor. /24 y /64 definen el tamaño de la subred VPN.
  • ListenPort: el puerto UDP en el que escucha WireGuard. 51820 es lo convencional.
  • PostUp/PostDown: reglas nftables que activan el NAT masquerading. Cuando un cliente VPN envía tráfico a internet, el servidor reescribe la IP origen con su propia IP pública. Esto es lo que hace funcionar el VPN en túnel completo.
  • AllowedIPs en la sección [Peer]: qué IPs VPN puede usar este cliente. /32 significa exactamente una IP. Esto impide que los clientes suplanten otras direcciones VPN.

Si usas ufw en lugar de nftables directamente, reemplaza PostUp/PostDown con:

PostUp = ufw route allow in on wg0 out on eth0; iptables -t nat -I POSTROUTING -o eth0 -j MASQUERADE
PostDown = ufw route delete allow in on wg0 out on eth0; iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE

Bloquea el archivo de configuración. Contiene tu clave privada:

sudo chmod 600 /etc/wireguard/wg0.conf

Abrir el firewall e iniciar el túnel

Permite el puerto UDP de WireGuard en el firewall:

sudo ufw allow 51820/udp

O directamente con nftables:

sudo nft add rule inet filter input udp dport 51820 accept

Inicia el túnel. La directiva enable lo hace persistente tras reinicios. El flag --now lo inicia de inmediato:

sudo systemctl enable --now wg-quick@wg0

sudo systemctl status wg-quick@wg0

● wg-quick@wg0.service - WireGuard via wg-quick(8) for wg0
     Loaded: loaded (/usr/lib/systemd/system/wg-quick@.service; enabled; preset: enabled)
     Active: active (exited) since ...

El estado muestra active (exited) porque wg-quick configura la interfaz y termina. El módulo del kernel se encarga del túnel a partir de ahí. Comprueba el túnel activo:

sudo wg show

interface: wg0
  public key: aB3dEfGhIjKlMnOpQrStUvWxYz1234567890abc=
  private key: (hidden)
  listening port: 51820

peer: xY9zAbCdEfGhIjKlMnOpQrStUvWxYz1234567890=
  preshared key: (hidden)
  allowed ips: 10.66.66.2/32, fd42:42:42::2/128

La salida (hidden) indica que WireGuard protege el material criptográfico sensible. Si ves latest handshake para un peer, ese peer se ha conectado con éxito.

Configuración del cliente

En tu máquina local, crea la configuración de WireGuard:

sudo nano /etc/wireguard/wg0.conf

[Interface]
Address = 10.66.66.2/24, fd42:42:42::2/64
PrivateKey = <contenido de client_private.key>
DNS = 10.66.66.1

[Peer]
PublicKey = <contenido de server_public.key>
PresharedKey = <contenido de psk.key>
AllowedIPs = 0.0.0.0/0, ::/0
Endpoint = YOUR_SERVER_PUBLIC_IP:51820
PersistentKeepalive = 25

Explicación de los parámetros clave:

  • AllowedIPs = 0.0.0.0/0, ::/0 enruta todo el tráfico a través de la VPN (túnel completo). Para split tunneling, donde solo el tráfico de la subred VPN pasa por el túnel, usa AllowedIPs = 10.66.66.0/24, fd42:42:42::/64.
  • Endpoint es la IP pública y el puerto del servidor. El cliente lo necesita para iniciar la conexión. El servidor no necesita el endpoint del cliente porque lo aprende de los paquetes entrantes.
  • PersistentKeepalive = 25 envía un paquete keepalive cada 25 segundos. Esto mantiene activas las asignaciones NAT para que el servidor pueda alcanzar al cliente. Sin esto, la conexión cae tras el timeout NAT (normalmente 30-120 segundos de inactividad).
  • DNS = 10.66.66.1 dirige las consultas DNS a la dirección VPN del servidor. Esto previene fugas DNS (explicado en la siguiente sección).

En macOS y Windows, usa la aplicación WireGuard. Importa el archivo de configuración o pégalo.

Conéctate desde el cliente:

sudo wg-quick up wg0

ping 10.66.66.1

PING 10.66.66.1 (10.66.66.1) 56(84) bytes of data.
64 bytes from 10.66.66.1: icmp_seq=1 ttl=64 time=4.23 ms
64 bytes from 10.66.66.1: icmp_seq=2 ttl=64 time=3.98 ms

Desde tu máquina local, confirma que tu IP pública ha cambiado (si usas túnel completo):

curl -s https://ifconfig.me

Debería devolver la IP pública del VPS, no tu IP doméstica.

Añadir más clientes

Para cada cliente adicional, genera un nuevo par de claves y una nueva clave precompartida (una PSK por par de peers). Añade un bloque [Peer] al wg0.conf del servidor:

[Peer]
PublicKey = <nueva clave pública del cliente>
PresharedKey = <nueva clave precompartida>
AllowedIPs = 10.66.66.3/32, fd42:42:42::3/128

Incrementa la dirección IP para cada cliente. Tras editar, recarga sin cortar conexiones existentes:

sudo wg syncconf wg0 <(sudo wg-quick strip wg0)

Esto aplica la nueva configuración de peers sin reiniciar la interfaz. Las conexiones existentes se mantienen.

Ajuste de MTU

WireGuard añade 60 bytes de overhead por paquete (28 bytes para las cabeceras externas IPv4 y UDP, 32 bytes para la cabecera WireGuard). Si tu VPS tiene un MTU estándar de 1500 bytes, configura el MTU de WireGuard a 1420 en la sección [Interface]:

MTU = 1420

Configúralo en servidor y cliente. MTUs diferentes causan fragmentación de paquetes y caídas de rendimiento difíciles de diagnosticar. Si ejecutas WireGuard sobre un enlace con MTU ya reducido (PPPoE, VXLAN), resta en consecuencia.

¿Cómo se previenen las fugas DNS con WireGuard?

Las fugas DNS ocurren cuando tu sistema envía consultas DNS fuera del túnel VPN, exponiendo qué dominios visitas a tu ISP o red local. Esto anula el beneficio de privacidad de enrutar tráfico por la VPN. La solución: ejecuta un resolver DNS local en el servidor VPN y apunta el DNS del cliente a ese resolver a través del túnel.

Instala Unbound en el servidor:

sudo apt install unbound -y

Crea un archivo de configuración para que Unbound escuche en la interfaz WireGuard:

sudo nano /etc/unbound/unbound.conf.d/wireguard.conf

server:
    interface: 10.66.66.1
    interface: fd42:42:42::1
    interface: 127.0.0.1
    access-control: 10.66.66.0/24 allow
    access-control: fd42:42:42::/64 allow
    access-control: 127.0.0.0/8 allow
    do-ip6: yes
    hide-identity: yes
    hide-version: yes
    harden-glue: yes
    harden-dnssec-stripped: yes
    use-caps-for-id: yes
    prefetch: yes

Las directivas hide-identity y hide-version impiden que Unbound revele su versión de software en las respuestas DNS. Revelar la versión ayuda a los atacantes a apuntar a vulnerabilidades conocidas. Las opciones harden-* aplican validación DNSSEC y previenen envenenamiento de caché. La opción use-caps-for-id añade codificación 0x20 a las consultas DNS, una defensa ligera contra respuestas falsificadas.

En Ubuntu 24.04, systemd-resolved escucha en el puerto 53 por defecto y entra en conflicto con Unbound. Desactívalo:

sudo systemctl disable --now systemd-resolved
sudo rm /etc/resolv.conf
echo "nameserver 127.0.0.1" | sudo tee /etc/resolv.conf

Inicia Unbound:

sudo systemctl enable --now unbound

sudo systemctl status unbound

● unbound.service - Unbound DNS server
     Loaded: loaded (/usr/lib/systemd/system/unbound.service; enabled; preset: enabled)
     Active: active (running) since ...

Comprueba que Unbound resuelve desde la interfaz WireGuard:

dig @10.66.66.1 example.com +short

Deberías obtener una o más direcciones IP. Las IPs exactas dependen de los registros DNS actuales del dominio.

La configuración del cliente ya establece DNS = 10.66.66.1. Cuando el túnel WireGuard está activo, todas las consultas DNS van por el túnel cifrado hacia Unbound. Ninguna consulta se filtra a tu ISP.

Para confirmar desde el lado del cliente, conéctate a la VPN y comprueba:

resolvectl status wg0

El servidor DNS debería mostrar solo 10.66.66.1. También puedes usar dnsleaktest.com.

Test Antes de VPN Después de VPN (con Unbound)
Servidor DNS mostrado Resolver del ISP (ej. 192.168.1.1) 10.66.66.1 (Unbound del VPS)
IP vista por el sitio de test IP de casa/oficina IP pública del VPS
Consultas DNS visibles para el ISP Sí No

Para profundizar en seguridad DNS incluyendo DNSSEC y DNS-over-HTTPS, consulta .

Kill switch: ¿qué pasa cuando cae el túnel?

Si el túnel WireGuard cae, el tráfico fluye sin cifrar por tu ruta por defecto. Tu IP real y consultas DNS quedan expuestas. Un kill switch lo impide bloqueando todo el tráfico no VPN a nivel de firewall.

En el cliente, añade reglas nftables que solo permitan tráfico a través de la interfaz WireGuard y la conexión cifrada al endpoint del servidor:

sudo nft add table inet killswitch
sudo nft add chain inet killswitch output { type filter hook output priority 0 \; policy drop \; }
sudo nft add rule inet killswitch output oifname "wg0" accept
sudo nft add rule inet killswitch output ip daddr YOUR_SERVER_PUBLIC_IP udp dport 51820 accept
sudo nft add rule inet killswitch output oifname "lo" accept

Con esto, si wg0 cae, todo el tráfico saliente se bloquea. Sin fugas DNS, sin paquetes en texto claro. El único tráfico permitido es el handshake WireGuard cifrado hacia el servidor.

Elimina el kill switch para restaurar el enrutamiento normal:

sudo nft delete table inet killswitch

Para un kill switch persistente que se active automáticamente, guarda estas reglas en un archivo y cárgalas con un servicio systemd que arranque antes de wg-quick@wg0.

¿Cómo se instala Tailscale en un VPS Linux?

Tailscale es un servicio VPN en malla construido sobre WireGuard. Gestiona la distribución de claves, la travesía NAT y el descubrimiento de peers a través de un servidor de coordinación. Instalas el cliente, te autentificas con tu proveedor de identidad y tus dispositivos pueden comunicarse entre sí. Sin intercambio manual de claves, sin redirección de puertos, sin reglas de firewall que abrir.

La contrapartida: el servidor de coordinación de Tailscale es un servicio de terceros. Ve los metadatos de tus dispositivos (IPs, nombres de host, qué dispositivos están en línea) pero nunca tu tráfico, que fluye peer-to-peer sobre WireGuard.

¿Cómo se instala Tailscale en Ubuntu 24.04 o Debian 12?

Añade el repositorio oficial de Tailscale e instala el paquete. Esto evita curl | sh y te permite verificar actualizaciones a través de apt.

Para Ubuntu 24.04 (Noble):

sudo mkdir -p --mode=0755 /usr/share/keyrings
curl -fsSL https://pkgs.tailscale.com/stable/ubuntu/noble.noarmor.gpg | sudo tee /usr/share/keyrings/tailscale-archive-keyring.gpg >/dev/null
curl -fsSL https://pkgs.tailscale.com/stable/ubuntu/noble.tailscale-keyring.list | sudo tee /etc/apt/sources.list.d/tailscale.list
sudo apt-get update && sudo apt-get install tailscale -y

Para Debian 12 (Bookworm):

sudo mkdir -p --mode=0755 /usr/share/keyrings
curl -fsSL https://pkgs.tailscale.com/stable/debian/bookworm.noarmor.gpg | sudo tee /usr/share/keyrings/tailscale-archive-keyring.gpg >/dev/null
curl -fsSL https://pkgs.tailscale.com/stable/debian/bookworm.tailscale-keyring.list | sudo tee /etc/apt/sources.list.d/tailscale.list
sudo apt-get update && sudo apt-get install tailscale -y

Inicia Tailscale y autentifícate:

sudo tailscale up

Esto muestra una URL de autenticación. Ábrela en tu navegador e inicia sesión con tu proveedor de identidad (Google, Microsoft, GitHub, etc.). Una vez autenticado, el VPS se une a tu tailnet.

sudo systemctl status tailscaled

● tailscaled.service - Tailscale node agent
     Loaded: loaded (/usr/lib/systemd/system/tailscaled.service; enabled; preset: enabled)
     Active: active (running) since ...

Comprueba la IP de Tailscale asignada:

tailscale ip -4

100.64.0.1

Cada dispositivo en tu tailnet recibe una dirección estable 100.x.x.x (rango CGNAT). Esta IP persiste tras reinicios y reconexiones. Úsala para alcanzar tu VPS desde cualquier otro dispositivo en el mismo tailnet.

Comprueba la conectividad con tus otros dispositivos:

tailscale status

100.64.0.1    vps-frankfurt    youruser@  linux   -
100.64.0.2    laptop           youruser@  macOS   active; direct 203.0.113.50:41641

La indicación direct significa que el tráfico fluye peer-to-peer sobre WireGuard. Si dice relay, el tráfico pasa por un servidor relay DERP, lo que añade latencia. El relay DERP ocurre cuando ambos peers están detrás de NATs restrictivos que impiden conexiones directas.

Desactivar la expiración de claves para servidores

Las claves de Tailscale expiran tras 180 días por defecto. Cuando expiran, el dispositivo queda offline hasta que alguien lo reautentifique. Para un VPS que debe permanecer conectado, tienes dos opciones.

Opción 1: desactivar la expiración en la consola de administración. Ve a la página Machines, encuentra tu VPS, haz clic en el menú y selecciona "Disable key expiry".

Opción 2 (recomendada): usar una clave de autenticación con etiqueta. Los dispositivos etiquetados tienen la expiración desactivada automáticamente. Genera una clave de autenticación reutilizable y etiquetada en la consola de administración en Settings > Keys, y únete con:

sudo tailscale up --auth-key=tskey-auth-XXXXX --advertise-tags=tag:server

Las etiquetas también funcionan con las ACL (tratadas más abajo), lo que las convierte en la mejor opción para infraestructura de servidores.

¿Cómo se configura un nodo de salida Tailscale en tu VPS?

Un nodo de salida (exit node) enruta todo el tráfico de internet de tus dispositivos a través del VPS. Tu tráfico saliente parece originarse desde la dirección IP del VPS. Funciona como una VPN tradicional: cifrar todo, salir desde la ubicación del VPS.

Habilita el reenvío de IP en el VPS:

echo 'net.ipv4.ip_forward = 1' | sudo tee /etc/sysctl.d/99-tailscale.conf
echo 'net.ipv6.conf.all.forwarding = 1' | sudo tee -a /etc/sysctl.d/99-tailscale.conf
sudo sysctl -p /etc/sysctl.d/99-tailscale.conf

Anuncia el VPS como nodo de salida:

sudo tailscale set --advertise-exit-node

Aprueba el nodo de salida en la consola de administración. Encuentra el VPS, haz clic en el menú, ve a "Edit route settings" y activa "Use as exit node".

Desde tu dispositivo cliente, empieza a usar el nodo de salida:

sudo tailscale set --exit-node=<vps-tailscale-ip>

Para mantener el acceso a la red local (impresoras, NAS, otros dispositivos) mientras enrutas el tráfico de internet por el nodo de salida:

sudo tailscale set --exit-node=<vps-tailscale-ip> --exit-node-allow-lan-access=true

Para dejar de enrutar a través del nodo de salida:

sudo tailscale set --exit-node=

Confirma que el nodo de salida funciona comprobando tu IP pública desde el cliente:

curl -s https://ifconfig.me

Debería devolver la IP pública del VPS.

Enrutamiento de subredes

El enrutamiento de subredes expone una red privada detrás del VPS a tu tailnet. Es útil cuando tu VPS puede alcanzar una subred de base de datos privada o servicios internos que no ejecutan Tailscale.

sudo tailscale set --advertise-routes=192.168.1.0/24

Aprueba la ruta en la consola de administración igual que los nodos de salida. Una vez aprobada, todos los dispositivos del tailnet pueden alcanzar 192.168.1.0/24 a través del VPS como gateway, sin instalar Tailscale en cada host de esa subred.

Puedes anunciar múltiples rutas separándolas con comas:

sudo tailscale set --advertise-routes=192.168.1.0/24,10.0.0.0/16

Para routers de subred con mucho tráfico y muchos flujos simultáneos, Tailscale recomienda el modo kernel (solo Linux) sobre el modo userspace. En Linux, el modo kernel es el predeterminado. Compruébalo con:

tailscale debug prefs | grep RouteAll

¿Cómo se configuran las ACL de Tailscale para acceso al VPS?

Por defecto, todos los dispositivos en un tailnet pueden comunicarse entre sí en todos los puertos. En producción, restringe esto con ACLs en el archivo de política del tailnet.

Una política mínima que limita el acceso al VPS a un grupo de administradores:

{
  "groups": {
    "group:admins": ["alice@example.com", "bob@example.com"]
  },
  "tagOwners": {
    "tag:server": ["group:admins"]
  },
  "acls": [
    {
      "action": "accept",
      "src": ["group:admins"],
      "dst": ["tag:server:*"]
    }
  ]
}

Esto dice: solo los miembros de group:admins pueden acceder a dispositivos etiquetados como tag:server. Todas las demás conexiones se deniegan por defecto. Edita esto en la consola de administración en Access Controls.

Etiqueta el VPS al unirte al tailnet:

sudo tailscale up --advertise-tags=tag:server

Una política más granular puede restringir por puerto:

{
  "groups": {
    "group:admins": ["alice@example.com"],
    "group:developers": ["bob@example.com", "charlie@example.com"]
  },
  "tagOwners": {
    "tag:server": ["group:admins"]
  },
  "acls": [
    {
      "action": "accept",
      "src": ["group:admins"],
      "dst": ["tag:server:*"]
    },
    {
      "action": "accept",
      "src": ["group:developers"],
      "dst": ["tag:server:22,80,443"]
    }
  ]
}

Los desarrolladores obtienen acceso SSH (22) y web (80, 443). Los administradores tienen acceso completo. Nadie más puede alcanzar el servidor. Tailscale aplica estas reglas a nivel de cliente, por lo que el tráfico se bloquea antes de llegar al servidor.

MagicDNS

Tailscale incluye MagicDNS, que da a cada dispositivo un nombre de host resolvible dentro del tailnet. En vez de recordar 100.64.0.1, haces SSH a vps-frankfurt. Actívalo en la consola de administración en los ajustes DNS. Sin necesidad de Unbound ni configuración DNS manual.

¿Qué es Headscale y cuándo deberías usarlo?

Headscale es una implementación de código abierto y autoalojada del servidor de coordinación de Tailscale. Usa los clientes Tailscale estándar pero ejecuta el plano de control en tu propia infraestructura. Sin límites de dispositivos, sin telemetría, sin dependencia del SaaS de Tailscale. Compatible con todos los clientes oficiales de Tailscale (Linux, macOS, Windows, iOS, Android).

La arquitectura:

┌─────────────┐       ┌──────────────────┐       ┌─────────────┐
│  Cliente A   │──────▶│   Headscale      │◀──────│  Cliente B   │
│  (tailscale) │       │ (tu servidor)    │       │  (tailscale) │
└──────┬───────┘       └──────────────────┘       └──────┬───────┘
       │                                                  │
       └────────────── Túnel WireGuard ───────────────────┘
                     (directo, peer-to-peer)

Headscale gestiona el intercambio de claves, el registro de dispositivos y la aplicación de ACLs. El tráfico VPN real fluye directamente entre peers usando WireGuard. Headscale nunca ve tu tráfico de datos, solo metadatos de coordinación.

Lo que Headscale soporta hoy: registro de dispositivos (CLI y OIDC), ACLs, routers de subred, nodos de salida, MagicDNS, claves pre-autorizadas y etiquetado. Cubre el conjunto de funciones principales de Tailscale.

Lo que no soporta: Tailscale Funnel, Serve, logs de flujo de red y algunas funciones beta. La interfaz de administración es solo por línea de comandos. Existen interfaces web creadas por la comunidad (headscale-ui) pero no cubren todas las funciones.

Cuándo tiene sentido Headscale:

  • La normativa prohíbe servidores de coordinación de terceros. Pueden requerirse acuerdos de tratamiento de datos RGPD para el SaaS de Tailscale. Headscale elimina esa dependencia.
  • Necesitas más dispositivos de los que permite el plan gratuito de Tailscale.
  • Quieres control total de auditoría sobre el registro de dispositivos y la gestión de claves.
  • Estás construyendo infraestructura donde depender de un SaaS externo es un punto único de fallo.

Cuándo no:

  • Necesitas la red global de relays DERP de Tailscale para travesía NAT fiable. Headscale puede usar DERP, pero debes ejecutar tus propios relays o aceptar usar los públicos de Tailscale.
  • Quieres una interfaz de administración pulida. Headscale está orientado a la línea de comandos.
  • Tienes un equipo pequeño y ninguna gana de mantener otro servicio.

Un tutorial completo de configuración de Headscale está previsto para un artículo futuro. Mientras tanto, consulta la documentación de Headscale.

WireGuard vs Tailscale vs Headscale: ¿cuál encaja en tu caso?

Usa WireGuard si necesitas control total, latencia mínima, redes air-gapped o requisitos regulatorios que prohíban servidores de coordinación de terceros. Usa Tailscale si gestionas múltiples dispositivos, necesitas travesía NAT sin redirección de puertos o quieres ACLs sin configuración manual. Para equipos que quieren funciones de Tailscale con control autoalojado, considera Headscale.

Dimensión WireGuard Tailscale Headscale
Tiempo de instalación 10-15 min por peer 2 min por dispositivo 30-60 min (servidor + clientes)
Gestión de claves Manual (generar, distribuir, rotar tú mismo) Automática (servidor de coordinación) Automática (tu servidor de coordinación)
Travesía NAT Ninguna. Requiere redirección de puertos o IP pública en al menos un lado Integrada (relays DERP + STUN) Parcial (DERP propio o relays públicos)
Descubrimiento de peers Configuración manual por peer Malla automática Malla automática
ACLs Reglas de firewall (nftables/iptables) Archivo de política en la consola admin Archivo de política en tu servidor
Dispositivos máx. Ilimitados El plan gratuito tiene límites (ver página de precios) Ilimitados
Malla multi-cloud Config en cada nodo, N*(N-1)/2 entradas de peers Unirse al tailnet, la malla se forma sola Como Tailscale, control autoalojado
Dependencia de terceros Ninguna Tailscale Inc. (solo coordinación) Ninguna
RGPD / cumplimiento Control total, sin procesador de datos externo Tailscale procesa metadatos de dispositivos Control total
DNS Manual (Unbound, etc.) MagicDNS (automático, nombres por dispositivo) MagicDNS (con configuración)
Latencia Mínima (WireGuard a nivel de kernel) Mínima en directo; +20-50 ms con relay DERP Como Tailscale
Incorporación de equipo Compartir configs y claves manualmente Enlace de invitación, login SSO Registro vía CLI o OIDC
Defensa post-cuántica PreSharedKey (configuración manual) No configurable por el usuario No configurable por el usuario

Atajos de decisión

Desarrollador en solitario, un VPS: WireGuard. El camino más simple. Cero dependencias. La menor latencia posible. Generas dos claves y escribes dos archivos de configuración.

Equipo de 3 a 15, múltiples dispositivos: Tailscale. El servidor de coordinación ahorra horas de gestión de claves. Las ACLs son más limpias que mantener reglas nftables por peer. La travesía NAT funciona sin cambios en la red.

Entorno regulado u obligación de autoalojamiento: Headscale si quieres la experiencia Tailscale sin la dependencia de terceros. WireGuard puro si quieres cero piezas móviles y tu equipo puede gestionar configuraciones.

Malla multi-cloud (5+ nodos en distintos proveedores): Tailscale o Headscale. Con WireGuard, 10 nodos requieren 45 entradas de peers en total. Con 20 nodos, son 190. La carga de gestión de configuración crece cuadráticamente.

Acceso a endpoint de inferencia IA: Si haces túnel a un VPS GPU desde tu portátil, ambos funcionan. Tailscale es más rápido de configurar. WireGuard no añade overhead medible para llamadas de inferencia sensibles a la latencia. Para configuraciones multi-GPU entre proveedores, la malla de Tailscale merece la pena.

Solución de problemas

Túnel WireGuard activo pero no fluye tráfico:

Comprueba el reenvío de IP:

sysctl net.ipv4.ip_forward

Debería devolver net.ipv4.ip_forward = 1. Comprueba que las reglas de masquerade están cargadas:

sudo nft list ruleset | grep masquerade

Si está vacío, las reglas PostUp no se ejecutaron. Reinicia con sudo systemctl restart wg-quick@wg0 y revisa journalctl -u wg-quick@wg0 en busca de errores.

El handshake de WireGuard nunca se completa:

sudo wg show

Si latest handshake nunca aparece para un peer, el puerto UDP 51820 está bloqueado en algún punto. Confirma que el servidor está escuchando:

sudo ss -ulnp | grep 51820

UNCONN 0      0        0.0.0.0:51820      0.0.0.0:*

WireGuard usa el módulo del kernel directamente, así que ss puede no mostrar un nombre de proceso para el socket.

Luego prueba desde el lado del cliente. Si tu cliente está detrás de un firewall corporativo, el UDP 51820 puede estar bloqueado. Algunas redes solo permiten TCP 443.

Tailscale muestra "offline" en la consola de administración:

sudo systemctl status tailscaled

Si está ejecutándose pero aparece offline, reautentifícate:

sudo tailscale up --force-reauth

Si tailscaled no está ejecutándose, comprueba conflictos de puertos con otro software VPN.

DNS sigue filtrándose tras instalar Unbound:

Comprueba que Unbound escucha en la IP de WireGuard:

ss -ulnp | grep :53

Busca 10.66.66.1:53 en la salida. Si Unbound solo se vincula a 127.0.0.1, revisa las líneas interface: en /etc/unbound/unbound.conf.d/wireguard.conf.

En Ubuntu, comprueba también que systemd-resolved está realmente parado:

sudo systemctl is-active systemd-resolved

Si devuelve active, está compitiendo con Unbound por el puerto 53.

Logs de servicios:

journalctl -u wg-quick@wg0 -f
journalctl -u tailscaled -f
journalctl -u unbound -f

Copyright 2026 Virtua.Cloud. Todos los derechos reservados. Este contenido es una obra original del equipo de Virtua.Cloud. La reproducción, republicación o redistribución sin permiso escrito está prohibida.

¿Listo para probarlo?

Despliega tu propio servidor en segundos. Linux, Windows o FreeBSD.

Ver planes VPS