--- title: "Túneles para exponer servicios locales: autoalojarlos o depender de un tercero" description: "frp, zrok o SSH permiten publicar un servicio local desde infraestructura propia; Cloudflare Tunnel, Tailscale Funnel o ngrok lo hacen a través de un tercero. Qué implica cada opción para soberanía, coste y seguridad." url: https://revistacloud.com/tuneles-exponer-servicios-locales-autoalojados-frp-zrok-cloudflare-tunnel/ date: 2026-11-12 modified: 2026-11-12 author: "Antonio" image: https://revistacloud.com/wp-content/uploads/2026/11/tuneles-servicios-locales-autoalojados.png categories: ["Cloud"] tags: ["Cloudflare", "open source", "seguridad", "túneles"] type: post lang: es --- # Túneles para exponer servicios locales: autoalojarlos o depender de un tercero **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](https://www.opensecurity.es/https-local-tuneles-herramientas-open-source-seguridad-mkcert-frp-zrok/), 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](https://github.com/fatedier/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](https://zrok.io/), 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](https://github.com/antoniomika/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](https://developers.cloudflare.com/cloudflare-one/connections/connect-networks/) 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](https://tailscale.com/kb/1223/funnel) abre a internet un servicio de una red Tailscale, mientras que Serve lo limita a los equipos de esa red privada. [ngrok](https://ngrok.com/), 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. ## Preguntas frecuentes ### ¿Qué túneles se pueden autoalojar? frp, zrok y sish, además del reenvío remoto de puertos de SSH. Todos son de código abierto y se ejecutan en un servidor propio. ### ¿Qué diferencia hay entre Tailscale Serve y Funnel? Serve publica un servicio solo dentro de la red privada de Tailscale; Funnel lo abre a todo internet. ### ¿Hace falta un túnel para tener HTTPS en desarrollo? No. Basta con una CA de desarrollo como mkcert o Caddy, o con un certificado de Let’s Encrypt obtenido por DNS-01. **Fuentes:** - [OpenSecurity: HTTPS local y túneles](https://www.opensecurity.es/https-local-tuneles-herramientas-open-source-seguridad-mkcert-frp-zrok/) - [frp](https://github.com/fatedier/frp) - [zrok](https://zrok.io/) - [ngrok: comparativa de alternativas](https://ngrok.com/alternatives/ngrok)