Funnels vs. Túneles: Repensando ngrok, Tailscale y Cloudflare para Infraestructura Zero-Trust

Por años, herramientas como ngrok fueron la respuesta predeterminada a “¿cómo pongo este servidor local en internet?”. Ejecuta un comando, obtén una URL HTTPS pública, y listo. Esa conveniencia es real, pero conlleva un compromiso con el que los equipos de plataforma y seguridad han estado menos cómodos: un túnel clásico crea un punto final público y no autenticado en el momento en que está activo.

La alternativa que gana terreno es la red en malla basada en identidad — redes overlay privadas como Tailscale, con mecanismos estrechos y auditados de “funnel” para los casos raros que realmente necesitan acceso público. Esto no es una historia de una herramienta reemplazando a otra; son dos respuestas diferentes a dos preguntas distintas. ngrok responde “¿cómo expongo esto a cualquiera en internet?”. Tailscale responde “¿cómo conecto los dispositivos de mi equipo sin exponer nada?”. Las funciones de funnel existen precisamente porque los equipos reales necesitan ambas respuestas, a veces en la misma tarde.

---

1. Cómo funciona realmente el túnel tradicional

Una herramienta como ngrok ejecuta un agente liviano en tu máquina que abre una conexión saliente hacia el borde de la nube de ngrok. Ese borde de la nube devuelve una URL pública, y cualquier solicitud a esa URL se enruta de vuelta por el túnel a tu puerto local. ngrok http 8080 y estás en línea en segundos — esa facilidad de uso no ha cambiado.

La arquitectura es centrada en el servicio: acceder a la URL es el control de acceso. No hay una verificación de identidad integrada en el túnel a menos que añadas una. Eso tiene algunas consecuencias prácticas para los equipos:

1. Eludir el firewall por diseño. Ese es el propósito de un túnel — pero también significa que un túnel no autorizado es un camino sin monitoreo hacia la red.
2. URLs de aspecto aleatorio no son un límite de seguridad. Son adivinables por escáneres con el tiempo, y si el servicio de respaldo no tiene autenticación propia, quien encuentre la URL tiene acceso a ella.
3. Puede convertirse silenciosamente en Shadow IT. Los datos que fluyen por un túnel que un equipo de seguridad no sabe, complican las conversaciones de cumplimiento como SOC 2, HIPAA o GDPR.

Nada de esto hace que ngrok sea inseguro de usar — lo convierte en una herramienta mejor orientada hacia afuera (demos públicas, webhooks de clientes) en lugar de hacia adentro (entornos internos de staging, comparticiones entre compañeros).

---

2. El cambio hacia Zero-Trust: redes en malla basadas en identidad

Las herramientas de redes en malla como Tailscale toman la configuración opuesta por defecto. En lugar de una URL pública que cualquiera puede alcanzar, cada dispositivo se autentica (usualmente mediante tu proveedor SSO) y se une a una red overlay privada — un “tailnet”. Los dispositivos se comunican entre sí a través de WireGuard, y un dispositivo que no está autenticado en el tailnet no puede resolver ni alcanzar nada en él, mucho menos ver que un servicio existe.

Una nuance que vale ser precisa: el tráfico de Tailscale es peer-to-peer cuando la traversión NAT tiene éxito, pero no siempre es un salto directo. Cuando dos dispositivos no pueden establecer un camino directo (común tras NAT restrictivos o firewalls corporativos), Tailscale recurre a su infraestructura de relay — servidores DERP — para transportar el tráfico cifrado. La carga útil permanece cifrada de extremo a extremo en cualquier caso, pero decir “nunca toca un servidor central” es una ligera exageración de cómo funciona la red en la práctica.

La propuesta de valor central se mantiene: el acceso requiere pertenecer al tailnet, no adivinar URLs, y cada conexión está vinculada a una identidad autenticada en lugar de una solicitud anónima.

---

3. Funnel de Tailscale vs. ngrok: Dos arquitecturas, dos filosofías

ngrok está diseñado para el caso en que quieres que internet público llegue a tu servicio — pruebas con webhooks, demostraciones a alguien sin cliente VPN, o aceptar conexiones entrantes desde entornos de clientes. Su inspector de tráfico, reproducción de solicitudes y motor de Políticas de Tráfico (sus reglas programables para autenticación, reescritura y limitación de tasa) siguen siendo muy fuertes para depurar tráfico API en vivo.

