Tailscale vs Cloudflare Tunnel: cuál usar y cuándo

Tailscale vs Cloudflare Tunnel: dos trabajos distintos

Tailscale y Cloudflare Tunnel parecen competir, pero resuelven problemas opuestos. Tailscale crea una red privada entre los dispositivos que tú inscribes, y nadie más entra en ella. Cloudflare Tunnel publica un servicio de tu VPS en internet para cualquier visitante, a través de una conexión que sale desde tu servidor, sin abrir ningún puerto de entrada. Así que la pregunta útil no es cuál es mejor. La pregunta es si quieres que ese servicio lo alcance el mundo o solo tú.

Con un VPS y sin equipo detrás, casi todas las dudas se resuelven en ese punto. SSH, Portainer, el panel de tu servidor de fotos: eso lo quieres privado. Un blog, una demo para un cliente, un endpoint que llama la API de un proveedor: eso tiene que ser público. Las dos herramientas comparten una única virtud técnica, que el servidor nunca acepta conexiones entrantes, y a partir de ahí se separan en todo lo demás.

Qué hace cada herramienta por dentro

Tailscale monta una malla (mesh) de túneles WireGuard entre tus dispositivos. Cada dispositivo genera su clave privada y no la envía a ningún sitio. El servicio de Tailscale actúa como plano de control: autentica a los nodos contra tu proveedor de identidad, reparte las claves públicas y ayuda a los dos extremos a encontrarse a través de sus routers. El tráfico va cifrado de extremo a extremo entre los nodos. Si nunca has usado la herramienta, la explicación de qué es Tailscale y cómo forma su red privada cubre el modelo antes de seguir aquí.

Cloudflare Tunnel funciona al revés. Instalas un demonio llamado cloudflared en el VPS, y ese demonio abre conexiones salientes hacia la red de Cloudflare. Luego apuntas un nombre DNS de tu dominio a ese túnel. Cuando alguien visita ese nombre, su petición llega a un POP (punto de presencia) de Cloudflare, y Cloudflare la mete por la conexión que tu servidor ya tenía abierta. El servidor responde por el mismo camino. Tu firewall puede quedarse cerrado por completo y el sitio sigue funcionando, que es exactamente la idea de publicar un servicio sin abrir puertos.

Quién puede llegar a tu VPS con cada opción

Aquí es donde conviene ser explícito, porque la diferencia no es de grado.

Con Tailscale, la superficie es tu propia red. Solo los dispositivos inscritos en tu tailnet pueden hablar con el servidor por esa interfaz, y las listas de control de acceso (ACL) pueden reducirlo más todavía: este portátil llega al puerto 22 del VPS, el móvil no. Nadie que escanee internet ve el servicio, porque no hay nada escuchando en la IP pública. El riesgo se traslada a tu cuenta de identidad: quien entre en tu cuenta de Google o GitHub puede inscribir un nodo nuevo y aparecer dentro de la red. Por eso existe la firma criptográfica de nodos nuevos con tailnet lock, que obliga a que un dispositivo ya de confianza apruebe cada incorporación.

Con Cloudflare Tunnel, la superficie es internet entero. Publicar un nombre significa que cualquiera puede pedirlo, incluidos los escáneres automáticos que encuentran ese nombre en los registros de certificados a los pocos minutos. Lo que Cloudflare te da es un filtro delante: reglas de firewall de aplicación, límites de peticiones y, si lo configuras, una política de acceso que exige iniciar sesión con un correo concreto antes de dejar pasar la petición. Sin esa política, tu servicio está público. Lo que sí desaparece es la IP de origen: el atacante no puede saltarse el filtro yendo directo a tu servidor, porque tu servidor no acepta nada entrante.

Quién termina el TLS de un nombre publicado

En un túnel de Cloudflare, el TLS (seguridad de la capa de transporte) del visitante termina en el POP de Cloudflare. Cloudflare descifra la petición, la lee y la vuelve a cifrar hacia tu origen. No es un defecto de configuración: es requisito de funcionamiento, porque para enrutar por nombre de host, aplicar reglas o servir una caché hay que ver el HTTP en claro. Puedes activar el modo estricto para que el tramo hasta tu VPS vaya cifrado y validado, y sigue siendo cierto que en el medio existe un punto donde el contenido está en claro.

