1. Objetivos

Los objetivos que se pretenden alcanzar con este tutorial son los siguientes:

  • Comprender el concepto y funcionamiento de los túneles inversos salientes como alternativa a la apertura tradicional de puertos (Port Forwarding / DNAT).

  • Diferenciar las características y casos de uso de los quick tunnels efímeros frente a los named tunnels persistentes integrados en Cloudflare Zero Trust.

  • Instalar y utilizar el conector oficial cloudflared tanto de forma nativa como mediante contenedores Docker y Docker Compose.

  • Exponer aplicaciones web (HTTP/HTTPS) y servicios TCP como SSH ubicados en la máquina local o en otros equipos de la red LAN.

2. Introducción

2.1. El problema de la exposición tradicional de servicios

En el modelo tradicional de redes, para que un servidor local ubicado detrás de un router doméstico o un cortafuegos corporativo sea accesible desde Internet, es necesario cumplir los siguientes requisitos y enfrentarse a varias limitaciones técnicas:

  1. Configurar el reenvío de puertos (Port Forwarding / DNAT): Abrir puertos de entrada en el router o cortafuegos perimetral redirigiendo el tráfico entrante hacia la dirección IP privada del servidor interno. Por ejemplo, el puerto 80 para HTTP, el 443 para HTTPS o el 22 para SSH.

  2. Disponer de una dirección IP pública enrutable: Contar con una dirección IP pública fija o dinámica mediante DDNS, asignada directamente al router.

  3. Incompatibilidad con entornos CGNAT: En conexiones móviles (4G/5G) o proveedores de Internet que utilizan CGNAT, la apertura tradicional de puertos es inviable al compartirse una misma dirección IP pública entre múltiples usuarios.

  4. Gestión manual del cifrado y certificados TLS: Es necesario aprovisionar, configurar y renovar periódicamente certificados digitales válidos (por ejemplo, mediante Let’s Encrypt o ACME) en el propio servidor para garantizar la confidencialidad del tráfico y evitar advertencias en los navegadores.

Riesgos de seguridad del enfoque tradicional

Exponer servicios directamente abriendo puertos perimetrales conlleva importantes riesgos de seguridad:

  • Exposición directa de la IP pública: Los atacantes pueden identificar la IP de origen y dirigir ataques de denegación de servicio distribuidos (DDoS) o escaneos continuos de vulnerabilidades.

  • Superficie de ataque permanente: Los puertos abiertos permanecen visibles e indexados en motores de búsqueda de dispositivos como Shodan o Censys.

  • Riesgo de intrusión y movimiento lateral en la LAN: Si el servicio expuesto contiene una vulnerabilidad, como una ejecución remota de código (RCE), el atacante puede comprometer el servidor y utilizarlo como punto de partida para acceder al resto de dispositivos de la red interna.

2.2. ¿Qué es Cloudflare?

Cloudflare es una plataforma global de servicios en la nube orientada a mejorar la seguridad, el rendimiento y la fiabilidad de aplicaciones, sitios web y servicios conectados a Internet.

Opera una de las redes perimetrales distribuidas (Anycast Edge Network) más extensas del mundo, con presencia en cientos de ciudades. En su modelo fundamental, actúa como un proxy inverso interpuesto entre los clientes en Internet y los servidores de origen.

Entre sus principales funciones y servicios destacan:

  • Seguridad perimetral y mitigación de ataques: Protección automática frente a ataques de denegación de servicio distribuido (DDoS), cortafuegos de aplicaciones web (WAF) y aprovisionamiento automático de certificados TLS/SSL.

  • Red de entrega de contenidos (CDN): Almacenamiento en caché y optimización de tráfico en los nodos perimetrales para acelerar los tiempos de carga y reducir el consumo de ancho de banda en los servidores de origen.

  • Gestión y resolución DNS: Servidores de nombres autoritativos y recursivos de alta velocidad y baja latencia.

  • Plataforma Zero Trust y conectividad segura: Arquitectura de seguridad basada en el principio de menor privilegio (Zero Trust), que incluye Cloudflare Tunnel (cloudflared) para conectar infraestructura interna a la nube mediante conexiones salientes seguras, sin exponer direcciones IP públicas ni abrir puertos de entrada en el cortafuegos.

2.3. ¿Qué es un túnel de red?

Un túnel de red (network tunnel o tunneling protocol) es una técnica de comunicación que permite transportar paquetes de un protocolo de red encapsulándolos dentro de la carga útil (payload) de otro protocolo de transporte diferente.

