Configurar un VPS como nodo de salida de Tailscale

Qué hace un nodo de salida de Tailscale

Un nodo de salida de Tailscale es una máquina de tu tailnet que transporta todo el tráfico de Internet de los demás dispositivos. Un VPS (servidor privado virtual) es una buena opción porque tiene una dirección pública fija y permanece conectado. Configurarlo requiere cinco pasos: instalar Tailscale en el servidor, anunciar el nodo de salida, habilitar el reenvío de IP, aprobar la ruta en la consola de administración y seleccionar el nodo en el portátil. El cuarto paso consiste en activar una opción en una página web, no en ejecutar un comando. Ahí es donde suele atascarse la mayoría de los usuarios.

Una vez activada, la VPN cifra cada paquete y lo envía al VPS. El VPS aplica NAT de origen (traducción de direcciones de red) y reenvía el paquete con su propia dirección IP pública. Los sitios web ven el VPS. La red Wi-Fi de la cafetería sólo ve un flujo UDP cifrado hacia el VPS y nada más. Sin un nodo de salida, Tailscale sólo transporta tráfico entre tus propios dispositivos, y cada sitio web sigue viendo tu dirección real. Esta es la diferencia que determina si Tailscale cuenta como VPN.

Tailscale usa WireGuard para el plano de datos y un servidor de coordinación que distribuye las claves y ayuda a que dos máquinas se encuentren a través de NAT. Por eso no es necesario copiar claves en los pasos siguientes. Para consultar una comparación detallada de las ventajas y desventajas, lea cómo se comparan Tailscale y WireGuard sin modificaciones. Si prefiere administrar personalmente todos los componentes del túnel, configure una VPN WireGuard sin modificaciones en su VPS.

Los pasos siguientes presuponen que Tailscale ya se está ejecutando en el portátil y que ambas máquinas han iniciado sesión en la misma tailnet. Una tailnet es su red privada de Tailscale. Salvo que un administrador haya desactivado IPv4 en ella, cada dispositivo recibe una dirección estable dentro de 100.64.0.0/10.

Instalar Tailscale en su VPS

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

El script de instalación selecciona el repositorio de paquetes para su distribución e instala el demonio tailscaled. A continuación, tailscale up muestra una URL de autenticación. Ábrala en un navegador e inicie sesión con la misma cuenta que utiliza en su equipo portátil, ya que un VPS conectado a una tailnet diferente no podrá dar servicio a su portátil.

tailscale status
tailscale ip -4

tailscale status debería mostrar ahora ambas máquinas. tailscale ip -4 imprime la dirección de la tailnet del VPS, que es la que proporcionará al cliente más adelante.

Tailscale necesita un dispositivo TUN para establecer el túnel. En un VPS basado en KVM, el dispositivo ya está presente. En planes basados en virtualización de contenedores que comparten el kernel del host, /dev/net/tun a veces no está disponible y tailscaled no puede crear la interfaz tailscale0. Ejecute ls -l /dev/net/tun antes de continuar.

Habilitar el reenvío de IP, o el VPS descartará cada paquete

Una máquina Linux descarta cualquier paquete que no esté dirigido a sí misma, porque net.ipv4.ip_forward es 0 de forma predeterminada. El nodo de salida aceptaría su tráfico, lo descifraría y luego lo descartaría. Escriba la configuración en un archivo para que persista tras un reinicio.

echo 'net.ipv4.ip_forward = 1' | sudo tee -a /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

tee -a añade contenido al final, por lo que ejecutar estas líneas una segunda vez escribirá ambas configuraciones dos veces. El resultado sigue funcionando, pero cat /etc/sysctl.d/99-tailscale.conf se verá extraño. Confirme el valor en tiempo real en lugar de confiar en el archivo:

sysctl net.ipv4.ip_forward

Debe imprimir net.ipv4.ip_forward = 1. Si omite esto y utiliza tailscale up --advertise-exit-node, el cliente le indicará:

Warning: IP forwarding is disabled, subnet routing/exit nodes will not work.

tailscale set --advertise-exit-node no ejecuta esa comprobación, por lo que el silencio de set no es prueba de que el reenvío esté activo. Lea el valor de sysctl usted mismo.

No necesita escribir una regla de enmascaramiento manualmente. tailscaled instala sus propias cadenas de firewall, llamadas ts-input, ts-forward y ts-postrouting, y la regla NAT para el tráfico del nodo de salida reside en ts-postrouting. Consúltelas con sudo iptables-save | grep ts-, o con sudo nft list ruleset en un sistema con nftables.

