Crea una CDN Anycast

Inizia dalla configurazione globale: due server Debian 12 appena installati con systemd, BIRD 2, NGINX e BGP per i clienti; un IPv4 /24 autorizzato e un ASN di origine concordato; un'origine HTTPS su un IP separato; un dominio di cui controlli il DNS. Gli esempi presuppongono peer BGP diretti. L'upstream deve fornire i valori reali del peering.

Prevedi i costi per spazio di indirizzi e accordi ASN, entrambi i server edge, traffico in uscita, traffico verso l'origine, verifiche dello stato DNS e monitoraggio. Richiedi preventivi aggiornati e conferma l'idoneità a BGP prima di ordinare. Gli indirizzi sotto sono esempi riservati alla documentazione: sostituiscili con i tuoi. I tempi di distribuzione e di guasto devono essere misurati sulla tua rete.

Concorda l'ASN di origine con i tuoi upstream. Se ti serve un ASN proprio, richiedilo al registro regionale o tramite un provider sponsor secondo i requisiti di quel registro. L'ASN identifica la rete che origina il tuo prefisso; è distinto dal noleggio o dal trasferimento degli indirizzi.

Fai autorizzare quell'ASN in RPKI dal titolare della risorsa: crea un ROA per il /24 con lunghezza massima /24. Aggiungi il corrispondente oggetto route IRR dove richiesto dall'upstream e fornisci una lettera di autorizzazione se richiesta. Un ROA autorizza l'instradamento; non annuncia la rotta al posto tuo.

Invia questa richiesta a entrambi i provider di hosting. Non iniziare la configurazione dei server finché non confermano che il prefisso è accettato e non forniscono le impostazioni dei peer.

Esegui questo a Parigi. Il /32 associa localmente l'indirizzo CDN; la rotta blackhole che copre il prefisso scarta i pacchetti per gli indirizzi inutilizzati del /24. L'unità systemd sotto ripristina entrambi dopo un riavvio, prima dell'avvio di BIRD e NGINX.

Consenti HTTPS verso l'IP CDN e BGP sulla porta TCP 179 dal peer del provider. Mantieni l'accesso di gestione sull'indirizzo unicast. Questa configurazione di reverse proxy non richiede l'inoltro di pacchetti Linux.

Salva questa unità con il tuo IP di servizio e il tuo prefisso reali. Aggiunge un'interfaccia dummy dedicata e conserva la configurazione unicast esistente del server.

Aggiungi la dipendenza a entrambi i servizi, avvia l'unità dell'indirizzo e verifica la rotta verso l'origine. Deve usare la rete unicast, non anycast0.

Aggiungi l'autenticazione o le impostazioni multihop richieste dal provider prima di avviare. Lo stato atteso è Established, senza alcun prefisso CDN esportato per il momento. Se la sessione rimane inattiva, verifica indirizzo del peer, ASN, firewall e autenticazione con il tuo upstream.

Quando la configurazione NGINX sottostante supera nginx -t, installa questo hook di distribuzione e verifica il timer di rinnovo su ogni nodo edge. Certificati indipendenti possono servire lo stesso hostname senza condividere una chiave privata. Con la crescita dei nodi, centralizza emissione e distribuzione sicura per ridurre l'esposizione delle credenziali DNS e coordinare i rinnovi.

Per un'origine NGINX, aggiungi questi blocchi location al server HTTPS esistente per origin.example.com. Forniscono una risorsa memorizzabile in cache e un endpoint di verifica non memorizzato in cache senza modificare l'applicazione. Usa il certificato valido dell'origine e conferma che il suo log di accesso registri entrambi i percorsi.

La risorsa di test rimane valida nella cache condivisa per 300 secondi grazie a s-maxage. inactive=60m controlla la rimozione degli oggetti inutilizzati, non la loro validità. La chiave distingue hostname e query string. Le richieste con cookie o autorizzazione aggirano la cache; NGINX rispetta anche la gestione delle risposte private, no-store, Set-Cookie e Vary.

Ogni PoP ha una propria cache su disco. Usa URL versionati per le risorse dei rilasci. Questa configurazione non offre un'API di svuotamento globale della cache e non forza la restituzione di contenuti obsoleti quando l'origine non funziona.

Dopo il superamento delle verifiche, abilita cdn_prefix e chiedi all'upstream di confermare che il /24 sia accettato e propagato. Imposta il record A dell'hostname sull'IP CDN. Usa la modalità solo DNS se il provider DNS offre anche un proxy CDN. Verifica HTTPS da una rete esterna prima di continuare.

