BYOIP у Cloudflare: ваші власні IP-префікси в мережі Cloudflare

Задокументований процес через API перевіряє префікс за IRR, RPKI і токеном власності, а потім ви прив’язуєте його до послуг, що використовуватимуть його адреси.

Що приймає Cloudflare

З документації Cloudflare, у день нашої перевірки:

• Хто. Облікові записи Enterprise, контракт яких передбачає BYOIP. Команда облікового запису підтверджує це, а також конфігурацію послуг облікового запису, до підключення.
• Розмір. /24 або більший блок для IPv4; для IPv6 – від /48 до /32.
• Реєстр. ARIN, RIPE NCC, APNIC або один з інших регіональних реєстрів. Нічого про простір PA, PI чи legacy.
• Хто анонсує. AS13335 у задокументованому процесі; щодо власного ASN запитайте команду облікового запису. Клієнти, які вже працюють на AS209242 від Cloudflare, можуть його зберегти, але нові підключення використовують AS13335.
• Де. Усі локації Cloudflare.
• Послуги. Magic Transit, Spectrum, CDN, а також Gateway DNS locations і dedicated egress IPs. Magic Transit має власне підключення, є «not a self-serve product» (переклад: «не продуктом самообслуговування») і може бути лише прив’язкою за замовчуванням для цілого префікса. Префікс обслуговує вхідний або вихідний трафік CDN, не обидва.
• Ціна. Не публікується. Умови кажуть, що адреси можна використовувати «solely in connection with the Customer's domains that are receiving Cloudflare's Enterprise Services» (переклад: «виключно у зв’язку з доменами Клієнта, які отримують Enterprise Services від Cloudflare»).
• Терміни. Щонайменше п’ять годин надання BGP до анонсу і від чотирьох до шести годин на поширення кожної прив’язки послуги. Конфігурація 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 називає лист авторизації, якого вимагають його транзитні провайдери. Cloudflare генерує його для вас, коли ви встановлюєте delegate_loa_creation на true, що спирається на ROA і перевірку власності. LOA, створений вручну, має бути у форматі PDF і бажано на фірмовому бланку з власноручним підписом, хоча Cloudflare приймає цифровий підпис, якщо зрозуміло, хто підписав. Транзитні провайдери можуть відхилити JPG чи PNG, а ручна обробка може сповільнити підключення.

Місце для токена перевірки: опис (descr) або remarks відповідного об’єкта route чи запис TXT cf-validation у кожній зоні зворотного DNS префікса.

ID облікового запису і токен API з дозволами IP Prefixes.

Крок за кроком

Це задокументований процес Cloudflare для префіксів, що не використовуються з Magic Transit, який має власне підключення через команду облікового запису.

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Прив’яжіть префікс до послуги. Кожен префікс потребує прив’язки послуги за замовчуванням для всього префікса; специфічніші прив’язки можуть спрямовувати його частини до CDN чи Spectrum. Cloudflare створює префікс BGP у відкликаному стані. Дайте щонайменше п’ять годин і дочекайтеся, поки кожна прив’язка стане активною.

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.
• Прив’язки займають години, і тим часом трафік страждає. Cloudflare каже, що послуги для відповідних адрес, імовірно, порушуються, поки прив’язка поширюється. Налаштуйте прив’язки до анонсу і змінюйте їх поза годинами пік.
• Дві мережі анонсують. Коли ви переносите робочий префікс, дайте 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 і підписуємо лист авторизації, тож вам залишаються кроки в API (оренда IPv4). Якщо BYOIP немає у вашому контракті з Cloudflare або вам потрібно менше ніж 256 адрес, ми анонсуємо блок і доставляємо його до вашого сервера через GRE або WireGuard, аж до однієї адреси (GRE- і WireGuard-тунелі). Інші провайдери: посібники BYOIP.