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 gestiona 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 un interruptor en una página web y no un comando; ahí es donde la mayoría de los usuarios se detiene.

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.

Tailscale es WireGuard para la ruta de datos, sumado a un servidor de coordinación que distribuye claves y ayuda a que dos máquinas se encuentren a través de NAT. Ese servidor de coordinación es la razón por la que no hay que copiar 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, aloje su propia 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 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, 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 ambas rutas por defecto, 0.0.0.0/0 y ::/0. Si el VPS no tiene una ruta IPv6 funcional hacia internet, los paquetes IPv6 llegan a través del túnel y se detienen allí. Realice una prueba en el VPS antes de confiar en él:

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

Una petición fallida significa que el VPS no tiene conectividad IPv6 ascendente. Los sitios web con doble pila (dual stack) suelen cargar de todos modos, ya que el cliente desiste de IPv6 y reintenta mediante IPv4, aunque ese reintento añade latencia en la primera conexión a cada sitio. Los destinos que solo funcionan con IPv6 permanecen inaccesibles.

La otra parte es el reenvío. net.ipv4.ip_forward = 1 con net.ipv6.conf.all.forwarding configurado en 0 le proporciona una ruta IPv4 funcional y un agujero negro para IPv6, lo cual el usuario experimenta como "algunos sitios son lentos" en lugar de un error que alguien pueda buscar. Ambas líneas deben incluirse en el archivo 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 desea 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ébelo en el mismo panel de Edit route settings, en su propio interruptor. Los clientes Linux ignoran la ruta anunciada hasta que usted utiliza --accept-routes, que es una de las diferencias que la guía del router de subred cubre en detalle.

Elija el rango con cuidado. Una ruta anunciada es más específica que la ruta predeterminada de su portátil, por lo que anunciar 192.168.1.0/24 desde el VPS toma el control de las direcciones de una red doméstica que utiliza el mismo rango, y los dispositivos en su escritorio dejarán de responder. Utilice un rango que usted haya elegido, no el rango que su router doméstico eligió por usted.

Acelerar el nodo de salida con reenvío UDP GRO

Tailscale 1.54 y versiones posteriores, sobre un kernel Linux 6.2 o superior, pueden utilizar 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. A fecha de agosto de 2026, este sigue siendo un paso manual en el nodo de salida.

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 accede a internet, por lo que nunca tendrá que adivinar entre eth0, ens3 y enp1s0. Confirme con ethtool -k $NETDEV | grep udp-gro-forwarding, que ahora debería mostrar on. GRO solo ayuda en una ruta que ya funciona correctamente; si el nodo de salida sigue siendo lento después, mida la ruta del mismo modo que lo haría para un túnel WireGuard simple que funciona más lento que el enlace subyacente.

El ajuste se pierde al reiniciar. En un sistema que ejecute networkd-dispatcher, automatícelo:

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 /etc/networkd-dispatcher/routable.d/ existe. Si no existe, la máquina no está ejecutando networkd-dispatcher, y una pequeña unidad de systemd que ejecute la línea ethtool al arrancar realizará la misma función.

Qué significa 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, quejas por escaneos de puertos. Lea la AUP (política de uso aceptable) de su proveedor antes de enrutar una red doméstica o de equipo a través de un servidor, y no abra un nodo de salida a personas por las que no pueda responder.

El ancho de banda cuenta doble. El tráfico llega al VPS a través del túnel y luego sale hacia internet; ambas direcciones suelen computar contra el límite de transferencia de su plan. Una transmisión de video vista a través de un nodo de salida consume más datos de lo que la mayoría espera.

Los rangos de direcciones de los centros de datos también tienen una reputación. Algunos sitios muestran más CAPTCHAs a estas direcciones y algunos servicios de streaming las bloquean directamente. Nada en su configuración cambia esto, ya que 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 prescindir del 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 confirmó. El tráfico sigue viajando directamente del portátil al VPS. El servidor de coordinación nunca lo transporta, aunque sí 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 admite seis usuarios con un número ilimitado de dispositivos propios. Por tanto, valore 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. Para valorarlo con rigor, debe saber a qué recursos podría acceder realmente un servidor de coordinación comprometido o una cuenta de identidad robada. Esto es lo que explica el modelo de confianza de Tailscale. 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 exit node 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 administrar toda la pila, 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 no se aprobó: abra la página Machines en la consola de administración, busque el VPS, elija Edit route settings y active Use as exit node. La aprobación es un interruptor de la consola y ningún comando en el servidor la realiza. 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?

El interruptor 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 impide 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 obtiene su propio interruptor de aprobación en Edit route settings. 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 la ruta anunciada es más específica que la ruta predeterminada y sus dispositivos locales dejarán de estar 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 claro siempre que el sitio web no esté cifrado. Un nodo de salida desplaza el punto donde su tráfico se une a Internet, desde la red en la que usted 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 el nombre de su cuenta asociado.