Los servidores de Cloudflare ya no poseen las direcciones IP. Entonces, ¿cómo se conectan a Internet?

Hemos documentado ampliamente una gran parte de la tecnología de Cloudflare. Por ejemplo, hemos comentado muchas veces en este blog cómo manejamos el tráfico entre los visitantes (los clientes) y nuestros servidores: "A brief primer on anycast" (2011), "Load Balancing without Load Balancers" (2013), "Path MTU discovery in practice" (2015), "Cloudflare's edge load balancer " (2020), "How we fixed the BSD socket API" (2022).

Por el contrario, casi nunca hemos hablado sobre la segunda parte de nuestra configuración de red: cómo nuestros servidores obtienen el contenido de Internet. En esta publicación nos ocuparemos de solventar este vacío. Explicaremos cómo gestionamos las direcciones IP de Cloudflare utilizadas para recuperar los datos de Internet, cómo nuestro diseño de la red de salida ha evolucionado y cómo lo hemos optimizado para utilizar el espacio de direcciones IP disponible de la mejor manera posible.

Prepárate. Tenemos mucho que tratar.

En primer lugar, la terminología.

Cada servidor de Cloudflare se ocupa de muchas clases de tráfico de red, pero las podemos clasificar en dos categorías generales:

• Tráfico cuya fuente es Internet: las conexiones de entrada que inician los clientes a nuestros servidores. En el contexto de esta publicación, las denominaremos simplemente "conexiones de entrada".
• Tráfico cuya fuente es Cloudflare: las conexiones de salida que inician nuestros servidores a otros servidores en Internet. En aras de la brevedad, las denominaremos sencillamente "conexiones de salida".

El componente de la salida, del que apenas hemos hablado en este blog, es esencial para nuestro funcionamiento. Nuestros servidores deben iniciar conexiones de salida para realizar su trabajo. Por ejemplo:

• En nuestro producto de la CDN, antes de almacenar el contenido en la caché, este se obtiene de los servidores de origen. Consulta "Pingora, the proxy that connects Cloudflare to the Internet" (2022), Argo y Alojamiento en caché.
• En el caso del producto Spectrum, cada conexión TCP de entrada genera una conexión de salida.
• Workers a menudo ejecuta varias solicitudes secundarias para crear una respuesta HTTP. Algunas de ellas podrían estar consultando servidores en Internet.
• También utilizamos productos de proxy de reenvío orientados al cliente, como WARP y Cloudflare Gateway. Estos proxies se ocupan de las conexiones de los visitantes destinadas a Internet. Nuestros servidores necesitan establecer conexiones a Internet en nombre de nuestros usuarios.

Y así sucesivamente.

Anycast en la entrada, unicast en la salida

Nuestra arquitectura de red de entrada es muy distinta a la arquitectura de salida. En la entrada, las conexiones cuyo origen es Internet las manejan exclusivamente nuestros rangos de direcciones IP anycast. Anycast es una tecnología donde cada uno de los centros de datos "anuncia" y puede manejar los mismos rangos de direcciones IP. Con muchos destinos posibles, ¿cómo sabe Internet dónde debe redirigir los paquetes? Los paquetes de los visitantes se dirigen al centro de datos más cercano en función de las métricas del BGP de Internet, que con frecuencia es también el más cercano geográficamente. Normalmente, las rutas del BGP no cambian mucho, y cabe esperar que cada dirección IP de visitante se redirija a un único centro de datos.

No obstante, aunque anycast funciona correctamente en la dirección de entrada, no puede funcionar en la salida. Establecer una conexión de salida desde una dirección IP anycast no funcionará. Considera el paquete de respuesta. Es probable que se redireccione de vuelta a una ubicación incorrecta: al centro de datos más próximo geográficamente al remitente, no necesariamente al centro de datos de origen.

Por este motivo, hasta hace poco, establecíamos conexiones de salida de una manera sencilla y convencional: proporcionábamos a cada servidor su propia dirección IP unicast. Una "dirección IP unicast" significa que un único servidor utiliza esa dirección en todo el mundo. Los paquetes de retorno se redireccionarán correctamente y volverán exactamente al servidor adecuado identificado por la dirección IP unicast.

Segmentación del tráfico según la dirección IP de salida

Al principio, las conexiones cuyo origen era Cloudflare eran principalmente operaciones de obtención de código HTTP que se dirigían a los servidores de origen en Internet. A medida que nuestra línea de productos creció, la diversidad del tráfico también. El ejemplo más destacado es nuestra aplicación WARP. Para WARP, nuestros servidores utilizan un proxy de reenvío y manejan el tráfico generado por los dispositivos de los usuarios finales. Para ello, no aplicamos el mismo nivel de intermediación que en nuestro producto de la CDN. Esto genera un problema. Los servidores de terceros en Internet, como los servidores de origen, deben poder distinguir entre las conexiones procedentes de los servicios de Cloudflare y nuestros usuarios de WARP. Tradicionalmente, para realizar esta segmentación del trafico utilizamos distintos rangos de direcciones IP para distintos tipos de tráfico (aunque hace poco introducimos técnicas más eficaces como por ejemplo Authenticated Origin Pulls).

