Construire un CDN Anycast

Commencez par la configuration globale : deux serveurs Debian 12 neufs avec systemd, BIRD 2, NGINX et BGP client ; un IPv4 /24 autorisé et un ASN d’origine convenu ; une origine HTTPS sur une adresse IP distincte ; et un domaine dont vous contrôlez le DNS. Les exemples supposent des pairs BGP directs. Votre opérateur amont doit fournir les paramètres de peering réels.

Prévoyez le budget pour l’espace d’adressage et l’ASN, les deux serveurs périphériques, le trafic sortant, le trafic vers l’origine, les contrôles de santé DNS et la supervision. Demandez des devis à jour et confirmez l’éligibilité au BGP avant de commander. Les adresses ci-dessous sont des exemples de documentation : remplacez-les par les vôtres. Mesurez les délais de déploiement et de basculement sur votre réseau.

Convenez de l’ASN d’origine avec vos opérateurs amont. Si vous avez besoin de votre propre ASN, faites une demande auprès de votre registre régional ou d’un fournisseur parrain, conformément aux critères d’éligibilité du registre. L’ASN identifie le réseau à l’origine de votre préfixe ; il est distinct de la location ou du transfert des adresses.

Demandez au détenteur de la ressource d’autoriser cet ASN dans RPKI : créez un ROA pour le /24 avec une longueur maximale /24. Ajoutez l’objet route IRR correspondant si votre opérateur amont l’exige et fournissez une lettre d’autorisation sur demande. Un ROA autorise le routage ; il n’annonce pas la route à votre place.

Envoyez cette demande aux deux hébergeurs. Ne commencez pas la configuration du serveur avant qu’ils aient confirmé l’acceptation du préfixe et fourni les paramètres du pair.

Exécutez ceci à Paris. Le /32 associe localement l’adresse du CDN ; la route blackhole couvrante supprime les paquets destinés aux adresses inutilisées du /24. L’unité systemd ci-dessous rétablit les deux après un redémarrage, avant le démarrage de BIRD et NGINX.

Autorisez HTTPS vers l’adresse IP du CDN et BGP sur le port TCP 179 depuis le pair de votre fournisseur. Gardez l’accès d’administration sur l’adresse unicast. Cette configuration de proxy inverse ne nécessite pas de transfert de paquets Linux.

Enregistrez cette unité avec votre adresse IP de service et votre préfixe réels. Elle ajoute une interface dummy dédiée et conserve la configuration unicast existante du serveur.

Ajoutez la dépendance aux deux services, démarrez l’unité d’adresse et vérifiez la route vers le serveur d’origine. Elle doit utiliser le réseau unicast, et non anycast0.

Ajoutez l’authentification ou les paramètres multihop exigés par le fournisseur avant le démarrage. La session doit passer à Established sans exporter encore le préfixe du CDN. Si elle reste inactive, vérifiez avec votre opérateur amont l’adresse du pair, l’ASN, le pare-feu et l’authentification.

Une fois la configuration NGINX ci-dessous validée par nginx -t, installez ce hook de déploiement et vérifiez le timer de renouvellement sur chaque nœud. Des certificats indépendants peuvent servir le même nom d’hôte sans partager de clé privée. À mesure que le parc s’agrandit, centralisez l’émission et sécurisez la distribution pour limiter l’exposition des identifiants DNS et coordonner les renouvellements.

Pour une origine NGINX, ajoutez ces blocs location dans son serveur HTTPS existant pour origin.example.com. Ils fournissent une ressource pouvant être mise en cache et une sonde non mise en cache, sans changer votre application. Utilisez le certificat valide de l’origine et vérifiez que son journal d’accès enregistre les deux chemins.

La ressource de test reste fraîche dans un cache partagé pendant 300 secondes grâce à s-maxage. inactive=60m contrôle l’éviction des objets inutilisés, pas leur fraîcheur. La clé distingue les noms d’hôte et les chaînes de requête. Les requêtes avec des cookies ou une autorisation contournent le cache ; NGINX respecte aussi private, no-store, Set-Cookie et le traitement des réponses Vary.

Chaque PoP possède son propre cache disque. Utilisez des URL de ressources versionnées pour chaque version déployée. Cette configuration ne fournit aucune API de purge globale et n’impose pas de servir du contenu périmé lorsque l’origine tombe en panne.

Une fois les contrôles réussis, activez cdn_prefix et demandez à votre opérateur amont de confirmer que le /24 est accepté et propagé. Faites pointer l’enregistrement A de votre nom d’hôte vers l’adresse IP du CDN. Utilisez le mode DNS seul si votre fournisseur DNS propose aussi un proxy CDN. Testez HTTPS depuis un réseau externe avant de continuer.

Laissez le DNS inchangé. Testez le nom d’hôte public depuis plusieurs réseaux et examinez X-Edge-Id. Pour contrôler un PoP précis, exécutez curl --resolve directement sur ce serveur ; utiliser l’adresse Anycast depuis votre ordinateur ne permet pas de forcer Paris ou New York.