En lugar de transmitir los datos directamente por la red siguiendo las rutas estándar de nivel de enlace o de red, el tráfico original (con sus datos y cabeceras) se introduce dentro de nuevos paquetes con las cabeceras del protocolo portador (carrier protocol). De este modo, los routers y pasarelas intermedias solo procesan la cabecera externa, transportando el tráfico de manera transparente entre los dos extremos del túnel.

Fases del funcionamiento de un túnel

El ciclo de vida de los datos a través de un túnel consta de tres fases fundamentales:

  1. Encapsulación: En el punto de entrada (nodo de origen o cliente), los paquetes de la aplicación se empaquetan y opcionalmente se cifran dentro de tramas o datagramas del protocolo portador. Por ejemplo: TCP, UDP, TLS o QUIC.

  2. Tránsito: El paquete encapsulado viaja a través de la red intermedia, como Internet o una red corporativa. Para los dispositivos de red intermedios, se trata de tráfico ordinario del protocolo portador.

  3. Desencapsulación: En el punto de salida (nodo de destino o servidor de relevo), se extrae el paquete original, se descifra si procede y se entrega al servicio destinatario.

Propósitos y ventajas principales

El uso de túneles de red proporciona importantes beneficios técnicos y de seguridad:

  • Superar barreras de red (NAT, CGNAT y cortafuegos): Permite comunicar dos nodos atravesando cortafuegos restrictivos, proxies o entornos con CGNAT donde las conexiones directas o el reenvío de puertos tradicional son inviables.

  • Seguridad, privacidad y cifrado: Añade una capa de cifrado y autenticación robusta mediante TLS, IPsec, SSH o WireGuard a protocolos que originalmente no son seguros o cuando se transmiten a través de redes públicas no confiables.

  • Creación de redes virtuales (Overlay Networks): Permite interconectar redes privadas geográficamente dispersas o crear redes superpuestas independientes de la topología física subyacente.

Túneles tradicionales (Inbound) frente a túneles inversos (Outbound)

Según cómo se inicia y establece la conexión, existen dos modelos principales:

  • Túneles entrantes tradicionales (Inbound Tunnels): Utilizados en tecnologías como las VPNs clásicas o SSH con reenvío de puertos local. Requieren que el servidor o cortafuegos de destino disponga de una dirección IP pública accesible y un puerto abierto a la escucha para aceptar las conexiones entrantes de los clientes.

Arquitectura de túnel entrante tradicional (Inbound)
Figura 1. Arquitectura de túnel entrante tradicional (Inbound)

  • Túneles inversos salientes (Reverse Tunnels): Utilizados por herramientas modernas como Cloudflare Tunnel (cloudflared) o Ngrok. En este modelo, un agente interno inicia una conexión saliente (Outbound / Egress-Only) hacia un servidor o red intermedia (Edge / Relay). Todo el tráfico procedente del exterior hacia el servicio interno se canaliza a través de dicha conexión saliente ya abierta, sin necesidad de abrir ningún puerto en el cortafuegos local ni disponer de una dirección IP pública.

Arquitectura de túnel inverso saliente (Outbound)
Figura 2. Arquitectura de túnel inverso saliente (Outbound)

2.4. Tipos de túneles en Cloudflare

Cloudflare ofrece diferentes modalidades para crear túneles según el nivel de persistencia, los requisitos de autenticación y el tipo de tráfico de red a gestionar.

1. Túneles Efímeros: Quick Tunnels

Es la modalidad más inmediata y ligera. Permite exponer un servicio local a Internet mediante un único comando, sin necesidad de registrarse en Cloudflare ni disponer de un nombre de dominio propio.

cloudflared tunnel --url <URL>

  • URL asignada: Genera dinámicamente un subdominio temporal y aleatorio bajo el dominio *.trycloudflare.com.

  • Ciclo de vida: Son túneles efímeros. El túnel y el subdominio se destruyen automáticamente en el momento en que se detiene el proceso en la consola (Ctrl + C).

  • No dispone de control de acceso ni autenticación: Cualquier persona que conozca la URL pública podrá conectarse al servicio.

  • Limitaciones técnicas y de servicio: Al ser una funcionalidad gratuita orientada a pruebas, no cuenta con acuerdo de nivel de servicio (SLA), el subdominio cambia en cada reinicio y no está concebida para streaming masivo de vídeo ni transferencias pesadas continuadas.

  • Casos de uso:

    • Pruebas de concepto rápidas (PoC) y laboratorios formativos.

    • Pruebas de desarrollo local. Ejemplos: Depuración de webhooks entrantes de GitHub, Stripe, PayPal o bots.

    • Demostraciones puntuales de aplicaciones a clientes o compañeros sin requerir despliegues en servidores externos.

2. Túneles Persistentes: Named Tunnels

