Cloudflare Tunnel: publique aplicaciones internas de su empresa sin abrir puertos en el firewall

Cloudflare Tunnel le permite publicar una aplicación web interna, como un portal de clientes, un panel de reportes o una herramienta de administración, en un nombre de host normal como portal.example.com sin abrir ningún puerto de entrada en su firewall. Un pequeño programa llamado cloudflared se ejecuta en un servidor dentro de su red y abre conexiones solo de salida hacia Cloudflare. Los visitantes se conectan a Cloudflare, y Cloudflare envía sus peticiones de vuelta por esas conexiones. Su dirección IP pública no necesita aceptar tráfico web en absoluto. Si además pone Cloudflare Access delante, ejecuta dos conectores para tener redundancia y mantiene cloudflared actualizado, tendrá una forma más segura de publicar aplicaciones internas que el reenvío de puertos.

Cómo funciona

La publicación tradicional consiste en reenviar los puertos 80 o 443 del firewall a un servidor interno. Así, cualquiera en internet puede llegar a ese servidor, escanearlo e intentar explotarlo.

Con un túnel:

1. cloudflared se inicia en una máquina que puede llegar a la aplicación, ya sea el propio servidor de la aplicación o una pequeña máquina virtual a su lado.
2. Abre conexiones de salida hacia los centros de datos cercanos de Cloudflare. Cada instancia de cloudflared abre cuatro conexiones.
3. Un visitante solicita portal.example.com. Cloudflare asocia el nombre de host con su túnel y envía la petición por él.
4. cloudflared reenvía la petición al servicio interno, por ejemplo http://localhost:8080, y devuelve la respuesta.

La documentación de Cloudflare recomienda un modelo de seguridad positivo: bloquear todo el tráfico de entrada y permitir solo el tráfico de salida que necesita cloudflared. El requisito principal es el puerto de salida 7844 por TCP y UDP (HTTP/2 y QUIC). Si su firewall restringe el tráfico de salida, permítalo primero.

Túneles administrados de forma remota frente a túneles administrados localmente

	Administrado de forma remota	Administrado localmente
Dónde vive la configuración	En Cloudflare (panel, API o Terraform)	En un archivo config.yml en su servidor
Cómo se crea	En el panel; usted ejecuta un comando de instalación que se le proporciona	Desde la línea de comandos con cloudflared tunnel create
Recomendación de Cloudflare	Recomendado para la mayoría de los casos	Pensado para casos específicos como desarrollo local, pruebas o configuraciones heredadas

Para la mayoría de las empresas, un túnel administrado de forma remota es la opción correcta. Cualquiera con acceso al panel puede ver y cambiar las rutas, y nadie tiene que entrar al servidor para agregar un nombre de host.

Cómo configurar un túnel administrado de forma remota

1. Asegúrese de que el dominio ya esté activo en Cloudflare. Un túnel solo puede publicar nombres de host de zonas de su cuenta.
2. En el panel de Cloudflare, vaya a Networking > Tunnels y seleccione Create a tunnel. Póngale un nombre claro, como office-portal. Cloudflare reorganiza sus menús de vez en cuando; si la ruta es distinta, busque "Tunnels" en el panel.
3. Elija el sistema operativo del servidor. Cloudflare muestra un comando de instalación que incluye su token del túnel. Ejecútelo en el servidor. Instala cloudflared como servicio del sistema (systemd en Linux, un servicio de Windows en Windows) para que el túnel arranque con el equipo.
4. Trate el token como una contraseña. Quien lo tenga puede ejecutar un conector para su túnel. No lo pegue en tickets ni en chats.
5. En la pestaña Routes del túnel, seleccione Add route > Published application. Escriba el subdominio y el dominio, y en Service URL ponga la dirección interna, por ejemplo http://localhost:8080 o https://10.0.0.20.

En una configuración DNS completa, Cloudflare crea el registro DNS por usted. Antes del paso 5, lea la sección sobre Access más abajo.

Túneles administrados localmente y reglas de ingreso

Si administra el túnel desde la línea de comandos, la secuencia que indica la documentación de Cloudflare es cloudflared tunnel login, cloudflared tunnel create <NOMBRE>, un archivo config.yml, cloudflared tunnel route dns <NOMBRE> <nombre-de-host> y cloudflared tunnel run <NOMBRE>. El archivo de configuración asocia nombres de host con servicios internos mediante reglas de ingreso (ingress rules):

tunnel: <Tunnel-UUID>
credentials-file: /root/.cloudflared/<Tunnel-UUID>.json

ingress:
  - hostname: portal.example.com
    service: http://localhost:8080
  - hostname: reports.example.com
    service: http://10.0.0.25:3000
  - service: http_status:404

Las reglas se revisan de arriba hacia abajo y gana la primera que coincide. Cloudflare exige una regla general al final. Lo habitual es http_status:404, que devuelve un 404 para cualquier nombre de host que usted no haya listado, de modo que nada quede expuesto por accidente. Dos comandos detectan errores antes de ponerlos en producción:

• cloudflared tunnel ingress validate comprueba que las reglas sean válidas.
• cloudflared tunnel ingress rule https://portal.example.com muestra qué regla coincidiría con una URL.

Para ejecutarlo como servicio en Linux, use cloudflared service install. Si lo ejecuta con sudo, indique --config con la ruta completa de su archivo, porque $HOME pasa a ser /root.

Combine siempre el túnel con Access

Un túnel oculta su servidor, pero no decide quién puede usar la aplicación. La documentación de Cloudflare advierte que una aplicación publicada sin una aplicación de Access delante queda disponible para cualquiera en internet. Para todo lo interno:

1. Cree una aplicación de Cloudflare Access para el nombre de host antes de agregar la ruta. Use una política Allow limitada al grupo de su personal en el proveedor de identidad o a correos específicos.
2. En la configuración de la ruta del túnel, active Protect with Access para que el propio cloudflared verifique el token de Access.

Para los sitios web que sí deben ser públicos, el WAF de Cloudflare agrega filtrado de peticiones.

Alta disponibilidad con réplicas

Un solo proceso cloudflared es un punto único de falla. Si esa máquina virtual se reinicia por actualizaciones, la aplicación queda fuera de línea. La respuesta de Cloudflare son las réplicas: ejecutar el mismo túnel en una segunda máquina. Cada réplica abre sus propias cuatro conexiones y, si un equipo falla, los demás siguen atendiendo el tráfico.

Dos límites que conviene conocer:

• Las réplicas no balancean la carga. Cloudflare envía el tráfico a la réplica geográficamente más cercana, sin reparto round-robin ni por hash. Para una distribución real del tráfico, Cloudflare remite a su producto Load Balancing con túneles separados.
• Las réplicas solo ayudan si se ejecutan en hardware distinto. Dos máquinas virtuales en el mismo servidor físico no lo protegen si ese servidor falla.

Las réplicas también le permiten actualizar cloudflared de una máquina a la vez, sin interrupciones.

Mantenga cloudflared actualizado

El README de cloudflared indica que Cloudflare da soporte a las versiones publicadas dentro del año posterior a la versión más reciente. Las versiones más antiguas pueden dejar de funcionar cuando Cloudflare cambia cosas de su lado. Para actualizar:

• Si lo instaló desde un repositorio de paquetes (apt, yum/dnf, Homebrew), actualícelo con ese gestor de paquetes y reinicie el servicio.
• Si instaló el binario independiente, ejecute cloudflared update y reinicie el servicio, por ejemplo sudo systemctl restart cloudflared.service en Linux.
• Con Docker, descargue la imagen más reciente y vuelva a crear el contenedor.

Una actualización reinicia cloudflared e interrumpe brevemente el tráfico. Con réplicas lo evita. Incluya cloudflared en su rutina habitual de parches como cualquier otro software.

Cuándo un túnel no es la herramienta adecuada

• Correo entrante. Los servidores de correo que reciben SMTP por el puerto 25 necesitan conexiones de entrada de otros servidores de correo. Una ruta de aplicación publicada no está pensada para eso.
• Personal que necesita toda la red. Si los empleados necesitan carpetas compartidas, RDP o muchas direcciones IP internas, el enrutamiento de red privada de Cloudflare con su cliente para dispositivos, o una VPN tradicional, encaja mejor que publicar aplicaciones una por una. Nuestra guía de trabajo remoto e híbrido repasa las opciones.
• Archivos grandes o peticiones muy largas. El tráfico con proxy está sujeto a los límites de tamaño de petición y a los tiempos de espera de Cloudflare, que varían según el plan. Las aplicaciones que mueven archivos muy grandes pueden necesitar otro diseño.
• Sitios que ya están en un hosting público. Un sitio en cPanel o en la nube que debe ser público suele resolverse mejor con un registro DNS con proxy, el modo SSL/TLS correcto y un firewall de origen restringido.

Core Florida IT configura Cloudflare Tunnel y Access para empresas como proveedor de TI independiente; Cloudflare no nos respalda. Nuestros equipos de ciberseguridad y soporte de TI administrado pueden revisar cuáles de sus aplicaciones internas están expuestas hoy. Solicite una evaluación de TI gratuita, ya sea que su oficina esté en Miami-Dade, Broward o en otra parte del sur de la Florida.

Fuentes

• Cloudflare Tunnel overview (Cloudflare Docs)
• Create a tunnel in the dashboard (Cloudflare Docs)
• Locally-managed tunnels (Cloudflare Docs)
• Configuration file and ingress rules (Cloudflare Docs)
• Tunnel availability and replicas (Cloudflare Docs)
• Tunnel with firewall (Cloudflare Docs)
• Update cloudflared (Cloudflare Docs)
• cloudflared README: supported versions (GitHub)
• Add a self-hosted public application (Cloudflare Docs)