1. Objetivos

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

  • Comprender el funcionamiento de los túneles inversos salientes como alternativa a la apertura tradicional de puertos.

  • Instalar cloudflared y exponer un servicio local mediante un Quick Tunnel efímero, tanto de forma nativa como con Docker y Docker Compose.

  • Conocer las limitaciones de los Quick Tunnels y cuándo es necesario recurrir a un Named Tunnel.

  • Supervisar el túnel con las métricas de cloudflared y con las herramientas de red del sistema.

  • Valorar el uso de estos túneles desde el punto de vista del bastionado, tanto como medida defensiva como vector de Shadow IT y de comunicaciones de comando y control, y aplicar las medidas de detección correspondientes.

2. Fundamentos

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

Para que un servidor situado detrás de un router o de un cortafuegos corporativo sea accesible desde Internet, el modelo tradicional exige lo siguiente:

  1. Reenvío de puertos (port forwarding o DNAT): abrir un puerto de entrada en el router y redirigirlo a la dirección privada del servidor.

  2. Dirección IP pública enrutable: fija o, en su defecto, asociada a un nombre mediante DNS dinámico.

  3. Ausencia de CGNAT: en conexiones móviles y en muchos operadores, una misma dirección pública se comparte entre varios clientes y el reenvío de puertos es inviable.

  4. Gestión del certificado TLS: emisión y renovación periódica en el propio servidor, por ejemplo con Let’s Encrypt.

Esta exposición directa conlleva riesgos de seguridad:

  • Superficie de ataque permanente: los puertos abiertos quedan indexados en buscadores como Shodan o Censys y reciben escaneos continuos.

  • Exposición de la dirección IP: facilita ataques de denegación de servicio distribuidos (DDoS) contra el origen.

  • Movimiento lateral: si el servicio expuesto tiene una vulnerabilidad de ejecución remota de código (RCE), el atacante obtiene un punto de apoyo dentro de la red interna.

2.2. Túneles entrantes y túneles inversos

Un túnel de red encapsula el tráfico de un protocolo dentro de otro, de modo que los equipos intermedios solo procesan la cabecera externa. Según quién inicie la conexión, existen dos modelos:

  • Túnel entrante (inbound): el cliente se conecta a una dirección pública y a un puerto abierto en el destino. Es el modelo de las VPN clásicas y del reenvío de puertos.

  • Túnel inverso saliente (reverse tunnel): un agente situado junto al servicio inicia una conexión saliente hacia un punto intermedio público. Las peticiones externas llegan a ese punto y se entregan al agente por la conexión que ya está abierta. No se abre ningún puerto de entrada ni se necesita una IP pública, por lo que funciona detrás de NAT y de CGNAT.

Túnel entrante frente a túnel inverso saliente
Figura 1. Túnel entrante frente a túnel inverso saliente

Cloudflare Tunnel y Ngrok implementan el segundo modelo.

2.3. Cloudflare y cloudflared

Cloudflare es una plataforma que opera una red global con direccionamiento Anycast y actúa como proxy inverso entre los clientes de Internet y los servidores de origen. Entre sus servicios figuran la mitigación de DDoS, el cortafuegos de aplicaciones web (WAF), la red de distribución de contenidos (CDN), el DNS y la plataforma Zero Trust.

Dentro de esta última, Cloudflare Tunnel conecta servicios internos con la red de Cloudflare mediante el conector de código abierto cloudflared, escrito en Go. Este conector admite dos modalidades, que se comparan en la sección 2.5.

2.4. Qué es un Quick Tunnel y cómo funciona

Un Quick Tunnel es la modalidad más sencilla: con una sola orden, cloudflared publica un servicio local en una dirección https://<palabras-al-azar>.trycloudflare.com, sin cuenta en Cloudflare, sin dominio propio, sin registros DNS, sin certificados y sin abrir puertos de entrada.

cloudflared tunnel --url http://localhost:8080
Arquitectura de un Quick Tunnel
Figura 2. Arquitectura de un Quick Tunnel

  1. cloudflared solicita un subdominio temporal al servicio api.trycloudflare.com mediante HTTPS.

  2. Abre una conexión saliente hacia el Edge de Cloudflare más cercano.

  3. Cuando un cliente accede a la URL, la petición llega al Edge, que termina la conexión TLS con un certificado válido, aplica la mitigación de ataques y añade cabeceras como CF-Connecting-IP y CF-Ray.

  4. El Edge reenvía la petición por el túnel, cloudflared la entrega al servicio local y la respuesta recorre el camino inverso.