Túneles de grado de producción vinculados de forma permanente a una cuenta de Cloudflare y asociados a dominios corporativos propios. En lugar de utilizar el subdominio *.trycloudflare.com usan el subdominio que el usuario defina, por ejemplo: app.iescelia.org. Cuentan con un identificador único (UUID) y credenciales criptográficas persistentes.

  • Modalidades de administración:

    • Administración remota (Cloudflare Zero Trust Dashboard): Se configuran y administran desde la consola web de Cloudflare One o mediante APIs y Terraform. El conector solo requiere ejecutarse con un token de autenticación.

      cloudflared tunnel run --token <TOKEN>

    • Administración local (CLI / config.yml): Se gestionan directamente en el servidor anfitrión mediante archivos de configuración YAML donde se definen las reglas de entrada (Ingress Rules).

  • Tipos de publicación y enrutamiento:

    • Public Hostname Routing (Capa 7): Publicación de aplicaciones web (HTTP/HTTPS) y servicios TCP (SSH, RDP) integrados con las políticas de identidad y acceso de Cloudflare Access (SSO con Google, Azure AD, Okta, MFA y verificación de postura del dispositivo).

    • Private Network Routing / WARP-to-Tunnel (Capa 3/4): Enrutamiento seguro de subredes privadas completas (ej. 10.20.0.0/16, 192.168.1.0/24) a la red corporativa de Cloudflare. Los usuarios remotos acceden mediante el cliente Cloudflare WARP bajo políticas Zero Trust (ZTNA), sustituyendo íntegramente a las VPNs tradicionales.

  • Casos de uso:

    • Publicación permanente de servicios internos corporativos (wikis, GitLab, paneles Proxmox, dashboards de Kubernetes).

    • Acceso remoto seguro a servidores y bases de datos vía SSH/RDP sin abrir puertos en el cortafuegos.

    • Reemplazo de VPNs tradicionales e interconexión segura entre centros de datos y múltiples nubes (Multi-Cloud / Hybrid Cloud).

Resumen Comparativo de Modalidades

Característica Quick Tunnels (TryCloudflare) Named Tunnels (Public Hostname) Named Tunnels (Private Network / CIDR)

Cuenta de Cloudflare

No requerida

Requerida

Requerida

Nombre de Dominio

Aleatorio efímero (*.trycloudflare.com)

Dominio corporativo propio

No requiere dominio público (Enrutamiento IP)

Persistencia

Temporal (vida del comando)

Permanente (servicio del sistema systemd / Docker)

Permanente (servicio del sistema systemd / Docker)

Control de Acceso

Público (sin autenticación)

Autenticación con IdP, MFA y políticas ZTNA

Políticas ZTNA a nivel de red, usuario y dispositivo

Nivel OSI

Capa 7 (HTTP) / TCP con proxy local

Capa 7 (HTTP/HTTPS) / TCP

Capa 3 / 4 (Subredes IP privadas)

Cliente Requerido

Solo navegador web

Navegador web (o cliente cloudflared para SSH/TCP)

Cliente corporativo Cloudflare WARP

Escenario idóneo

Pruebas temporales, desarrollo y demos

Publicación de aplicaciones web corporativas

Acceso remoto corporativo y sustitución de VPNs

2.5. ¿Qué es un Quick Tunnel y cómo funciona?

Un Quick Tunnel es una funcionalidad del conector ligero de código abierto cloudflared que permite exponer temporalmente una aplicación local a Internet a través de la red global de Cloudflare sin necesidad de:

  • Registrar una cuenta en Cloudflare.

  • Poseer ni configurar un nombre de dominio propio.

  • Abrir ningún puerto entrante en el cortafuegos ni en el router (Egress-Only).

  • Configurar registros DNS.

  • Generar manualmente certificados SSL/TLS.

Cómo funcionan los túneles inversos salientes (Reverse Tunnels)

En lugar de esperar conexiones entrantes (Inbound), el demonio cloudflared establece una conexión saliente (Outbound / Egress-Only) segura contra los centros de datos (Edge Data Centers) de Cloudflare más cercanos geográficamente.

Cuando un usuario externo accede a la URL asignada:

  1. La petición llega al centro de datos Edge de Cloudflare.

  2. Cloudflare aplica mitigación de ataques DDoS, termina la conexión TLS con un certificado válido y reenvía la petición a través del túnel saliente previamente establecido.

  3. El proceso local cloudflared recibe la petición del túnel y la entrega mediante conexión local (localhost) a la aplicación de destino.

  4. La respuesta sigue el camino inverso.

Comparativa: Exposición inbound tradicional vs túnel inverso (Egress-Only)
Figura 3. Comparativa: Exposición inbound tradicional vs túnel inverso (Egress-Only)