Depuis un réseau externe qui atteint actuellement Paris, ouvrez régulièrement de nouvelles connexions HTTPS. Arrêtez le contrôleur de santé avant de désactiver manuellement la route, afin qu’il ne puisse pas la réactiver. Vérifiez que les requêtes réussies finissent par identifier New York. Notez les échecs et le temps écoulé ; les connexions existantes peuvent devoir se reconnecter.

Pendant que le contrôleur fonctionne et que la route est annoncée, arrêtez NGINX à Paris. Confirmez que le contrôleur retire cdn_prefix et que les requêtes externes se déplacent vers New York. Relancez NGINX et vérifiez que le délai de rétablissement empêche une nouvelle annonce immédiate. Répétez l’opération sur l’autre nœud.

Redémarrez un nœud pendant que l’autre sert le trafic. Vérifiez que l’adresse dummy, la session BIRD, le certificat, le cache et le contrôleur se rétablissent dans l’ordre. Mesurez le comportement du nœud restant avec un cache chaud puis un cache froid. Consignez les résultats observés avec les versions logicielles et les réseaux utilisés pour les sondes ; ne supposez pas un délai fixe de convergence BGP.

Dans un service GeoDNS comme Route 53, créez des enregistrements A de géolocalisation portant le même nom, cdn.example.com, avec des identifiants d’enregistrement distincts. Associez Europe à EU_CDN_IP, North America à US_CDN_IP et Default à GLOBAL_CDN_IP. Ces valeurs sont des exemples à remplacer par vos adresses réelles. Commencez avec un TTL de 60 secondes et mesurez le comportement des résolveurs.

Si vous déplacez votre DNS faisant autorité de Cloudflare vers Route 53, adaptez aussi l’émission des certificats au plugin DNS Route 53, ou déléguez explicitement la zone de challenge ACME. Le plugin Cloudflare précédent exige le contrôle des enregistrements de challenge faisant autorité.

Associez chaque enregistrement à l’état de santé de son pool. Dans Route 53, si la correspondance géographique est défaillante, la résolution peut se rabattre sur un enregistrement géographique plus large, puis sur l’enregistrement par défaut. Gardez le pool global de secours opérationnel et assez dimensionné pour absorber le trafic régional. Si les pools globaux et régionaux partagent les mêmes sites, configurez et surveillez leurs préfixes séparément ; le contrôleur de l’exemple gère un préfixe par instance.

Combinez les contrôles des nœuds individuels par leurs chemins unicast avec des sondes externes de l’adresse IP de service régionale. Une sonde vers une adresse Anycast peut continuer à réussir après la panne d’un nœud parce qu’elle atteint un autre nœud. Retirez un pool du DNS lorsque le pool ne peut plus servir le trafic, et non dès qu’un de ses membres tombe en panne.

Retirez d’abord un seul nœud : l’adresse IP régionale doit rester accessible par un autre nœud du pool. Rendez ensuite tout le pool indisponible dans un test contrôlé : les nouvelles réponses DNS doivent sélectionner le pool de secours. Testez à la fois les nouvelles résolutions et les clients qui conservent l’ancienne réponse. Une modification DNS ne peut ni déplacer une connexion existante ni remplacer immédiatement toutes les réponses en cache.

GeoDNS estime la localisation à partir du résolveur récursif ou d’une indication EDNS Client Subnet. Testez depuis plusieurs réseaux réels, y compris avec des résolveurs publics. Ne considérez pas l’enregistrement par défaut comme une garantie de secours : Route 53 peut renvoyer des enregistrements défaillants lorsque tous les choix admissibles échouent aux contrôles de santé.

Vous pouvez aussi combiner des nœuds annoncés mondialement avec des nœuds dont l’opérateur amont n’exporte les routes que vers certains réseaux. Configurez cela avec les communautés BGP documentées par ce fournisseur et vérifiez leur portée depuis l’extérieur. NO_EXPORT concerne les limites des AS, pas les continents. Cette politique de routage est distincte de la sélection de pools régionaux par GeoDNS.

Si un hébergeur ne peut pas établir de peering BGP, un fournisseur de transit peut annoncer votre préfixe et acheminer le trafic par des tunnels. Vérifiez le routage de retour et le MTU, et placez un cache sur chaque site de réception. Ramener tous les tunnels vers un cache unique éloigné laisse ce cache et ses liaisons sur le chemin de chaque requête.

Vous pouvez ajouter du trafic lorsque les deux PoP servent un HTTPS valide, que chacun produit MISS puis HIT, que les réponses privées ne sont pas mises en cache et que le retrait de l’une ou l’autre route déplace les nouvelles requêtes vers le site restant. Commencez par les ressources statiques publiques et mesurez la charge sur l’origine avant d’ajouter d’autres chemins pouvant être mis en cache.