El cifrado TLS no es de extremo a extremo

El tráfico viaja cifrado entre el cliente y el Edge, y entre el Edge y cloudflared, pero Cloudflare termina el TLS y puede ver el contenido en claro. No exponga mediante un Quick Tunnel información que no deba ser accesible a un tercero.

2.4.1. Protocolos de transporte y puertos

cloudflared se comunica con el Edge por el puerto 7844, con uno de estos dos protocolos:

Protocolo Transporte Puerto Características

quic

UDP

7844

Predeterminado. Menor latencia y reconexión rápida ante cambios de red

http2

TCP

7844

Alternativa cuando una red bloquea el tráfico UDP saliente

cloudflared intenta primero QUIC y, pasados unos segundos, ejecuta unas comprobaciones previas de conectividad sobre ambos protocolos. Si UDP está bloqueado y TCP no, el resumen indica Environment ready with degraded transport y que continuará con http2. Si están bloqueados los dos, informa de critical failures y el túnel no llega a establecerse. La documentación oficial exige permitir el puerto 7844 en TCP y UDP hacia region1.v2.argotunnel.com y region2.v2.argotunnel.com. El registro del subdominio usa además HTTPS por el puerto 443.

2.4.2. Limitaciones

Limitación Detalle

Sin garantía de servicio

Cloudflare no ofrece disponibilidad garantizada

Dirección efímera

El subdominio cambia en cada ejecución y desaparece al detener el proceso

Sin control de acceso

Quien conozca la URL accede al servicio, sin autenticación

200 peticiones simultáneas

Las que superan ese límite reciben el código 429

Sin eventos enviados por el servidor

No se admite SSE

Solo HTTP y HTTPS

No se admiten servicios TCP arbitrarios como SSH

Los Quick Tunnels no sirven para SSH ni para otros servicios TCP

Aunque cloudflared tunnel --url tcp://localhost:22 crea el túnel sin errores, en las pruebas realizadas con cloudflared 2026.9.3 el cliente cloudflared access tcp no consigue establecer la conexión: el WebSocket se cierra de forma anormal antes de llegar al servicio. La documentación oficial de TryCloudflare tampoco contempla servicios TCP. Para acceder a SSH o a RDP debe utilizarse un Named Tunnel protegido con Cloudflare Access.

2.5. Quick Tunnels frente a Named Tunnels

Característica Quick Tunnel Named Tunnel

Cuenta de Cloudflare

No necesaria

Necesaria

Dominio

Aleatorio, *.trycloudflare.com

Propio, por ejemplo app.midominio.org

Persistencia

Mientras dure el proceso

Permanente, como servicio de systemd o contenedor

Autenticación

Ninguna

Cloudflare Access con proveedor de identidad y MFA

Protocolos

HTTP y HTTPS

HTTP, HTTPS y TCP, como SSH o RDP

Uso adecuado

Pruebas, desarrollo y demostraciones

Servicios en producción

Esta guía se centra en los Quick Tunnels. Los Named Tunnels requieren una cuenta y un dominio gestionado por Cloudflare, y su configuración queda fuera de su alcance.

3. Instalación y primer túnel

3.1. Instalación de cloudflared

  • macOS, con Homebrew:

    brew install cloudflared

  • Debian y Ubuntu, con el repositorio oficial de paquetes de Cloudflare:

    sudo mkdir -p --mode=0755 /usr/share/keyrings
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 any main' | sudo tee /etc/apt/sources.list.d/cloudflared.list
sudo apt-get update && sudo apt-get install cloudflared

  • Windows: instalador .msi publicado en el repositorio oficial. En Windows, las actualizaciones no son automáticas.

  • Docker: imagen oficial cloudflare/cloudflared, que se estudia en la sección 4.

cloudflared --version
cloudflared version 2026.9.3 (built 2026-09-24T15:31:10Z)

3.2. Primer Quick Tunnel

Para probar el túnel se necesita un servicio local. El servidor web que incorpora Python, enlazado solo a la interfaz local, sirve el contenido del directorio actual:

mkdir ~/lab_quicktunnel && cd ~/lab_quicktunnel
echo '<h1>Servicio de prueba</h1>' > index.html
python3 -m http.server 8080 --bind 127.0.0.1