2.6. Arquitectura y flujo de comunicación

A continuación se detalla la arquitectura completa de un Quick Tunnel:

Arquitectura de Cloudflare Quick Tunnels
Figura 4. Arquitectura de Cloudflare Quick Tunnels

Protocolos de transporte del túnel

cloudflared establece múltiples conexiones redundantes hacia el Edge de Cloudflare utilizando uno de los siguientes protocolos de transporte:

  • QUIC (HTTP/3 sobre UDP 7844 - Predeterminado): Proporciona menor latencia, multiplexación sin bloqueo de cabeza de línea (Head-of-Line Blocking) y reconexión automática ante cambios de red.

  • HTTP/2 (sobre TCP 443 - Modo Fallback): Utilizado automáticamente si la red local o el cortafuegos corporativo bloquea el tráfico UDP saliente.

3. Instalación del conector cloudflared

cloudflared es un archivo ejecutable de código abierto desarrollado en Go por Cloudflare. Se encuentra disponible para los principales sistemas operativos (GNU/Linux, macOS y Windows), así como en formato de imagen oficial para contenedores Docker.

Para consultar los pasos detallados de instalación y descargar los paquetes actualizados correspondientes a su sistema operativo, consulte la documentación oficial de Cloudflare:

3.1. Creación de un túnel efímero con cloudflared

En este ejemplo vamos a suponer que tenemos un servidor web ejecutándose en nuestra máquina en el puerto 8080. Para crear un túnel temporal que permita a cualquier usuario acceder a nuestro servidor desde Internet, tendríamos que ejecutar el siguiente comando:

cloudflared tunnel --url http://localhost:8080

4. Uso del contenedor Docker de cloudflared

Como alternativa a la instalación del binario directamente en el sistema operativo anfitrión, Cloudflare distribuye la imagen oficial cloudflare/cloudflared en Docker Hub. Esta opción permite ejecutar túneles en cualquier entorno con Docker sin necesidad de gestionar dependencias ni paquetes locales.

4.1. Exposición de un servicio ubicado en otro equipo de la red local (LAN)

Un escenario muy habitual consiste en ejecutar el conector cloudflared en un contenedor Docker en nuestro portátil o estación de trabajo, pero desear exponer un servicio alojado en otra máquina o dispositivo de la red local. Por ejemplo, una Raspberry Pi, un panel de gestión Proxmox, un NAS, un servidor interno de desarrollo o un router.

Dado que el contenedor Docker dispone de conectividad saliente hacia la subred local a través del puente de red predeterminado (Default Bridge), cloudflared puede alcanzar directamente la dirección IP privada o el nombre de host de cualquier equipo accesible en la LAN.

4.1.1. Conexión a un servicio HTTP en la red local

Para tunelizar un servidor HTTP ubicado, por ejemplo, en la dirección IP 192.168.1.50 en el puerto 8080:

docker run --rm -it cloudflare/cloudflared:latest tunnel --url http://192.168.1.50:8080

4.1.2. Conexión a un servicio con HTTPS y certificado autofirmado en la LAN

Si el servicio remoto en la red local utiliza HTTPS con un certificado SSL autofirmado o emitido por una CA privada interna (como el panel web de Proxmox VE, TrueNAS, VMware ESXi o pfSense/OPNsense), añadimos el modificador --no-tls-verify para que cloudflared omita la validación del certificado local sin afectar al cifrado TLS público con Cloudflare:

docker run --rm -it cloudflare/cloudflared:latest tunnel --no-tls-verify --url https://192.168.1.100:8443
En este escenario, el contenedor actúa como puerta de enlace (Gateway) entre la red Anycast de Cloudflare y los servidores de la LAN, permitiendo publicar servicios sin necesidad de instalar cloudflared en cada una de las máquinas de la red interna.

4.2. Exposición de servicios entre contenedores en una red Docker

Si el servicio que deseamos exponer se ejecuta en otro contenedor Docker, la mejor práctica consiste en conectar ambos contenedores a una misma red virtual (User-Defined Bridge Network). De esta forma, cloudflared puede comunicarse con el servicio mediante el nombre del contenedor sin necesidad de publicar ningún puerto en el host:

# 1. Crear una red privada de Docker
docker network create lab-net

# 2. Iniciar el servicio web de prueba (Nginx) conectado a la red
docker run -d --name web-local --network lab-net nginx:alpine

# 3. Iniciar el túnel conectándolo a la misma red y apuntando al nombre del contenedor
docker run --rm -it --network lab-net cloudflare/cloudflared:latest tunnel --url http://web-local:80

4.3. Orquestación multicontenedor con Docker Compose

