Ing. Calogero Bono
Cloudflare ha hecho disponible de forma general el soporte para orígenes privados, lanzado en beta cerrada en junio. Un registro DNS con proxy puede ahora apuntar a una IP privada, y el tráfico llega al servidor a través de la conexión Cloudflare One que ya tienes. Para quien gestiona API internas, backends de agentes de IA o herramientas operativas, significa aplicar WAF, caché y bot management sin exponer el servidor en Internet. Aun así, conviene entender qué requisitos hacen falta de verdad.
Algunos términos, antes de entrar en los hechos. Origen es el servidor que aloja la aplicación, detrás de Cloudflare. WAF es el firewall de aplicaciones que filtra las peticiones dañinas. Cloudflare One es la plataforma de conectividad privada de la empresa, con túneles y redes. RFC 1918 define las direcciones IPv4 privadas, como 10.0.0.50. CGNAT indica las direcciones compartidas del bloque 100.64.0.0/10, usadas por los operadores.
¿Qué ha publicado Cloudflare?
Según el blog oficial de Cloudflare, durante la beta cerrada el acceso estaba reservado a clientes idóneos, que lo solicitaban a su account team. Ahora el acceso se abre más allá de ese grupo.
Se apunta un registro A o AAAA con proxy a una IP privada, y las herramientas de aplicación funcionan igual que con los orígenes públicos.
- WAF y reglas gestionadas
- Bot management
- Rate limiting
- Caching
- Reglas de transformación y reescritura
- Workers
¿Qué problema resuelve?
Cloudflare cuenta que ha oído con frecuencia el mismo problema. Las API internas, los backends de agentes de IA, los servidores MCP y las herramientas operativas no están pensados para estar en Internet, pero deben aceptar peticiones de socios, clientes o agentes.
Antes, poner Cloudflare delante de estos servicios requería una IP pública, un puerto abierto en el firewall o cloudflared junto al servidor. Muchas aplicaciones privadas se quedaban sin las mismas protecciones que las públicas.
Quien trabaja con redes privadas puede profundizar con nuestra guía sobre subredes privadas y grupos de seguridad en AWS.
¿Cómo funciona el enrutamiento privado?
Se crea un registro con proxy hacia el origen. Para los rangos privados compatibles, la opción de enrutamiento privado se activa sola. Si el origen tiene una IP pública accesible solo desde la red privada, se activa a mano.
La configuración es automática para las direcciones RFC 1918, para el bloque CGNAT RFC 6598 y para las IPv6 locales RFC 4193. Para estos rangos no se puede desactivar, y el intento vía API devuelve un error.
Vía API basta el atributo private_routing en el registro DNS. Cuando el proxy lo detecta, pasa la petición a la capa de red privada, que usa la conectividad existente, ya sea IPsec, GRE, Cloudflare Tunnel, CNI o Cloudflare Mesh. Con Cloudflare WAN no hace falta ningún conector en el origen. Con Mesh un conector en la red puede servir a varios orígenes.
¿Qué hace falta para activarlo?
Hacen falta algunos requisitos indicados por Cloudflare.
- El permiso Private Origins en la cuenta, que se solicita al account team.
- Conectividad Cloudflare One con IPsec, GRE, CNI, Tunnel o Mesh.
- Unified Routing activo, excepto con Tunnel.
- Con WAN o Mesh, una ruta de retorno para los rangos de origen de Cloudflare, 100.64.0.0/12 para IPv4 y 2606:4700 – cf1:5000 – – /64 para IPv6.
Cloudflare advierte de que la ruta de retorno que falta ha sido el error de configuración más frecuente. Si las peticiones caducan y al servidor no llega nada, conviene revisar eso primero.
Limitaciones a tener en cuenta
Siguen existiendo limitaciones. Argo Smart Routing y las IP de salida dedicadas de la CDN no son compatibles, y las comprobaciones de estado del origen requieren Load Balancing. La lista completa está en la documentación para desarrolladores. No hay precios ni verificaciones independientes, y la activación pasa por tu account team. El tráfico entre redes privadas todavía está en desarrollo.
Qué cambia para quien trabaja con lo digital
Si expones API para socios o agentes de IA, puedes mantener el servidor sin IP pública y sin puertos abiertos, reduciendo la superficie de ataque. Un servidor con reglas de acceso claras sigue necesitando configurarse con cuidado a nivel de red Linux. Las reglas WAF, la caché y el bot management que ya usas se aplican al nombre de host sin más intervenciones. Para las pequeñas empresas la barrera es comercial, porque se necesita una infraestructura Cloudflare One y contactar con el departamento comercial.
Nuestra opinión
El paso es útil, porque lleva las protecciones públicas allí donde antes se renunciaba por comodidad. Pero el coste oculto es la dependencia. Para proteger un servicio privado atas red, DNS y filtros a un único proveedor, con requisitos que pasan por el account team. Para las empresas que ya usan Cloudflare One tiene sentido; para las demás conviene comparar soluciones más sencillas antes de comprometerse.
Preguntas frecuentes
¿Qué son los orígenes privados de Cloudflare?
Son servidores con IP privada, a los que Cloudflare llega a través de tu conexión Cloudflare One. Siguen sin estar expuestos en Internet. WAF, caché, bot management y Workers funcionan igual que con un origen público.
¿Hace falta abrir un puerto en el firewall?
No. Según Cloudflare, el origen conserva su IP privada y no se necesita ninguna excepción de entrada en el firewall. Con Cloudflare WAN ni siquiera hace falta un conector en el servidor.
¿Qué conexiones son compatibles?
Cloudflare indica IPsec, GRE, CNI, Cloudflare Tunnel y Cloudflare Mesh. Unified Routing funciona con todas, excepto con Tunnel.
¿Por qué las peticiones caducan por tiempo de espera?
Casi siempre falta la ruta de retorno. Cloudflare dice que fue el error más común durante la beta. Con WAN o Mesh configura las rutas para 100.64.0.0/12 y 2606:4700 – cf1:5000 – – /64.
¿Funciona también entre redes privadas?
Todavía no. La versión actual cubre el tráfico público hacia orígenes privados. Cloudflare apunta a una beta cerrada para el tráfico entre redes privadas a principios de 2027.
El paso al tráfico entre redes privadas, previsto para 2027
El siguiente paso anunciado por Cloudflare es llevar también WAF y rate limiting al tráfico entre redes privadas. Por ahora es una ambición, con una beta cerrada prevista para los primeros meses de 2027.
- Lee en la documentación la lista actualizada de limitaciones antes de planificar una migración.
- Pregunta a tu account team por las condiciones de acceso a Private Origins y a la futura beta privada.
- Haz un inventario de qué servicios internos necesitan realmente recibir peticiones desde fuera, para saber dónde hace falta esta protección.