Anunciar el VPS como nodo de salida

sudo tailscale set --advertise-exit-node

tailscale set cambia una preferencia y mantiene las demás intactas. tailscale up --advertise-exit-node también anuncia el nodo, pero tiene un efecto secundario: up interpreta las flags de su línea de comandos como el conjunto completo de configuraciones no predeterminadas, por lo que una ejecución posterior de sudo tailscale up sin argumentos fallará y mostrará:

changing settings via 'tailscale up' requires mentioning all
non-default flags. To proceed, either re-run your command with --reset or
use the command below to explicitly mention the current value of
all non-default settings:

Utilice set para cambios continuos y evitará este mensaje.

El anuncio es una oferta. El VPS le comunica al servidor de coordinación que está disponible para actuar como nodo de salida. Ningún cliente puede utilizarlo todavía.

Aprobar el nodo de salida de Tailscale en la consola de administración

Este paso no requiere ejecutar comandos. Abra la página de máquinas en la consola de administración, localice el VPS, abra el menú de tres puntos al final de su fila, seleccione Edit route settings y active Use as exit node.

Mientras ese interruptor esté desactivado, el plano de control retiene la oferta y no la asigna a nadie. tailscale exit-node list en su equipo portátil no muestra nada y su tráfico mantiene su ruta habitual. No aparece ningún mensaje de error en ninguna de las máquinas. El nodo de salida simplemente no aparece.

Puede aprobar nodos de salida automáticamente mediante una entrada en el archivo de políticas de la tailnet:

"autoApprovers": {
  "exitNode": ["tag:exit"],
}

Un dispositivo iniciado con --advertise-tags=tag:exit se aprueba automáticamente, siempre que tag:exit esté definido bajo tagOwners en el mismo archivo de políticas. El etiquetado cambia la propiedad: un dispositivo etiquetado pertenece a la tailnet en lugar de a su cuenta de usuario, y las reglas de acceso que se le aplican cambian en consecuencia. Para un solo VPS, el interruptor es más sencillo.

Seleccione el nodo de salida en su equipo portátil

En un cliente Linux:

tailscale exit-node list
sudo tailscale set --exit-node=vps.your-tailnet.ts.net

exit-node list muestra los nodos de salida aprobados en su tailnet junto con sus direcciones. Una lista vacía significa que el paso de aprobación no se completó. En macOS, Windows, iOS y Android, la misma opción se encuentra en el menú Exit Node dentro de la aplicación Tailscale.

Verifique desde el cliente, nunca desde el servidor:

curl -4 https://ifconfig.me

Ejecútelo una vez antes de seleccionar el nodo de salida y otra después. La dirección debe cambiar de la local a la IP pública del VPS. Para dejar de usar el nodo de salida:

sudo tailscale set --exit-node=

Hay un parámetro adicional importante desde el primer día. Con un nodo de salida seleccionado, el cliente envía todo el tráfico a través del túnel, incluidos los paquetes dirigidos a 192.168.1.50, por lo que su impresora y su almacenamiento en red dejarán de responder. Mantenga la red local en la ruta local:

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

Por qué su DNS cambia al activar el nodo de salida

De forma predeterminada, un dispositivo que utiliza un nodo de salida también emplea dicho nodo como su resolvedor DNS (sistema de nombres de dominio) para todos los dominios, lo cual anula los servidores de nombres globales y divididos configurados para su tailnet. Este comportamiento es deliberado. Si las consultas siguieran dirigiéndose al resolvedor de la red local, el router de una cafetería podría ver el nombre de cada sitio que visita, incluso si el tráfico en sí fuera privado. Los nombres y los paquetes deben salir desde el mismo lugar.

Una consecuencia afecta a quienes ejecutan un resolvedor interno: un servidor de nombres de la tailnet del cual usted depende deja de utilizarse mientras el nodo de salida está activo. Active Use with exit node para ese servidor de nombres en la página DNS de la consola de administración para restablecerlo.

Los nombres de MagicDNS siguen funcionando porque el cliente de Tailscale los responde localmente en 100.100.100.100 antes de que cualquier cosa llegue al nodo de salida. Verifíquelo con dig @100.100.100.100 your-vps.your-tailnet.ts.net, o en un cliente con systemd-resolved mediante resolvectl status, donde la interfaz de Tailscale muestra 100.100.100.100 como su servidor DNS.