Para automatizar y reproducir el despliegue del servicio web y el conector cloudflared de forma declarativa, creamos un archivo compose.yaml:

services:
  # Servicio Web Local (No expone puertos al host)
  webapp:
    image: nginx:alpine
    container_name: webapp-internal
    restart: unless-stopped
    volumes:
      - ./html:/usr/share/nginx/html:ro
    networks:
      - tunnel-net

  # Conector Quick Tunnel de Cloudflare
  tunnel:
    image: cloudflare/cloudflared:latest
    container_name: cloudflared-quick
    restart: unless-stopped
    command: tunnel --no-autoupdate --url http://webapp-internal:80
    depends_on:
      - webapp
    networks:
      - tunnel-net

networks:
  tunnel-net:
    driver: bridge

Despliegue y obtención de la URL

  1. Crear el contenido web de prueba:

    mkdir -p html
echo "<h1>Servicio desplegado con Docker y Quick Tunnel</h1>" > html/index.html

  2. Iniciar los contenedores en segundo plano:

    docker compose up -d

  3. Obtener la URL asignada consultando los logs del contenedor cloudflared:

    docker compose logs tunnel | grep -o 'https://[-a-zA-Z0-9]*\.trycloudflare\.com'

  4. Detener y limpiar el laboratorio:

    docker compose down

    Al ejecutar docker compose down, los contenedores se detendrán y la red virtual tunnel-net quedará eliminada de forma limpia.

5. Opciones y parámetros avanzados de cloudflared

cloudflared dispone de múltiples modificadores de línea de comandos para adaptar el comportamiento del túnel a diferentes escenarios de red y necesidades técnicas.

5.1. Selección forzada del protocolo de transporte

Por defecto, cloudflared intenta comunicarse utilizando QUIC (UDP 7844). En algunas redes corporativas donde las conexiones UDP salientes no estándar están bloqueadas por el cortafuegos, se puede forzar el uso de HTTP/2 sobre TCP (puerto 443 estándar):

# Forzar el protocolo HTTP/2 (TCP 443)
cloudflared tunnel --protocol http2 --url http://localhost:8080

Para forzar explícitamente el protocolo QUIC:

cloudflared tunnel --protocol quic --url http://localhost:8080

5.2. Túneles hacia servicios locales con HTTPS y certificados autofirmados

Si el servicio local que deseamos exponer ya utiliza HTTPS con un certificado SSL autofirmado o de una CA privada interna, como por ejemplo, un panel de gestión Proxmox, pfSense o un servidor web local con certificado propio. cloudflared verificará el certificado y denegará la conexión por defecto.

Para omitir la validación del certificado local sin afectar al cifrado TLS público entre el cliente y Cloudflare, se utiliza el modificador --no-tls-verify:

cloudflared tunnel --no-tls-verify --url https://localhost:8443
Utilice --no-tls-verify únicamente en entornos de laboratorio o desarrollo donde se utilicen certificados autofirmados conocidos.

5.3. Exposición de servicios SSH y TCP arbitrarios

Aunque el uso más habitual de los Quick Tunnels es HTTP/HTTPS, cloudflared permite tunelizar conexiones TCP arbitrarias como SSH:

# En el servidor que aloja el servicio SSH (puerto 22)
cloudflared tunnel --url tcp://localhost:22

Para conectarse desde un equipo cliente externo es necesario tener instalado cloudflared. Se puede establecer la conexión de las siguientes formas:

1. Conexión directa con ssh y -o ProxyCommand

Podemos pasar la instrucción ProxyCommand directamente como parámetro al cliente SSH:

ssh -o ProxyCommand="cloudflared access tcp --hostname %h" usuario@alpha-beta-gamma-delta.trycloudflare.com

2. Conexión mediante cloudflared access ssh

cloudflared dispone de un subcomando específico para iniciar la sesión SSH de forma transparente:

cloudflared access ssh --hostname alpha-beta-gamma-delta.trycloudflare.com --user usuario

3. Configuración en ~/.ssh/config para conexiones recurrentes

Si se desea simplificar la conexión recurrente asignándole un alias, se puede añadir la siguiente entrada al archivo ~/.ssh/config:

Host mi-servidor-tunel
    HostName alpha-beta-gamma-delta.trycloudflare.com
    User miusuario
    ProxyCommand cloudflared access tcp --hostname %h

Y conectarse ejecutando únicamente:

ssh mi-servidor-tunel

5.4. Servidor local de métricas Prometheus

cloudflared incluye un servidor HTTP de métricas en formato Prometheus que permite monitorizar el estado operativo del túnel, la latencia y el volumen de peticiones procesadas.

1. Ejecución nativa en el sistema anfitrión

