Tailscale Funnel: la palabra que pone tu aplicación en internet público

Dos comandos de Tailscale se diferencian en una palabra. tailscale serve comparte un servicio local con los dispositivos de tu propio tailnet. tailscale funnel encamina el tráfico desde internet en sentido amplio hacia ese mismo servicio, al alcance de cualquiera que tenga la URL.

Misma sintaxis, exposición opuesta. Ese es todo el artículo en dos frases, pero equivocarse de sentido deja en internet abierto un servicio que creías privado, así que conviene ser preciso sobre lo que Funnel hace y lo que no.

Qué es Funnel en realidad

La descripción de Tailscale es directa: Funnel «permite encaminar tráfico desde internet en sentido amplio hacia un servicio local que se ejecuta en un dispositivo de tu red Tailscale». El objetivo es compartir con personas que no están en tu tailnet y no tienen cuenta de Tailscale.

Serve es el caso inverso, y la documentación lo dice sin rodeos: si quieres compartir servicios locales solo con los demás dispositivos de tu tailnet, usa Serve.

La decisión no es una preferencia técnica, es una pregunta sobre tu público:

• Solo tus máquinas y las personas invitadas al tailnet → Serve.
• Cualquiera con el enlace, incluidos desconocidos → Funnel.

Si no sabes responder a esa pregunta para un servicio concreto, no ejecutes todavía ninguno de los dos comandos.

Las tres restricciones que deciden si Funnel encaja

Funnel es deliberadamente estrecho, y sus límites están documentados en lugar de descubrirse sobre la marcha. Tres de ellos resuelven la mayoría de los casos antes de escribir una línea de configuración.

Los puertos: 443, 8443, 10000. Esa es la lista entera. Funnel solo puede escuchar en esos tres. No es un valor por defecto que se pueda sobrescribir: si tu servicio debe ser accesible públicamente en otro puerto, Funnel no es la herramienta.

El nombre de host pertenece a Tailscale. Funnel solo puede usar nombres DNS del dominio de tu tailnet, con la forma tailnet-name.ts.net. Si pensabas poner un producto, una demo para clientes o algo con tu marca en un dominio propio, no es lo que hace.

El ancho de banda está limitado, y el límite no es tuyo. Tailscale afirma que el tráfico enviado por Funnel está sujeto a límites no configurables. Para una página de configuración o una herramienta interna pequeña, da igual. Para transmitir una mediateca a familiares, ese tope será seguramente la restricción, antes que tu velocidad de subida.

La parte que se salta: no hay ningún inicio de sesión delante

Esta es la razón por la que la confusión Serve/Funnel importa más que una errata cualquiera.

La documentación de Tailscale no describe ninguna capa de autenticación delante de un punto de entrada Funnel, y es por diseño: toda su finalidad es servir a gente que no está en tu tailnet y que, por tanto, no puede ser autenticada por él. Funnel te da una entrada HTTPS pública; no te da una puerta.

Consecuencia práctica: la autenticación de tu aplicación es lo único que hay entre internet y tus datos. Un panel sin contraseña, un explorador de archivos que confía en la red local, un panel de administración que solo era accesible desde tu LAN: todos quedan abiertos en cuanto se «funnelan» en lugar de servirse.

Antes de activarlo sobre nada, la prueba honesta cabe en una pregunta: ¿publicaría esta URL abiertamente sin incomodidad? Si la respuesta es no, el servicio necesita su propia autenticación, o necesita Serve en lugar de Funnel.

Activarlo: primero el archivo de políticas

Funnel no está activo por defecto en un nodo. Requiere un atributo de nodo funnel en el archivo de políticas de tu tailnet, que le indica a Tailscale qué usuarios pueden utilizarlo. Por defecto, ese permiso va a autogroup:member.

Esa indirección merece entenderse en vez de saltarse: significa que Funnel es una decisión administrativa a nivel de tailnet, no solo un comando que alguien ejecuta en su portátil. En un tailnet compartido, quien controla el archivo de políticas controla si alguien puede exponer servicios públicamente.

Cuándo Funnel es la respuesta correcta y cuándo no

Funnel encaja cuando quieres dar a alguien ajeno a tu tailnet una URL HTTPS que funcione con el mínimo de ceremonia: un endpoint de webhook que un servicio externo debe alcanzar, una vista previa de lo que estás construyendo, un envío temporal. Los certificados y la entrada pública se gestionan por ti, y funciona en todos los planes.

Funnel no encaja cuando necesitas un dominio propio, un puerto fuera de los tres permitidos, caudal sostenido o una capa de autenticación que controles. Esos requisitos apuntan a otra parte: un proxy inverso en una máquina con IP pública propia, o un producto de túnel construido en torno a dominios personalizados.

Y para el caso en el que la gente suele pensar al recurrir a Funnel — quiero que mis propios dispositivos alcancen este servicio desde cualquier lugar — ni Funnel ni un túnel público son la respuesta. Eso ya lo hace el tailnet, y lo hace un nodo de salida o un servidor WireGuard autoalojado sin exponer nada públicamente.

Lo esencial

serve y funnel están a una palabra de distancia en la terminal y son opuestos en lo que publican. Serve mantiene un servicio dentro del tailnet; Funnel lo pone en internet, en uno de tres puertos, bajo un nombre ts.net, con un tope de ancho de banda y sin nada que autentique a los visitantes.

Decide a qué público te diriges realmente antes de teclear cualquiera de los dos. Si la respuesta es «mis propias máquinas», nunca necesitaste una entrada pública, y la exposición más segura es la que jamás se abrió.