Si deshabilita la gestión de DNS de Tailscale con --accept-dns=false, el cliente mantiene el resolvedor que obtuvo de la red local. El tráfico se tuneliza pero las consultas no, lo que resulta en la misma fuga de DNS que afecta a los túneles WireGuard configurados manualmente. No modifique --accept-dns a menos que tenga una razón específica para hacerlo.

IPv6 a través del nodo de salida

Un nodo de salida anuncia las dos rutas predeterminadas, 0.0.0.0/0 y ::/0. Si el VPS no tiene una ruta IPv6 operativa hacia Internet, los paquetes IPv6 llegan por el túnel y se detienen allí. Pruebe el VPS antes de confiar en él:

ip -6 addr show
curl -6 https://ifconfig.me

Si una solicitud no logra conectarse, el VPS no tiene una ruta IPv6 operativa hacia el exterior. Si curl muestra "Could not resolve host", el problema está en la resolución de nombres y no en IPv6. Corrija el DNS en el VPS y vuelva a ejecutar la prueba. Los sitios web con doble pila normalmente siguen cargando porque los clientes que implementan Happy Eyeballs, incluido curl, inician un intento IPv4 en paralelo cuando el intento IPv6 no se ha conectado después de una espera breve y conservan la conexión que se establece primero. curl espera 200 milisegundos de forma predeterminada, por lo que esa espera añade un retraso a las conexiones nuevas en lugar de producir un error. Los destinos que sólo tienen IPv6 siguen siendo inaccesibles.

La otra parte es el reenvío. net.ipv4.ip_forward = 1 con net.ipv6.conf.all.forwarding establecido en 0 proporciona una ruta IPv4 operativa y un agujero negro para IPv6. El usuario lo percibe como que "algunos sitios son lentos", no como un error que se pueda buscar fácilmente. Ambas líneas deben estar en el archivo de sysctl.

¿Debe anunciar también rutas de subred el VPS?

Un nodo de salida transporta todo el tráfico de Internet. Una ruta de subred transporta un único rango privado situado detrás de la máquina que lo anuncia. Son funciones independientes con aprobaciones independientes, y una misma máquina puede hacer ambas cosas. Ninguna de las dos expone un servicio que se ejecute en el propio VPS. Si lo que realmente necesita es una URL HTTPS para una aplicación de ese servidor, las funciones serve y funnel son las adecuadas.

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

Anuncie una subred cuando el VPS comparta una red privada con otros servidores a los que quiera acceder mediante sus direcciones privadas. Apruébela en el mismo panel Edit route settings, mediante su propio interruptor. Los clientes Linux ignoran la ruta anunciada hasta que se pasa --accept-routes. Esta es una de las diferencias que explica en detalle el tutorial sobre enrutadores de subred.

Elija el rango con cuidado. Una vez aprobada una ruta, un portátil que la acepte (Windows, macOS, iOS y Android lo hacen de forma predeterminada; Linux, después de --accept-routes) puede enviar al túnel el tráfico destinado a ese rango. Si aprueba 192.168.1.0/24 desde el VPS y un portátil de una red doméstica usa el mismo rango, esas direcciones pueden pasar al túnel y los dispositivos de su escritorio dejarán de responder. Use un rango que haya elegido usted, no el que haya elegido el router doméstico.

Acelere el exit node con el reenvío UDP GRO

Tailscale 1.54 y versiones posteriores, con un kernel Linux 6.2 o posterior, pueden usar una descarga de recepción que aumenta el rendimiento del tráfico reenviado. GRO (generic receive offload) combina los paquetes entrantes antes de que el kernel los procese individualmente. En octubre de 2026, esto todavía requiere un paso manual en el exit node.

sudo apt install -y ethtool
NETDEV=$(ip -o route get 8.8.8.8 | cut -f 5 -d " ")
sudo ethtool -K $NETDEV rx-udp-gro-forwarding on rx-gro-list off

ip -o route get 8.8.8.8 informa de la interfaz que realmente proporciona acceso a Internet, por lo que no tiene que adivinar entre eth0, ens3 y enp1s0. Confírmelo con ethtool -k $NETDEV | grep udp-gro-forwarding, que ahora debería mostrar on. GRO sólo ayuda cuando la ruta funciona correctamente. Si el exit node sigue siendo lento después, mida la propia ruta de la misma forma que lo haría con un túnel WireGuard simple que funciona más lento que el enlace subyacente.