En otra terminal se crea el túnel:

cloudflared tunnel --url http://localhost:8080
INF Requesting new quick Tunnel on trycloudflare.com...
INF |  Your quick Tunnel has been created! Visit it at (it may take some time to be reachable):  |
INF |  https://verde-soft-frequent-coastal.trycloudflare.com                                      |  (1)
INF Initial protocol quic                                                                        (2)
INF Starting metrics server on 127.0.0.1:20241/metrics                                           (3)
1 URL pública asignada. Puede tardar unos segundos en ser accesible.
2 Protocolo inicial de transporte.
3 Servidor local de métricas, estudiado en la sección 5.3.

Se comprueba el acceso desde cualquier equipo conectado a Internet:

curl -i https://verde-soft-frequent-coastal.trycloudflare.com

La respuesta incluye cabeceras añadidas por Cloudflare, como server: cloudflare y cf-ray. Al pulsar Ctrl + C en la terminal de cloudflared, el túnel y la URL dejan de existir.

Mientras el túnel está activo, cualquier persona que conozca la URL accede al servicio. Compruebe qué se sirve antes de crearlo: un servidor web como el anterior publica todo el contenido del directorio desde el que se ejecuta.

Con los conceptos explicados hasta aquí, ya puede realizar el Ejercicio 1. Primer Quick Tunnel.

4. Quick Tunnels con Docker

La imagen oficial cloudflare/cloudflared permite ejecutar el conector sin instalar nada en el anfitrión. En entornos reproducibles conviene fijar una etiqueta de versión concreta en lugar de latest.

4.1. Servicio en otro equipo de la red local

El contenedor accede a la red local a través del puente predeterminado de Docker, de modo que puede actuar como pasarela hacia cualquier equipo accesible, sin instalar cloudflared en él:

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

4.2. Servicios entre contenedores

Si el servicio también es un contenedor, ambos deben compartir una red definida por el usuario. Así cloudflared alcanza el servicio por su nombre, sin publicar ningún puerto en el anfitrión:

docker network create lab-net
docker run -d --name web-local --network lab-net nginx:alpine
docker run --rm -it --network lab-net cloudflare/cloudflared:latest tunnel --url http://web-local:80

4.3. Despliegue con Docker Compose

Para un despliegue declarativo y reproducible se utiliza un fichero compose.yaml:

services:
  webapp:
    image: nginx:alpine
    container_name: webapp-internal
    volumes:
      - ./html:/usr/share/nginx/html:ro
    networks:
      - tunnel-net

  tunnel:
    image: cloudflare/cloudflared:latest
    container_name: cloudflared-quick
    command: tunnel --no-autoupdate --url http://webapp-internal:80
    depends_on:
      - webapp
    networks:
      - tunnel-net

networks:
  tunnel-net:
    driver: bridge

El servicio web monta el contenido en modo de solo lectura y no publica ningún puerto. La opción --no-autoupdate es necesaria en contenedores, ya que la imagen no se actualiza a sí misma.

mkdir -p html && echo "<h1>Servicio desplegado con Docker</h1>" > html/index.html
docker compose up -d
docker compose logs tunnel | grep -o 'https://[-a-z0-9]*\.trycloudflare\.com' | grep -v '^https://api\.'
docker compose down

El filtro final descarta api.trycloudflare.com, que aparece en los registros cuando falla la solicitud del subdominio.

No añada restart: unless-stopped al servicio tunnel si necesita conservar la URL: cada reinicio crea un túnel nuevo con una dirección distinta.

Con los conceptos explicados en esta sección, ya puede realizar el Ejercicio 2. Quick Tunnel con Docker Compose.

5. Opciones avanzadas

5.1. Selección del protocolo de transporte

Por defecto, cloudflared intenta QUIC y conmuta a HTTP/2 cuando sus comprobaciones previas detectan que UDP está bloqueado. Puede forzarse uno concreto con --protocol, por ejemplo para validar el comportamiento en una red que bloquea UDP:

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

El protocolo en uso aparece en el registro, en la línea Initial protocol, y en la de registro de la conexión, protocol=http2.

5.2. Servicios locales con HTTPS y certificado no confiable

Si el servicio local usa HTTPS con un certificado autofirmado o de una CA privada, como Proxmox, pfSense o un servidor de pruebas, cloudflared rechaza la conexión al no poder validarlo. La opción --no-tls-verify desactiva esa validación solo en el tramo local:

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