Para resolver el problema de la diferenciación de la agrupación del tráfico fiable vs. no fiable, añadimos una dirección IP de WARP no fiable a cada uno de nuestros servidores:

Direcciones IP de salida con etiqueta de país

Pronto resultó evidente que las etiquetas de fiable vs. no fiable no eran las únicas necesarias. Para el servicio WARP, también necesitamos etiquetas de país. Por ejemplo, los usuarios de WARP del Reino Unido esperan que el sitio web bbc.com simplemente funcione. No obstante, la BCC restringe muchos de sus servicios para que únicamente puedan acceder a ellos las personas del Reino Unido.

Para ello, aplica geovallas. Utiliza una base de datos que correlaciona las direcciones IP públicas con los países, y solo permite aquellas que corresponden al Reino Unido. Actualmente, el uso de las geovallas está muy extendido en Internet. Para evitar problemas al utilizarlas, debemos elegir direcciones de salida específicas con la etiqueta de país adecuada, en función de la ubicación del usuario de WARP. Al igual que muchos otros en Internet, etiquetamos nuestro espacio de direcciones IP de salida con los códigos de país y lo publicamos como un geofeed (como este). Ten en cuenta que el geofeed publicado solo incluye datos. El hecho de que una dirección IP contenga una etiqueta de, por ejemplo, el Reino Unido, no significa que se proporcione desde el Reino Unido. Simplemente significa que el operador desea que esté ubicada geográficamente en el Reino Unido. Como muchos otros elementos en Internet, es una cuestión de confianza.

Ten en cuenta que, por ahora, tenemos tres etiquetas geográficas independientes:

• la etiqueta del país del usuario de WARP (la dirección IP de conexión del visitante)
• la ubicación del centro de datos al que se conecta el visitante
• la etiqueta del país de la dirección IP de salida

Para poder prestar el mejor servicio posible, elegiremos la dirección IP de salida de manera que su etiqueta de país coincida con el país de la dirección IP del visitante. No obstante, la salida desde una dirección IP con una etiqueta de país específica presenta algunas dificultades: nuestros centros de datos dan servicio a usuarios de todo el mundo, posiblemente de muchos países. Recuerda que, debido a anycast, no controlamos directamente el enrutamiento de entrada. La geografía de Internet no siempre coincide con la geografía física. Por ejemplo, nuestro centro de datos de Londres recibe tráfico no solo de los usuarios del Reino Unido, sino también de Irlanda o Arabia Saudí. Como resultado, nuestros servidores en Londres necesitan tener muchas direcciones de salida de WARP asociadas con muchos países:

¿Ves hacia dónde nos encaminamos? El espacio problemático se multiplica. Ya no tenemos una o dos direcciones IP de salida para cada servidor. Ahora necesitamos docenas, y el coste de las direcciones IPv4 es alto. Con este diseño, necesitamos tener muchas direcciones por servidor. Dado que trabajamos con miles de servidores, esta arquitectura resulta muy costosa.

¿Supone anycast un problema?

Recapitulemos: con la entrada anycast, no controlamos a qué centro de datos se redirige al usuario. En consecuencia, cada uno de los centros de datos debe poder realizar la salida desde una dirección con cualquier etiqueta imaginable. En el centro de datos, tampoco controlamos a qué servidor se redirige la conexión. Potencialmente, un centro de datos contiene muchas etiquetas, muchos centros de datos y muchos servidores.

¿Quizás el problema radica en la arquitectura de entrada? ¿Tal vez es mejor utilizar un diseño de red tradicional, donde se redirige a un visitante específico con el DNS a un centro de datos específico, o incluso a un servidor?

Es una posibilidad, pero nosotros decidimos adoptar un enfoque distinto. Nos gusta tener anycast en la entrada. Nos proporciona muchas ventajas:

• Rendimiento: con anycast, por definición, se redirige al visitante al centro de datos más próximo (según las métricas del BGP). Este suele ser el centro de datos más rápido para un usuario determinado.
• Conmutación por error automática: si uno de nuestros centros de datos deja de estar disponible, el tráfico se redireccionará automáticamente a la siguiente mejor ubicación posible.
• Resiliencia contra DDoS: durante un ataque de denegación de servicio o un pico de tráfico, se realiza automáticamente el equilibrio de carga entre muchos centros de datos, lo que reduce considerablemente el impacto.
• Software uniforme: la funcionalidad de cada centro de datos y de cada servidor en un centro de datos es idéntica. Utilizamos la misma pila de software en todos los servidores de todo el mundo. Cada máquina puede realizar cualquier acción, para cualquier producto. Esto posibilita una depuración fácil y la escalabilidad adecuada.

