Lanzamiento de Cloudflare Mesh: redes privadas seguras para usuarios, nodos, agentes y Workers

• En una era en la que los agentes de IA necesitan acceder de forma segura a recursos de red privados, herramientas existentes como VPN y túneles SSH tienen limitaciones estructurales porque no fueron diseñadas para software autónomo en lugar de personas
• Cloudflare Mesh es una solución de red privada bidireccional que conecta dispositivos personales, servidores remotos y agentes con un solo conector ligero
• Al extender Workers VPC, los agentes creados con Agents SDK pueden acceder directamente a la red Mesh, con soporte para conectar servicios internos mediante una llamada fetch() con un solo binding
• Para los usuarios existentes de Cloudflare One, las políticas de Gateway, reglas de Access y verificaciones de postura del dispositivo se aplican automáticamente al tráfico de Mesh sin configuración adicional
• Se ofrece gratis hasta 50 nodos y 50 usuarios y, con enrutamiento global en el edge en más de 330 ciudades, puede adoptarse de inmediato desde startups hasta empresas

---

El problema del acceso a redes privadas en la era de los agentes

• Están creciendo rápidamente los flujos de trabajo donde los agentes de IA necesitan alcanzar recursos privados, como consultar bases de datos de staging, llamar APIs internas o acceder a servicios de una red doméstica
• Limitaciones de las herramientas existentes:
  • Las VPN requieren inicio de sesión interactivo
  • Los túneles SSH requieren configuración manual
  • Exponer servicios públicamente genera riesgos de seguridad
  • Falta visibilidad sobre lo que realmente hace un agente una vez conectado

Tres flujos de trabajo clave

• Acceso remoto para agentes personales: al ejecutar OpenClaw en una Mac mini y acceder desde móvil o laptop, si se expone públicamente se habilita acceso al shell, sistema de archivos y red, por lo que un solo error de configuración puede crear un riesgo de seguridad
• Acceso de agentes de programación a entornos de staging: para que herramientas como Claude Code, Cursor o Codex accedan a servicios dentro de una VPC privada en la nube, hoy suele ser necesario exponerlos a Internet o tunelizar toda la VPC
• Conexión de agentes desplegados a servicios privados: cuando agentes de Workers basados en Agents SDK acceden a APIs internas o bases de datos, se necesita permiso con alcance definido, trazabilidad de auditoría y prevención de filtración de credenciales

Arquitectura y funcionamiento de Cloudflare Mesh

• Un solo conector ligero (binario) conecta dispositivos personales, servidores remotos y endpoints de usuario
• Los dispositivos conectados se comunican en ambos sentidos mediante IP privadas a través de la red global de Cloudflare en más de 330 ciudades
• El anterior WARP Connector pasa a llamarse Cloudflare Mesh node, y WARP Client pasa a llamarse Cloudflare One Client
• Casos de uso concretos:
  • Con Cloudflare One Client para iOS, conexión segura desde móvil a OpenClaw en una Mac mini local
  • Con Cloudflare One Client para macOS, un agente de programación en laptop accede a base de datos y API de staging
  • Con un nodo Mesh en un servidor Linux, se interconectan VPCs de nubes externas para que los agentes accedan a recursos y MCP de redes privadas externas

Diferencia entre Mesh y Tunnel

• Cloudflare Tunnel: adecuado para hacer proxy de tráfico unidireccional desde el edge de Cloudflare hacia un servicio privado específico, como un servidor web o una base de datos
• Cloudflare Mesh: ofrece una red bidireccional, many-to-many en la que todos los dispositivos y nodos pueden accederse mutuamente mediante IP privadas
  • No hace falta configurar un Tunnel separado por cada recurso; se puede acceder a todos los recursos conectados a Mesh

Uso de la red de Cloudflare: resolver el problema de atravesar NAT

• La mayor parte de Internet está detrás de NAT (Network Address Translation) y, si ambos dispositivos están detrás de NAT, cuando falla la conexión directa se depende de un servidor de retransmisión
• Si la infraestructura de retransmisión tiene PoP (Point of Presence) limitados, una parte significativa del tráfico pasa por relay, lo que aumenta la latencia y reduce la confiabilidad
• Cloudflare Mesh enruta todo el tráfico por la red global de Cloudflare para ofrecer rendimiento consistente sin servidores de retransmisión separados
• En tráfico cross-region y multi-cloud, ofrece mejor rendimiento de forma sostenida frente al enrutamiento por Internet público

Principales capacidades

• 50 nodos y 50 usuarios gratis: incluido en todas las cuentas de Cloudflare
• Enrutamiento global en el edge: más de 330 ciudades, backbone optimizado y sin rutas de fallback degradadas en rendimiento
• Controles de seguridad desde el día 1: políticas de Gateway, filtrado DNS, DLP, inspección de tráfico y verificaciones de postura del dispositivo se pueden activar en la misma plataforma, y cada función se habilita con un solo toggle
• Alta disponibilidad (HA): varios conectores pueden ejecutarse con el mismo token en modo active-passive, anunciando la misma ruta IP para lograr failover automático ante fallas

Integración con Workers VPC

• Extiende Workers VPC para que toda la red Mesh sea accesible desde Workers y Durable Objects
• En el archivo wrangler.jsonc, se hace binding a la red Mesh con la palabra clave reservada cf1:network:
  • "vpc_networks": [{ "binding": "MESH", "network_id": "cf1:network", "remote": true }]