Utilice --no-tls-verify únicamente en laboratorio y con servicios cuyo certificado conozca. Si el servicio está en otro equipo de la red, un atacante en esa red podría suplantarlo sin que cloudflared lo detecte.

5.3. Métricas y estado del túnel

cloudflared incluye un servidor HTTP con métricas en formato Prometheus. Por defecto escucha en 127.0.0.1 y usa el primer puerto libre desde el 20241. Para fijar uno, se utiliza --metrics:

cloudflared tunnel --metrics 127.0.0.1:9090 --url http://localhost:8080
curl -s http://127.0.0.1:9090/metrics | grep -E '^cloudflared_tunnel_(total_requests|request_errors|ha_connections|server_locations)'
curl -i http://127.0.0.1:9090/ready
Métrica Significado

cloudflared_tunnel_total_requests

Peticiones procesadas desde el inicio

cloudflared_tunnel_request_errors

Peticiones que han producido error

cloudflared_tunnel_ha_connections

Conexiones activas con el Edge

cloudflared_tunnel_server_locations

Centro de datos del Edge al que se está conectado

El punto /ready devuelve el código 200 cuando el túnel tiene al menos una conexión activa.

En un contenedor, el servidor de métricas se enlaza a todas las interfaces. Para consultarlo desde el anfitrión, publique el puerto solo en la interfaz local:

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

host.docker.internal está disponible en Docker Desktop. En Linux debe añadirse --add-host=host.docker.internal:host-gateway al comando.

5.4. Ejecución en segundo plano

Al cerrar la terminal, el túnel se destruye. Para mantenerlo activo existen dos métodos habituales:

  • Multiplexor de terminal: con tmux, se crea una sesión con tmux new -s tunel, se inicia el túnel en ella, se desacopla con Ctrl + b seguido de d y se recupera con tmux attach -t tunel. Permite consultar el registro en directo.

  • Proceso desacoplado con registro en fichero:

    nohup cloudflared tunnel --url http://localhost:8080 > tunnel.log 2>&1 &
TUNEL_PID=$!
grep -o 'https://[-a-z0-9]*\.trycloudflare\.com' tunnel.log | grep -v '^https://api\.'
kill "$TUNEL_PID"

    Guardar el identificador del proceso evita el uso de killall, que detendría también los túneles de otros usuarios o proyectos.

5.5. Resumen de órdenes

Caso de uso Orden

Servicio HTTP local

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

Servicio HTTPS con certificado no confiable

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

Forzar HTTP/2 sobre TCP 7844

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

Métricas en un puerto fijo

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

Contenedor hacia un equipo de la LAN

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

Con los conceptos explicados en esta sección, ya puede realizar el Ejercicio 3. Métricas y conexiones de red.

6. Seguridad y bastionado

Los túneles inversos presentan una dualidad: reducen la superficie de ataque del servicio que publican, pero pueden convertirse en un canal no controlado dentro de una red corporativa.

6.1. Beneficios defensivos

  • Cierre de los puertos de entrada: el cortafuegos del host puede aplicar una política DROP por defecto en la entrada. El servicio sigue siendo accesible porque la conexión se inicia desde dentro.

  • Protección del origen: la dirección IP del servidor no aparece en registros DNS públicos y la mitigación de ataques volumétricos se realiza en el Edge.

  • Certificado válido sin gestión local.

6.2. Riesgos de usar Quick Tunnels

  • Acceso público sin autenticación: la URL actúa como única protección. Si se filtra, por ejemplo en una captura de pantalla o en un historial de terminal, cualquiera accede.

  • Exposición accidental: publicar un directorio, una base de datos o un panel de administración por descuido.

  • Dependencia de un tercero: Cloudflare termina el TLS y no garantiza el servicio.

  • Protecciones del propio servicio: el túnel no sustituye la autenticación, las actualizaciones ni la configuración segura de la aplicación publicada.

6.3. Shadow IT y comunicaciones de comando y control

Un Quick Tunnel permite saltarse los controles perimetrales sin modificar el cortafuegos, ya que solo necesita tráfico saliente hacia Cloudflare. Esto lo hace atractivo para:

  • Empleados que publican servicios internos para teletrabajar sin autorización del equipo de seguridad, lo que se conoce como Shadow IT.

  • Atacantes que lo emplean como canal de comando y control o para exfiltrar datos, mezclado con tráfico legítimo de Cloudflare. MITRE ATT&CK lo recoge en la técnica Protocol Tunneling (T1572).

