12 noviembre 2026
Cloud
4 minutos de lectura

Túneles para exponer servicios locales: autoalojarlos o depender de un tercero

Antonio

Publicar un servicio que corre en un portátil o en un servidor detrás de un router, para recibir un webhook, enseñar una demo o acceder a un panel interno, se ha vuelto una tarea diaria en muchos equipos, y la elección de la herramienta tiene más implicaciones de las que parece. Hay opciones de código abierto que se despliegan en infraestructura propia, como frp, zrok, sish o el reenvío de puertos de SSH, y servicios gestionados como Cloudflare Tunnel, Tailscale Funnel o ngrok, en los que el tráfico pasa por la red de un tercero.

Las claves de los túneles para servicios locales en 20 segundos

frp, zrok, sish y SSH permiten mantener el extremo público en infraestructura propia.
Cloudflare Tunnel, Tailscale Funnel y ngrok son más cómodos, pero meten a un tercero en el camino.
Cualquier túnel es una puerta de entrada a la red interna y necesita autenticación.
Para tener solo HTTPS en local no hace falta ningún túnel.

En OpenSecurity hemos publicado una guía detallada de herramientas de HTTPS local y túneles, con sus riesgos de seguridad uno por uno. Aquí nos centramos en la decisión de fondo para equipos que trabajan en la nube: dónde termina el tráfico, quién lo controla y cuánto cuesta mantenerlo.

Primero, separar los dos problemas

Mucha gente recurre a un túnel cuando solo necesita que el navegador confíe en su entorno local. Eso se resuelve sin exponer nada, con una autoridad de certificación de desarrollo como mkcert o la CA interna de Caddy, o con un certificado real de Let’s Encrypt obtenido mediante el desafío DNS-01, que no necesita conexiones entrantes. El túnel solo tiene sentido cuando algo de fuera, un proveedor de pagos, un cliente o un compañero, tiene que llegar a una máquina que no es accesible desde internet.

Autoalojado: el extremo público es tuyo

frp, con licencia Apache 2.0, es la opción más completa: un servidor en un VPS propio y un cliente en el equipo local, con proxies HTTP, HTTPS, TCP y UDP. zrok, también Apache 2.0 y basado en la red de confianza cero OpenZiti, añade comparticiones privadas en las que solo otro usuario autorizado puede entrar. sish ofrece algo parecido a ngrok usando solo SSH, y el reenvío remoto de OpenSSH (ssh -R) no necesita instalar nada si ya se tiene un servidor.

La ventaja es que no hay intermediarios ni límites de un plan gratuito, y que el tráfico no sale de la infraestructura que se controla, algo relevante cuando se manejan datos de clientes o hay requisitos de soberanía. El precio es operativo: el servidor que hace de extremo público es un servicio expuesto a internet que hay que parchear, vigilar y proteger con tokens o claves. Para muchas empresas tiene sentido alojarlo en un VPS o un servidor dedicado en un proveedor europeo, con red y cortafuegos gestionados.

Gestionado: comodidad a cambio de dependencia

Cloudflare Tunnel conecta un demonio de código abierto, cloudflared, con la red de Cloudflare mediante una conexión saliente, y permite poner delante políticas de acceso de Cloudflare Access. Tailscale Funnel abre a internet un servicio de una red Tailscale, mientras que Serve lo limita a los equipos de esa red privada. ngrok, propietario, destaca por su inspector de peticiones, muy útil para depurar webhooks.

Son opciones rápidas de poner en marcha, con certificados válidos y sin servidores que mantener. A cambio, el tráfico atraviesa la infraestructura de un proveedor estadounidense, las condiciones de los planes gratuitos cambian con frecuencia y la configuración queda atada a una cuenta y, en el caso de Cloudflare, a una zona DNS alojada allí. Para pruebas puntuales suele compensar; para servicios permanentes conviene pensarlo dos veces.

En ambos casos rige la misma regla: un túnel es una vía de entrada. Que la conexión sea saliente no impide que cualquiera en internet llegue al puerto publicado. Hay que limitarlo a un único servicio, añadir autenticación y cerrarlo cuando ya no se necesite.