Ваши IP-адреса в облаке Cloudflare: полный контроль и гибкость

Когда клиент хочет подключить пространство IP-адресов к Cloudflare, ему всегда приходилось обращаться к своей команде по работе с клиентами, чтобы подать запрос. Этот запрос затем направлялся в различные инженерные команды Cloudflare, такие как команды по работе с адресацией и сетевой инженерии, а затем — в команду, ответственную за конкретный сервис, который клиент хотел использовать с префиксом (например, CDN, Magic Transit, Spectrum, Egress). Кроме того, им приходилось взаимодействовать со своими собственными юридическими отделами и, возможно, с другой организацией, если у них не было основного права собственности на IP-префикс, чтобы получить Доверенность (LOA), проходя через множество согласований. Этот процесс сложен, выполняется вручную и отнимает много времени у всех вовлеченных сторон — иногда он занимает до 4–6 недель в зависимости от различных согласований.

Что ж, больше нет! Сегодня мы рады объявить о запуске нашего самообслуживаемого BYOIP API, который позволяет нашим клиентам самостоятельно подключать и настраивать свои BYOIP-префиксы.

С самообслуживанием мы берем на себя всю бюрократию. Мы автоматизировали этот процесс, используя золотой стандарт безопасности маршрутизации — Инфраструктуру открытых ключей ресурсов (RPKI). При этом мы продолжаем обеспечивать наилучшее качество обслуживания, генерируя LOA от имени наших клиентов на основе гарантий безопасности нашего нового процесса проверки права собственности. Это гарантирует, что клиентские маршруты продолжают приниматься в каждом уголке Интернета.

Cloudflare очень серьезно относится к безопасности и стабильности всего Интернета. RPKI — это криптографически стойкий механизм авторизации, и мы считаем, что он значительно надежнее общепринятой практики, которая полагается на ручную проверку отсканированных документов. Однако развертывание и доступность некоторых подписанных RPKI артефактов, таких как объект авторизации пути AS (ASPA), все еще ограничены, и по этой причине мы ограничиваем первоначальную область самостоятельного подключения BYOIP-префиксами, исходящими из номера автономной системы (ASN) Cloudflare AS 13335. Делая это, нам нужно полагаться только на публикацию объектов авторизации источника маршрута (ROA), которые широко доступны. Этот подход имеет преимущество в виде безопасности для Интернета и одновременно удовлетворяет потребности большинства наших BYOIP-клиентов.

Сегодня мы делаем крупный шаг вперед в предложении клиентам более комплексной платформы управления IP-адресами (IPAM). С недавним обновлением, позволяющим использовать несколько сервисов на одном BYOIP-префиксе, и этим последним достижением, позволяющим самостоятельное подключение через наш API, мы надеемся, что клиенты почувствуют себя empowered, чтобы взять под контроль свои IP-адреса в нашей сети.

Мы хотим, чтобы Cloudflare ощущался как расширение вашей инфраструктуры, поэтому мы первоначально запустили Bring-Your-Own-IP (BYOIP) еще в 2020 году.

Краткое напоминание: Bring-your-own-IP назван именно так, что он делает — он позволяет клиентам подключать собственное пространство IP-адресов к Cloudflare. Клиенты выбирают BYOIP по ряду причин, но основные из них — это контроль и настраиваемость. IP-префикс — это диапазон или блок IP-адресов. Маршрутизаторы создают таблицу достижимых префиксов, известную как таблица маршрутизации, чтобы обеспечить правильную доставку пакетов по Интернету. Когда сервисы Cloudflare клиента настроены на использование собственных адресов клиента, подключенных к Cloudflare как BYOIP, пакет с соответствующим адресом назначения будет маршрутизироваться через Интернет к глобальной edge-сети Cloudflare, где он будет принят и обработан. BYOIP можно использовать с нашими сервисами 7-го уровня, Spectrum или Magic Transit.

Давайте сделаем шаг назад и посмотрим на текущее состояние мира BYOIP. Допустим, клиент имеет право управления диапазоном IP-адресов и хочет подключить их к Cloudflare. Мы требуем от клиентов предоставить нам Доверенность (LOA) и иметь запись в Реестре маршрутизации Интернета (IRR), соответствующую их префиксу и ASN. Как только мы это получим, требуется ручная проверка инженером Cloudflare. У этого процесса есть несколько проблем:

• Небезопасно: LOA — это всего лишь документ, лист бумаги. Безопасность этого метода полностью зависит от добросовестности инженера, проверяющего документ. Если проверка не способна обнаружить, что документ является поддельным или неточным, возможен захват префикса или ASN.