6.4. Detección y contramedidas

Los equipos de seguridad pueden combinar controles en tres niveles:

Nivel Indicador Acción

DNS

Consultas a *.trycloudflare.com y a api.trycloudflare.com

Registrar o bloquear en el resolvedor corporativo

Red

Conexiones salientes a region1.v2.argotunnel.com y region2.v2.argotunnel.com por el puerto 7844, y SNI como cftunnel.com

Bloquear TCP y UDP; bloquear solo UDP no basta, porque el conector recurre a HTTP/2 por TCP

Equipo

Proceso cloudflared, incluso renombrado, y líneas de órdenes con tunnel --url

Reglas de detección en el EDR o en el SIEM, con sondeo de procesos y de conexiones al ASN de Cloudflare

El bloqueo debe valorarse con cuidado: la misma infraestructura da servicio a usos legítimos de Cloudflare Tunnel. Una política razonable bloquea trycloudflare.com, ya que los Named Tunnels corporativos no lo utilizan, y permite el resto únicamente a los equipos autorizados. El ASN de Cloudflare es un indicador adicional de esa conectividad.

7. Ejercicios prácticos

Los ejercicios están diseñados para realizarse en orden y, preferiblemente, en una máquina virtual Ubuntu de pruebas con acceso a Internet. Los ejercicios 4 y 5 modifican el cortafuegos, por lo que requieren Linux. Para crear la máquina puede seguir la guía de Multipass. El último ejercicio elimina todo lo creado.

Cada túnel publica un servicio en Internet mientras está activo. Sirva únicamente directorios de prueba creados para la práctica y detenga cada túnel al terminar el ejercicio.
Nº Ejercicio Competencia que desarrolla

1

Primer Quick Tunnel

Crear un túnel e interpretar su salida

2

Quick Tunnel con Docker Compose

Publicar un contenedor sin exponer puertos y analizar las cabeceras de Cloudflare

3

Métricas y conexiones de red

Supervisar el túnel y localizar sus conexiones

4

Bastionado del host con cortafuegos

Comprobar que el servicio funciona con la entrada denegada

5

Bloqueo del puerto 7844 y detección

Simular las medidas de bloqueo y detección

6

Limpieza del entorno

Revertir los cambios realizados

7.1. Ejercicio 1. Primer Quick Tunnel

Realice los siguientes pasos:

  1. Instale cloudflared, compruebe su versión y cree el directorio ~/lab_quicktunnel con un fichero index.html.

  2. Inicie un servidor web de Python enlazado solo a 127.0.0.1:8080 y, en otra terminal, cree el túnel. Anote la URL y la tabla de comprobaciones previas de conectividad.

  3. Acceda a la URL con curl -i y localice las cabeceras server y cf-ray. Explique qué indican sobre quién responde al cliente.

  4. Detenga el túnel con Ctrl + C y compruebe que la URL deja de funcionar. Cree otro y verifique que la dirección es distinta.

7.2. Ejercicio 2. Quick Tunnel con Docker Compose

Realice los siguientes pasos:

  1. Cree el directorio ~/lab_quicktunnel/compose con un compose.yaml que despliegue el servicio traefik/whoami y el conector cloudflare/cloudflared en una red común, sin publicar ningún puerto.

  2. Inicie los contenedores y extraiga la URL de los registros descartando api.trycloudflare.com.

  3. Acceda a la URL y analice la respuesta de whoami. Localice las cabeceras Cf-Connecting-Ip, Cf-Ray, Cf-Ipcountry y X-Forwarded-For, e indique qué dirección es la del cliente real y cuál la del Edge.

  4. Compruebe que ningún contenedor publica puertos en el anfitrión y que el servicio no es accesible desde la red local por su dirección.

7.3. Ejercicio 3. Métricas y conexiones de red

Realice los siguientes pasos:

  1. Detenga la pila anterior con docker compose down y cree un túnel nativo con las métricas en el puerto 9090.

  2. Consulte /ready y las métricas cloudflared_tunnel_total_requests, cloudflared_tunnel_ha_connections y cloudflared_tunnel_server_locations. Realice varias peticiones al túnel y compruebe cómo evoluciona el contador.

  3. Liste las conexiones de red del proceso cloudflared. Identifique el puerto remoto del túnel y la conexión HTTPS que se establece al arrancar. Repita con --protocol http2 y compare el protocolo y el puerto.