Por defecto, el servidor de métricas se enlaza a un puerto dinámico en 127.0.0.1 (seleccionando el primer puerto libre en el rango 20241–20245). Para fijar un puerto estático, se utiliza la opción --metrics:

cloudflared tunnel --metrics 127.0.0.1:9090 --url http://localhost:8080

Podemos consultar las métricas en tiempo real con curl:

curl http://127.0.0.1:9090/metrics | grep -E "tunnel_total_requests|quic_trans_received"

O verificar el estado de salud del túnel mediante el endpoint /ready:

curl -i http://127.0.0.1:9090/ready

2. Ejecución dentro de un contenedor Docker

Si se ejecuta dentro de un contenedor Docker, enlazar a 127.0.0.1 limitaría el acceso exclusivamente al entorno interno del contenedor. Para poder consultar las métricas desde la máquina anfitriona o desde un sistema Prometheus externo, es necesario enlazar a 0.0.0.0 y publicar el puerto en el host:

docker run --rm -it -p 9090:9090 cloudflare/cloudflared:latest \
  tunnel --metrics 0.0.0.0:9090 --url http://host.docker.internal:8080

5.5. Redirección de logs y ejecución en segundo plano

Al ejecutar cloudflared en una consola interactiva, el túnel se destruye al cerrar la terminal o pulsar Ctrl + C. Para mantener el túnel activo en segundo plano existen dos métodos habituales:

1. Ejecución con multiplexores de terminal (tmux)

El uso de un multiplexor de terminal como tmux es la opción recomendada cuando se desea dejar el proceso en ejecución de forma persistente y mantener la posibilidad de reconectarse a la sesión para consultar los logs en vivo.

  1. Crear e iniciar una nueva sesión de tmux:

    tmux new -s tunel-cf

  2. Iniciar el túnel dentro de la sesión:

    cloudflared tunnel --url http://localhost:8080

    Una vez que aparezca en pantalla la URL asignada (*.trycloudflare.com), el túnel estará operativo.

  3. Desconectar la sesión (Detach): Para salir de la sesión dejando el proceso ejecutándose en segundo plano, pulsar la combinación de teclas:

    • Ctrl + b y a continuación pulsar d.

  4. Listar las sesiones activas de tmux:

    tmux ls

  5. Reconectarse a la sesión (Attach): Para volver a la sesión interactiva y ver los logs en tiempo real o detener el túnel:

    tmux attach -t tunel-cf

  6. Cerrar la sesión: Para finalizar el túnel y destruir la sesión, dentro de la sesión pulse Ctrl + C para detener cloudflared y ejecute exit (o pulse Ctrl + D).

2. Ejecución con nohup y redirección de logs a archivo

Si se desea desacoplar el proceso de la terminal y registrar toda la salida en un archivo de log:

  1. Iniciar el proceso con nohup:

    nohup cloudflared tunnel --url http://localhost:8080 > ~/laboratorio-quicktunnel/tunnel.log 2>&1 &

  2. Extraer la URL pública generada:

    grep -o 'https://[-a-zA-Z0-9]*\.trycloudflare\.com' ~/laboratorio-quicktunnel/tunnel.log

  3. Detener el proceso en segundo plano:

    killall cloudflared

    De esta forma nos aseguramos de que el túnel se detenga y no quede en segundo plano consumiendo recursos.

5.6. Resumen de comandos más utilizados (Cheat Sheet)

Caso de uso Comando / Instrucción

Servicio HTTP local

cloudflared tunnel --url http://localhost:8080

Servicio HTTPS con autofirmado

cloudflared tunnel --no-tls-verify --url https://localhost:8443

Servicio SSH local (Servidor)

cloudflared tunnel --url tcp://localhost:22

Cliente SSH remoto (Conexión)

cloudflared access ssh --hostname <SUBDOMINIO>.trycloudflare.com --user <USUARIO>

Forzar protocolo TCP (HTTP/2)

cloudflared tunnel --protocol http2 --url http://localhost:8080

Métricas Prometheus nativas

cloudflared tunnel --metrics 127.0.0.1:9090 --url http://localhost:8080

Contenedor Docker hacia la LAN

docker run --rm -it cloudflare/cloudflared:latest tunnel --url http://192.168.1.50:8080

Segundo plano con tmux

tmux new -s tunel-cf y desacoplar con Ctrl + b seguido de d

6. Análisis de seguridad, bastionado y detección de amenazas

Desde la perspectiva de la seguridad informática y el bastionado de sistemas, los túneles inversos presentan una dualidad: son una herramienta defensiva excelente para reducir la superficie de ataque, pero representan un vector de riesgo significativo si se utilizan sin control dentro de una red corporativa.