• Отнимает много времени: Создание одной LOA не всегда достаточно. Если вы арендуете IP-пространство, мы попросим вас также предоставить документацию, подтверждающую эти отношения, чтобы мы могли увидеть четкую цепочку авторизации от первоначального назначения или выделения адресов вам. Получение всех бумажных документов для проверки этой цепочки владения в сочетании с необходимостью ждать ручной проверки может привести к неделям ожидания перед развертыванием префикса!

Переход на модель самообслуживания позволил нам переосмыслить способ проведения проверок права собственности на префиксы. Мы спросили себя: Как мы можем быстро, безопасно и автоматически доказать, что вы уполномочены использовать ваш IP-префикс и намерены маршрутизировать его через Cloudflare?

В итоге мы убили двух зайцев одним выстрелом благодаря нашему двухэтапному процессу, включающему создание RPKI ROA (проверка намерения) и модификацию записей IRR или rDNS (проверка права собственности). Самообслуживание открывает возможность не только быстрее подключать префиксы без вмешательства человека, но и проводить более строгие проверки права собственности, чем когда-либо мог бы позволить простой отсканированный документ. Хотя это не на 100% защищено от ошибок, это значительное улучшение в способе проверки права собственности.

Региональные интернет-регистраторы (RIR) — это организации, ответственные за распределение и управление интернет-числовыми ресурсами, такими как IP-адреса. Они состоят из 5 различных entities, работающих в разных регионах мира (RIRs). Первоначально получив выделенное адресное пространство от Администрации адресного пространства Интернета (IANA), они, в свою очередь, назначают и выделяют это IP-пространство локальным интернет-регистраторам (LIR), таким как интернет-провайдеры.

Этот процесс основан на политиках RIR, которые обычно учитывают такие вещи, как юридическая документация, существующие записи в базах данных/реестрах, технические контакты и информация BGP. Конечные пользователи могут получать адреса от LIR или, в некоторых случаях, напрямую через RIR. Поскольку адреса IPv4 стали более дефицитными, были запущены брокерские услуги, позволяющие арендовать адреса на фиксированные периоды у их первоначальных правообладателей.

Реестр маршрутизации Интернета (IRR) — это отдельная система, ориентированная на маршрутизацию, а не на назначение адресов. Многие организации управляют экземплярами IRR и позволяют публиковать информацию о маршрутизации, включая все пять RIR. Хотя большинство экземпляров IRR накладывают мало препятствий для публикации данных маршрутизации, те, которые управляются RIR, способны связать возможность публикации информации о маршрутизации с организациями, которым были назначены соответствующие адреса. Мы считаем, что возможность изменить запись IRR, защищенную таким образом, является хорошим сигналом того, что пользователь имеет права на использование префикса.

Пример объекта маршрута, содержащего токен проверки (используется адрес только для документации 192.0.2.0/24):

% whois -h rr.arin.net 192.0.2.0/24

route:          192.0.2.0/24
origin:         AS13335
descr:          Example Company, Inc.
                cf-validation: 9477b6c3-4344-4ceb-85c4-6463e7d2453f
admin-c:        ADMIN2521-ARIN
tech-c:         ADMIN2521-ARIN
tech-c:         CLOUD146-ARIN
mnt-by:         MNT-CLOUD14
created:        2025-07-29T10:52:27Z
last-modified:  2025-07-29T10:52:27Z
source:         ARIN

Для тех, кто не хочет проходить процесс проверки на основе IRR, обратный DNS (rDNS) предоставляется как еще один безопасный метод проверки. Чтобы управлять rDNS для префикса — будь то создание PTR-записи или TXT-записи безопасности — вам должно быть предоставлено разрешение от entity, которая изначально выделила блок IP (обычно ваш интернет-провайдер или RIR).

Это разрешение демонстрируется одним из двух способов:

• Напрямую через аутентифицированный клиентский портал владельца IP (ISP/RIR).

• Путем делегирования владельцем IP прав вашему стороннему DNS-провайдеру через NS-запись для вашей обратной зоны.

Пример поиска обратного домена с помощью команды dig (используется адрес только для документации 192.0.2.0/24):

% dig cf-validation.2.0.192.in-addr.arpa TXT

; <<>> DiG 9.10.6 <<>> cf-validation.2.0.192.in-addr.arpa TXT
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16686
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;cf-validation.2.0.192.in-addr.arpa. IN TXT

;; ANSWER SECTION:
cf-validation.2.0.192.in-addr.arpa. 300 IN TXT "b2f8af96-d32d-4c46-a886-f97d925d7977"

