Qué es Cloudflare Tunnel

Cloudflare Tunnel (antes llamado Argo Tunnel) es un servicio gratuito que crea una conexión cifrada y saliente entre un servidor tuyo —en este caso, un NUC en mi casa— y la red de Cloudflare. En vez de abrir puertos en tu router para que el mundo llegue a tu servidor, es tu servidor el que “sale” a buscar a Cloudflare y mantiene esa conexión viva. El tráfico entra por Cloudflare y se enruta de vuelta por ese mismo túnel hasta tu servicio.

Un pequeño agente llamado cloudflared corre en tu máquina (yo lo uso como contenedor Docker) y es el que establece y mantiene esa conexión.

Ventajas frente al modelo tradicional de port forwarding

  • No abres ningún puerto en tu router. No hay superficie de ataque expuesta directamente a internet; nadie puede escanear tu IP buscando servicios abiertos.
  • No necesitas IP pública ni DNS dinámico. Funciona igual detrás de CGNAT.
  • TLS automático. Cloudflare gestiona el certificado del subdominio; no tienes que lidiar con Let’s Encrypt ni renovaciones.
  • Protección de borde incluida. El tráfico pasa primero por la red de Cloudflare, con su capa de mitigación DDoS.
  • Un solo túnel, múltiples servicios. No necesitas un túnel por cada aplicación; agregas hostnames (subdominios) a un mismo túnel y cada uno apunta a un puerto o servicio distinto en tu red interna.
  • Gratis para uso personal. El plan Zero Trust Free permite hasta 50 usuarios y, según los límites de cuenta publicados por Cloudflare, hasta 1,000 túneles por cuenta —muy por encima de lo que necesita cualquier homelab.

Por qué terminé usándolo en mi casa

Contraté Claro PyME: 950 Mbps simétricos con IP fija pública. En teoría, con IP fija debería poder exponer mis servicios directamente sin depender de nada externo. El problema fue el equipo que me instalaron.

Claro me entregó un terminal GPON Dual Band Wi-Fi (modelo real NPE3039GB, etiquetado como AX3000). Su panel de administración solo permite configurar el WiFi y ver el estado de la conexión — no hay opción de modo bridge, NAT personalizado ni port forwarding. Todo el equipo se administra de forma remota por Claro vía TR-069, así que no tengo control real sobre él.

Pedí el modo bridge para poner mi propio router/firewall detrás y manejar el enrutamiento yo mismo, pero mientras eso se resuelve (o si nunca se resuelve), no tenía forma de exponer nada de mi red interna hacia afuera.

En vez de quedarme bloqueado esperando una gestión con el ISP, o comprar un router/firewall nuevo solo para esto, Cloudflare Tunnel me permitió exponer servicios sin tocar el equipo de Claro en absoluto. El túnel sale desde mi NUC hacia Cloudflare por una conexión normal saliente, algo que en general los equipos de ISP no bloquean.

El primer servicio que expuse así fue Filebrowser, corriendo en Docker en mi NUC, disponible ahora en un subdominio propio sobre mi dominio de pruebas.

Paso a paso: activar Cloudflare Tunnel desde el dashboard

Requisito previo: tu dominio debe estar gestionado por Cloudflare (nameservers apuntando a ellos).

  1. Activar Zero Trust. Entra a tu dashboard de Cloudflare → busca Zero Trust en el menú. Si es la primera vez, te pedirá elegir un team name y activar un plan — selecciona Zero Trust Free ($0/mes, hasta 50 usuarios). Aunque no cuesta nada, Cloudflare te pide registrar un método de pago y autorizar el cobro del uso que exceda los límites gratuitos.
  2. Ir a Tunnels & Mesh. En el menú lateral: Networks → Tunnels & Mesh.
  3. Crear el túnel. Clic en Create a tunnel → elige el tipo Cloudflared (no Mesh, esa es para redes site-to-site).
  4. Nombrarlo. Dale un nombre descriptivo (yo usé Homelab-Nuc) y continúa.
  5. Copiar el token de conexión. Cloudflare te muestra un comando de instalación con un --token largo. Ese token identifica tu túnel; lo vas a necesitar en el paso de Docker. Trátalo como una contraseña — no lo subas a ningún repositorio.
  6. Configurar la ruta pública (Route Tunnel → Published applications).
    • Subdomain: el subdominio que quieres usar (ej. datos).
    • Domain: tu dominio ya gestionado en Cloudflare.
    • Service Type: HTTP (o HTTPS si tu servicio interno ya usa TLS).
    • URL: la dirección donde escucha tu servicio dentro de tu red — ver el detalle de puertos en la siguiente sección.
    • Guarda. Cloudflare crea automáticamente el registro DNS (CNAME) hacia el túnel; no hay que tocar nada en la zona DNS manualmente.