Tailscale parte de la premisa opuesta: privado por defecto, y es fundamentalmente una red en malla dispositivo a dispositivo, no una herramienta de ingreso público.

Funnel es la respuesta de Tailscale a la necesidad ocasional de cruzar ese límite: una función que enruta tráfico de internet público a un nodo específico en tu tailnet. Algunas cosas que vale la pena saber si realmente planeas usarla en producción:

• Sigue en beta. Según la documentación de Tailscale a principios de 2026, Funnel sigue etiquetado como beta — usable y razonablemente maduro, pero sin un SLA de soporte formal. Es recomendable consultarlo con el equipo de seguridad antes de considerarlo infraestructura definitiva.
• Los puertos están restringidos. Funnel solo escucha en 443, 8443 o 10000, y solo sobre TLS. Esto no es una configuración flexible — es una restricción impuesta. Tailscale automáticamente gestiona el certificado TLS para tu nombre *.ts.net.
• El ancho de banda está limitado, y ese límite no se publica. Tailscale describe el tráfico de Funnel como sujeto a límites de ancho de banda no configurables, sin especificar el número.
• El mismo puerto no puede correr Serve y Funnel a la vez. La última configuración que toque el puerto gana — configúralo como serve y será solo para tailnet; configúralo como funnel y será público. No hay un estado intermedio accidental.
• Ngrok no tiene restricción equivalente en puertos. Soporta tráfico TCP/UDP arbitrario en prácticamente cualquier puerto, por eso (o por especialistas en UDP para juegos/VoIP) aún gana para todo fuera de HTTPS.

---

4. Compartición localhost Zero-Trust: Un flujo de trabajo práctico

Supón que un desarrollador frontend necesita compartir localhost:3000 con un tester de QA y un PM.

La forma antigua: ngrok http 3000, y luego pegar la URL en Slack. Si alguien olvida cerrar la terminal, esa URL — y lo que esté corriendo detrás — permanece accesible para quien la encuentre, todo el fin de semana si hace falta. (Por cierto, la tarifa gratuita de ngrok no cierra sesiones automáticamente después de un tiempo fijo como a menudo se dice en línea — más sobre esa idea errónea en un momento. El mayor riesgo aquí no es un timeout, sino que nada cierra la puerta por ti.)

La forma Zero-Trust, con la sintaxis actual de CLI: Tailscale cambió su sintaxis de los comandos Serve/Funnel en la versión 1.52 del cliente — tutoriales antiguos que muestran tailscale serve --port 3000 usan la sintaxis previa a 1.52 y fallarán o se traducirán automáticamente con aviso de depreciación. La sintaxis actual es así:

tailscale serve https / http://localhost:3000

