Trampas de Tailscale Funnel: eliminación de identidad y confusión de DNS para autoalojadores

Un desarrollador documentó riesgos significativos de seguridad y conectividad encontrados al exponer un panel de operaciones local basado en Windows a dispositivos móviles mediante Tailscale. Publicado el 12 de noviembre de 2026, el relato detalla cómo funciones de conveniencia estándar como Funnel y configuraciones específicas de DNS pueden crear inadvertidamente superficies de ataque públicas o causar fallos de conexión engañosos.

Qué sucedió

El autor pretendía acceder a un panel interno de operaciones ejecutándose en localhost desde un smartphone mientras estaba fuera de casa. La configuración inicial usando tailscale serve funcionaba correctamente dentro de la tailnet privada, cifrando el tráfico sobre WireGuard y restringiendo el acceso a dispositivos autorizados. Sin embargo, los intentos de extender este acceso a servicios externos o de solucionar problemas de conectividad llevaron a tres errores de configuración distintos. Dos de estos errores crearon vulnerabilidades de seguridad graves al exponer la aplicación a Internet público sin autenticación adecuada, mientras que el tercero causó un fallo de resolución de DNS que imitaba una caída del servidor.

El primer problema importante surgió cuando el autor usó el comando tailscale funnel para exponer un endpoint de API específico a Internet público. Esta acción asignó automáticamente un registro DNS público y un certificado TLS válido al host. Cuando el navegador del teléfono del autor intentó acceder al panel vía HTTP, se actualizó automáticamente a HTTPS. Dado que la entrada pública solo servía la ruta específica de la API, la URL raíz del panel devolvía un error 404. Más críticamente, el autor se dio cuenta de que las solicitudes de funnel no incluyen el encabezado Tailscale-User-Login. La lógica de su aplicación trataba los encabezados ausentes como solicitudes de loopback local, otorgando efectivamente acceso administrativo completo a cualquier usuario anónimo en Internet público.

El segundo problema ocurrió cuando el autor intentó mitigar la exposición moviendo el panel a un puerto HTTPS exclusivo de la tailnet. La conectividad falló con un error "Server not found" (Servidor no encontrado). La causa raíz no era un servidor caído, sino un conflicto de DNS. La consulta del teléfono evitó MagicDNS de Tailscale y alcanzó el registro DNS público creado por la configuración anterior de funnel. Este resolutor público apuntaba a la entrada de funnel, que solo escuchaba en el puerto 443, dejando inalcanzable el nuevo puerto personalizado. La solución final funcional implicó usar un reenvío TCP directo direccionado por la dirección IP de la tailnet del nodo, lo cual evitaba completamente el DNS pero requería un manejo cuidadoso de los hosts permitidos y las listas de control de acceso.

Detalles clave

• Usar tailscale funnel asigna un nombre DNS público y un certificado TLS, haciendo que el host sea accesible desde Internet abierto.
• La entrada de Funnel elimina el encabezado Tailscale-User-Login, haciendo que las aplicaciones que confían en solicitudes sin encabezados traten a los usuarios públicos como administradores locales.
• Los registros DNS públicos creados por Funnel pueden interferir con servicios exclusivos de la tailnet si los dispositivos cliente consultan resolutores públicos en lugar de MagicDNS.
• Los reenvíos TCP crudos usando direcciones IP de la tailnet evitan problemas de resolución de DNS, pero también carecen de encabezados de identidad, lo que requiere una aplicación estricta de ACLs.
• Una respuesta 404 del propio daemon de Tailscale sirve como herramienta diagnóstica fiable para confirmar que el túnel VPN está activo independientemente de la salud de la aplicación.
• Las aplicaciones deben listar explícitamente literales de IP en su configuración de hosts permitidos cuando usan reenvíos TCP crudos para evitar el rechazo de solicitudes.

Contexto

Tailscale es un servicio de VPN mesh que simplifica la conectividad de red entre dispositivos. Normalmente usa una función llamada MagicDNS para resolver nombres de dispositivos dentro de la red privada. El comando serve crea túneles seguros y cifrados para servicios locales, accesibles solo para miembros autenticados de la tailnet. En contraste, la función funnel expone puertos específicos a Internet público, actuando como un proxy inverso. Cuando Funnel está activo, gestiona automáticamente certificados TLS y registros DNS públicos. La mayoría de los frameworks web validan el encabezado Host en las solicitudes entrantes para prevenir ataques de cabecera de host, requiriendo que los desarrolladores mantengan una lista blanca de nombres de dominio o direcciones IP aceptables.

Por qué importa

Para equipos que ejecutan software autoalojado, la distinción entre entrada privada y pública es crítica para la postura de seguridad. Muchas herramientas internas están construidas bajo la suposición de que todo el tráfico entrante proviene de redes locales confiables o usuarios de VPN autenticados. Como se demostró, introducir un punto de entrada público como Funnel puede eliminar metadatos de identidad en los que estas aplicaciones confían para la autorización. Si una aplicación asume un estado "confiable" por defecto cuando no hay identidad de usuario presente, habilitar el acceso público convierte silenciosamente una herramienta interna en un activo explotable públicamente. Este riesgo se ve agravado por la facilidad con la que se puede habilitar Funnel, a menudo sin señales visuales inmediatas de que el servicio ahora es público.

La depuración de conectividad también se vuelve más compleja al mezclar registros DNS públicos y privados. Los ingenieros pueden perder tiempo investigando logs de servidores o reglas de firewall cuando el problema real radica en las rutas de resolución de DNS. Entender que un dispositivo cliente podría resolver un nombre de tailnet a una dirección IP pública ayuda a aislar si un fallo es relacionado con la red o con la aplicación. Reconocer que diferentes métodos de transporte llevan diferente información de identidad permite a los desarrolladores construir lógica de autorización más robusta que no dependa de la confianza implícita basada en la proximidad de red.

Qué puedes hacer

• Audita la lógica de autorización de la aplicación para asegurar que los encabezados de identidad faltantes resulten en denegación de acceso en lugar de privilegios elevados.
• Restringe el uso de Funnel a endpoints de API específicos y sin estado, en lugar de aplicaciones o paneles completos.
• Verifica que los dispositivos cliente usen MagicDNS para nombres de tailnet para evitar conflictos con registros DNS públicos creados por Funnel.
• Usa reenvíos TCP crudos con direcciones IP de la tailnet para una conectividad estable, pero aplica listas de control de acceso estrictas para limitar el acceso de pares.
• Añade tanto literales de IPv4 como de IPv6 de la tailnet a la configuración de hosts permitidos de tu aplicación cuando uses acceso directo por IP.
• Usa la página 404 predeterminada del daemon de Tailscale como comprobación base para confirmar la conectividad VPN antes de depurar errores específicos de la aplicación.