Lascia invariato il DNS. Verifica l'hostname pubblico da più reti ed esamina X-Edge-Id. Per controllare un PoP specifico, esegui curl --resolve su quel server stesso; usare l'IP Anycast dal portatile non può forzare Parigi o New York.

Da una rete esterna che al momento raggiunge Parigi, continua a creare nuove connessioni HTTPS. Ferma il controller di controllo dello stato prima di disabilitare manualmente la rotta, così non può riabilitarla. Verifica che le richieste riuscite finiscano per identificare New York. Registra gli errori e il tempo trascorso; le connessioni esistenti potrebbero dover essere ristabilite.

Con il controller in esecuzione e la rotta annunciata, ferma NGINX a Parigi. Conferma che il controller ritiri cdn_prefix e che le richieste esterne passino a New York. Avvia di nuovo NGINX e verifica che il ritardo di recupero impedisca un nuovo annuncio immediato. Ripeti sull'altro nodo edge.

Riavvia un nodo edge mentre l'altro serve traffico. Verifica che indirizzo dell'interfaccia dummy, sessione BIRD, certificato, cache e controller si ripristinino nell'ordine corretto. Misura il comportamento del nodo rimasto attivo sia con cache calda sia con cache fredda. Registra i risultati osservati insieme alle versioni software e alle reti usate per le verifiche; non presumere un tempo fisso di convergenza BGP.

In un servizio GeoDNS come Route 53, crea record A di geolocalizzazione con lo stesso nome, cdn.example.com, e identificatori distinti. Imposta Europa su EU_CDN_IP, Nord America su US_CDN_IP e Default su GLOBAL_CDN_IP. Questi valori sono segnaposto per i tuoi indirizzi reali. Inizia con un TTL di 60 secondi e misura il comportamento dei resolver.

Se sposti il DNS autoritativo da Cloudflare a Route 53, aggiorna anche l'emissione dei certificati per usare il plugin DNS di Route 53, oppure delega consapevolmente la zona delle challenge ACME. Il plugin Cloudflare precedente richiede il controllo dei record autoritativi delle challenge.

Associa ogni record allo stato del relativo pool. In Route 53, una corrispondenza geografica non sana può ripiegare su un record geografico più ampio e poi sul record predefinito. Mantieni il fallback globale sano e con capacità sufficiente ad assorbire il traffico regionale. Se ospiti insieme pool globali e regionali, configura e monitora separatamente i loro prefissi; il controller dell'esempio gestisce un prefisso per istanza.

Combina le verifiche dei singoli nodi edge tramite percorsi unicast con controlli esterni dell'IP di servizio regionale. Un controllo verso un IP Anycast può continuare a riuscire dopo il guasto di un nodo perché raggiunge un altro nodo. Rimuovi il pool dal DNS quando non può servire traffico, anziché a ogni guasto di un singolo membro.

Ritira prima un nodo edge: l'IP regionale deve continuare a funzionare tramite un altro nodo dello stesso pool. Poi rendi indisponibile l'intero pool in un test controllato: le nuove risposte DNS devono selezionare il fallback. Verifica sia nuove risoluzioni sia client che conservano la vecchia risposta. Le modifiche DNS non possono spostare una connessione esistente né sostituire immediatamente tutte le risposte in cache.

GeoDNS stima la posizione dal resolver ricorsivo o da un'indicazione EDNS Client Subnet. Verifica da più reti reali, inclusi resolver pubblici. Non considerare un record predefinito una garanzia di recupero: Route 53 può restituire record non sani quando tutte le opzioni idonee falliscono le verifiche dello stato.

Puoi anche combinare nodi annunciati globalmente con nodi le cui rotte vengono esportate dall'upstream solo verso reti selezionate. Configura questa politica con le community BGP documentate dal provider e verifica l'ambito dall'esterno. NO_EXPORT riguarda i confini tra AS, non i continenti. È una politica di instradamento distinta dalla selezione dei pool regionali tramite GeoDNS.

Se un provider di hosting non può stabilire un peering BGP, un provider di transito può annunciare il tuo prefisso e consegnare il traffico tramite tunnel. Verifica instradamento di ritorno e MTU e installa una cache in ogni sede ricevente. Riportare tutti i tunnel a un'unica cache distante mantiene quella cache e i suoi collegamenti nel percorso di ogni richiesta.

Puoi iniziare a inviare traffico quando entrambi i PoP servono HTTPS valido, ciascuno dimostra MISS e poi HIT, le risposte private rimangono fuori dalla cache e il ritiro di una qualsiasi delle due rotte sposta le nuove richieste alla sede rimasta attiva. Inizia con risorse statiche pubbliche e misura il carico sull'origine prima di aggiungere altri percorsi memorizzabili in cache.