Para estas razones, nos gustaría mantener anycast en la entrada. Decidimos resolver el problema de la cardinalidad de las direcciones de salida de alguna otra manera.

Solución del problema del millón

Cada uno de los miles de servidores que utilizamos debe poder usar una dirección IP de salida con cualquiera de las etiquetas posibles. Para explicar nuestra solución, lo más fácil es mostrar primero dos diseños extremos.

Cada servidor posee todas las direcciones IP necesarias: cada servidor tiene todas las direcciones IP de salida especializadas con las etiquetas necesarias.

Un solo servidor posee la dirección IP necesaria: una dirección IP de salida especializada reside en una sola ubicación, y otros servidores le reenvían el tráfico.

Ambas opciones tienen ventajas y desventajas:

Hay una tercera manera

Hemos estado reflexionando mucho sobre este problema. Sinceramente, la primera opción extrema, donde tenemos cada dirección IP necesaria localmente en cada servidor de Cloudflare, no es completamente inviable. Lo pudimos lograr, más o menos, con IPv6. Con IPv6, el acceso al enorme espacio de direcciones IP necesario no es un problema.

Sin embargo, con IPv4 ninguna de las dos opciones es aceptable. La primera opción ofrece una salida rápida y fiable, pero el coste es muy elevado: las direcciones IPv4 necesarias son caras. La segunda opción utiliza el espacio de direcciones IP más pequeño posible, por lo que es barata, pero pone en riesgo el rendimiento y la fiabilidad.

La solución que hemos diseñado representa un compromiso entre ambos extremos. La idea general es cambiar la unidad de asignación. En lugar de asignar una dirección IPv4 /32 a cada servidor, hemos ideado un método donde asignamos una dirección IP /32 a cada centro de datos, y la compartimos entre todos los servidores físicos.

Uso compartido de una dirección IP en el centro de datos

La idea de compartir una dirección IP entre los servidores no es nueva. Tradicionalmente, para ello se puede utilizar la traducción de direcciones IP (NAT) de origen en un enrutador. Por desgracia, debido a la ingente cantidad de direcciones IP de salida que necesitamos y al gran volumen de nuestra operación, no podemos confiar en la NAT o el firewall con estado a nivel de enrutador. Tampoco nos gusta el estado compartido, por lo que no nos entusiasman las instalaciones de NAT distribuida.

Lo que decidimos hacer es dividir una dirección IP de salida entre los servidores por su rango de puertos. Para una dirección IP de salida determinada, cada servidor posee un pequeño porcentaje de los puertos de origen disponibles, una parte de los puertos.

Cuando los paquetes de retorno llegan de Internet, debemos redirigirlos a la máquina correcta. Para esta tarea, hemos personalizado "Unimog", nuestro equilibrador de carga basado en XDP de la capa 4 ("Unimog, Cloudflare's load balancer" (2020)) y funciona perfectamente.

Con una parte de los puertos de, por ejemplo, 2048 puertos, podemos compartir una dirección IP entre 31 servidores. Sin embargo, siempre existe la posibilidad de que nos quedemos sin puertos. Para resolver este problema, hemos trabajado mucho para poder reutilizar con eficiencia los puertos de salida. Consulta "How to stop running out of ports" (2022), "How to share IPv4 addresses" (2022) y nuestro segmento de Cloudflare.TV.

Básicamente, eso es todo. Cada servidor sabe qué direcciones IP y qué parte de los puertos posee. Para el enrutamiento de entrada, Unimog inspecciona los puertos y envía los paquetes a las máquinas adecuadas.

Uso compartido de una subred entre centros de datos

Sin embargo, aquí no acaba la historia. No hemos comentado cómo podemos redireccionar una única dirección /32 a un centro de datos. Tradicionalmente, en la red pública de Internet, solo es posible redireccionar subredes con una granularidad de direcciones IP /24 o 256. En nuestro caso, esto haría que se desperdiciara mucho espacio de direcciones IP.

Para resolver este problema y mejorar la utilización de nuestro espacio de direcciones IP, hemos implementado nuestros rangos de salida como... anycast. Al aplicar anycast, personalizamos Unimog y le enseñamos a reenviar los paquetes a través de nuestra red troncal al centro de datos adecuado. Unimog mantiene una base de datos como la siguiente:

198.51.100.1 - forward to LHR
198.51.100.2 - forward to CDG
198.51.100.3 - forward to MAN
...

