BYOIP na Cloudflare: os seus próprios prefixos IP na rede da Cloudflare

Um fluxo de API documentado verifica o prefixo face ao IRR, ao RPKI e a um token de propriedade, e depois o cliente associa-o aos serviços que vão usar os seus endereços.

O que a Cloudflare aceita

Segundo a documentação da Cloudflare, no dia em que a consultámos:

• Quem. Contas Enterprise cujo contrato inclua BYOIP. A equipa de conta confirma isto, e a configuração de serviços da conta, antes da integração.
• Tamanho. Um /24 ou maior para IPv4; para IPv6, de um /48 a um /32.
• Registo. ARIN, RIPE NCC, APNIC ou um dos outros registos regionais. Nada sobre espaço PA, PI ou legacy.
• Quem origina. AS13335 no fluxo documentado; para o seu próprio ASN, pergunte à equipa de conta. Os clientes que já estão no AS209242 da Cloudflare podem mantê-lo, mas as novas integrações usam AS13335.
• Onde. Todos os locais da Cloudflare.
• Serviços. Magic Transit, Spectrum, a CDN, e as DNS locations e dedicated egress IPs do Gateway. O Magic Transit tem a sua própria integração, "not a self-serve product" (tradução: «não é um produto self-service»), e só pode ser o binding predefinido de um prefixo inteiro. Um prefixo serve a entrada da CDN ou a saída da CDN, não ambas.
• Preço. Não publicado. As condições dizem que os endereços têm de ser usados "solely in connection with the Customer's domains that are receiving Cloudflare's Enterprise Services" (tradução: «exclusivamente em ligação com os domínios do Cliente que recebem os Enterprise Services da Cloudflare»).
• Prazo. Pelo menos cinco horas de aprovisionamento BGP antes de anunciar, e quatro a seis horas para a propagação de cada service binding. A configuração do Magic Transit "takes around one day to roll out" (tradução: «demora cerca de um dia a ser implementada»).

Antes de começar

A Cloudflare não pode integrar um prefixo se falhar alguma verificação de registo, IRR, RPKI ou propriedade. Prepare isto:

Um objeto route que corresponda exatamente. Um objeto route por cada prefixo que integra, para exatamente esse prefixo, com a origem que a Cloudflare vai usar: AS13335 no fluxo padrão. Para o verificar, a Cloudflare sugere o IRR Explorer ou whois -h rr.ntt.net 203.0.113.0/24.

Um ROA correto para a mesma origem. A Cloudflare pede-lhe que o verifique no seu RPKI Portal e numa segunda fonte, como o Routinator (RPKI e ROA).

Uma letter of agency (LOA), o nome que a Cloudflare dá à Letter of Authorization, que os seus fornecedores de trânsito exigem. A Cloudflare gera-a por si quando define delegate_loa_creation como true, o que assenta no ROA e na verificação de propriedade. Uma LOA manual tem de ser um PDF, e deve estar em papel timbrado da empresa com assinatura manuscrita, embora a Cloudflare aceite uma assinatura digital se for claro quem assinou. Os fornecedores de trânsito podem rejeitar um JPG ou PNG, e o tratamento manual pode atrasar a integração.

Um sítio para o token de validação: a descrição (descr) ou os remarks do objeto route correspondente, ou um registo TXT cf-validation em cada zona de DNS inverso do prefixo.

Um ID de conta e um token de API com as permissões de IP Prefixes.

Passo a passo

Este é o fluxo documentado da Cloudflare para prefixos não usados com o Magic Transit, que tem a sua própria integração através da equipa de conta.

01Acrescente o prefixo à conta que o vai deter:

curl "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/addressing/prefixes" \
  --request POST --header "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \
  --json '{"cidr":"203.0.113.0/24","asn":13335,"delegate_loa_creation":true}'

Guarde o id e o ownership_validation_token da resposta.

02Publique o token. Acrescente cf-validation: <token> ao objeto route, ou o registo TXT às zonas inversas.

03Valide. Envie um POST para .../prefixes/$PREFIX_ID/validate. Quando as verificações de IRR, RPKI e propriedade passam, o campo approved do prefixo indica "V", e pode retirar o token. Se uma verificação falhar, os detalhes do prefixo mostram estados como missing, invalid ou mismatch_asn.

04Associe o prefixo a um serviço. Cada prefixo precisa de um service binding predefinido sobre o prefixo inteiro; bindings mais específicos podem enviar partes dele para a CDN ou o Spectrum. A Cloudflare cria o prefixo BGP em estado retirado. Conte com pelo menos cinco horas, e aguarde até todos os bindings estarem ativos.

05Anuncie:

curl "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/addressing/prefixes/$PREFIX_ID/bgp/prefixes/$BGP_PREFIX_ID" \
  --request PATCH --header "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \
  --json '{"on_demand":{"advertised":true}}'

A Cloudflare diz que o anúncio demora normalmente dois a sete minutos, e a retirada cerca de 15.

06Para a CDN, crie um address map depois de o prefixo ser anunciado, para que os registos DNS em proxy respondam com os seus endereços.

Armadilhas

• Um objeto route abrangente não chega. A Cloudflare quer um objeto route que corresponda exatamente a cada prefixo que integra, com a origem certa.
• Os bindings demoram horas, e o tráfego sofre entretanto. A Cloudflare diz que os serviços para os endereços em causa ficam provavelmente perturbados enquanto um binding se propaga. Configure os bindings antes de anunciar, e altere-os fora das horas de maior movimento.
• Duas redes a anunciar. Quando muda um prefixo ativo, deixe a Cloudflare anunciar primeiro, verifique-o num looking glass sob AS13335 e depois retire o seu próprio anúncio. Se deixar o seu ativo, algum tráfego pode contornar a Cloudflare.
• A regra dos 15 minutos. Depois de alterar o anúncio de um prefixo, aguarde pelo menos 15 minutos antes de o voltar a alterar; a API recusa com o erro 1004 (HTTP 429, rate_limit_exceeded) as chamadas feitas antes desse prazo.

Se alugar o bloco

As condições específicas do serviço da Cloudflare, atualizadas pela última vez a 28 de setembro de 2026, tratam disto diretamente. Se não for o proprietário legal dos endereços, "must obtain written authorization from the legal owner" (tradução: «tem de obter autorização escrita do proprietário legal») para que a Cloudflare os anuncie, e se o proprietário a retirar, a Cloudflare pode deixar de os anunciar. O titular trata também do lado do registo: o ROA para AS13335, o objeto route com AS13335 como origem, e o token de validação nesse objeto, que só o maintainer do titular pode editar. As condições pedem dados WHOIS exatos e entradas IRR e RPKI válidas em todos os momentos, pelo que um aluguer que termina ou um ROA que muda pode tirar o prefixo da Cloudflare.

Onde entra a RTM Networks

Alugamos /24 e maiores a partir do nosso próprio espaço de endereçamento do RIPE NCC, e vendemos blocos nas regiões RIPE NCC, ARIN e APNIC. No espaço que lhe alugamos, criamos o ROA e o objeto route exato para AS13335, acrescentamos-lhe o token de validação da Cloudflare e assinamos a Letter of Authorization, pelo que os passos da API são o que lhe resta (alugar IPv4). Se o BYOIP não estiver no seu contrato Cloudflare, ou se precisar de menos de 256 endereços, anunciamos um bloco e entregamo-lo ao seu servidor por GRE ou WireGuard, até um único endereço (túneis GRE e WireGuard). Outros fornecedores: guias BYOIP.