• Dentro del código del Worker, se puede acceder directamente a hosts privados con env.MESH.fetch("http://10.0.1.50/api/data";), sin preregistro
• Puede usarse junto con bindings VPC basados en Tunnel, ampliando las opciones de seguridad de red
• Esto permite construir agentes y MCP cross-cloud con acceso seguro a bases de datos privadas, APIs internas y MCP

Componentes de la arquitectura completa

• Nodos Mesh: ejecutan una versión headless de Cloudflare One Client en servidores, VMs y contenedores, reciben una IP Mesh y permiten comunicación privada bidireccional por IP entre servicios
• Dispositivos: laptops y teléfonos ejecutan Cloudflare One Client para acceder directamente a nodos Mesh; SSH, consultas a bases de datos y llamadas API se manejan por IP privada
• Agentes de Workers: acceden a servicios privados mediante Workers VPC Network bindings; la red controla el alcance de acceso del agente y los servidores MCP controlan el comportamiento del agente

Hoja de ruta futura

• Enrutamiento por hostname

  • Este verano se ampliará a Mesh el enrutamiento por hostname de Cloudflare Tunnel
  • El tráfico podrá enrutarse mediante hostnames privados como wiki.local o api.staging.internal, eliminando la necesidad de administrar listas de IP
  • Se reducirá la complejidad del enrutamiento en IPs dinámicas, grupos con auto scaling y entornos temporales de contenedores

• Mesh DNS

  • Más adelante este año, todos los nodos y dispositivos que participen en Mesh recibirán hostnames internos enrutable automáticamente
  • Se podrá acceder a postgres-staging.mesh sin configuración DNS ni registros manuales
  • En combinación con el enrutamiento por hostname, será posible un acceso sin direcciones IP como ssh postgres-staging.mesh o curl http://api-prod.mesh:3000/health

• Enrutamiento con reconocimiento de identidad (Identity-aware Routing)

  • Actualmente los nodos Mesh usan un ID compartido en la capa de red; los dispositivos se autentican con ID de usuario, pero los nodos no tienen un ID de enrutamiento separado que las políticas de Gateway puedan distinguir
  • El objetivo es asignar un ID único a cada nodo, dispositivo y agente para escribir políticas basadas en el sujeto que se conecta, no en rangos de IP
  • Modelo de ID para agentes en planificación:
    • Principal/Sponsor: la persona que aprobó la acción
    • Agent: el sistema de IA que ejecuta la acción, incluyendo el ID de sesión
    • Scope: el alcance del trabajo permitido al agente
  • Esto permitirá implementar políticas granulares como “permitir lectura a agentes, pero escritura solo a humanos directamente”
  • La infraestructura ya está construida (token por nodo, ID por usuario y binding VPC por servicio); lo que se está implementando es la visibilidad de identidad en la capa de políticas

• Soporte de Mesh para contenedores

  • Actualmente los nodos Mesh se ejecutan en servidores Linux VM y bare metal
  • Está en preparación una imagen Docker de Mesh para entornos de contenedores como pods de Kubernetes, stacks de Docker Compose y runners de CI/CD
  • Al agregar un sidecar de Mesh a un stack de Docker Compose, todos los servicios del stack podrán acceder a la red privada
  • En pipelines de CI/CD, un runner de GitHub Actions podrá obtener la imagen de contenedor de Mesh, unirse a la red, ejecutar pruebas de integración contra el entorno de staging y lograr eliminación automática del nodo al terminar el contenedor
  • Estará disponible más adelante este año

Cómo empezar

• Cloudflare Mesh: comenzar desde Networking > Mesh en el dashboard de Cloudflare, gratis hasta 50 nodos y 50 usuarios
• Agents SDK + Workers VPC: instalar con npm i agents y consultar la guía de inicio rápido de Workers VPC y la guía de servidores MCP remotos
• Usuarios actuales de Cloudflare One: compatible con la configuración existente; las políticas de Gateway, verificaciones de postura del dispositivo y reglas de Access se aplican automáticamente al tráfico de Mesh

[eoeoe]

Originalmente solo había configurado un túnel en la computadora de mi casa y usaba nada más RDP... creo que también voy a tener que probar el agente.

[yangeok]

Si el precio es gratis y la seguridad es buena, obvio que lo usaría jaja

Cuando ves cosas así, te das una idea general de hacia dónde también va a cambiar DevOps

[xguru]

Como dicen que es mesh, pensé que quizá era algo parecido a Tailscale, pero es un poco distinto.
No usa un esquema P2P como Tailscale, sino una estructura que pasa por la red edge de Cloudflare,
por lo que se aplican automáticamente funciones de seguridad como las políticas de Gateway o DLP,
y lo que lo diferencia es que desde el SDK de Workers/Agents se puede llamar a servicios privados con una sola línea de fetch().
Yo mejor me quedo usando Tailscale..

[minhoryang]

Yo más bien pensé que, como el edge de Cloudflare haría el papel del relay DERP de Tailscale, ¿no habrá aparecido un competidor todavía más fuerte? Tailscale también envía la comunicación a través del relay DERP cuando no funciona el P2P. La parte de “si los PoP (Point of Presence) de la infraestructura de relay son limitados, una parte considerable del tráfico pasa por el relay, lo que provoca mayor latencia y menor confiabilidad” en particular me sonó a que estaba hablando de Tailscale. Creo que voy a usar ambos mezclados. Voy a probarlo ahora mismo.

[minhoryang]

Parece que Cloudflare Edge también usa un rango que empieza con 100.96.0.0/100. Quise usarlo junto con Tailscale, pero hubo pequeños inconvenientes desde la instalación hasta el uso. Lo comparto como referencia para quienes, como yo, quieran usar ambos al mismo tiempo.