Hoy hemos anunciado Cloudflare Magic Transit, que hace que la red de Cloudflare esté disponible para cualquier tráfico de IP en internet. Hasta ahora, Cloudflare ha administrado principalmente servicios proxy: nuestros servidores finalizan sesiones HTTP, TCP y UDP con usuarios de internet y pasan esos datos a través de nuevas sesiones que crean con servidores de origen. Con Magic Transit, ahora también operamos en la capa IP: además de finalizar sesiones, nuestros servidores están aplicando una serie de funciones de red (mitigación de DoS, establecimiento de firewall, enrutamiento, etc.) por paquete.
En los últimos nueve años, hemos creado una red global sólida y escalable que actualmente se extiende a 193 ciudades en más de 90 países y se sigue expandiendo. Todos los clientes de Cloudflare se benefician con este alcance gracias a dos técnicas importantes. La primera es la red de direccionamiento anycast. Cloudflare fue uno de los primeros en adoptarla, y utilizó esta técnica de enrutamiento para distribuir el tráfico de internet a través de nuestros centros de datos. Esto significa que cualquier centro de datos puede manejar el tráfico de cualquier cliente, y podemos crear nuevos centros de datos sin la necesidad de adquirir y suministrar nuevas direcciones IP. La segunda técnica es la arquitectura de servidor homogénea. Todos los servidores en cada uno de nuestros centros de datos periféricos puede ejecutar cada tarea. Construimos nuestros servidores en hardware básico, lo que permite aumentar rápidamente nuestra capacidad de procesamiento mediante la adición de nuevos servidores a los centros de datos existentes. Al no tener que depender de un hardware especial, hemos adquirido experiencia en ir hasta el límite de lo posible en las redes utilizando técnicas modernas del núcleo Linux.
Magic Transit se ha creado en la misma red utilizando las mismas técnicas, lo que significa que nuestros clientes ahora pueden ejecutar sus funciones de red en Cloudflare. Nuestra ventaja global rápida, segura y confiable se convierte en una ventaja para nuestros clientes. Para ver cómo funciona, sigamos el recorrido de un paquete desde un usuario en internet hasta la red de un cliente de Magic Transit.
Ponemos en funcionamiento nuestra mitigación para DoS... ¡Para usted!
En announcement blog post describimos un ejemplo de implementación para Acme Corp. Continuemos con este ejemplo aquí. Cuando Acme trae su prefijo de IP 203.0.113.0/24 a Cloudflare, comenzamos a anunciar ese prefijo a nuestros proveedores de tránsito, colegas y a los intercambios de internet en cada uno de nuestros centros de datos de todo el mundo. Además, Acme deja de anunciar el prefijo a sus propios ISP. Esto significa que cualquier paquete de IP en internet con una dirección de destino dentro del prefijo de Acme se entrega a un centro de datos de Cloudflare cercano, no al enrutador de Acme.
Supongamos que quiero acceder al servidor FTP de Acme en 203.0.113.100 desde mi computadora en la oficina de Cloudflare en Champaign, IL. Mi computadora genera un paquete TCP SYN con la dirección de destino 203.0.113.100 y lo envía a Internet. Gracias a anycast, ese paquete termina en el centro de datos de Cloudflare en Chicago, que es el centro de datos más cercano (en cuanto a distancia de enrutamiento de internet) a Champaign. El paquete llega en el enrutador del centro de datos, que utiliza el enrutamiento ECMP (Multitrayecto de igual costo) para seleccionar qué servidor debe administrar el paquete y enviarlo al servidor seleccionado.
Una vez en el servidor, el paquete fluye a través de nuestras funciones de detección y mitigación de DoS XDP e iptables. Si se determina que este paquete TCP SYN forma parte de un ataque, se descartaría y sería el fin de este. Afortunadamente para mí, el paquete puede pasar.
Hasta ahora, esto es exactamente igual que cualquier otro tráfico en la red de Cloudflare. Debido a nuestra experiencia en la gestión de una red anycast global, podemos atraer el tráfico de clientes de Magic Transit a cada centro de datos y aplicar la misma solución de mitigación de DoS que ha estado protegiendo a Cloudflare durante años. Nuestra solución de DoS ha controlado algunos de los ataques más grandes que se registraron, lo que incluye un ataque SYN de 942 Gbps en 2018. A continuación se muestra una captura de pantalla de un reciente ataque SYN de 300 millones de paquetes por segundo. Nuestra arquitectura nos permite escalar para detener los ataques más grandes.
Espacios de nombres de red para aislamiento y control
Lo anterior es idéntico a la forma en que se procesa todo el resto del tráfico de Cloudflare, pero aquí es donde se acaban las similitudes. Para nuestros otros servicios, el paquete TCP SYN ahora se enviaría a un proceso de proxy local (por ejemplo, nuestra pila HTTP/S en nginx). Para Magic Transit, queremos suministrar y aplicar de manera dinámica funciones de red definidas por el cliente como firewalls y enrutamiento. Necesitábamos una manera de acelerar y configurar estas funciones de red, y al mismo tiempo proporcionar un aislamiento entre redes. Para ello, recurrimos a los espacios de nombres de red.
Los espacios de nombres son una serie de características del núcleo Linux para crear instancias virtuales ligeras de recursos del sistema que se pueden compartir entre un grupo de procesos. Los espacios de nombres son un componente fundamental para la contenerización en Linux. En particular, Docker se crea en espacios de nombres de Linux. Un espacio de nombres de red es una instancia aislada de la pila de la red Linux, que incluye sus propias interfaces de red (con sus propios ganchos eBPF), tablas de enrutamiento, configuración de netfilter, etc. Los espacios de nombres de red nos proporcionan un mecanismo de bajo costo para aplicar rápidamente configuraciones de red definidas por el cliente en forma aislada, con las características integradas del núcleo Linux para que el rendimiento no se vea afectado por el reenvío de paquetes del espacio de usuario o el proxy.
Cuando un nuevo cliente comienza a usar Magic Transit, creamos un nuevo espacio de nombres de red para ese cliente en todos los servidores de nuestra red perimetral (¿mencioné que cada servidor puede ejecutar cada tarea?). Creamos un daemon que se ejecuta en nuestros servidores y se encarga de administrar estos espacios de nombres de red y sus configuraciones. Este daemon lee constantemente las actualizaciones de configuración de Quicksilver, nuestra tienda clave distribuida a nivel global, y aplica las configuraciones definidas por el cliente para firewalls, enrutamiento, etc., dentro del espacio de nombres del cliente. Por ejemplo, si Acme desea suministrar una regla de firewall para permitir el tráfico de FTP (puertos TCP 20 y 21) a 203.0.113.100, esa configuración se propaga a nivel global a través de Quicksilver y el daemon de Magic Transit aplica la regla de firewall mediante la adición de una regla nftables al espacio de nombres del cliente Acme:
# Apply nftables rule inside Acme’s namespace
$ sudo ip netns exec acme_namespace nft add rule inet filter prerouting ip daddr 203.0.113.100 tcp dport 20-21 accept# Aplicar regla nftables en el espacio de nombres de Acme
$ sudo ip netns exec acme_namespace nft add rule inet filter prerouting ip daddr 203.0.113.100 tcp dport 20-21 accept
Llevar el tráfico del cliente a su espacio de nombres de red requiere una configuración de enrutamiento en el espacio de nombres de red predeterminado. Cuando se crea un espacio de nombres de red, también se crea un par de interfaces ethernet virtuales (veth): una en el espacio de nombres predeterminado y la otra en el espacio de nombres recién creado. Este par de interfaz crea un "cable virtual” para enviar el tráfico de red dentro y fuera del nuevo espacio de nombres de red. En el espacio de nombres de red predeterminado, mantenemos una tabla de enrutamiento que reenvía los prefijos de IP del cliente de Magic Transit a las veth que corresponden a los espacios de nombres de esos clientes. Utilizamos iptables para marcar los paquetes que están destinados a los prefijos del cliente de Magic Transit, y tenemos una regla de enrutamiento que especifica que estos paquetes marcados especialmente deben utilizar la tabla de enrutamiento de Magic Transit.
(¿Por qué tomarse la molestia de marcar los paquetes en iptables y mantener una tabla de enrutamiento separada? Aislamiento. Al mantener separadas las configuraciones de enrutamiento de Magic Transit, reducimos el riesgo de modificar accidentalmente la tabla de enrutamiento predeterminada y afectar el flujo del tráfico que no es de Magic Transit en nuestra periferia).
Los espacios de nombres de red ofrecen un entorno ligero donde un cliente de Magic Transit puede ejecutar y administrar funciones de red de manera aislada, lo que nos permite poner el control total en manos del cliente.
GRE + anycast = magia
Después de pasar las funciones de red perimetral, el paquete TCP SYN está listo finalmente para ser entregado nuevamente a la infraestructura de red del cliente. Debido a que Acme Corp. no tiene un espacio físico de red en una instalación con Cloudflare, necesitamos enviar su tráfico de red a través de la internet pública.
Esto plantea un problema. La dirección de destino del paquete TCP SYN es 203.0.113.100, pero la única red que anuncia el prefijo IP 203.0.113.0/24 en internet es Cloudflare. Esto significa que no podemos simplemente reenviar este paquete a internet, ¡ya que volvería a nosotros como un bumerán! Para enviar este paquete a Acme necesitamos utilizar una técnica que se denomina tunelización.
La tunelización es un método que permite transportar tráfico desde una red a través de otra red. En nuestro caso, esto implica la encapsulación de los paquetes de IP de Acme dentro de los paquetes de IP que se pueden enviar al enrutador de Acme a través de internet. Hay una serie de protocolos de tunelización comunes, pero la encapsulación de enrutamiento genérico (GRE) se utiliza con frecuencia por su simplicidad y el soporte generalizado que brindan los proveedores.
Los extremos del túnel de GRE se configuran tanto en los servidores de Cloudflare (dentro del espacio de nombres de red de Acme) como en el enrutador de Acme. Luego, los servidores de Cloudflare encapsulan los paquetes de IP con destino a 203.0.113.0/24 dentro de los paquetes de IP con destino a una dirección IP enrutable públicamente para el enrutador de Acme, que desencapsula los paquetes y los libera en la red interna de Acme.
Ahora bien, he omitido un detalle importante en el diagrama anterior: la dirección IP del lado de Cloudflare del túnel de GRE. La configuración de un túnel de GRE exige la especificación de una dirección IP para cada lado, y el encabezado IP externo para los paquetes enviados por el túnel debe utilizar estas direcciones específicas. Pero Cloudflare tiene miles de servidores, cada uno de los cuales puede necesitar el envío de paquetes al cliente a través de un túnel. Entonces, ¿con cuántas direcciones IP de Cloudflare (y túneles de GRE) necesita hablar el cliente? La respuesta: solo una, gracias a la magia de anycast.
Cloudflare utiliza direcciones IP de anycast para los extremos de nuestro túnel de GRE, lo que significa que cualquier servidor en cualquier centro de datos puede encapsular y desencapsular paquetes para el mismo túnel de GRE. ¿Cómo es posible? ¿Un túnel no es un enlace de extremo a extremo? El protocolo GRE en sí es un protocolo sin estado, cada paquete se procesa de manera independiente y no se necesita ninguna negociación o coordinación entre los extremos del túnel. Si bien el túnel está técnicamente vinculado a una dirección IP, no necesita estar vinculado a un dispositivo específico. Todo dispositivo que pueda quitar los encabezados externos y luego enrutar el paquete interno puede administrar cualquier paquete de GRE enviado por el túnel. En realidad, en el contexto de anycast el término “túnel” resulta confuso, ya que implica un enlace entre dos puntos fijos. Con GRE de Anycast de Cloudflare, un único “túnel” le brinda un conducto a cada servidor en cada centro de datos en el perímetro global de Cloudflare.
Una ventaja muy importante del GRE de Anycast es que elimina las fallas individuales que luego generan una falla global. Tradicionalmente, el GRE en internet puede resultar un problema, ya que un corte de internet entre los dos extremos del GRE rompe completamente el “túnel”. Esto significa que para enviar datos de manera segura es necesario configurar y mantener túneles de GRE adicionales que terminen en diferentes sitios físicos y volver a enrutar el tráfico cuando uno de los túneles se rompe. Pero como Cloudflare encapsula y envía el tráfico de los clientes desde cada uno de los servidores de cada centro de datos, si se rompe un “túnel”, están los adicionales. Esto significa que los clientes de Magic Transit pueden aprovechar la redundancia y la fiabilidad de las terminales de los túneles en varios sitios físicos y configurar y mantener un único extremo de GRE, lo que simplifica sus trabajos.
Nuestra escala ahora es su escala
Magic Transit es una manera novedosa y potente de implementar funciones de red a escala. No solo le brindamos una instancia virtual, le ofrecemos una ventaja virtual a nivel global. Magic Transit toma los componentes de hardware que usted normalmente colocaría en la red en sus instalaciones y los distribuye entre todos los servidores de cada centro de datos en la red de Cloudflare. Esto le brinda acceso a nuestra red de anycast global, a nuestra flota de servidores con capacidad de ejecutar sus tareas y a nuestra experiencia en ingeniería para construir redes rápidas, confiables y seguras. Nuestra escala ahora es su escala.