Cómo usar tu 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 tus otros 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 la mayoría de las personas se detiene.

Cuando está activo, el portátil 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 usando 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.

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

Los pasos siguientes suponen que Tailscale ya se está ejecutando en tu portátil y que ambas máquinas han iniciado sesión en la misma tailnet. Una tailnet es tu red privada de Tailscale, y cada dispositivo que pertenece a ella obtiene una dirección estable dentro de 100.64.0.0/10.

Instalar Tailscale en el VPS

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

El script de instalación selecciona el repositorio de paquetes correspondiente a su distribución e instala el daemon 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 usa su portátil, porque un VPS autenticado en un tailnet diferente no puede proporcionar acceso a su portátil.

tailscale status
tailscale ip -4

tailscale status debería mostrar ahora ambos equipos. tailscale ip -4 muestra la dirección del VPS en el tailnet. Esa es la dirección que proporcionará al cliente más adelante.

Tailscale necesita un dispositivo TUN para crear el túnel. En un VPS KVM, el dispositivo está disponible. En los planes basados en virtualización mediante contenedores que comparten el kernel del host, a veces falta /dev/net/tun 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 descarta todos los paquetes

Una máquina Linux descarta cualquier paquete que no esté dirigido a ella porque net.ipv4.ip_forward es 0 de forma predeterminada. El nodo de salida aceptaría el tráfico, lo descifraría y después lo descartaría. Escriba el ajuste 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 escribe ambos ajustes dos veces. El resultado sigue funcionando y cat /etc/sysctl.d/99-tailscale.conf tendrá un aspecto extraño. Confirme el valor activo en lugar de confiar en el archivo:

sysctl net.ipv4.ip_forward

Debe mostrar net.ipv4.ip_forward = 1. Si omite este paso y usa tailscale up --advertise-exit-node, el cliente le indica lo siguiente:

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

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

No es necesario escribir manualmente una regla de masquerade. 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 se encuentra en ts-postrouting. Consulte las cadenas con sudo iptables-save | grep ts- o use 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 deja las demás intactas. tailscale up --advertise-exit-node también anuncia el nodo y tiene un efecto secundario: up trata las opciones de su línea de comandos como el conjunto completo de ajustes no predeterminados, por lo que un sudo tailscale up posterior sin argumentos no se ejecuta y muestra

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:

Use set para los cambios posteriores y no volverá a aparecer ese mensaje.

Anunciar es una oferta. El VPS informa ahora al servidor de coordinación de que está dispuesto a actuar como nodo de salida. Ningún cliente puede usarlo todavía.

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

Este es el paso que no tiene un comando asociado. Abra la página Machines en la consola de administración, busque el VPS, abra el menú de tres puntos al final de su fila, seleccione Edit route settings y active Use as exit node.

Hasta que active esa opción, el plano de control conserva la oferta y no se la asigna a ningún dispositivo. tailscale exit-node list en su portátil no muestra nada y el tráfico mantiene su ruta normal. No aparece ningún mensaje de error en ninguno de los dos equipos. El nodo de salida simplemente nunca aparece.

Puede aprobar los nodos de salida automáticamente mediante una entrada en el archivo de políticas de 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 aplicables también cambian. Para un solo VPS, la opción de la consola es más sencilla.

Selecciona el nodo de salida en tu 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 tu 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 aparece como elemento de menú en Exit Node, dentro de la aplicación Tailscale.

Verifícalo desde el cliente, nunca desde el servidor:

curl -4 https://ifconfig.me

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

sudo tailscale set --exit-node=

Hay otra opción importante desde el primer día. Con un nodo de salida seleccionado, el cliente envía todo por el túnel, incluidos los paquetes dirigidos a 192.168.1.50, por lo que la impresora y el almacenamiento de red dejan de responder. Mantén la red local en la ruta local:

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

Por qué cambia el DNS en cuanto se activa el nodo de salida

De forma predeterminada, un dispositivo que usa un nodo de salida también usa ese nodo como resolvedor del sistema de nombres de dominio (DNS) para todos los dominios. Esto reemplaza los servidores DNS globales y divididos configurados para tu tailnet. El comportamiento es deliberado. Si las consultas siguieran enviándose al resolvedor de la red local, el router de la cafetería seguiría viendo el nombre de cada sitio que visitas, aunque el tráfico fuera privado. Los nombres y los paquetes deben salir desde el mismo lugar.

Esto afecta especialmente a quienes ejecutan un resolvedor interno: un servidor de nombres de la tailnet del que dependes deja de utilizarse mientras el nodo de salida está activo. Activa Use with exit node para ese servidor de nombres en la página DNS de la consola de administración para volver a utilizarlo.

Los nombres de MagicDNS siguen funcionando porque el cliente de Tailscale los resuelve localmente en 100.100.100.100 antes de que nada llegue al nodo de salida. Compruébalo con dig @100.100.100.100 your-vps.your-tailnet.ts.net o, en un cliente con systemd-resolved, con resolvectl status. Allí la interfaz de Tailscale muestra 100.100.100.100 como su servidor DNS.