Paso a paso: desplegar cloudflared con Docker Compose

Requisitos previos

  • Docker y Docker Compose instalados en el servidor donde correrá cloudflared (en mi caso, el NUC).
  • El servicio que quieres exponer ya corriendo y accesible localmente. En mi caso, Filebrowser está publicado en el host en el puerto 8200 (mapeado internamente al 8080 del contenedor):
    0.0.0.0:8200->8080/tcp
  • El token del túnel obtenido en el paso 5 anterior.

El archivo docker-compose.yml

Si el servicio que expones ya está publicado en un puerto del host (como mi caso con Filebrowser en 8200), la forma más simple es correr cloudflared en modo network_mode: host. Así el contenedor ve los mismos puertos que el sistema anfitrión y puede llegar a localhost:PUERTO sin depender de redes Docker compartidas.

services:
  cloudflared:
    image: cloudflare/cloudflared:latest
    container_name: cloudflared
    restart: unless-stopped
    network_mode: host
    command: tunnel --no-autoupdate run --token TU_TOKEN_AQUI

Guárdalo en su propia carpeta (ej. ~/cloudflared/docker-compose.yml) y levántalo:

docker compose up -d

Alternativa: si en vez de un puerto publicado en el host tu servicio vive solo dentro de una red Docker (por ejemplo, no expones ningún puerto y accedes por el nombre del contenedor), conviene poner cloudflared en esa misma red de Docker en lugar de network_mode: host, y usar http://nombre_del_contenedor:puerto_interno como URL en la ruta pública.

Verificación

docker logs cloudflared

Deberías ver algo como:

INF Registered tunnel connection connIndex=0 ...
INF Updated to new configuration config="{\"ingress\":[{\"hostname\":\"datos.tu-dominio.com\",\"service\":\"http://localhost:8200\"}, ...]}"

Y al final, un bloque de connectivity pre-checks con SUMMARY: Environment is healthy. Si todo pasa en verde, el servicio ya debería estar accesible en https://tu-subdominio.tu-dominio.com.

Para agregar más servicios después

No hace falta crear un túnel nuevo por cada aplicación. Vuelve a Networks → Tunnels & Mesh, entra al túnel existente y agrega otra ruta de tipo Published application apuntando a otro puerto o servicio interno. El mismo contenedor cloudflared que ya tienes corriendo maneja todos los hostnames que le agregues.

Según los límites publicados por Cloudflare, una cuenta admite hasta 1,000 túneles — pero en la práctica, para un homelab, un solo túnel con múltiples hostnames es suficiente y mucho más simple de mantener.

Conclusión

Tenía IP fija pública y, aun así, no podía exponer nada: el equipo de Claro no me deja tocar el NAT ni hacer port forwarding. Cloudflare Tunnel me resolvió eso sin comprar hardware y sin esperar el modo bridge: un contenedor en el NUC, un token y una ruta en el dashboard, y Filebrowser quedó publicado sin abrir un solo puerto en mi red.

Ojo con un detalle: sin puertos abiertos no significa sin exposición. La aplicación sigue accesible en su hostname público, así que su propio login (o Cloudflare Access) sigue siendo lo que la protege. Y si Claro habilita algún día el modo bridge, podré poner mi propio router/firewall; hasta entonces, el túnel me cubre lo importante.