;; Query time: 35 msec
;; SERVER: 127.0.2.2#53(127.0.2.2)
;; WHEN: Fri Oct 24 10:43:52 EDT 2025
;; MSG SIZE  rcvd: 150

Итак, как именно нужно изменять эти записи? Вот здесь и появляется токен проверки. Как только вы выбираете метод IRR или обратного DNS, мы предоставляем уникальный одноразовый токен проверки. Вы должны добавить этот токен в содержимое соответствующей записи, либо в IRR, либо в DNS. Наша система затем ищет наличие токена как доказательство того, что запрос делается кем-то, у кого есть право вносить запрашиваемые изменения. Если токен найден, проверка завершена и ваше владение подтверждено!

Владение — это только половина дела; нам также нужно подтвердить ваше намерение, что вы разрешаете Cloudflare анонсировать ваш префикс. Для этого мы полагаемся на золотой стандарт безопасности маршрутизации: инфраструктуру закрытых ключей ресурсов (RPKI), и в частности на объекты авторизации источника маршрута (ROA).

ROA — это криптографически подписанный документ, который определяет, какой номер автономной системы (ASN) уполномочен объявлять ваш IP-префикс. Вы можете думать о ROA как о цифровом эквиваленте заверенного, подписанного и нотариально удостоверенного договора от владельца префикса.

Заинтересованные стороны могут проверять подписи в ROA с помощью RPKI. Вы просто создаете ROA, который указывает ASN Cloudflare (AS13335) как авторизованного источника, и организуете его подписание. Многие наши клиенты использовали для этого размещенные системы RPKI, доступные через порталы RIR. Когда наши системы обнаруживают эту подписанную авторизацию, ваше намерение маршрутизации мгновенно подтверждается.

Многие другие компании, поддерживающие BYOIP, требуют сложного рабочего процесса, включающего создание самоподписанных сертификатов и ручное изменение записей RDAP (протокол доступа к регистрационным данным) — серьезная административная нагрузка. Предоставляя выбор между модификацией объектов IRR и записями обратного DNS TXT в сочетании с RPKI, мы предлагаем процесс проверки, который гораздо более привычен и прост для существующих сетевых операторов.

Хотя новый самостоятельный процесс устраняет необходимость в "реликвии динозавров", которой является LOA, многие сетевые операторы по всему миру все еще полагаются на нее как часть процесса принятия префиксов от других сетей.

Чтобы помочь обеспечить принятие вашего префикса смежными сетями по всему миру, Cloudflare автоматически генерирует документ от вашего имени для распространения вместо LOA. Этот документ предоставляет информацию о проверках, которые мы провели, чтобы подтвердить, что мы уполномочены объявлять клиентский префикс, и подтверждает наличие действительных ROA для авторизации нашего объявления его. Таким образом, мы можем поддерживать рабочие процессы сетевых операторов, к которым мы подключаемся и которые полагаются на LOA, без того, чтобы наши клиенты несли бремя их создания.

Одна из проблем при проектировании Self-Serve API — это компромисс между предоставлением клиентам гибкости и внедрением необходимых защитных мер, чтобы IP-префикс никогда не анонсировался без соответствующей привязки к сервису. Если бы это произошло, Cloudflare объявлял бы префикс, не имея представления о том, что делать с трафиком, когда мы его получаем! Мы называем это "черной дырой" для трафика. Чтобы справиться с этим, мы ввели требование привязки к сервису по умолчанию — то есть привязки сервиса, которая охватывает весь диапазон подключенного IP-префикса.

Клиент может позже наложить различные привязки к сервисам поверх своей привязки по умолчанию через множественные привязки сервисов, например, разместив CDN поверх привязки сервиса Spectrum по умолчанию. Таким образом, префикс никогда не может быть объявлен без привязки к сервису и создать черную дыру для трафика наших клиентов.

Ознакомьтесь с нашей документацией для разработчиков по самой актуальной документации о том, как подключить, объявить и добавить сервисы к вашим IP-префиксам через наш API. Помните, что подключения могут быть сложными, и не стесняйтесь задавать вопросы или обращаться к нашей команде профессиональных услуг, если вы хотите, чтобы мы сделали это за вас.

Возможность скриптовать и интегрировать управление BYOIP в существующие рабочие процессы меняет правила игры для современных сетевых операций, и мы только начинаем. В ближайшие месяцы ожидайте самостоятельный BYOIP в панели управления, а также самостоятельное отключение BYOIP, чтобы дать клиентам еще больше контроля.