Eso cambia qué es sensato publicar. Un blog o una landing no pierden nada. Un gestor de contraseñas sí: aunque la bóveda viaje cifrada por el cliente, el JavaScript de la interfaz web se entrega por ese mismo camino, así que quien controle el camino controla el código que se ejecuta en el navegador del usuario. Un servicio de ese tipo pertenece a la red privada, no a un nombre público.

En Tailscale no hay un tercero que descifre. Los datos van en un túnel WireGuard entre los dos dispositivos, y el plano de control reparte claves públicas, nunca privadas. La contrapartida está en otro sitio: ese plano decide qué nodos se conocen entre sí, y ese es el poder real que tiene. El análisis de qué ve y qué no ve el plano de control de Tailscale entra en el detalle.

Qué sigue funcionando si el proveedor no responde

Esta pregunta separa las dos herramientas más que ninguna otra.

Si el plano de control de Tailscale deja de estar accesible, las conexiones directas ya establecidas siguen funcionando, porque el cifrado y el enrutado ocurren entre tus propios dispositivos. Lo que se pierde es la coordinación: no puedes inscribir un nodo nuevo, los cambios de ACL no se propagan y un nodo que estaba usando un relevo de Tailscale pierde ese camino. Además, las claves de nodo caducan por defecto al cabo de unos meses, así que en servidores conviene desactivar esa caducidad para que una avería larga no te deje fuera. Si ese plano de control te incomoda, puedes alojarlo tú con Headscale, la implementación libre del plano de control de Tailscale.

Si el POP de Cloudflare no responde, tu nombre público no responde, y no hay estado local que lo salve: el POP es la puerta de entrada, no un acelerador opcional. Esto no es un argumento contra el producto, es una dependencia que debes aceptar a conciencia. Y tiene una consecuencia práctica: no dejes tu única vía de administración dentro de esa dependencia. Si el túnel es lo único que te conecta al servidor y el túnel falla, te queda la consola del panel del proveedor.

Detrás de CGNAT las dos funcionan

Muchos operadores en España y en América Latina entregan CGNAT (traducción de direcciones a escala de operador), es decir, tu conexión comparte una IP pública con cientos de clientes. Sin IP propia no puedes redirigir puertos, y ahí mueren las guías clásicas de port forwarding. Las dos herramientas de este artículo sirven, porque ninguna necesita puertos entrantes.

Tailscale intenta primero una ruta directa entre los dos dispositivos, perforando el NAT con ayuda del plano de control. Cuando los dos extremos están detrás de un NAT que no colabora, la conexión cae a un relevo (DERP) de Tailscale, que reenvía paquetes ya cifrados sin poder leerlos, y eso añade camino y latencia. Verás la diferencia en tailscale status, que marca cada par como direct o relay; las causas de que una conexión salga relayed en vez de direct explican cómo recuperar la ruta directa. Si lo que querías era exactamente sustituir la redirección de puertos de tu router, el planteamiento de usar Tailscale en lugar de port forwarding es el camino corto.

En Cloudflare Tunnel la pregunta ni aparece: el tráfico siempre pasa por el POP, así que el CGNAT del visitante y el del servidor son irrelevantes.

Cómo se ve cada uno en el VPS

Los comandos que siguen son el ejemplo para que lo ejecutes tú en tu servidor. Los dos procesos necesitan salida a internet y una autenticación en el navegador, así que no reproduzco aquí lo que imprimen: sigue la documentación oficial de cada producto, porque los flags cambian con las versiones.

Tailscale en Ubuntu 24.04 se instala con el script oficial y se activa con un comando:

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

sudo tailscale up te pide autenticar el nodo en el navegador. Después, tailscale status lista los dispositivos de la red y tailscale ip -4 te da la dirección privada del servidor, que es la que usarás para conectarte por SSH.

cloudflared viene del repositorio de paquetes de Cloudflare:

curl -fsSL https://pkg.cloudflare.com/cloudflare-main.gpg | sudo tee /usr/share/keyrings/cloudflare-main.gpg >/dev/null
echo 'deb [signed-by=/usr/share/keyrings/cloudflare-main.gpg] https://pkg.cloudflare.com/cloudflared any main' | sudo tee /etc/apt/sources.list.d/cloudflared.list
sudo apt-get update && sudo apt-get install cloudflared

Y el túnel se crea en tres pasos, con el dominio ya delegado en los servidores de nombres de Cloudflare:

cloudflared tunnel login
cloudflared tunnel create mi-tunel
cloudflared tunnel route dns mi-tunel app.ejemplo.com

El fichero de configuración dice a qué servicio local apunta el túnel:

url: http://localhost:8000
tunnel: <UUID-del-tunel>
credentials-file: /root/.cloudflared/<UUID-del-tunel>.json

Se arranca con cloudflared tunnel run mi-tunel y, cuando la prueba manual funciona, se instala como servicio del sistema para que sobreviva a los reinicios. Un detalle que importa: haz que tu aplicación escuche en 127.0.0.1, no en 0.0.0.0. Si escucha en todas las interfaces, el puerto queda publicado también por la IP pública y el túnel deja de ser tu única puerta. Con contenedores este error es fácil de cometer sin darte cuenta, porque Docker escribe sus reglas por debajo de ufw y publica el puerto de todas formas. Y si vas a cerrar la entrada por completo apoyándote en la red privada, repasa antes las reglas básicas de ufw en un VPS y deja una sesión abierta mientras aplicas los cambios.

Qué elegir en cada caso real

• SSH y cualquier panel de administración: Tailscale. Un panel público invita a intentos de acceso constantes, y en la red privada no hay nada que intentar porque no hay puerto que alcanzar.
• Immich, Jellyfin o Vaultwarden para ti y tu familia: Tailscale. Los usuarios son pocos y conocidos, así que instalar un cliente en cada dispositivo es una vez y ya está. El contenido no pasa por nadie.
• Un sitio web, un blog o una tienda: Cloudflare Tunnel. Los visitantes no van a instalar nada, y la terminación cerca del usuario con caché de estáticos es precisamente lo que quieres.
• Un endpoint de webhook que llama un proveedor de pagos o un repositorio: Cloudflare Tunnel. Quien llama es un servidor ajeno que no puede unirse a tu red.
• Una demo para un cliente durante dos semanas: Cloudflare Tunnel con una política de acceso que exija el correo del cliente, o bien Funnel de Tailscale si prefieres no delegar el TLS. La diferencia entre tailscale serve y Funnel aclara cuál de los dos publica hacia fuera.
• Un servicio privado que debe abrir exactamente una persona de fuera: política de acceso delante del túnel, o Funnel para ese único recurso. Abrir el firewall por una persona es el trato que no deberías aceptar.

Hay un caso frecuente que no es ninguno de los dos: querer salir a internet con la IP de tu VPS, por ejemplo para ver un servicio geográficamente restringido. Eso es un nodo de salida en el VPS, y un túnel de Cloudflare no lo hace. Si lo que buscas es el mecanismo de cifrado por debajo, la comparación entre WireGuard puro y Tailscale explica qué automatiza uno sobre el otro.

Latencia desde España y América Latina

No doy números, porque dependen de tu operador y de dónde esté tu VPS. El mecanismo sí es estable y con él puedes predecir el resultado.

Con Cloudflare Tunnel, el visitante negocia TCP y TLS contra el POP más cercano, y Madrid, São Paulo, Bogotá, Santiago o Querétaro suelen estar a pocos milisegundos de casa. De ahí la petición viaja por la red de Cloudflare hasta el POP donde tu cloudflared está conectado y baja por el túnel a tu servidor. Para una página web esto ayuda mucho: el saludo TLS, que es lo más caro de una visita nueva, ocurre cerca del usuario, la conexión se reutiliza para las decenas de peticiones siguientes y las imágenes se sirven desde la caché sin tocar tu VPS.

