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 en su tailnet que transporta todo el tráfico de internet de sus otros dispositivos. Un VPS (servidor privado virtual) es una buena opción porque tiene una dirección pública fija y permanece en línea. Configurar uno 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, finalmente, seleccionar el nodo en su portátil. El cuarto paso es una casilla de verificación en una página web y no un comando; ahí es donde la mayoría de las personas se detienen.

Una vez activado, su portátil cifra cada paquete y lo envía al VPS. El VPS aplica NAT (traducción de direcciones de red) de origen y envía el paquete con su propia dirección IP pública. Los sitios web ven al VPS. El Wi-Fi de una cafetería solo ve un flujo UDP cifrado hacia el VPS y nada más. Sin un nodo de salida, Tailscale solo transporta tráfico entre sus propios dispositivos y cada sitio web sigue viendo su dirección real, lo cual es la distinción detrás de si Tailscale cuenta realmente como una VPN.

Tailscale es WireGuard para la ruta de datos más un servidor de coordinación que distribuye claves y ayuda a dos máquinas a encontrarse a través de NAT. Ese servidor de coordinación es la razón por la que no hay copia de claves en ninguna parte a continuación. Para conocer las ventajas y desventajas detalladas, lea cómo se comparan Tailscale y WireGuard estándar. Si prefiere gestionar cada parte del túnel usted mismo, autoaloje una VPN WireGuard estándar en su VPS en su lugar.

Los pasos a continuación asumen que Tailscale ya se ejecuta en su portátil y que ambas máquinas han iniciado sesión en la misma tailnet. Una tailnet es su red privada de Tailscale y, a menos que un administrador haya desactivado IPv4 para ella, cada dispositivo en ella obtiene 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 y localice el VPS, que ahora debería mostrar una insignia de Exit Node. Abra el menú de ese dispositivo, seleccione Edit exit node, marque la casilla Use as exit node y haga clic en Save.

Mientras esa casilla no esté marcada y guardada, el plano de control retiene la oferta y no la asigna a nadie. tailscale exit-node list en su 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 único VPS, el uso de la casilla de verificación 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.

¿Debería 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 rango privado que se encuentra detrás de la máquina que lo anuncia. Son funciones independientes con aprobaciones independientes, y una misma máquina puede realizar ambas. Ninguna de ellas expone un servicio que se ejecute en el propio VPS, por lo que si lo que realmente necesita es una URL HTTPS para una aplicación en ese servidor, serve y funnel son las funciones que debe utilizar.

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 desee acceder mediante sus direcciones privadas. Apruébela en su propio cuadro de diálogo, separado del nodo de salida: en la página Machines, seleccione el VPS, vaya a su sección Subnets, seleccione Edit para abrir Edit subnet routes, seleccione la ruta y, a continuación, seleccione Save. Los clientes Linux ignoran la ruta anunciada hasta que usted ejecute --accept-routes, que es una de las diferencias que la guía de configuración del enrutador de subred cubre en detalle.

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 tráfico para ese rango a través del túnel. Apruebe 192.168.1.0/24 desde el VPS y un portátil en una red doméstica que utilice el mismo rango puede perder esas direcciones en favor del túnel, y los dispositivos de su escritorio dejarán de responder. Utilice un rango que usted haya elegido, no el rango que su router doméstico eligió por usted.

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 Machines, elija Edit exit node en el menú del VPS, marque Use as exit node y seleccione Save.

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 cualquier 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 ejecute 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. Compruebe 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 el tráfico 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?

Existen dos causas comunes. El nodo de salida se anunció pero nunca se aprobó: abra la página Machines en la consola de administración, busque el VPS, elija Edit exit node en su menú, marque Use as exit node y seleccione Save. La aprobación se realiza en la consola y ningún comando en el servidor puede ejecutarla. La segunda causa es distinta: el reenvío de IP está desactivado, por lo que el túnel se establece, tailscale ping hacia el VPS funciona, pero cualquier dirección externa agota el tiempo de espera. Verifique con sysctl net.ipv4.ip_forward, que debe devolver 1.

¿Debo aprobar el nodo de salida manualmente cada vez?

La aprobación es una acción única 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 bajo tagOwners e inicie el nodo con --advertise-tags=tag:exit. Un dispositivo etiquetado pertenece a la tailnet en lugar de a su cuenta de usuario, por lo que las reglas de acceso que se le aplican también cambian.

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

El propio nodo de salida. Un dispositivo que utiliza un nodo de salida envía todas las consultas DNS allí, lo que anula los servidores DNS globales y divididos configurados para la tailnet. Esto evita que la red local vea los nombres que usted consulta. Para mantener un servidor de nombres de la tailnet activo, habilite Use with exit node para él en la página DNS de la consola de administración. Los nombres de MagicDNS siguen resolviéndose, ya que el cliente de Tailscale los responde localmente en 100.100.100.100.

¿Puede un 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 se aprueba en su propio diálogo: el nodo de salida a través de Edit exit node en el menú del dispositivo en la página Machines, y la subred a través de Edit en la sección Subnets del dispositivo, que abre Edit subnet routes. Ambos requieren que el reenvío de IP esté habilitado en el VPS. Evite anunciar un rango que coincida con la red doméstica de su portátil, ya que una vez que esa ruta es aprobada y su portátil la acepta, puede sustraer esas direcciones de su red local y sus dispositivos locales dejarán de ser accesibles.

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

No. El túnel termina en el VPS, por lo que el tráfico sale del servidor en la forma que el destino espera, y su proveedor lo transporta en texto plano siempre que el sitio web no esté cifrado. Un nodo de salida traslada el punto donde su tráfico se une a internet, desde la red en la que se encuentra hasta el servidor que alquila. Oculta su navegación de la red Wi-Fi de una cafetería y de su ISP doméstico, pero muestra esa misma navegación a su proveedor de VPS con su nombre de cuenta asociado.