Criar uma CDN Anycast

Comece com a configuração global: dois servidores Debian 12 recém-configurados com systemd, BIRD 2, NGINX e BGP do cliente; um IPv4 /24 autorizado e um ASN de origem acordado; uma origem HTTPS em um IP separado; e um domínio cujo DNS você controla. Os exemplos pressupõem peers BGP diretos. Seu provedor upstream deve fornecer os valores reais de peering.

Inclua no orçamento o bloco de endereços e os acordos de ASN, os dois servidores de borda, o tráfego de saída e de origem, as verificações de saúde DNS e o monitoramento. Obtenha cotações atuais e confirme a elegibilidade para BGP antes de contratar. Os endereços abaixo são exemplos para documentação; substitua-os pelos seus. Os tempos de implantação e de falha precisam ser medidos na sua rede.

Acorde o ASN de origem com seus provedores upstream. Se precisar de um ASN próprio, solicite-o ao registro regional ou a um provedor patrocinador, conforme as regras de elegibilidade desse registro. O ASN identifica a rede que origina o prefixo; ele é independente do aluguel ou da transferência do bloco de endereços.

Peça ao titular do bloco que autorize esse ASN no RPKI: crie um ROA para o /24 com comprimento máximo /24. Adicione o objeto de rota IRR correspondente quando o provedor upstream exigir e forneça uma carta de autorização se solicitada. Um ROA autoriza o roteamento; ele não anuncia a rota por você.

Envie esta solicitação aos dois provedores de hospedagem. Não comece a configurar o servidor antes que confirmem a aceitação do prefixo e forneçam as configurações dos peers.

Execute isto em Paris. O /32 associa o endereço da CDN localmente; a rota blackhole que cobre o /24 descarta pacotes para os endereços não utilizados. A unidade systemd abaixo restaura os dois após uma reinicialização, antes de BIRD e NGINX iniciarem.

Permita HTTPS para o IP da CDN e BGP na porta TCP 179 a partir do peer do seu provedor. Mantenha o acesso de administração no endereço unicast. Esta configuração de proxy reverso não precisa de encaminhamento de pacotes no Linux.

Salve esta unidade com seu IP real de serviço e seu prefixo. Ela adiciona uma interface dummy dedicada e preserva a configuração unicast existente no servidor.

Adicione a dependência aos dois serviços, inicie a unidade de endereço e verifique a rota até a origem. Ela deve usar a rede unicast, não anycast0.

Adicione a autenticação ou as configurações multihop exigidas pelo provedor antes de iniciar. O estado esperado é Established, ainda sem exportação do prefixo da CDN. Se a sessão continuar inativa, verifique o endereço do peer, o ASN, o firewall e a autenticação com seu provedor upstream.

Após a configuração NGINX abaixo passar em nginx -t, instale este hook de implantação e verifique o temporizador de renovação em cada nó de borda. Certificados independentes podem atender o mesmo nome de host; não precisam compartilhar uma chave privada. Conforme o conjunto de nós cresce, centralize a emissão e a distribuição segura para reduzir a exposição das credenciais DNS e coordenar as renovações.

Para uma origem NGINX, adicione estes blocos location ao servidor HTTPS existente de origin.example.com. Eles fornecem um recurso que pode ser colocado em cache e uma sonda sem cache, sem alterar a aplicação. Use o certificado válido da própria origem e confirme que seu log de acesso registra os dois caminhos.

O recurso de teste permanece válido em um cache compartilhado por 300 segundos devido a s-maxage. inactive=60m controla a remoção de objetos não utilizados, não sua validade. A chave separa nomes de host e strings de consulta. Requisições com cookies ou autorização ignoram o cache; o NGINX também respeita private, no-store, Set-Cookie e o tratamento de respostas Vary.

Cada PoP tem seu próprio cache em disco. Use URLs de recursos versionadas para as versões publicadas. Esta configuração não oferece uma API global de limpeza de cache nem força o fornecimento de conteúdo obsoleto quando a origem falha.

Após as verificações passarem, habilite cdn_prefix e peça ao provedor upstream que confirme a aceitação e a propagação do /24. Configure o registro A do nome de host para o IP da CDN. Use o modo somente DNS se seu provedor DNS também oferecer um proxy CDN. Teste o HTTPS a partir de uma rede externa antes de continuar.

