contacto@openit.ar | +54 9 3446434264

Publicar servicios sin abrir puertos: Cloudflare Tunnel en lugar de redirección de puertos

Publicar servicios sin abrir puertos: Cloudflare Tunnel en lugar de redirección de puertos

Durante años, publicar un servidor de la oficina en internet tuvo una sola receta: abrir un puerto en el router y redirigirlo a la IP interna. Funciona, pero deja una puerta abierta que cualquiera puede probar, las 24 horas.

Hay otra forma: que el servidor salga hacia afuera en lugar de esperar que entren. Es lo que hace Cloudflare Tunnel. En este post cuento cómo funciona, qué se gana, qué se resigna y cuándo lo recomiendo.

El problema de abrir puertos

Cuando redirigís un puerto, el servicio queda visible para todo internet, no solo para tus usuarios. Hay escáneres que recorren las direcciones IPv4 en forma permanente buscando servicios expuestos, y un puerto abierto aparece en esas búsquedas en poco tiempo.

Lo que encuentran es el servicio tal cual: un panel de administración, un escritorio remoto, una cámara. Si tiene una vulnerabilidad sin parchear o una contraseña débil, el atacante llega directo, sin nada en el medio que lo frene.

Hay además un problema práctico. Muchos proveedores ya no entregan una IP pública propia y usan CGNAT, una IP compartida entre varios clientes. Con CGNAT, la redirección de puertos directamente no funciona.

Cómo funciona un túnel saliente

En lugar de abrir un puerto, se instala un programa liviano, cloudflared, en un equipo de la red interna. Ese programa abre conexiones salientes y cifradas hacia la red de Cloudflare. Mantiene cuatro conexiones permanentes contra dos centros de datos distintos, así que tiene redundancia de fábrica.

Cuando alguien entra a app.tuempresa.com, el pedido llega primero a Cloudflare. Desde ahí viaja por el túnel ya establecido hasta cloudflared, que lo entrega al servicio interno, por ejemplo http://localhost:8080. La respuesta hace el camino inverso.

La clave está en quién inicia la conexión: tu servidor, no internet. Como casi todos los firewalls permiten el tráfico saliente, no hace falta tocar el router, y se pueden bloquear todas las conexiones entrantes.

Qué se gana

  • Ningún puerto entrante abierto. El firewall puede bloquear todo lo que entra y el servidor no expone una IP pública. Los escáneres no tienen nada que encontrar.
  • Funciona detrás de CGNAT o con IP dinámica. Como la conexión sale desde adentro, no importa qué IP te asigne el proveedor ni si la comparte con otros clientes.
  • Protección incluida. Todo el tráfico pasa por Cloudflare antes de llegar a tu servidor, así que se aplican su firewall de aplicaciones web, la mitigación de ataques DDoS y la caché.
  • HTTPS sin gestionar certificados. Cloudflare presenta el certificado al visitante, y el servicio interno puede seguir hablando HTTP dentro de la red.
  • Acceso con login previo. Con Cloudflare Access se puede exigir que el usuario se identifique antes de llegar a la aplicación, por ejemplo con su cuenta de Google o Microsoft.
  • Sin costo para empezar. El túnel está disponible en todos los planes, incluido el gratuito.

Qué se resigna

Ninguna solución es gratis en todos los sentidos. Antes de migrar, conviene tener claro esto:

  • Cloudflare ve tu tráfico. Para aplicar el firewall y la caché, descifra las conexiones en su red y las vuelve a cifrar hacia tu túnel. Si manejás datos sensibles, eso tiene que entrar en tu análisis de riesgos.
  • Dependés de un tercero. Si Cloudflare se cae, tus servicios quedan inaccesibles aunque tu servidor funcione perfecto. Pasó el 18 de noviembre de 2025, cuando una falla global dejó fuera de línea a miles de sitios durante horas.
  • El dominio tiene que estar en Cloudflare. Cada nombre publicado es un registro DNS que apunta al túnel, y eso se gestiona desde la misma cuenta de Cloudflare.
  • Lo que no es web requiere software del lado del usuario. Para SSH, escritorio remoto o TCP genérico, quien se conecta también tiene que correr cloudflared en su equipo.
  • El plan gratuito tiene límites. Cada subida está limitada a 100 MB, y los términos de servicio exigen un producto pago para servir video y archivos grandes.

Cuándo conviene y cuándo no

Lo recomiendo para:

  • Aplicaciones web internas que necesitan acceso desde afuera: un sistema de gestión, una intranet, el panel de un NAS.
  • Conexiones con CGNAT o IP dinámica, donde redirigir puertos no es opción.
  • Paneles de administración, siempre detrás de Cloudflare Access y nunca abiertos sin login.
  • Empresas chicas que no tienen quien mantenga el firewall y renueve certificados.

No lo recomiendo para:

  • Datos que por norma o contrato no pueden pasar descifrados por un tercero.
  • Servicios que mueven video o archivos grandes, salvo que se contrate el producto adecuado.
  • Dar acceso al personal a toda la red interna. Para eso, una VPN como WireGuard es más directa.

Cómo empezar

  1. Pasá el DNS del dominio a Cloudflare. Se cambian los servidores de nombres en el registrador; el plan gratuito alcanza.
  2. Creá el túnel. En el panel de Cloudflare, en Networking > Tunnels, se crea un túnel nuevo y el panel muestra el comando de instalación con su token.
  3. Instalá cloudflared en la red interna. Puede ser un servidor Linux, una máquina virtual o un contenedor; no hace falta que sea el mismo equipo que corre la aplicación.
  4. Publicá la aplicación. Se asocia un nombre público, como app.tuempresa.com, con el servicio interno, como http://192.168.1.10:8080. Cloudflare crea el registro DNS solo.
  5. Protegé lo sensible con Access. Cualquier panel de administración tiene que pedir login antes de mostrarse.
  6. Cerrá los puertos viejos. Si antes había redirecciones en el router, eliminalas. Un túnel con los puertos todavía abiertos no mejora nada.

Para tener redundancia, conviene correr una segunda instancia de cloudflared con el mismo túnel en otro equipo: si uno se cae, el otro sigue atendiendo.

En resumen

Cloudflare Tunnel cambia la lógica de publicar servicios. En lugar de abrir una puerta y vigilarla, el servidor sale hacia afuera, y nadie puede forzar una puerta que no existe. A cambio, sumás un intermediario que ve tu tráfico y del que dependés.

Para la mayoría de las aplicaciones web de una PyME, ese intercambio conviene. Para datos sensibles o servicios que no son web, hay que pensarlo dos veces.

Si querés evaluar cómo aplicarlo en tu empresa, en Open Tecnología te ayudamos con el diagnóstico.

Compartir:

Post anterior