7.4. Ejercicio 4. Bastionado del host con cortafuegos

Realice los siguientes pasos:

  1. Con un túnel activo, compruebe con ss -tlnp que el servidor web solo escucha en 127.0.0.1.

  2. Active ufw con la política deny en la entrada y allow en la salida. Si accede por SSH, permita antes ese servicio para no perder la sesión.

  3. Compruebe que el servicio sigue accesible a través de la URL del túnel y explique por qué el cortafuegos no lo impide.

  4. Desde otro equipo de la red, ejecute nmap sobre la dirección del servidor y verifique que el puerto 8080 no aparece abierto.

7.5. Ejercicio 5. Bloqueo del puerto 7844 y detección

Realice los siguientes pasos:

  1. Bloquee la salida UDP hacia el puerto 7844 y arranque de nuevo el túnel. Espere unos segundos y observe los reintentos con QUIC, la tabla de comprobaciones previas y la línea de resumen.

  2. Bloquee además la salida TCP hacia el puerto 7844 y compruebe que el resumen informa de fallos críticos y que no aparece ninguna línea Registered tunnel connection. Concluya qué regla necesita una organización para impedir estos túneles.

  3. Con el túnel activo, escriba una orden que lo detecte desde el propio equipo, a partir de la línea de órdenes del proceso y de sus conexiones al puerto 7844.

7.6. Ejercicio 6. Limpieza del entorno

Realice los siguientes pasos:

  1. Elimine las reglas de iptables creadas y restablezca ufw a su estado inicial.

  2. Detenga los procesos de cloudflared y del servidor web, elimine los contenedores y la red de Docker y borre el directorio de trabajo.

  3. Compruebe que no queda ningún proceso cloudflared y que ninguna URL de las anteriores responde.

8. Preguntas de autoevaluación

  1. ¿Por qué un Quick Tunnel no requiere abrir puertos de entrada?

      1. Porque desactiva el cortafuegos del sistema.

      1. Porque cloudflared inicia una conexión saliente hacia el Edge y las peticiones llegan por ella.

      1. Porque usa UPnP para abrir puertos en el router.

      1. Porque solo funciona en redes sin cortafuegos.

  2. ¿Qué puerto y qué protocolos utiliza cloudflared para comunicarse con el Edge?

      1. TCP 443 y UDP 443.

      1. TCP 23 y UDP 23.

      1. El puerto 7844, con UDP para QUIC y con TCP para HTTP/2.

      1. ICMP.

  3. Un cortafuegos corporativo bloquea el puerto UDP 7844. ¿Impide esto el uso de Quick Tunnels?

      1. Sí, porque QUIC es el único protocolo disponible.

      1. No, porque cloudflared puede utilizar HTTP/2 sobre TCP 7844, por lo que también debe bloquearse ese tráfico.

      1. No, porque usa el puerto 443 de forma exclusiva.

      1. Sí, porque Cloudflare exige UDP.

  4. ¿Qué diferencia fundamental existe entre un Quick Tunnel y un Named Tunnel?

      1. Los Quick Tunnels exigen comprar un dominio.

      1. Los Named Tunnels son más lentos.

      1. Los Quick Tunnels son efímeros, no requieren cuenta y no ofrecen autenticación; los Named Tunnels son persistentes y admiten Cloudflare Access.

      1. Los Quick Tunnels solo funcionan sin cortafuegos.

  5. ¿Se puede utilizar un Quick Tunnel para acceder por SSH a un servidor?

      1. Sí, con --url tcp://localhost:22.

      1. No: solo admiten HTTP y HTTPS, y para SSH debe usarse un Named Tunnel.

      1. Sí, pero solo con QUIC.

      1. Sí, pero solo en Docker.

  6. ¿Qué riesgo plantea el uso no controlado de cloudflared en una red corporativa?

      1. Impide las actualizaciones del sistema.

      1. Permite publicar servicios internos o establecer un canal de comando y control que elude el cortafuegos perimetral mediante tráfico saliente.

      1. Desactiva los certificados de los navegadores.

      1. Aumenta el consumo de papel de las impresoras.

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.