Crea una CDN Anycast

Empieza con la configuración global: dos servidores Debian 12 nuevos con systemd, BIRD 2, NGINX y BGP del cliente; un IPv4 /24 autorizado y un ASN de origen acordado; un origen HTTPS en una IP independiente; y un dominio cuyo DNS controles. Los ejemplos asumen peers BGP directos. Tu proveedor de tránsito debe proporcionar los valores reales de la conexión.

Presupuesta el espacio de direcciones y los acuerdos sobre el ASN, ambos servidores perimetrales, el tráfico de salida, el tráfico del origen, las comprobaciones de salud DNS y la supervisión. Pide presupuestos actuales y confirma que puedes usar BGP antes de contratar. Las direcciones siguientes son ejemplos de documentación; sustitúyelas por las tuyas. Mide los tiempos de despliegue y fallo en tu propia red.

Acuerda el ASN de origen con tus proveedores de tránsito. Si necesitas tu propio ASN, solicítalo a tu registro regional o a un proveedor patrocinador según los requisitos de ese registro. El ASN identifica la red que origina tu prefijo; es independiente del alquiler o la transferencia de direcciones.

Pide al titular del recurso que autorice ese ASN en RPKI: crea un ROA para el /24 con longitud máxima /24. Añade el objeto de ruta IRR correspondiente donde lo exija el proveedor de tránsito y proporciona una carta de autorización si se solicita. Un ROA autoriza el enrutamiento; no anuncia la ruta por ti.

Envía esta solicitud a ambos proveedores de alojamiento. No empieces la configuración del servidor hasta que confirmen que aceptan el prefijo y te proporcionen los ajustes del peer.

Ejecuta esto en París. El /32 asigna localmente la dirección de CDN; la ruta blackhole que cubre el prefijo descarta paquetes destinados a direcciones no usadas del /24. La unidad systemd siguiente restaura ambos tras un reinicio, antes de que arranquen BIRD y NGINX.

Permite HTTPS hacia la IP de CDN y el puerto TCP 179 de BGP desde el peer de tu proveedor. Mantén el acceso de gestión en la dirección unicast. Esta configuración de proxy inverso no necesita reenvío de paquetes de Linux.

Guarda esta unidad con tu IP de servicio y tu prefijo reales. Añade una interfaz dummy dedicada y conserva la configuración unicast existente del servidor.

Añade la dependencia a ambos servicios, inicia la unidad de dirección y comprueba la ruta hacia el origen. Debe usar la red unicast, no anycast0.

Añade la autenticación o la configuración multihop que requiera el proveedor antes de empezar. Deberías ver Established sin ningún prefijo de CDN exportado todavía. Si la sesión sigue caída, comprueba la dirección del peer, el ASN, el firewall y la autenticación con tu proveedor de tránsito.

Cuando la configuración NGINX siguiente supere nginx -t, instala este hook de despliegue y comprueba el temporizador de renovación en cada nodo perimetral. Los certificados independientes pueden servir el mismo nombre de host; no necesitan compartir una clave privada. A medida que crezca la flota, centraliza la emisión y la distribución segura para reducir la exposición de credenciales DNS y coordinar las renovaciones.

Para un origen NGINX, añade estas ubicaciones a su servidor HTTPS existente de origin.example.com. Proporcionan un recurso que se puede guardar en caché y una sonda sin caché, sin modificar la aplicación. Usa el certificado válido propio del origen y confirma que su registro de acceso incluye ambas rutas.

El recurso de prueba permanece vigente en una caché compartida durante 300 segundos por s-maxage. inactive=60m controla la expulsión de objetos sin uso, no su vigencia. La clave distingue los nombres de host y las cadenas de consulta. Las solicitudes con cookies o autorización evitan la caché; NGINX también respeta el tratamiento de respuestas private, no-store, Set-Cookie y Vary.

Cada PoP tiene su propia caché de disco. Usa URLs de recursos con versión para las publicaciones. Esta configuración no ofrece una API de purga global ni obliga a servir contenido obsoleto cuando falla el origen.

Cuando las comprobaciones sean correctas, activa cdn_prefix y pide al proveedor de tránsito que confirme que acepta y propaga el /24. Configura el registro A del nombre de host con la IP de CDN. Usa el modo de solo DNS si tu proveedor DNS también ofrece un proxy CDN. Prueba HTTPS desde una red externa antes de continuar.

Mantén el DNS sin cambios. Comprueba el nombre de host público desde varias redes e inspecciona X-Edge-Id. Para comprobar un PoP concreto, ejecuta curl --resolve en ese propio servidor; usar la IP Anycast desde tu portátil no puede forzar París ni Nueva York.