Mantenha o DNS inalterado. Teste o nome de host público a partir de várias redes e inspecione X-Edge-Id. Para verificar um PoP específico, execute curl --resolve no próprio servidor; usar o IP Anycast do seu laptop não força a seleção de Paris ou Nova York.

A partir de uma rede externa que atualmente chega a Paris, continue abrindo novas conexões HTTPS. Pare o controlador de saúde antes de desabilitar a rota manualmente para que ele não a reative. Verifique se as requisições bem-sucedidas passam a identificar Nova York. Registre as falhas e o tempo decorrido; as conexões existentes podem precisar ser refeitas.

Com o controlador em execução e a rota anunciada, pare o NGINX em Paris. Confirme que o controlador retira cdn_prefix e que as requisições externas passam a chegar a Nova York. Inicie o NGINX novamente e verifique se o atraso de recuperação impede um novo anúncio imediato. Repita no outro nó de borda.

Reinicie um nó de borda enquanto o outro atende ao tráfego. Verifique se o endereço dummy, a sessão BIRD, o certificado, o cache e o controlador se recuperam na ordem correta. Meça o comportamento do nó restante com cache aquecido e vazio. Registre os resultados observados junto das versões de software e das redes usadas nas sondas; não presuma um tempo fixo de convergência BGP.

Em um serviço GeoDNS como o Route 53, crie registros A de geolocalização com o mesmo nome, cdn.example.com, e identificadores distintos. Configure Europe como EU_CDN_IP, North America como US_CDN_IP e Default como GLOBAL_CDN_IP. Esses valores são marcadores para seus endereços reais. Comece com um TTL de 60 segundos e meça o comportamento dos resolvedores.

Se você migrar o DNS autoritativo da Cloudflare para o Route 53, atualize também a emissão de certificados para usar o plugin DNS do Route 53, ou delegue deliberadamente a zona de desafio ACME. O plugin Cloudflare usado antes exige controle dos registros autoritativos de desafio.

Associe cada registro ao estado de saúde do seu pool. No Route 53, quando a correspondência geográfica não está saudável, a resolução pode recorrer a um registro geográfico mais amplo e depois ao registro padrão. Mantenha o pool global de fallback saudável e com capacidade para absorver o tráfego regional. Se os pools globais e regionais estiverem nos mesmos locais, configure e monitore seus prefixos separadamente; o controlador do exemplo gerencia um prefixo por instância.

Combine verificações de cada nó de borda por seus caminhos unicast com sondas externas do IP regional de serviço. Uma sonda para um IP Anycast pode continuar funcionando após a falha de um nó porque alcança outro. Remova um pool do DNS quando ele não puder atender o tráfego, não a cada falha de um de seus membros.

Primeiro retire um nó de borda: o IP regional deve continuar funcionando por outro nó do mesmo pool. Depois torne o pool inteiro indisponível em um teste controlado: novas respostas DNS devem selecionar o fallback. Teste consultas novas e clientes que ainda guardam a resposta antiga. Mudanças no DNS não transferem uma conexão existente nem substituem imediatamente todas as respostas em cache.

O GeoDNS estima a localização pelo resolvedor recursivo ou por uma indicação EDNS Client Subnet. Teste a partir de várias redes reais, incluindo resolvedores públicos. Não considere o registro padrão uma proteção garantida contra falhas: o Route 53 pode retornar registros não saudáveis quando todas as opções elegíveis falham nas verificações de saúde.

Você também pode combinar nós anunciados globalmente com nós cujas rotas o provedor upstream exporta apenas para redes selecionadas. Configure isso com as communities BGP documentadas desse provedor e verifique o escopo externamente. NO_EXPORT se refere a limites entre AS, não a continentes. Essa política de roteamento é separada da seleção de pools regionais pelo GeoDNS.

Se o provedor de hospedagem não puder estabelecer peering BGP, um provedor de trânsito pode anunciar seu prefixo e entregar o tráfego por túneis. Verifique o roteamento de retorno e a MTU e coloque um cache em cada local que recebe o tráfego. Direcionar todos os túneis a um único cache distante mantém esse cache e seus links no caminho de todas as requisições.

Você pode adicionar tráfego quando os dois PoPs atenderem HTTPS válido, cada um demonstrar MISS seguido de HIT, as respostas privadas permanecerem fora do cache e a retirada de qualquer rota levar as novas requisições ao local restante. Comece com recursos estáticos públicos e meça a carga na origem antes de adicionar outros caminhos que possam ser colocados em cache.