Con este diseño, no importa a qué centro de datos se entregan los paquetes de retorno. Unimog siempre puede corregir el error y reenviar los datos a la ubicación adecuada. Básicamente, en la capa del BGP utilizamos anycast. Sin embargo, debido a nuestro diseño, semánticamente una dirección IP identifica un centro de datos, mientras que un rango de direcciones IP y de puertos identifica una máquina específica. Este comportamiento es prácticamente igual al de unicast.

Denominamos a esta pila tecnológica "soft-unicast". Es como si fuera magia. Así es como aplicamos unicast en software sobre anycast en la capa del BGP.

Soft-unicast no se distingue de la magia

Con esta configuración, hemos logrado considerables ventajas:

• Podemos compartir una dirección IP de salida /32 entre muchos servidores.
• Podemos distribuir una única subred entre muchos centros de datos, y modificarla fácilmente sobre la marcha. Esto nos permite utilizar completamente nuestros rangos de direcciones IPv4 de salida.
• Podemos agrupar direcciones IP similares. Por ejemplo, todas las direcciones IP con la etiqueta del Reino Unido podrían formar un único rango continuo. Esto reduce el tamaño del geofeed publicado.
• Podemos incorporar fácilmente nuevos rangos de direcciones IP de salida, como las direcciones IP de los clientes. Esto es muy útil para algunos de nuestros productos, como Cloudflare Zero Trust.

Todo ello se puede conseguir a un coste razonable, sin detrimento del rendimiento ni de la fiabilidad:

• Normalmente, el usuario puede salir directamente del centro de datos más próximo. Esto proporciona el mejor rendimiento posible.
• En función de las necesidades reales, podemos asignar o liberar las direcciones IP. Esto nos ofrece flexibilidad en cuanto a la gestión del coste de las direcciones IP. No necesitamos un gasto excesivo inicial.
• Puesto que utilizamos múltiples direcciones IP de salida en distintas ubicaciones, la fiabilidad nunca está en riesgo.

La verdadera ubicación de nuestras direcciones IP: "la nube"

Soft-unicast nos permite mejorar considerablemente la eficiencia. Sin embargo, nos hemos topado con algunos problemas. A veces nos preguntan: "¿Dónde existe físicamente esta dirección IP?". Es imposible responder a esta pregunta. Nuestras direcciones IP de salida no existen físicamente en ninguna ubicación. Desde la perspectiva del BGP, nuestros rangos de salida son anycast, así que residen en cualquier parte. Lógicamente, cada dirección se utiliza en un centro de datos cada vez, pero podemos moverla de un sitio a otro según la demanda.

Las redes de entrega de contenido desvían a los usuarios

Otro ejemplo: un problema que nos hemos encontrado con las CDN de terceros. Como hemos mencionado anteriormente, hay tres etiquetas de país en nuestro proceso:

• La etiqueta de país de la dirección IP desde el que se conecta el visitante
• La ubicación de nuestro centro de datos
• La etiqueta de país de las direcciones IP que hemos elegido para las conexiones de salida

El hecho de que nuestra dirección de salida tenga la etiqueta "UK" no significa siempre que se utilice realmente en el Reino Unido. Nos hemos encontrado casos donde un usuario de WARP con la etiqueta "UK", debido al mantenimiento de nuestro centro de datos de LHR, se ha redirigido a París. Una conocida CDN realizaba una búsqueda inversa de nuestras direcciones IP de salida, encontraba que tenía la etiqueta "UK" y redirigía al usuario al servidor de la CDN de Londres. Esto suele funcionar bien...pero entonces realmente realizábamos la salida desde París. Este usuario acababa redirigiendo los paquetes desde su ubicación en el Reino Unido, a París, y de vuelta al Reino Unido. Esto es perjudicial en términos del rendimiento.

Para resolver este problema, realizamos las solicitudes de DNS en el centro de datos de salida. Para el DNS, utilizamos las direcciones IP con la etiqueta de la ubicación del centro de datos, no la geoubicación específica del usuario. Esto suele resolver el problema. Sin embargo, por desgracia, aún hay excepciones.

El futuro ya está aquí

Nuestros experimentos de 2021 con la agilidad del direccionamiento han demostrado que tenemos muchas oportunidades de innovación con el direccionamiento de la entrada. Soft-unicast nos muestra que podemos conseguir gran flexibilidad y densidad en el lado de la salida.

Con cada nuevo producto, el número de etiquetas que necesitamos en la salida aumenta. Estas incluyen, entre otras, la fiabilidad del tráfico, la categoría del producto y la geolocalización. A medida que la agrupación de direcciones IPv4 utilizables disminuye, es indudable que habrá más innovación en ese espacio. Soft-unicast es nuestra solución. Pero por supuesto no es nuestro último desarrollo.

Por el momento, no obstante, parece que nos estamos alejando del unicast tradicional. Nuestras direcciones IP de salida no existen ya en ninguna ubicación fija, y actualmente algunos de nuestros servidores ni siquiera poseen una verdadera dirección IP unicast.