Diseñamos la plataforma Zero Trust de Cloudflare para ayudar a las empresas a confiar en nuestra red para conectar sus redes privadas de forma segura, mejorando al mismo tiempo el rendimiento y reduciendo la carga operativa. De esta manera, podías crear una única red privada virtual, en la que todas tus redes privadas conectadas debían ser identificables de forma única.
Estamos encantados de anunciar que, a partir de hoy, puedes empezar a crear muchas redes privadas virtuales aisladas sobre Cloudflare Zero Trust, empezando por la conectividad virtualizada para los conectores Cloudflare WARP y Cloudflare Tunnel.
Conectar tus redes privadas a través de Cloudflare
Piensa en tu equipo, en los servicios alojados en distintas redes privadas, y en los empleados que acceden a esos recursos. Ahora más que nunca, esos usuarios pueden trabajar en itinerancia, en remoto, o de manera presencial. En cualquier caso, tienes que asegurarte de que solo ellos puedan acceder a tus servicios privados. Incluso entonces, querrás tener un control granular sobre lo que puede acceder cada usuario dentro de tu red.
Aquí es donde Cloudflare puede ayudarte. Ponemos a tu disposición nuestra eficaz red global, que actúa como un puente virtual entre tus usuarios y los servicios privados. El uso de Cloudflare WARP en los dispositivos de tus usuarios permite que su tráfico salga por la red de Cloudflare. Por otro lado, tus servicios privados están detrás de Cloudflare Tunnel, accesibles solo a través de la red de Cloudflare. Juntos, estos conectores protegen tu red privada virtual de un extremo a otro.
Lo mejor de esta configuración es que tu tráfico es inmediatamente más rápido y más seguro. Pero luego puedes llevarlo un paso más allá y sacar valor de muchos servicios de Cloudflare para tu tráfico enrutado de red privada: auditoría, filtrado detallado, protección ante la pérdida de datos, detección de malware, navegación segura y muchos más.
Nuestros clientes ya están encantados con nuestra solución de enrutamiento de red privada Zero Trust. Sin embargo, como todas las cosas que nos gustan, hay margen de mejora.
El problema de las redes superpuestas
En la imagen anterior, el usuario puede acceder a cualquier servicio privado como si estuviera físicamente situado dentro de la red de ese servicio privado. Por ejemplo, esto significa que escribir jira.intra en el navegador, o utilizar el protocolo SSH a una IP privada 10.1.2.3, funcionará de manera eficaz, a pesar de que ninguno de esos servicios privados está expuesto a Internet.
Sin embargo, es una asunción excesiva. Se supone que esas IP privadas subyacentes son únicas en las redes privadas conectadas a Cloudflare en la cuenta del cliente.
Supongamos ahora que tu equipo tiene dos (o más) centros de datos que utilizan el mismo espacio IP, algo que se suele conocer como CIDR, p. ej. 10.1.0.0/16. Puede que uno sea el primario y el otro el secundario, replicándose mutuamente. En este ejemplo, existiría una máquina en cada uno de esos dos centros de datos, ambas con la misma IP: 10.1.2.3.
Hasta hoy, no podías hacer esta configuración a través de Cloudflare. Conectarías el centro de datos 1 con un túnel de Cloudflare responsable del tráfico hacia 10.1.0.0/16. Luego harías lo mismo en el centro de datos 2, pero recibirías un error que te prohibiría crear una ruta IP ambigua:
En un mundo ideal, un equipo no tendría este problema. Cada red privada tendría un espacio IP único. Pero, en la práctica, no es factible, sobre todo para las grandes empresas. Pensemos en dos empresas que se han fusionado. Es casi imposible esperar que reorganicen sus redes privadas para conservar la singularidad de las direcciones IP.
$ cloudflared tunnel route ip add 10.1.0.0/16 dc-2-tunnel
API error: Failed to add route: code: 1014, reason: You already have a route defined for this exact IP subnetPrimeros pasos con tus nuevas redes virtuales
Ahora puedes superar el problema anterior mediante la creación redes virtuales únicas que aíslen de forma lógica tus rutas IP superpuestas. Se podría pensar que una red virtual es como un grupo de subespacios IP. Esto te permite crear tu infraestructura global en redes privadas independientes (virtualizadas) a las que puede acceder tu organización de Cloudflare Zero Trust a través de Cloudflare WARP.
Establezcamos este escenario.
Comenzamos creando dos redes virtuales, una de ellas será la predeterminada:
A continuación, podemos crear los túneles y enrutar los CIDR hacia ellos:
$ cloudflared tunnel vnet add —-default vnet-frankfurt "For London and Munich employees primarily"
Successfully added virtual network vnet-frankfurt with ID: 8a6ea860-cd41-45eb-b057-bb6e88a71692 (as the new default for this account)
$ cloudflared tunnel vnet add vnet-sydney "For APAC employees primarily"
Successfully added virtual network vnet-sydney with ID: e436a40f-46c4-496e-80a2-b8c9401feac7¡Y eso es todo! Ahora se pueden ejecutar tus dos túneles y conectarán tus centros de datos privados con Cloudflare, a pesar de tener IP superpuestas.
$ cloudflared tunnel create tunnel-fra
Created tunnel tunnel-fra with id 79c5ba59-ce90-4e91-8c16-047e07751b42
$ cloudflared tunnel create tunnel-syd
Created tunnel tunnel-syd with id 150ef29f-2fb0-43f8-b56f-de0baa7ab9d8
$ cloudflared tunnel route ip add --vnet vnet-frankfurt 10.1.0.0/16 tunnel-fra
Successfully added route for 10.1.0.0/16 over tunnel 79c5ba59-ce90-4e91-8c16-047e07751b42
$ cloudflared tunnel route ip add --vnet vnet-sydney 10.1.0.0/16 tunnel-syd
Successfully added route for 10.1.0.0/16 over tunnel 150ef29f-2fb0-43f8-b56f-de0baa7ab9d8Ahora se enrutará a tus usuarios a través de la red virtual vnet-frankfurt por defecto. Si algún usuario lo quisiera de otra manera, podría elegir en la configuración de la interfaz del cliente WARP, por ejemplo, que se le enrutara a través de vnet-sydney.
Cuando el usuario cambia la red virtual elegida, se informa a la red de Cloudflare de esta decisión de enrutamiento. Esto propagará esa información por todos nuestros centros de datos mediante Quicksilver en cuestión de segundos. A continuación, el cliente WARP reinicia su conectividad con nuestra red, interrumpiendo las conexiones TCP existentes que se estaban enrutando a la red virtual que se había seleccionado con anterioridad. Esto podría percibirse como si desconectaras y volvieras a conectar el cliente WARP.
Todas las organizaciones de Cloudflare Zero Trust que usan el enrutamiento de red privada contarán ahora con una red virtual por defecto que abarcará las rutas IP a Cloudflare Tunnels. Puedes empezar a usar los comandos anteriores para ampliar tu red privada, y tener IP superpuestas, y reasignar una red virtual por defecto, si así lo consideras.
Si no tienes IP superpuestas en tu infraestructura privada, no tendrás que hacer nada.
¿Y ahora qué?
Esto es solo el principio de nuestra compatibilidad con las distintas redes virtuales en Cloudflare. Como ya habrás visto, la semana pasada anunciamos la posibilidad de crear, implementar y gestionar Cloudflare Tunnels directamente desde el panel de control de Zero Trust. En este momento, las redes virtuales solo son compatibles a través de la CLI de cloudflared, pero estamos intentando integrar la gestión de las redes virtuales también en el panel de control.
Nuestro siguiente paso será hacer que Cloudflare Gateway reconozca estas redes virtuales para que se puedan aplicar políticas de Zero Trust a estos rangos de IP superpuestos. Una vez que Gateway reconozca estas redes virtuales, también propondremos este concepto con el Registro de redes para poder auditar y solucionar problemas en el futuro.