← Справочные архитектуры / reference-architecture / diagrams / network

Использование собственного IP-пространства в Cloudflare

Cloudflare обеспечивает безопасность и производительность цифровых сред наших клиентов. Однако одна из особенностей проксирующих сервисов заключается в том, что обращения в сети, направляемые в Cloudflare (например, DNS-запросы или запросы к SaaS-провайдерам), для остального мира выглядят так, будто они исходят из адресного пространства IP Cloudflare. Это может создавать сложности для некоторых организаций.

Например, партнёры или другие стороны в отношениях B2B могут использовать публичное адресное пространство клиента для подтверждения подлинности и атрибуции в различных транзакциях. Они могут смотреть на разрешённый адрес публичного хоста (например, www.example.com) и ожидать, что этот IP-адрес будет соответствовать определенному диапазону или адресу, известному как принадлежащий клиенту.

Использование собственного IP (BYOIP) позволяет предприятиям переносить своё IP пространство в Cloudflare, получая при этом преимущества безопасности и производительности платформы Cloudflare, но оставаясь видимыми для остального мира под собственным публичным IP пространством. Эта справочная архитектурная диаграмма показывает различные способы, которыми клиенты могут перенести своё IP пространство в сеть Cloudflare, и преимущества, которые при этом достигаются.

По умолчанию при DNS-запросе к проксируемому в Cloudflare хостнейму возвращается один из IP-адреса anycast по умолчанию ↗. Далее трафик ускоряется, защищается и, если ответ не отдается из кэша Cloudflare, передается на исходный сервер клиента.

На диаграмме ниже показано отклонение от поведения по умолчанию: трафик проксируется через платформу прикладных сервисов Cloudflare, но DNS запросы возвращают IP адрес, принадлежащий клиенту, при этом клиент всё равно пользуется преимуществами anycast сети Cloudflare.

В этом примере используются два разных диапазона сети:

• 152.3.15.0/24 - принадлежащий клиенту диапазон IP-адресов, который будет связан с сетью Cloudflare.
• 152.3.14.0/24 - принадлежащий клиенту диапазон IP-адресов, который останется связанным с его origin сетью.

1. Чтобы Cloudflare мог отвечать на DNS-запросы адресами из пространства клиента, клиент должен предоставить Cloudflare письмо-разрешение (Letter of Agency, LOA), чтобы эти адреса можно было выделить и анонсировать. Это адресное пространство (в примере, 152.3.15.0/24) должен использоваться исключительно для конфигурации Cloudflare и не применяться больше нигде в среде клиента.
2. Конфигурация DNS Cloudflare для сервера источника www.abc.com настроен с IP-адресом 152.3.14.10/32.
3. DNS-запрос для www.abc.com выполнен.
4. Cloudflare возвращает адрес из пространства клиента, ранее настроенного из диапазона BYOIP, предоставленного клиентом. В этом случае ответом был 152.2.15.200, являющийся частью /24 префикс 152.2.15.0/24.
5. Конечный пользователь (eyeball) отправляет запрос к 152.2.15.200 который направляется в Cloudflare.
6. Cloudflare проксирует соединение, используя SNI (www.abc.com) чтобы определить фактический IP-адрес источника, 152.3.14.10. Затем запрос направляется через прокси-сервисы Cloudflare, такие как защита от DDoS, Web Application Firewall и Bot Management.
7. Успешные запросы направляются на источник (если не обслужены из кэша) в 152.3.14.10 с исходным IP-адресом из сети Cloudflare.

Cloudflare хорошо известна сервисами защиты от DDoS-атак для публичных сайтов и API. Те же технологии можно применять и для защиты сетей целиком. Cloudflare Magic Transit предоставляет облачный сервис защиты сети от DDoS-атак для публичного IP-пространства наших клиентов.

1. Чтобы Cloudflare мог привлекать трафик, предназначенный для сетевых префиксов клиента, клиент должен предоставить Cloudflare письмо-разрешение (Letter of Agency, LOA), чтобы эти префиксы можно было выделить и анонсировать.
2. После настройки Cloudflare анонсирует префиксы клиента в интернет, привлекая трафик, предназначенный для этих сетей, в сеть Cloudflare.
3. Весь трафик, предназначенный для этих префиксов, направляется в Cloudflare.
4. Cloudflare снижает влияние DDoS-трафика, а легитимный трафик направляется обратно в сети клиентов через туннели, либо через Cloudflare Network Interconnect (CNI) для подключения к среде клиента.

Подробнее о возможностях Magic Transit см. в Эталонная архитектура Magic Transit.

• Защита гибридных облачных сетей с помощью Cloudflare Magic Transit
• Защита публичных сетей с помощью Cloudflare