Cloudflare Tunnel: expón servicios locales sin abrir puertos ni tocar el firewall

Un Jedi no muestra su sable hasta que es necesario. Un sysadmin no abre puertos hasta que no queda otra opción.

El acceso remoto clásico hace lo contrario: abre puertos en el router y publica tu posición. El 8443 de tu Proxmox, el 8096 de tu Jellyfin, el 22 de tu SSH — visibles para cualquier bot que escanee internet, esperando a que alguien encuentre el exploit del mes.

Cloudflare Tunnel gira esa lógica. Tu servidor establece una conexión saliente hacia Cloudflare — son ellos quienes reciben el tráfico exterior y lo reenvían hacia ti. El router no abre nada. Tu IP real no aparece en ningún sitio. El atacante no puede atacar lo que no ve.

Sin un solo puerto abierto. Sin IP fija. Sin NAT. Y tu Jellyfin accesible desde cualquier lugar del mundo con HTTPS y con tu propio dominio.

Índice

• El problema que Tunnel resuelve
• Cómo funciona Cloudflare Tunnel
• OPNsense o Linux
• Instalación en Linux
• Crear el túnel desde Cloudflare
• Exponer servicios: Jellyfin, Proxmox y más
• Token seguro y arranque con systemd
• Varios servicios desde el mismo túnel
• Proteger el acceso con Cloudflare Access
• Cuándo usar Tunnel y cuándo no

El problema que Tunnel resuelve

Tienes un servidor en casa con Jellyfin, un panel de monitorización, quizás un Proxmox. Quieres acceder desde fuera.

La solución clásica: abrir puertos en el router, configurar NAT, apuntar un DDNS a tu IP dinámica y esperar a que tu ISP no te cambie la IP en el momento más inoportuno. Si además quieres HTTPS, toca gestionar certificados. Si la IP cambia, el certificado deja de funcionar hasta que lo renuevas.

Cada puerto abierto es superficie de ataque. Bots escaneando el 22, el 8443, el 1194. Tu IP real expuesta en los logs de cualquier servicio que consulte el cliente. Un solo exploit en el software expuesto puede comprometer toda la red interna.

Cloudflare Tunnel invierte la lógica. En lugar de abrir un puerto para que entre el tráfico, es tu servidor el que establece una conexión saliente hacia la red de Cloudflare. Cloudflare recibe las peticiones externas y las reenvía por ese canal hacia tu servicio. El router no expone nada. Tu IP real no aparece en ningún sitio.

Cómo funciona Cloudflare Tunnel

cloudflared es el daemon que corre en tu servidor. Al arrancar, establece conexiones persistentes hacia los edge nodes de Cloudflare usando el protocolo QUIC — rápido, con baja latencia y resistente a cambios de red.

Cuando alguien accede a jellyfin.tudominio.com:

1. La petición llega a Cloudflare (el DNS del dominio apunta a sus servidores)
2. Cloudflare la enruta por el túnel establecido hacia tu servidor
3. cloudflared la reenvía al servicio interno en localhost:8096
4. La respuesta vuelve por el mismo camino

Tu router no tiene ningún puerto abierto. Cloudflare gestiona el TLS — el cliente ve un certificado válido sin que tú tengas que hacer nada. Y si tu IP dinámica cambia, el túnel se reconecta automáticamente.

OPNsense o Linux

Hay dos formas de desplegar Cloudflare Tunnel:

Plugin os-cloudflared en OPNsense — el tunnel corre en el firewall y puede acceder a cualquier servicio de la red interna. Una sola instancia para toda la infraestructura, gestionada desde la GUI de OPNsense.

Linux directo — instalas cloudflared en el servidor que quieres exponer. Útil cuando el servicio corre en una máquina específica: un NAS, un servidor multimedia, un LXC en Proxmox.