Esto enlaza la app local a la dirección de tu propio tailnet (algo como https://dev-laptop.tailnet-name.ts.net) — visible solo para dispositivos autenticados en ese tailnet. El tráfico está cifrado de extremo a extremo con WireGuard, y Tailscale puede pasar encabezados de identidad para que la app receptora sepa quién se conecta, sin que tengas que construir una capa de autenticación para uso interno.

Si un cliente externo sin Tailscale necesita acceder, elevas el mismo puerto a público:

tailscale funnel 443 on

Ahora es alcanzable desde internet abierto en un endpoint HTTPS gestionado por Tailscale — deliberadamente, en un puerto fijo, con un registro de quién lo activó.

---

5. Cloudflare Tunnel: La otra alternativa de Funnel

Cloudflare Tunnel (parte de la plataforma más amplia Cloudflare One / Cloudflare Zero Trust, que también incluye Access, Secure Web Gateway, DLP, Remote Browser Isolation, CASB y seguridad de email en un solo plano de control) adopta un tercer enfoque: en lugar de una malla peer, enruta a través del borde global de Cloudflare. El daemon cloudflared corre en tu máquina o servidor y abre una conexión saliente hacia el data center más cercano de Cloudflare — sin puertos entrantes, nunca. Coloca Cloudflare Access delante del túnel y los visitantes deben autenticarse vía SSO antes de llegar a tu origen.

Algunas cosas han cambiado recientemente y vale la pena conocerlas si usas cloudflared hoy: Cloudflare eliminó el comando proxy-dns en las versiones nuevas de cloudflared en febrero de 2026 para corregir una vulnerabilidad en una librería DNS subyacente — si lo usabas como resolver DNS-over-HTTPS (como en Pi-hole), ese caso ahora requiere otra herramienta; la funcionalidad principal del túnel no se vio afectada. Además, Cloudflare tiene programada una limpieza en su API para octubre de 2026 que elimina los identificadores de rutas codificados en CIDR y el campo connections en las respuestas de la API de Tunnel/Mesh en favor de valores route_id simples — relevante si gestionas rutas del túnel vía Terraform o API en lugar del panel.

La división práctica: Cloudflare Tunnel suele ser mejor para publicar apps internas a una fuerza laboral distribuida que ya usa Cloudflare Access; Tailscale suele ser mejor para conectividad entre desarrolladores y en entornos domésticos donde importa más la baja latencia y la conexión peer-to-peer con WireGuard que un borde centralizado.

---

6. Construyendo infraestructura segura para equipos: ¿Qué cambió realmente en 2026?

Si planeas esta migración, algunos hechos clave para tener en cuenta, porque cambiaron este año:

SCIM ya no es solo para empresas. La revisión de precios de Tailscale en abril de 2026 (“pricing v4”) movió la provisión automática de usuarios vía SCIM, políticas de postura de dispositivos y webhooks a todos los planes de pago con autoservicio — antes, SCIM requería un contrato Enterprise. Los niveles actuales son Personal (gratis, hasta 6 usuarios), Standard ($8/usuario/mes), Premium ($18/usuario/mes, añade SSO/SAML, logs de flujo de red y Funnel entre otras cosas), y precios Enterprise personalizados. Si tu última estimación de costos asumía precios empresariales solo para activar SCIM, vale la pena revisarlo.

Los logs de auditoría de configuración ahora están incluidos en todos los planes de pago, no solo en los superiores — útil para construir la plataforma de auditoría “quién activó Funnel y cuándo” que los equipos de plataforma quieren.

Con esto en mente, la implementación será similar:

• Desplegar el cliente de malla en estaciones de trabajo, runners de CI/CD y servidores de staging, integrados con tu IdP vía SSO y SCIM para provisión/desprovisionamiento automático.
• Activar MagicDNS para que las personas se comuniquen por nombre en lugar de IP, y escribir ACLs para que el acceso esté restringido por equipo — frontend puede acceder a staging, solo plataforma puede SSH en producción.
• Enviar el tráfico de túneles por defecto a Serve, y poner Funnel detrás de un atributo de nodo explícito en tu política ACL para que activar exposición pública sea una acción deliberada y registrada, no solo correr un binario.
• Enviar logs de flujo y auditoría a tu SIEM para que la visibilidad que ngrok no puede ofrecer (un proceso sin monitoreo en la laptop de alguien) sea la norma en lugar de la excepción.

---

7. Cuándo ngrok sigue siendo la herramienta adecuada

No es una comparación de suma cero, y vale la pena ser justo en dónde ngrok todavía gana:

1. Conectividad entre organizaciones. Si tu SaaS necesita acceder a la red de un cliente, no puedes pedirle que se una a tu tailnet. El túnel centrado en servicios está hecho para esto.
2. Inspección profunda del tráfico. La reproducción de solicitudes y el inspector de ngrok siguen siendo superiores para depurar tráfico webhook o API en vivo.
3. Protocolos no HTTPS ni TCP. Funnel solo soporta HTTPS en tres puertos fijos. Si necesitas UDP público — un servidor de juegos, VoIP, algunos protocolos IoT — ngrok (o una alternativa especializada en UDP) es la herramienta, no Funnel.

Y para que quede claro: la afirmación de que “la tarifa gratuita de ngrok expira después de 2 horas” que circula en línea no es precisa según la documentación actual de ngrok — la tarifa gratuita no tiene timeout de sesión; los endpoints permanecen activos mientras el proceso esté en ejecución, incluso como servicio en segundo plano. Lo que sí se aplica en la tarifa gratuita es un límite de transferencia de 1 GB/mes, 3 endpoints en línea, una página de advertencia en navegador (que se puede saltar con un encabezado ngrok-skip-browser-warning para uso API/programático), y dominios personalizados no disponibles. Esos son límites reales — el timeout de 2 horas simplemente no lo es.

---

8. Una revisión de realidad: Zero-Trust tampoco es invulnerable

Es tentador presentar esta comparación como “túneles públicos malos, malla privada buena” y detenerse allí. Pero vale resistir un poco esa idea. En mayo de 2026, los propios boletines de seguridad de Tailscale revelaron una vulnerabilidad de denegación de servicio (seguimiento TS-2026-008) que afectaba tanto a Serve como a Funnel: una solicitud HTTP malformada con un camino que no empezaba con / podía hacer que la lógica de coincidencia de solicitudes entrara en un bucle infinito, saturando un núcleo de CPU al 100% indefinidamente. Se solucionó sin timeout para interrumpir el ciclo. Tailscale lo parchó haciendo que la lógica de coincidencia del camino terminara correctamente.

Nada de eso socava el argumento arquitectónico de acceso basado en identidad — un bug de DoS en la capa de ingreso es un modo de fallo diferente a “quien encuentra esta URL entra”. La transparencia en la divulgación de Tailscale es exactamente lo que se esperaría de una infraestructura en la que confías con tráfico interno. Pero es un recordatorio útil de que “zero-trust” describe un modelo de acceso, no inmunidad a bugs. Cualquier capa de ingreso que elijas aún necesita parches, monitoreo y un plan para cuando algo falle.

---

Conclusión

El cambio de túneles a funnels es realmente un cambio en qué significa “conveniente” para un equipo: de “la forma más rápida de hacer algo público” a “la forma más rápida de poner algo en manos de las personas correctas, con registro”. ngrok sigue siendo la opción correcta cuando el objetivo es exposición pública — conectividad con clientes, pruebas con webhooks, demostraciones a alguien sin cliente VPN. Tailscale (o Cloudflare Tunnel, dependiendo si priorizas malla peer-to-peer o un borde centralizado) es la opción predeterminada mejor para todo lo que sea realmente interno.

El movimiento práctico no es prohibir una herramienta en favor de otra — es hacer que privado por defecto sea la norma, y tratar la exposición pública como una excepción deliberada y registrada en lugar de un hábito.

---

Registro de cambios

Cambios estructurales: - Se eliminaron metadatos SEO, frases clave en negrita repetidas y la lista de referencias pseudo-citadas del borrador original; reescrito en prosa sencilla. - Se añadió una nueva sección (§8) sobre la divulgación de Tailscale en mayo de 2026 respecto a Serve/Funnel y DoS, para balancear — el borrador original no abordaba que las herramientas Zero-Trust también tienen su historia de vulnerabilidades.

Correcciones contra fuentes primarias: - Desmentido del “ngrok free tier times out after 2 hours” — confirmado en la documentación actual de ngrok que la tarifa gratuita no tiene timeout de sesión; los límites reales son 1 GB/mes, 3 endpoints en línea y advertencia en navegador. - Actualización de la estructura de planes de ngrok — los niveles actuales son Free / Hobbyist ($8–10/mes) / Pay-as-you-go ($20/mes + uso) / Enterprise, reemplazando los nombres y precios antiguos “Personal/Pro/Enterprise”. - Corrección de la sintaxis CLI de Tailscale — los comandos tailscale serve --port 3000 y tailscale funnel 3000 son antiguos; ahora se usan tailscale serve https / http://localhost:3000 y tailscale funnel 443 on. - Corrección en SCIM y logs de auditoría de Tailscale — ahora en todos los planes de pago, no solo en Enterprise, según la actualización de abril de 2026; también se actualizaron nombres y precios. - Se marcó que Funnel sigue en beta en 2026 — la documentación indica que aún no es GA. - Se añadió la nuance del relay DERP — el tráfico de Tailscale no siempre es peer-to-peer; recurre a relays cuando NAT traversal falla, manteniendo cifrado de extremo a extremo. - Cambios en Cloudflare Tunnel en 2026 — eliminación del comando proxy-dns en febrero y la limpieza programada en API en octubre, ambos no en el borrador original. - Confirmado que las restricciones de puerto de Funnel (443/8443/10000, TLS-only), el límite de ancho de banda no publicado, y la lógica de “último comando gana” cuando Serve y Funnel usan el mismo puerto, son correctas.

Fuentes verificadas: documentación de ngrok (límites, página de precios), documentación de Tailscale (Funnel, Serve, CLI, seguridad, precios v4), documentación y changelog de Cloudflare One / Cloudflare Tunnel.