6.1. Beneficios para el bastionado defensivo

  1. Cierre total de puertos de entrada (Zero Inbound Ports): Se puede configurar el cortafuegos del host (ufw, nftables, iptables) con política por defecto DROP en la cadena INPUT para todas las interfaces externas. El host es completamente invisible a escaneos de red (nmap -sS).

  2. Protección DDoS y absorción de tráfico en el Edge: Los ataques volumétricos de denegación de servicio son mitigados por la infraestructura Anycast de Cloudflare antes de llegar al servidor de origen.

  3. Aislamiento de la infraestructura real: La dirección IP pública del proveedor de hosting o del centro de datos nunca queda expuesta en registros DNS públicos.

6.2. Riesgos de seguridad corporativa: Shadow IT y C2 malicioso

A pesar de sus ventajas legítimas, los Quick Tunnels son frecuentemente utilizados por:

  • Empleados (Shadow IT): Desarrolladores o administradores que exponen bases de datos, paneles de administración o servicios internos a Internet para teletrabajar sin autorización del equipo de seguridad, eludiendo los controles del cortafuegos perimetral.

  • Actores de amenazas (Threat Actors): Ciberdelincuentes y equipos de Red Team que emplean cloudflared como canal de Comando y Control (C2) o para exfiltración de datos, ya que el tráfico saliente hacia Cloudflare suele estar permitido y se confunde con tráfico web legítimo cifrado.

6.3. Detección, monitorización y contramedidas en la red corporativa

Para que un equipo de seguridad (Blue Team / SOC) detecte y neutralice el uso no autorizado de Quick Tunnels:

1. Filtrado y monitorización a nivel de DNS

  • Bloquear o auditar consultas hacia el dominio comodín *.trycloudflare.com y hacia la API de registro api.trycloudflare.com.

  • Implementar soluciones de DNS Sinkholing o cortafuegos DNS (DNS over HTTPS / DNSSEC inspeccionado).

2. Filtrado de tráfico de red a nivel de Cortafuegos / IPS

  • Bloquear conexiones salientes en el puerto UDP 7844 utilizado por el protocolo QUIC de Cloudflare Tunnel.

  • Inspeccionar certificados TLS y SNI (Server Name Indication) en proxies web corporativos para identificar conexiones hacia trycloudflare.com.

3. Detección en el Endpoint (EDR / SIEM)

  • Monitorizar la ejecución del binario cloudflared y variantes renombradas mediante reglas SIGMA o Yara.

  • Auditar líneas de comandos sospechosas que incluyan el parámetro tunnel --url.

  • Detectar procesos no autorizados que abren sockets salientes hacia el ASN de Cloudflare.

7. Actividades

Para afianzar los conocimientos adquiridos a lo largo del tutorial, se propone la realización de las siguientes actividades prácticas:

7.1. Actividad 1: Exposición de un servicio web con Docker Compose y análisis de telemetría

  1. Crear un directorio de trabajo y definir un archivo compose.yaml que incluya un contenedor con el servicio web traefik/whoami (o un servidor Nginx) y el contenedor oficial cloudflare/cloudflared configurado para crear un Quick Tunnel.

  2. Iniciar la pila en segundo plano con docker compose up -d y extraer la URL pública asignada a partir de los logs del conector (docker compose logs).

  3. Acceder a la URL pública asignada desde un navegador web o con curl y analizar las cabeceras HTTP inyectadas por el Edge de Cloudflare (CF-Connecting-IP, CF-IPCountry, CF-Ray y X-Forwarded-For).

  4. Comprobar que en el archivo compose.yaml no se ha publicado ningún puerto en el equipo anfitrión (ports: ausente) y verificar que el servicio web únicamente es accesible a través del túnel.