Si usas OPNsense, el plugin es la opción más limpia y está documentada en detalle en Zero Trust en mi homelab sin gastar un euro. Las secciones siguientes cubren la instalación directa en Linux.

Instalación en Linux

Cloudflare mantiene repositorio oficial para Debian y Ubuntu. La forma más limpia:

curl -fsSL https://pkg.cloudflare.com/cloudflare-main.gpg \
  | sudo tee /usr/share/keyrings/cloudflare-main.gpg > /dev/null

echo 'deb [signed-by=/usr/share/keyrings/cloudflare-main.gpg] \
  https://pkg.cloudflare.com/cloudflared bookworm main' \
  | sudo tee /etc/apt/sources.list.d/cloudflared.list

sudo apt update && sudo apt install cloudflared

Para otras distribuciones o arquitecturas (ARM, Alpine), los paquetes están en la página de releases de cloudflared.

Verifica que quedó bien:

cloudflared --version

cloudflared version 2025.x.x (built ...)

Crear el túnel desde Cloudflare

Toda la configuración vive en el panel de Cloudflare Zero Trust — cloudflared solo necesita el token para conectarse.

Paso 1 — Cuenta y panel Zero Trust

Necesitas una cuenta en Cloudflare con el dominio dado de alta. Si aún no tienes dominio propio, en el artículo DDNS gratuito en Linux explico cómo conseguir uno sin coste y añadirlo a Cloudflare. El plan gratuito cubre todo lo que vas a necesitar.

Ve a one.dash.cloudflare.com, acepta los términos del plan gratuito y entra en el panel Zero Trust.

Paso 2 — Crear el túnel

En el menú lateral: Networks → Tunnels → Create a tunnel

• Tipo de conector: Cloudflared
• Nombre: algo descriptivo (ej: homelab, servidor-casa)

En la pantalla siguiente aparece el token del túnel — una cadena larga que empieza por eyJ.... Cópiala, la necesitas en el siguiente paso.

Paso 3 — Conectar el servidor

Con el token en mano, conecta cloudflared al túnel e instálalo como servicio systemd en un solo comando:

sudo cloudflared service install TU_TOKEN_AQUI
sudo systemctl enable --now cloudflared

En el panel de Cloudflare el túnel pasará a estado Healthy en unos segundos. Si ves Inactive pasado un minuto, revisa los logs:

sudo journalctl -u cloudflared -f

Exponer servicios: Jellyfin, Proxmox y más

El siguiente paso es decirle a Cloudflare qué peticiones redirigir hacia qué servicio. Se configura en Networks → Tunnels → tu túnel → Public Hostname.

Cada regla tiene dos campos principales:

• Subdomain + Domain: el nombre público (ej: jellyfin.tudominio.com)
• Service: la URL interna (ej: http://localhost:8096)

Cloudflare crea automáticamente el registro DNS en tu zona. No hace falta tocarlo a mano.

Ejemplo: Jellyfin

Jellyfin escucha por defecto en el puerto 8096 sin TLS. La regla en Cloudflare:

Una vez guardada, jellyfin.tudominio.com es accesible con HTTPS desde cualquier sitio, con certificado válido gestionado por Cloudflare.

Servicios con certificado autofirmado

Proxmox, TrueNAS y muchos paneles de administración usan HTTPS con certificado autofirmado. La configuración es igual, pero hay que activar No TLS Verify en la regla:

Sin esa opción, cloudflared rechaza la conexión porque el certificado autofirmado no es de confianza.

Token seguro y arranque con systemd

cloudflared service install TOKEN crea el servicio systemd y escribe el token directamente en el fichero de unidad. Funciona, pero el token queda visible en texto plano en /etc/systemd/system/cloudflared.service.

Si quieres más control, guárdalo en un fichero con permisos restringidos:

sudo mkdir -p /etc/cloudflare
echo "TUNNEL_TOKEN=TU_TOKEN_AQUI" | sudo tee /etc/cloudflare/tunnel.env
sudo chmod 600 /etc/cloudflare/tunnel.env
sudo chown root:root /etc/cloudflare/tunnel.env

Luego crea el fichero de unidad:

sudo tee /etc/systemd/system/cloudflared.service > /dev/null <<'EOF'
[Unit]
Description=Cloudflare Tunnel
After=network-online.target
Wants=network-online.target

[Service]
EnvironmentFile=/etc/cloudflare/tunnel.env
ExecStart=/usr/bin/cloudflared tunnel --no-autoupdate run --token ${TUNNEL_TOKEN}
Restart=on-failure
RestartSec=5s
User=root

[Install]
WantedBy=multi-user.target
EOF

sudo systemctl daemon-reload
sudo systemctl enable --now cloudflared
sudo systemctl status cloudflared

El token solo es legible por root. El servicio se reinicia automáticamente si cloudflared cae.

Varios servicios desde el mismo túnel

Un solo túnel puede exponer todos los servicios que quieras — añades reglas en el panel de Cloudflare y no hace falta instalar cloudflared en cada máquina.

Si el servicio no corre en el mismo servidor donde está cloudflared, usa la IP interna como destino:

cloudflared enruta cada petición al destino correspondiente según el hostname. Una instancia en el firewall gestiona toda la infraestructura desde un solo punto.

Proteger el acceso con Cloudflare Access

Tunnel expone el servicio. Pero por defecto cualquiera que conozca el subdominio puede llegar a él.

Cloudflare Access añade autenticación delante: antes de que la petición llegue a tu servidor, el usuario tiene que identificarse — con Google, GitHub, correo con OTP, o cualquier proveedor compatible. Sin autenticación, la petición no pasa.

Access está incluido en el plan gratuito hasta 50 usuarios y se configura en el mismo panel de Cloudflare Zero Trust.

El siguiente artículo de esta serie cubre Access en detalle: cómo crear políticas, qué proveedores de identidad soporta y cómo combinar Tunnel + Access para un acceso remoto realmente seguro → Cloudflare Zero Trust: protege el acceso a tus servicios con identidad, no con VPN.

Cuándo usar Tunnel y cuándo no

Tunnel resuelve bien un caso concreto: exponer un servicio HTTP/HTTPS a internet sin abrir puertos. Para ese caso, es difícil encontrar algo comparable en sencillez y coste.

Hay situaciones donde no es la opción adecuada:

Protocolos que no sean HTTP/HTTPS. Tunnel es un proxy HTTP. Si necesitas exponer SSH, una base de datos, o cualquier cosa que use un protocolo binario sobre TCP directamente, Tunnel no te sirve. Cloudflare tiene Spectrum para TCP/UDP arbitrario, pero es de pago.

Acceso a toda la red interna. Tunnel expone servicios concretos. Si lo que quieres es conectar un dispositivo remoto como si estuviera en tu LAN — acceder a cualquier servicio interno sin configurar cada uno por separado — la alternativa es ZeroTier o Tailscale. Los dos tienen plugins para OPNsense y son igualmente gratuitos.

Privacidad total. El tráfico pasa por los servidores de Cloudflare. Cloudflare gestiona el TLS — técnicamente puede ver el contenido no cifrado antes de reenviarlo. En la mayoría de casos esto no es relevante, pero si no quieres que los datos pasen por una tercera parte, un túnel directo WireGuard es más adecuado.

Latencia baja. El salto extra por los servidores de Cloudflare añade algunos milisegundos. Para streaming de baja latencia o gaming puede notarse.

Si te encaja en el caso de uso — y para la mayoría de servicios de homelab lo hace — es gratuito, no requiere mantenimiento y añade HTTPS automático. Difícil de mejorar.

Si quieres ver Tunnel integrado en un stack completo — con VLANs en OPNsense, ZeroTier y Tailscale — lo tienes documentado en Zero Trust en mi homelab sin gastar un euro.