Si desactivas la gestión de DNS de Tailscale con --accept-dns=false, el cliente conserva el resolvedor que aprendió de la red local. El tráfico se tuneliza, pero las consultas no, lo que constituye la misma fuga de DNS que afecta a los túneles WireGuard configurados manualmente. Deja --accept-dns sin cambios salvo que tengas un motivo específico para modificarlo.

IPv6 a través del nodo de salida

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

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

Una solicitud fallida significa que el VPS no tiene conectividad IPv6 ascendente. Los sitios web con doble pila normalmente siguen cargando, porque el cliente abandona IPv6 y vuelve a intentarlo mediante IPv4, aunque ese reintento añade un retraso en la primera conexión con cada sitio. Los destinos que sólo ofrecen 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 pueda buscar fácilmente. Ambas líneas deben estar en el archivo de sysctl.

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

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.

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.

Elija el rango con cuidado. Una ruta anunciada es más específica que la ruta predeterminada del portátil. Por tanto, anunciar 192.168.1.0/24 desde el VPS toma el control de las direcciones de una red doméstica que use el mismo rango, y los dispositivos de su escritorio dejan de responder. Use un rango que haya elegido usted, no el que haya elegido su 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 uno por uno. En agosto de 2026, este paso todavía se debe realizar manualmente 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 llega a Internet, por lo que no tiene que elegir entre eth0, ens3 y enp1s0. Confírmelo con ethtool -k $NETDEV | grep udp-gro-forwarding, que ahora debería mostrar on.

La configuración se pierde al reiniciar. En un sistema que ejecuta networkd-dispatcher, hágala automática:

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 función.

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

Cada paquete que un cliente envía a través del nodo de salida 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 derechos de autor y reclamaciones por análisis de puertos. Lea la AUP (política de uso aceptable) de su proveedor antes de encaminar el tráfico de un hogar o un equipo a través de un solo servidor. No abra un nodo de salida a personas cuya actividad no pueda supervisar.

El ancho de banda se contabiliza dos veces. El tráfico llega al VPS a través del túnel y después vuelve a salir hacia Internet. Normalmente, ambas direcciones cuentan para el límite de transferencia del plan. Una transmisión de vídeo vista a través de un nodo de salida consume más transferencia de la que la mayoría espera.

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

Por qué el tráfico sigue saliendo por la 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 dos máquinas registra un error. Abra la página Machines y active Use as exit node.

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

El reenvío está desactivado. El síntoma es específico: tailscale ping <vps> funciona, el túnel está claramente activo y todas las direcciones externas agotan el tiempo de espera. sysctl net.ipv4.ip_forward muestra 0. Corrija el archivo sysctl y ejecute después 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 esto suele ser suficiente. Un equipo que ya ejecuta ufw o Docker puede terminar con una política FORWARD de DROP y con reglas situadas antes que las de Tailscale. No adivine cuál es la causa: 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. Compruebe también el firewall de red de su proveedor en el panel de control, porque es un control independiente de cualquier componente que se ejecute en el servidor.

Funciona, pero es lento. Ejecute tailscale netcheck en ambas máquinas. Si indica que UDP está bloqueado, los dos dispositivos no pueden establecer una ruta directa y usan como alternativa un relay DERP, lo que añade latencia a todas las conexiones. 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 de usar 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 seleccionó. El tráfico sigue circulando directamente del portátil al VPS, y el servidor de coordinación nunca lo transporta. Sin embargo, determina quién puede unirse al tailnet y a qué recursos puede acceder cada dispositivo. Si quiere eliminar esa dependencia, ejecute Headscale como su propio servidor de control de Tailscale y configure ambos clientes para usarlo. Después, los pasos del 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.

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 control 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 funciona con el VPS y todas las direcciones externas agotan el tiempo de espera. Compruébelo con sysctl net.ipv4.ip_forward, que debe mostrar 1.

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

El control es una acción única para cada máquina. Si reconstruye el VPS con frecuencia, añada un bloque autoApprovers al archivo de políticas de su 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 también cambian las reglas de acceso que se le aplican.

¿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 reemplaza los servidores DNS globales y de DNS dividido configurados para la tailnet. Esto impide que la red local vea los nombres que consulta. Para mantener un servidor DNS 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 enrutador 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 control 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, porque la ruta anunciada es más específica que la ruta predeterminada y sus 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 con el formato que espera el destino, y el proveedor lo transporta sin cifrar cuando el propio sitio no usa cifrado. Un nodo de salida cambia el punto donde su tráfico se incorpora a Internet: pasa de la red que está usando al servidor que alquila. Oculta su navegación a la Wi-Fi de la cafetería y a su ISP doméstico, pero muestra esa misma navegación al proveedor del VPS junto con el nombre de su cuenta.