7.2. Actividad 2: Exposición y acceso remoto por SSH mediante túnel TCP en segundo plano con tmux

  1. Iniciar una nueva sesión de tmux denominada tunel-ssh:

    tmux new -s tunel-ssh

  2. Dentro de la sesión de tmux, levantar un Quick Tunnel hacia el servicio SSH local (tcp://localhost:22):

    cloudflared tunnel --url tcp://localhost:22

  3. Anotar el nombre del subdominio efímero asignado (*.trycloudflare.com) y desconectar la sesión de tmux pulsando Ctrl + b seguido de d.

  4. Desde un equipo cliente externo con cloudflared instalado, conectarse al servidor SSH a través del túnel utilizando el comando:

    cloudflared access ssh --hostname <SUBDOMINIO>.trycloudflare.com --user <USUARIO>

  5. En el servidor, verificar con who y consultando los logs del servicio SSH (journalctl -u ssh) que la sesión remota figura conectada desde 127.0.0.1 o el socket local del túnel.

  6. Reanudar la sesión de tmux (tmux attach -t tunel-ssh) y detener el túnel pulsando Ctrl + c.

7.3. Actividad 3: Auditoría de bastionado defensivo y verificación de puertos con ss y nmap

  1. Con un túnel activo en el servidor, ejecutar el comando ss -tupn para auditar los sockets de red del conector cloudflared. Identificar el protocolo de transporte en uso (UDP 7844 o TCP 443) y las direcciones IP públicas del Edge de Cloudflare a las que se conecta.

  2. Configurar el cortafuegos local del host (ufw o iptables) con política por defecto DROP en la cadena de entrada (INPUT), bloqueando todo el tráfico entrante directo.

  3. Comprobar que el servicio sigue siendo 100% accesible desde Internet a través de la URL de Cloudflare gracias a la naturaleza saliente (Egress-Only) del túnel.

  4. Realizar un escaneo de puertos con nmap desde otro equipo de la red hacia la dirección IP local del servidor y verificar que ningún puerto aparece abierto.

7.4. Actividad 4: Simulación de bloqueo UDP y verificación del modo Fallback HTTP/2

  1. Iniciar un túnel cloudflared habilitando el servidor local de métricas en el puerto 9090:

    cloudflared tunnel --metrics 127.0.0.1:9090 --url http://localhost:8080

  2. Consultar las métricas iniciales con curl http://127.0.0.1:9090/metrics y comprobar que el túnel utiliza QUIC (UDP) por defecto.

  3. En otra terminal, configurar una regla en el cortafuegos local para bloquear todo el tráfico saliente en el puerto UDP 7844:

    sudo iptables -A OUTPUT -p udp --dport 7844 -j DROP

  4. Reiniciar el túnel y comprobar en los logs cómo cloudflared detecta el bloqueo UDP y conmuta automáticamente al protocolo http2 sobre TCP 443 (Fallback).

  5. Eliminar la regla de iptables tras completar la prueba:

    sudo iptables -D OUTPUT -p udp --dport 7844 -j DROP

    De esta forma nos aseguramos de restablecer el estado del cortafuegos y permitir que cloudflared vuelva a operar con el protocolo QUIC.

8. Preguntas de autoevaluación

  1. ¿Por qué un Quick Tunnel de Cloudflare no requiere abrir puertos en el router o cortafuegos local?

      1. Porque desactiva temporalmente el cortafuegos del sistema operativo.

      1. Porque utiliza una conexión saliente (Egress-Only) establecida desde el cliente hacia la red de Cloudflare, la cual permite el paso de respuestas bidireccionales a través de la tabla de estados del NAT.

      1. Porque utiliza el protocolo UPnP para abrir puertos en el router de forma oculta.

      1. Porque solo funciona en redes que no disponen de cortafuegos.

  2. ¿Qué protocolo de transporte utiliza cloudflared de forma predeterminada para comunicarse con el Edge de Cloudflare?

      1. Telnet sobre TCP 23.

      1. QUIC (HTTP/3) sobre UDP 7844.

      1. FTP pasivo sobre TCP 21.

      1. ICMP Echo Request.

  3. ¿Cuál es la principal diferencia entre un Quick Tunnel y un Named Tunnel de Cloudflare Zero Trust?

      1. Los Quick Tunnels requieren comprar un dominio .com.

      1. Los Named Tunnels son más lentos que los Quick Tunnels.

      1. Los Quick Tunnels son efímeros y no requieren cuenta, mientras que los Named Tunnels son persistentes y permiten integrar políticas de autenticación y control de acceso (IdP / MFA / Device Posture).

      1. Los Quick Tunnels solo funcionan en entornos sin cortafuegos.

  4. Desde la perspectiva de la ciberseguridad corporativa, ¿qué riesgo principal plantea el uso no controlado de herramientas como cloudflared por parte de los usuarios?

      1. Impide que el ordenador reciba actualizaciones del sistema operativo.

      1. Puede ser utilizado como canal de Shadow IT o Comando y Control (C2), eludiendo las políticas de bloqueo del cortafuegos perimetral mediante túneles salientes cifrados.

      1. Aumenta el consumo de papel en las impresoras de red.

      1. Desactiva los certificados SSL de los navegadores.

9. Referencias

10. Licencia

Licencia CC BY-NC-ND 4.0

Esta página forma parte del curso Bastionado de Redes y Sistemas © 2026 de José Juan Sánchez Hernández y su contenido se distribuye bajo una licencia Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 International.

Esta licencia exige que quienes reutilicen el material otorguen el debido crédito al autor. Permite copiar y redistribuir el material en cualquier medio o formato, únicamente en su forma original, y solo para fines no comerciales.