BYOIP la Cloudflare: propriile prefixe IP în rețeaua Cloudflare

Un flux API documentat verifică prefixul față de IRR, RPKI și un token de proprietate, iar apoi îl legați de serviciile care îi vor folosi adresele.

Ce acceptă Cloudflare

Din documentația Cloudflare, în ziua în care am verificat:

• Cine. Conturile Enterprise al căror contract include BYOIP. Account team-ul confirmă asta, precum și configurația de servicii a contului, înainte de preluare.
• Mărime. Un /24 sau mai mare pentru IPv4; pentru IPv6, de la /48 până la /32.
• Registru. ARIN, RIPE NCC, APNIC sau unul dintre celelalte registre regionale. Nimic despre spațiul PA, PI sau legacy.
• Cine este originea. AS13335 în fluxul documentat; pentru propriul ASN, întrebați account team-ul. Clienții aflați deja pe AS209242 al Cloudflare îl pot păstra, dar preluările noi folosesc AS13335.
• Unde. Toate locațiile Cloudflare.
• Servicii. Magic Transit, Spectrum, CDN și Gateway DNS locations și dedicated egress IPs. Magic Transit are propria preluare, este „not a self-serve product” (traducere: „nu este un produs self-service”) și poate fi doar binding-ul implicit al unui prefix întreg. Un prefix servește fie CDN ingress, fie CDN egress, nu amândouă.
• Preț. Nepublicat. Termenii spun că adresele trebuie folosite „solely in connection with the Customer's domains that are receiving Cloudflare's Enterprise Services” (traducere: „exclusiv în legătură cu domeniile Clientului care primesc Enterprise Services de la Cloudflare”).
• Termen. Cel puțin cinci ore de configurare BGP înainte să anunțați și patru până la șase ore pentru propagarea fiecărui service binding. Configurația Magic Transit „takes around one day to roll out” (traducere: „are nevoie de circa o zi ca să fie aplicată”).

Înainte să începeți

Cloudflare nu poate prelua un prefix dacă pică vreo verificare de înregistrare, IRR, RPKI sau proprietate. Pregătiți următoarele:

Un obiect route care se potrivește exact. Un obiect route per prefix preluat, exact pentru acel prefix, cu originea pe care o va folosi Cloudflare: AS13335 în fluxul standard. Pentru verificare, Cloudflare sugerează IRR Explorer sau whois -h rr.ntt.net 203.0.113.0/24.

Un ROA corect pentru aceeași origine. Cloudflare vă cere să îl verificați în RPKI Portal-ul său și într-o a doua sursă, cum ar fi Routinator (RPKI și ROA).

O letter of agency (LOA), numele pe care Cloudflare îl dă Letter of Authorization, cerută de furnizorii săi de tranzit. Cloudflare o generează pentru dvs. când setați delegate_loa_creation la true, ceea ce se bazează pe ROA și pe verificarea proprietății. O LOA manuală trebuie să fie un PDF și ar trebui să fie pe hârtie cu antetul companiei, cu semnătură olografă, deși Cloudflare acceptă o semnătură digitală dacă este clar cine a semnat. Furnizorii de tranzit pot respinge un JPG sau PNG, iar procesarea manuală poate încetini preluarea.

Un loc pentru tokenul de validare: descrierea (descr) sau remarks ale obiectului route corespunzător ori o înregistrare TXT cf-validation în fiecare zonă DNS inversă a prefixului.

Un account ID și un API token cu permisiunile IP Prefixes.

Pas cu pas

Acesta este fluxul documentat de Cloudflare pentru prefixele care nu sunt folosite cu Magic Transit, care are propria preluare prin account team.

01Adăugați prefixul în contul care îl va deține:

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}'

Salvați id și ownership_validation_token din răspuns.

02Publicați tokenul. Adăugați cf-validation: <token> în obiectul route sau înregistrarea TXT în zonele inverse.

03Validați. Trimiteți un POST la .../prefixes/$PREFIX_ID/validate. Când verificările IRR, RPKI și de proprietate trec, câmpul approved al prefixului arată "V" și puteți șterge tokenul. Dacă pică o verificare, detaliile prefixului arată stări precum missing, invalid sau mismatch_asn.

04Legați prefixul de un serviciu. Fiecare prefix are nevoie de un service binding implicit pe tot prefixul; binding-uri mai specifice pot trimite părți din el către CDN sau Spectrum. Cloudflare creează prefixul BGP în stare retrasă. Lăsați cel puțin cinci ore și așteptați până când fiecare binding este activ.

05Anunțați:

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}}'

Cloudflare spune că anunțarea durează de obicei două până la șapte minute, iar retragerea circa 15.

06Pentru CDN, creați un address map după ce prefixul este anunțat, ca înregistrările DNS proxied să răspundă cu adresele dvs.

Capcane

• Un obiect route care acoperă prefixul nu este suficient. Cloudflare vrea un obiect route care se potrivește exact cu fiecare prefix preluat, cu originea corectă.
• Binding-urile durează ore, iar între timp traficul suferă. Cloudflare spune că serviciile pentru adresele în cauză sunt probabil perturbate cât timp un binding se propagă. Configurați binding-urile înainte să anunțați și modificați-le în afara orelor aglomerate.
• Două rețele care anunță. Când mutați un prefix activ, lăsați Cloudflare să anunțe întâi, verificați-l într-un looking glass sub AS13335, apoi retrageți propriul anunț. Dacă îl lăsați pe al dvs., o parte din trafic poate ocoli Cloudflare.
• Regula celor 15 minute. După modificarea anunțului unui prefix, așteptați cel puțin 15 minute înainte să îl modificați din nou; API-ul refuză apelurile mai timpurii cu eroarea 1004 (HTTP 429, rate_limit_exceeded).

Dacă închiriați blocul

Termenii specifici de serviciu ai Cloudflare, actualizați ultima dată pe 28 septembrie 2026, tratează direct acest caz. Dacă nu sunteți proprietarul legal al adreselor, „must obtain written authorization from the legal owner” (traducere: „trebuie să obțineți autorizarea scrisă a proprietarului legal”) ca Cloudflare să le anunțe, iar dacă proprietarul o retrage, Cloudflare poate înceta să le anunțe. Deținătorul face și partea de registru: ROA-ul pentru AS13335, obiectul route cu AS13335 ca origine și tokenul de validare în acel obiect, pe care doar maintainerul deținătorului îl poate edita. Termenii cer date WHOIS exacte și intrări IRR și RPKI valide în orice moment, așa că o închiriere care se încheie sau un ROA care se schimbă poate scoate prefixul de pe Cloudflare.

Unde se încadrează RTM Networks

Închiriem /24 și mai mari din propriul spațiu de adrese RIPE NCC și vindem blocuri în regiunile RIPE NCC, ARIN și APNIC. Pentru spațiul închiriat de la noi, creăm ROA-ul și obiectul route exact pentru AS13335, adăugăm în el tokenul de validare Cloudflare și semnăm Letter of Authorization, așa că vă rămân doar pașii API (închiriere IPv4). Dacă BYOIP nu este în contractul dvs. Cloudflare sau aveți nevoie de mai puțin de 256 de adrese, anunțăm un bloc și îl livrăm la serverul dvs. prin GRE sau WireGuard, până la o singură adresă (tuneluri GRE și WireGuard). Alți furnizori: ghiduri BYOIP.