El ajuste se pierde al reiniciar. En un sistema que ejecuta networkd-dispatcher, hágalo automático:

printf '#!/bin/sh\n\nethtool -K %s rx-udp-gro-forwarding on rx-gro-list off \n' "$(ip -o route get 8.8.8.8 | cut -f 5 -d " ")" | sudo tee /etc/networkd-dispatcher/routable.d/50-tailscale
sudo chmod 755 /etc/networkd-dispatcher/routable.d/50-tailscale

Compruebe primero que exista /etc/networkd-dispatcher/routable.d/. Si no existe, la máquina no ejecuta networkd-dispatcher. En ese caso, una unidad pequeña de systemd que ejecute la línea ethtool durante el arranque realiza la misma tarea.

Qué implica la política de uso aceptable de su proveedor para el tráfico del exit node

Cada paquete que un cliente envía a través del exit node sale con la dirección IP pública del VPS, por lo que se atribuye a su cuenta. Los informes de abuso llegan a su bandeja de entrada: avisos de copyright y quejas por análisis de puertos. Lea la AUP (acceptable use policy) de su proveedor antes de enrutar el tráfico de un hogar o un equipo a través de un solo servidor. No abra un exit node a personas de las que no pueda responder.

El ancho de banda se contabiliza una vez, al salir. Cada byte que pasa por el exit node atraviesa el VPS dos veces: llega por un lado y sale por el otro. En la mayoría de los planes VPS, sólo se mide la mitad de salida. En octubre de 2026, SSD Nodes indica la asignación de cada plan KVM como transferencia saliente, desde 4TB hasta 48TB al mes, y la documentación de Vultr establece que el tráfico entrante no se mide. En una descarga, el tramo medido es el recorrido desde el VPS hasta su portátil a través del túnel. En una subida, es el recorrido desde el VPS hacia Internet. En ambos casos, todo lo que enrute a través del exit node cuenta una vez contra la asignación, y una transmisión de vídeo vista a través de un exit node consume más asignación de la que muchas personas esperan. Compruebe su propio plan, porque un proveedor que mida ambas direcciones contabiliza esa transmisión dos veces.

Los rangos de direcciones de los centros de datos también tienen una reputación asociada. Algunos sitios les muestran más CAPTCHA y algunos servicios de streaming los rechazan directamente. Ningún ajuste de su configuración cambia esto, porque es una propiedad del bloque de direcciones que posee su proveedor.

Por qué el tráfico sigue saliendo a través de su conexión local

El nodo de salida está anunciado pero no aprobado. tailscale exit-node list en el cliente no muestra nada y ninguna de las máquinas registra un error. Vaya a la página de Machines y active Use as exit node.

El cliente nunca lo seleccionó. La aprobación hace que el nodo esté disponible para la tailnet. La selección es una acción independiente en cada dispositivo. Ejecute sudo tailscale set --exit-node=<name> de nuevo y luego verifique curl -4 https://ifconfig.me otra vez.

El reenvío está desactivado. El síntoma es específico: tailscale ping <vps> tiene éxito, el túnel está claramente activo y cada dirección externa agota el tiempo de espera. sysctl net.ipv4.ip_forward muestra 0. Corrija el archivo sysctl y luego ejecute sudo sysctl -p /etc/sysctl.d/99-tailscale.conf.

Un firewall descarta los paquetes reenviados. tailscaled inserta su propia cadena ts-forward y, en un VPS limpio, eso es suficiente. Un equipo que ya ejecuta ufw o Docker puede terminar con una política FORWARD en DROP y reglas ordenadas antes que las de Tailscale. No adivine cuál es: ejecute sudo iptables -L FORWARD -n -v mientras el cliente intenta cargar una página y observe qué contadores aumentan. En un equipo con ufw, la solución habitual es DEFAULT_FORWARD_POLICY="ACCEPT" en /etc/default/ufw, seguido de sudo ufw reload. Verifique también el firewall de red de su proveedor en el panel de control, ya que es un control independiente de cualquier cosa que se ejecute en el servidor.

Funciona, pero es lento. Ejecute tailscale netcheck en ambas máquinas. Si informa que UDP está bloqueado, los dos dispositivos no pueden establecer una ruta directa y recurren a un relé DERP, lo que añade latencia a cada conexión. Permitir UDP entrante en el puerto 41641 hacia el VPS en el firewall de red del proveedor suele restaurar la ruta directa.