Con Tailscale, el cliente intenta hablar directamente con el servidor, así que la latencia es la del camino real de internet entre los dos. Si tu VPS está en Alemania y tú estás en Chile, ese retardo es el suelo y ninguna herramienta lo baja. Lo que sí puedes evitar es empeorarlo: una conexión que cae a relevo añade un desvío.

Por qué importa la distinción: en una sesión SSH cada pulsación de tecla es un viaje de ida y vuelta, y el retardo se nota en los dedos, así que quieres el camino más corto posible y directo. En una carga de página lo que domina son los saludos y la cantidad de peticiones, así que terminar cerca del visitante gana aunque el tramo hasta el origen sea más largo. Mismo servidor, dos criterios contrarios, y por eso mucha gente acaba con las dos herramientas instaladas.

Los dos en la misma máquina

Convivan sin problema, porque ninguno necesita puertos entrantes y cada uno usa su propia interfaz. El reparto habitual: cloudflared publica el nombre de cara al público, y Tailscale te da la vía de administración. Con eso el firewall de entrada puede quedarse denegando todo, lo que reduce el ruido de los registros a cero.

Dos precauciones antes de cerrar el puerto 22 en la IP pública. Primero, comprueba que puedes entrar por la dirección de Tailscale en otra terminal, con la sesión actual todavía abierta. Segundo, verifica que tienes acceso a la consola del panel de tu proveedor, porque es lo que te salva si el demonio no arranca tras un reinicio. Sobre precios y límites de plan no digo nada aquí a propósito: cambian a menudo, y en septiembre de 2026 lo único sensato es mirarlos en las páginas oficiales de cada producto antes de decidir por coste.

FAQ

¿Cloudflare puede ver el contenido de mi servicio si uso un túnel?

Sí, en el tramo del POP. Cloudflare termina el TLS del visitante, descifra la petición y la vuelve a cifrar hacia tu origen, porque necesita el HTTP en claro para enrutar por nombre, aplicar reglas y servir caché. El modo estricto protege el tramo hasta tu VPS, no elimina ese punto intermedio. Por eso un blog es un buen candidato a túnel y un gestor de contraseñas no: su interfaz web se entrega por ese mismo camino.

¿Puedo usar Cloudflare Tunnel para entrar por SSH?

Se puede, y requiere software de Cloudflare también en el ordenador desde el que te conectas, además de configurar la aplicación en el panel. Para un administrador con un VPS, Tailscale llega antes al mismo resultado: instalas el cliente, obtienes una dirección privada y usas ssh normal contra ella. Si además quieres que ese acceso quede registrado por usuario, ahí es donde la política de acceso de Cloudflare aporta algo que la red privada sola no da.

¿Qué pasa si Tailscale o Cloudflare dejan de funcionar?

No se parecen. Una caída del plano de control de Tailscale deja vivas las conexiones directas ya establecidas, porque el cifrado ocurre entre tus dispositivos, y te impide inscribir nodos o propagar cambios de ACL. Una caída del POP de Cloudflare tumba el nombre público entero, porque el POP es la puerta de entrada. Si tu única vía de administración va por el túnel, quédate con la consola del proveedor a mano.

¿Sirven las dos si mi operador me da CGNAT?

Sí, porque ninguna necesita puertos entrantes ni IP pública propia. Tailscale perfora el NAT y, cuando no lo consigue, reenvía por un relevo que añade latencia sin poder leer el tráfico. Cloudflare Tunnel siempre pasa por el POP, así que el CGNAT no influye. Lo que no funciona detrás de CGNAT es la redirección de puertos del router, y ese es el motivo por el que llegaste a estas dos herramientas.

¿Cuál elijo si solo quiero una cosa instalada?

Decide por el público. Si todas las personas que van a usar el servicio pueden instalar un cliente en su dispositivo, quédate con Tailscale y no publiques nada. Si alguna no puede, porque es un visitante anónimo, un cliente puntual o un servidor ajeno que llama a un webhook, necesitas un nombre público y ahí Cloudflare Tunnel es la respuesta.