Desde una red externa que actualmente llegue a París, sigue creando conexiones HTTPS nuevas. Detén el controlador de salud antes de desactivar manualmente la ruta para que no pueda reactivarla. Comprueba que las solicitudes correctas acaban identificando Nueva York. Registra los fallos y el tiempo transcurrido; las conexiones existentes pueden necesitar reconectarse.

Con el controlador activo y la ruta anunciada, detén NGINX en París. Confirma que el controlador retira cdn_prefix y que las solicitudes externas pasan a Nueva York. Vuelve a iniciar NGINX y comprueba que la espera de recuperación impide volver a anunciar inmediatamente. Repite en el otro nodo perimetral.

Reinicia un nodo perimetral mientras el otro atiende tráfico. Comprueba que la dirección dummy, la sesión BIRD, el certificado, la caché y el controlador se recuperan en orden. Mide el comportamiento con caché caliente y fría en el nodo superviviente. Registra los resultados observados con las versiones de software y las redes de las sondas; no asumas un tiempo fijo de convergencia BGP.

En un servicio GeoDNS como Route 53, crea registros A de geolocalización con el mismo nombre, cdn.example.com, e identificadores de registro distintos. Configura Europe con EU_CDN_IP, North America con US_CDN_IP y Default con GLOBAL_CDN_IP. Esos valores son marcadores para tus direcciones reales. Empieza con un TTL de 60 segundos y mide el comportamiento del resolvedor.

Si trasladas el DNS autoritativo de Cloudflare a Route 53, cambia también la emisión de certificados al plugin DNS de Route 53 o delega expresamente la zona del desafío ACME. El plugin anterior de Cloudflare requiere controlar los registros autoritativos del desafío.

Asocia cada registro a la salud de su grupo. En Route 53, una coincidencia geográfica no saludable puede recurrir a un registro geográfico más amplio y después al predeterminado. Mantén el grupo global de respaldo saludable y con capacidad suficiente para absorber el tráfico regional. Si alojas juntos grupos globales y regionales, configura y supervisa sus prefijos por separado; el controlador de ejemplo gestiona un prefijo por instancia.

Combina las comprobaciones de nodos perimetrales individuales por sus rutas unicast con sondas externas de la IP regional de servicio. Una sonda a una IP Anycast puede seguir funcionando tras el fallo de un nodo porque alcanza otro. Retira el grupo del DNS cuando no pueda servir tráfico, en lugar de hacerlo cada vez que falle uno de sus miembros.

Retira primero un nodo perimetral: la IP regional debería seguir funcionando a través de otro nodo del grupo. Después deja todo el grupo fuera de servicio en una prueba controlada: las nuevas respuestas DNS deben seleccionar el respaldo. Prueba tanto las consultas nuevas como los clientes que conservan la respuesta anterior. Los cambios DNS no pueden trasladar una conexión existente ni sustituir inmediatamente todas las respuestas en caché.

GeoDNS estima la ubicación a partir del resolvedor recursivo o de una indicación EDNS Client Subnet. Prueba desde varias redes reales, incluidos los resolvedores públicos. No trates un registro predeterminado como una garantía ante fallos: Route 53 puede devolver registros no saludables cuando todas las opciones elegibles fallan las comprobaciones de salud.

También puedes combinar nodos anunciados globalmente con nodos cuyas rutas un proveedor de tránsito exporte solo a redes seleccionadas. Configúralo con las comunidades BGP documentadas del proveedor y verifica externamente el alcance. NO_EXPORT se refiere a los límites de AS, no a continentes. Es una política de enrutamiento independiente de la selección de grupos regionales mediante GeoDNS.

Si un proveedor de alojamiento no puede establecer una sesión BGP, un proveedor de tránsito puede anunciar tu prefijo y entregar el tráfico mediante túneles. Comprueba el enrutamiento de retorno y la MTU, y coloca una caché en cada ubicación receptora. Enviar todos los túneles a una única caché lejana mantiene esa caché y sus enlaces en la ruta de cada solicitud.

Estás listo para añadir tráfico cuando ambos PoPs sirvan HTTPS válido, cada uno demuestre MISS y después HIT, las respuestas privadas permanezcan fuera de la caché y retirar cualquiera de las rutas traslade las nuevas solicitudes al nodo superviviente. Empieza con recursos estáticos públicos y mide la carga del origen antes de añadir más rutas que se puedan guardar en caché.