Cuándo dejar el servidor de coordinación de Tailscale

Todo lo anterior depende del servidor de coordinación alojado de Tailscale para el intercambio de claves y para la aprobación que realizó. El tráfico viaja directamente del portátil al VPS, o a través de uno de los relés DERP de Tailscale cuando no se puede establecer una ruta directa. El servidor de coordinación nunca transporta ese tráfico, aunque decide quién puede unirse al tailnet y a qué dispositivos puede acceder cada equipo. El precio rara vez es el motivo para cambiar, porque el plan gratuito cubre seis usuarios con dispositivos propios ilimitados. Por tanto, evalúe la dependencia en sí y no el coste. El séptimo usuario es el punto en el que esto cambia. Como Tailscale factura por usuario y no por dispositivo, calcule cuánto paga realmente un hogar o un equipo de cinco personas antes de decidir por motivos económicos. Evaluar la situación correctamente requiere saber a qué recursos podría acceder realmente un servidor de coordinación comprometido o una cuenta de identidad robada. Esto se explica en el modelo de confianza de Tailscale. Si quiere eliminar esa dependencia, ejecute Headscale como su propio servidor de control de Tailscale y apunte ambos clientes a él. Después, los pasos para usar el nodo de salida son los mismos. La aprobación de la ruta se realiza mediante la línea de comandos de Headscale en lugar de la consola alojada. Headscale sustituye el plano de control, pero permite seguir usando los clientes de Tailscale. Si prefiere ejecutar toda la pila por su cuenta, NetBird incluye su propio servidor de coordinación y clientes que puede alojar en un VPS.

FAQ

¿Por qué mi tráfico sigue usando mi conexión local después de seleccionar el nodo de salida?

Hay dos causas habituales. El nodo de salida se anunció, pero nunca se aprobó: abra la página Machines en la consola de administración, busque el VPS, seleccione Edit route settings y active Use as exit node. La aprobación es un interruptor de la consola; ningún comando del servidor la realiza. La segunda causa es diferente: el reenvío IP está desactivado. El túnel se establece, tailscale ping al VPS funciona y todas las direcciones externas agotan el tiempo de espera. Compruébelo con sysctl net.ipv4.ip_forward, cuyo valor debe ser 1.

¿Tengo que aprobar manualmente el nodo de salida cada vez?

El interruptor se activa una sola vez para cada máquina. Si reconstruye el VPS con frecuencia, añada un bloque autoApprovers a su archivo de políticas de tailnet que contenga "exitNode": ["tag:exit"], defina tag:exit en tagOwners y active el nodo con --advertise-tags=tag:exit. Un dispositivo etiquetado pertenece a la tailnet y no a su cuenta de usuario, por lo que las reglas de acceso que se le aplican también cambian.

¿Qué servidor DNS usa mi portátil mientras hay un nodo de salida activo?

El propio nodo de salida. Un dispositivo que usa un nodo de salida envía allí todas las consultas DNS, lo que anula los servidores DNS globales y de DNS dividido configurados para la tailnet. La red local deja de ver los nombres que consulta. Para mantener un servidor de nombres de la tailnet, active Use with exit node para ese servidor en la página DNS de la consola de administración. Los nombres de MagicDNS siguen resolviéndose porque el cliente de Tailscale responde localmente en 100.100.100.100.

¿Puede un mismo VPS ser un nodo de salida y un router de subred al mismo tiempo?

Sí. sudo tailscale set --advertise-exit-node y sudo tailscale set --advertise-routes=10.0.0.0/24 son independientes, y cada uno tiene su propio interruptor de aprobación en Edit route settings. El reenvío IP debe estar activado en el VPS para ambos. Evite anunciar un rango que coincida con la red doméstica de su portátil. Cuando esa ruta se aprueba y el portátil la acepta, puede apropiarse de esas direcciones en lugar de la red local, y los dispositivos locales dejan de ser accesibles.

¿Un nodo de salida oculta mi tráfico al proveedor del VPS?

No. El túnel termina en el VPS, por lo que el tráfico sale del servidor en el formato que espera el destino. El proveedor lo transporta sin cifrar cuando el propio sitio no usa cifrado. Un nodo de salida cambia el punto donde el tráfico se incorpora a Internet: pasa de la red a la que está conectado al servidor que alquila. Oculta la navegación de la Wi-Fi de una cafetería y de su ISP doméstico, pero muestra esa misma navegación al proveedor del VPS con su nombre de cuenta asociado.