BYOIP в Cloudflare: собствени IP префикси в мрежата на Cloudflare

Документиран процес в API проверява префикса спрямо IRR, RPKI и токен за собственост, след което го свързвате с услугите, които ще използват адресите му.

Какво приема Cloudflare

От документацията на Cloudflare, в деня на проверката:

• Кой. Enterprise акаунти, чийто договор включва BYOIP. Account екипът потвърждава това, както и конфигурацията на услугите в акаунта, преди въвеждането.
• Размер. /24 или по-голям за IPv4; за IPv6 – от /48 до /32.
• Регистър. ARIN, RIPE NCC, APNIC или някой от другите регионални регистри. Нищо за PA, PI или legacy адреси.
• Кой анонсира. AS13335 в документирания процес; за собствен ASN попитайте account екипа. Клиенти, които вече са на AS209242 на Cloudflare, могат да го запазят, но новите въвеждания използват AS13335.
• Къде. Всички локации на Cloudflare.
• Услуги. Magic Transit, Spectrum, CDN, както и Gateway DNS locations и dedicated egress IPs. Magic Transit има собствено въвеждане, „not a self-serve product“ (превод: „не е продукт на самообслужване“) и може да бъде само binding по подразбиране на целия префикс. Префикс обслужва входящия трафик на CDN или изходящия трафик на CDN, не и двете.
• Цена. Не е публикувана. Условията казват, че адресите трябва да се използват „solely in connection with the Customer's domains that are receiving Cloudflare's Enterprise Services“ (превод: „единствено във връзка с домейните на клиента, които получават Enterprise услугите на Cloudflare“).
• Срок. Поне пет часа предоставяне на BGP, преди да анонсирате, и от четири до шест часа за разпространението на всеки service binding. Конфигурацията на Magic Transit „takes around one day to roll out“ (превод: „отнема около един ден за въвеждане“).

Преди да започнете

Cloudflare не може да въведе префикс, ако някоя проверка на регистрацията, IRR, RPKI или собствеността се провали. Подгответе следното:

Route обект, който съвпада точно. По един обект route за всеки въвеждан префикс, точно за този префикс, с origin, който Cloudflare ще използва: AS13335 в стандартния процес. За проверка Cloudflare предлага IRR Explorer или whois -h rr.ntt.net 203.0.113.0/24.

Правилен ROA за същия origin. Cloudflare Ви моли да го проверите в своя RPKI Portal и във втори източник, например Routinator (RPKI и ROA).

Letter of agency (LOA), както Cloudflare нарича Letter of Authorization, което изискват транзитните му доставчици. Cloudflare го генерира вместо Вас, когато зададете delegate_loa_creation на true, като разчита на ROA и проверката на собствеността. Ръчно LOA трябва да е PDF и да е на фирмена бланка с ръкописен подпис, макар че Cloudflare приема и електронен подпис, ако е ясно кой е подписал. Транзитните доставчици може да отхвърлят JPG или PNG, а ръчната обработка може да забави въвеждането.

Място за токена за валидиране: описанието (descr) или remarks на съответния route обект, или TXT запис cf-validation във всяка reverse DNS зона на префикса.

Account ID и API токен с правата IP Prefixes.

Стъпка по стъпка

Това е документираният процес на Cloudflare за префикси, които не се използват с Magic Transit, който има собствено въвеждане чрез account екипа.

01Добавете префикса в акаунта, който ще го притежава:

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

Запазете id и ownership_validation_token от отговора.

02Публикувайте токена. Добавете cf-validation: <token> в route обекта или TXT записа в обратните зони.

03Валидирайте. Изпратете POST към .../prefixes/$PREFIX_ID/validate. Когато проверките на IRR, RPKI и собствеността минат, полето approved на префикса показва "V" и можете да премахнете токена. Ако проверка се провали, данните на префикса показват статуси като missing, invalid или mismatch_asn.

04Свържете префикса с услуга. Всеки префикс има нужда от service binding по подразбиране за целия префикс; по-специфични bindings могат да изпращат части от него към CDN или Spectrum. Cloudflare създава BGP префикса в оттеглено състояние. Предвидете поне пет часа и изчакайте, докато всеки binding стане активен.

05Анонсирайте:

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 казва, че анонсирането обикновено отнема от две до седем минути, а оттеглянето около 15.

06За CDN създайте address map, след като префиксът е анонсиран, така че проксираните DNS записи да отговарят с Вашите адреси.

Капани

• Покриващ route обект не стига. Cloudflare иска route обект, който съвпада точно с всеки въвеждан префикс, с правилния origin.
• Bindings отнемат часове, а междувременно трафикът страда. Cloudflare казва, че услугите за засегнатите адреси вероятно ще бъдат нарушени, докато binding се разпространява. Настройте bindings, преди да анонсирате, и ги променяйте извън натоварените часове.
• Две мрежи анонсират. Когато премествате активен префикс, оставете Cloudflare да анонсира първи, проверете го в looking glass под AS13335, след това оттеглете собственото си анонсиране. Ако оставите Вашето, част от трафика може да заобиколи Cloudflare.
• Правилото за 15 минути. След промяна на анонсирането на префикс изчакайте поне 15 минути, преди да го промените отново; API отказва по-ранни извиквания с грешка 1004 (HTTP 429, rate_limit_exceeded).

Ако наемате блока

Специфичните за услугата условия на Cloudflare, последно обновени на 28 септември 2026 г., уреждат това пряко. Ако не сте законният собственик на адресите, „must obtain written authorization from the legal owner“ (превод: „трябва да получите писмено упълномощаване от законния собственик“), за да може Cloudflare да ги анонсира, а ако собственикът го оттегли, Cloudflare може да спре да ги анонсира. Държателят поема и регистровата страна: ROA за AS13335, route обекта с AS13335 като origin и токена за валидиране в този обект, който може да редактира само maintainer на държателя. Условията изискват точни WHOIS данни и валидни записи в IRR и RPKI по всяко време, така че приключил наем или променен ROA може да свали префикса от Cloudflare.

Къде се вписва RTM Networks

Отдаваме под наем /24 и по-големи блокове от нашето собствено адресно пространство в RIPE NCC и продаваме блокове в регионите на RIPE NCC, ARIN и APNIC. За адреси, наети от нас, създаваме ROA и точния route обект за AS13335, добавяме в него токена за валидиране на Cloudflare и подписваме Letter of Authorization, така че за Вас остават стъпките в API (наем на IPv4). Ако BYOIP не е включен в договора Ви с Cloudflare или са Ви нужни по-малко от 256 адреса, анонсираме блок и го доставяме до сървъра Ви през GRE или WireGuard, до един адрес (GRE и WireGuard тунели). Други доставчици: ръководства за BYOIP.