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

Эталонная архитектура Magic Transit

Цель этого документа заключается в описании ключевой архитектуры, функциональности и вариантов сетевого развертывания Cloudflare Magic Transit: сервис защиты от DDoS-атак и ускорения трафика на основе BGP для сетевой инфраструктуры, обращенной к интернету.

Эта эталонная архитектура предназначена для ИТ- и сетевых специалистов, которые отвечают за существующую сетевую инфраструктуру организации или знакомы с ней. Полезно иметь опыт работы с технологиями и понятиями, важными для доставки контента: маршрутизаторами, DNS и межсетевыми экранами.

Чтобы лучше разобраться в Cloudflare, рекомендуем следующие материалы:

• Что такое Cloudflare? | Сайт ↗ (5 минут на чтение) или видео ↗ (2 минуты)

• Блог: Magic Transit делает вашу сеть умнее, лучше, надёжнее и дешевле в эксплуатации ↗ (14 минут на чтение)

Прочитав эту эталонную архитектуру, вы узнаете:

• Как Cloudflare Magic Transit защищает вашу сетевую инфраструктуру от атак типа «отказ в обслуживании» (DDoS)
• Как встроить Magic Transit в существующую сетевую инфраструктуру

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

Cloudflare Magic Transit обеспечивает защиту от DDoS-атак и ускорение трафика для локальных, облачных и гибридных сетей. Благодаря дата-центрам, охватывающим сотни городов ↗ и предлагая сотни Tbps мощности для смягчения атак, Magic Transit способен обнаруживать и смягчать атаки близко к их источнику в среднем менее чем за три секунды по всему миру, при этом трафик маршрутизируется быстрее, чем через публичный интернет.

На высоком уровне Magic Transit работает следующим образом:

• Подключение: Благодаря анонсам маршрутов по протоколу BGP (Border Gateway Protocol) в интернет и anycast сети Cloudflare, трафик клиента принимается в дата центре Cloudflare, ближайшем к источнику.

• Защита и обработка: Весь трафик клиентов проверяется на наличие атак. При обнаружении атаки немедленно применяются продвинутые автоматизированные методы противодействия. Также в виде сервиса доступны дополнительные функции, такие как балансировка нагрузки, межсетевой экран нового поколения, кеширование контента и бессерверные вычисления.

• Ускорение: Чистый трафик направляется по низколатентным сетевым каналам Cloudflare для оптимальной пропускной способности и передается в исходную сеть через IP-туннели (GRE или IPsec) либо через частные сетевые соединения (PNI). Magic Transit использует anycast IP-адреса для конечных точек туннелей Cloudflare, поэтому любой сервер в любом дата-центре может инкапсулировать и деинкапсулировать пакеты для одного и того же туннеля. Подробнее о туннелях и инкапсуляции см. в Туннели GRE и IPsec.

Magic Transit использует anycast IP-адреса для своих конечных точек сетевого туннеля, поэтому один туннель, настроенный от сети клиента к Cloudflare, подключается ко всем глобальным дата-центрам Cloudflare (за исключением China Network). Это не создает дополнительной нагрузки на маршрутизатор: с его точки зрения это единственный туннель к единственной IP-конечной точке.

Это работает потому, что хотя конечная точка туннеля технически привязана к IP-адресу, она не обязана быть привязана к конкретному устройству. Любое устройство, способное снять внешние заголовки и направить внутренний пакет дальше, может обработать любой пакет, отправленный через туннель.

При сбое сети или других неполадках туннели автоматически переключаются на резервный вариант, не влияя на производительность сети клиента.

По умолчанию Magic Transit обрабатывает трафик только во входящем направлении (из интернета в сеть клиента). Обратный трафик от сервера к клиентам маршрутизируется пограничным маршрутизатором дата-центра клиента через его аплинки в интернет (к провайдеру) на основании таблицы маршрутизации пограничного маршрутизатора по умолчанию. Этот обратный трафик сервера не проходит через Cloudflare по туннелям. Такой подход называется Direct Server Return (DSR).

Сетевая схема на рисунке 2 иллюстрирует такую настройку Magic Transit и сквозной путь пакетов трафика, защищённого Magic Transit. В этой настройке туннель использует GRE для инкапсуляции.

• Cloudflare предоставляет клиенту anycast-адрес IPv4 для стороны Cloudflare на конечных точках туннеля. Это публично маршрутизируемый IP-адрес из адресного пространства, принадлежащего Cloudflare. Сбои в своей сети Cloudflare обрабатывает автоматически, анонсируя IP-адрес конечной точки с нескольких узлов в разных глобально распределенных дата-центрах. Чтобы обрабатывать сбои в сети клиента, настройте два туннеля с отдельных маршрутизаторов. Чтобы запросить дополнительные anycast-адреса, клиенты могут обратиться в свою команду по работе с клиентами. В приведенной выше конфигурации показан один туннель, где адрес конечной точки со стороны Cloudflare: 192.0.2.1.

• Конец anycast GRE туннеля со стороны клиента должен иметь публично маршрутизируемый адрес. Обычно это IP-адрес WAN-интерфейса на пограничном маршрутизаторе клиента. В этом примере используется адрес 192.0.2.153.

• IP-адреса интерфейсов туннелей являются частными адресами RFC 1918. Эти адреса имеют значение только "локально", в пределах конкретного экземпляра сервиса Magic Transit, к которому они относятся. Поэтому клиент может выбрать любые адреса RFC 1918 по своему желанию, при условии что они не пересекаются с адресами других туннелей, настроенных в рамках того же экземпляра сервиса Magic Transit.

• В качестве рекомендуемой практики, поскольку туннели представляют собой соединения точка-точка, для выделения 2 IP-адресов, необходимых для одного туннеля, достаточно подсети /31. В приведённом выше примере выбрана подсеть 10.10.10.0/31: интерфейс туннеля на стороне Cloudflare получает адрес 10.10.10.0/31, а сторона пограничного маршрутизатора дата-центра клиента получает 10.10.10.1/31.

• После настройки туннеля в экземпляре сервиса Magic Transit настраивается маршрут, который направляет трафик, предназначенный для определенного префикса клиента, в нужный туннель.

• Трафик, предназначенный для клиентского префикса 203.0.113.0/24, направляется в туннель, удалённый конец интерфейса которого (то есть конец на стороне клиента, если смотреть со стороны сети Cloudflare) имеет адрес 10.10.10.1.

• Поскольку это конфигурация Direct Server Return (DSR), обратный трафик от сервера идет по маршруту по умолчанию (ip route 0/0), настроенному на пограничном маршрутизаторе клиента, и отправляется на аплинк, то есть на маршрутизатор интернет-провайдера клиента, возвращаясь к клиентам через интернет. Этот обратный трафик не проходит через сеть Cloudflare.

Примечание: Наименьший размер префикса IP (то есть с самой длинной маской подсети), который большинство интернет-провайдеров принимают во взаимных BGP анонсах, составляет /24; например, x.x.x.0/24 или y.y.y.0/23 допустимы, а z.z.z.0/25 нет. Поэтому наименьший размер префикса IP, который Cloudflare Magic Transit может анонсировать от имени клиентов, составляет /24.

Если Magic Transit развёрнут с включённой опцией Egress, исходящий трафик из сети клиента также проходит через сеть Cloudflare. Такой вариант развёртывания обеспечивает симметричность трафика: и запросы от клиента к серверу, и ответный трафик сервера проходят через сеть Cloudflare. Это повышает безопасность и надёжность ответного трафика сервера благодаря возможностям сети Cloudflare.

На следующей сетевой схеме показан сквозной путь пакетов между конечным клиентом и сетью клиента при включенной опции Magic Transit Egress.

• Поток входящего трафика такой же, как в описанном выше сценарии Default Configuration.

• Чтобы исходящий трафик принимался и обрабатывался Magic Transit, исходные IP-адреса трафика должны входить в диапазон IP-префиксов, защищённых Magic Transit, а адреса назначения должны быть маршрутизируемыми в публичном интернете, то есть не входить в диапазоны RFC 1918.

Обратите внимание, что для клиентов, которые используют собственные публичные IP-адреса (BYOIP) для облачных сервисов опция Magic Transit Egress дает дополнительную выгоду, поскольку избавляет от необходимости приобретать и внедрять BYOIP-услуги у облачных провайдеров, снижая счета за облако и операционные затраты.

Для этого IP-туннели, обеспечивающие выход трафика в Magic Transit, настраиваются между VPC облачных провайдеров и сетью Cloudflare. При использовании опции Magic Transit Egress трафик клиент-сервер в обоих направлениях проходит через эти туннели. Адреса BYOIP в туннелируемых пакетах скрыты за внешними IP-адресами конечных точек туннеля и заголовком туннеля, поэтому они остаются «невидимыми» для сетевых элементов облачного провайдера, лежащих между VPC и сетью Cloudflare.

Cloudflare Network Interconnect (CNI) позволяет клиентам подключать свою сетевую инфраструктуру напрямую к Cloudflare в обход публичного интернета, обеспечивая более надёжную, производительную и безопасную работу.

• CNI предоставляется провайдерами кросс-коннектов в виде набора соединений уровня 2, и Cloudflare выделяет пару IP-адресов из собственного маршрутизируемого в интернете блока IP-адресов Cloudflare для каждого соединения.

• При подключении CNI Cloudflare совместно с клиентом настраивает эти каналы и устанавливает по ним сеанс пиринга BGP.

• Как только сессия BGP между сетью Cloudflare и пограничным маршрутизатором клиента, соединенными через CNI, установлена, префиксы, принадлежащие Cloudflare, анонсируются по этому каналу CNI пограничному маршрутизатору клиента.

Рисунок 4 иллюстрирует типовую конфигурацию Magic Transit поверх CNI и связанный с ней путь пакетов.

Примечание: Пример, рассмотренный здесь, относится к сервису Magic Transit по умолчанию без включённой опции Egress. Как было описано в предыдущих разделах, в режиме Magic Transit Direct Server Return (то есть только Ingress) обратный трафик сервера направляется пограничным маршрутизатором клиента пользователям через их интернет-провайдера по публичному интернету.

Когда опция Egress в Magic Transit включена и используется, ответный трафик сервера может отправляться клиентам через сеть Cloudflare по IP-туннелям, настроенным поверх соединений CNI. Пример такой схемы показан на рисунке 5.

Magic Transit защищает сервисы, размещённые как локально, так и в облаке. Этот сценарий использования иллюстрирует настройку для облачного развёртывания.

• В этом примере у клиента есть два развёртывания VPC в облаке, у двух разных облачных провайдеров и в двух разных географических регионах.

• В этом примере префикс клиента /24 или больше разбивается на несколько более мелких префиксов (то есть с более длинной маской подсети, например /26) и назначается различным VPC в разных локациях. После установления туннелей от сети Cloudflare к каждому из VPC клиент может централизованно настроить маршруты в конфигурации Magic Transit, чтобы направлять трафик в соответствующие VPC. Такая настройка выполняется через API или через дашборд.

Обратите внимание, что с опцией Magic Transit Egress клиент может обойти сервисы BYOIP каждого облачного провайдера, связанные с ними расходы, а также сложность настройки и эксплуатации, отправляя исходящий трафик (то есть обратный трафик сервера или трафик от сервера в интернет из защищённого префикса) через глобальную сеть Cloudflare с помощью туннелей Magic Transit.

Помимо защиты и маршрутизации трафика внешних сервисов предприятия (то есть маршрутизируемого в интернете трафика «север-юг») с помощью сервиса Cloudflare Magic Transit, клиенты могут защищать внутренний трафик «восток-запад» между подразделениями предприятия (например, частные адреса по RFC 1918), объединяя все площадки предприятия с помощью Cloudflare WAN (ранее Magic WAN).

Cloudflare WAN заменяет устаревшие WAN-архитектуры сетью Cloudflare, обеспечивая глобальную связность, облачную безопасность, производительность и управление через единый простой интерфейс.

Сервисы Cloudflare Magic Transit и Cloudflare WAN в совокупности обеспечивают комплексное, безопасное, надежное и высокопроизводительное решение network-as-a-service глобального уровня для всего предприятия: они защищают и ускоряют как трафик north-south, так и трафик east-west.

Оба сервиса можно развернуть в рамках одного экземпляра, либо, если клиент предпочитает полностью разделить администрирование и трафик внешних сетей, обращённых в Интернет, и внутренних корпоративных сетей, для Magic Transit и Cloudflare WAN можно развернуть отдельные экземпляры сервисов.

Рисунок 7 иллюстрирует пример развёртывания сервисов Magic Transit и Cloudflare WAN в отдельных экземплярах сервиса.

Примечание: подписи на этом изображении могут отражать предыдущее название продукта.

• В этом примере для соединения различных площадок клиента через глобальную anycast сеть Cloudflare используются GRE туннели. Anycast IP адрес Cloudflare для экземпляра сервиса Magic Transit это 192.0.2.1, а для экземпляра сервиса Cloudflare WAN это 192.0.2.2. Сервис Magic Transit включён с параметром Egress.

• Сервис Magic Transit защищает и маршрутизирует внешний клиент-серверный трафик. Сервис Cloudflare WAN защищает и маршрутизирует внутренний трафик предприятия, например трафик внутренних приложений, синхронизации баз данных на backend, а также трафик между филиалами и центром обработки данных и между самими филиалами.

Хотя Magic Transit защищает сервисы клиентов от DDoS-атак, многим сетевым администраторам также нужна возможность контролировать и блокировать другой нежелательный или потенциально вредоносный трафик. Cloudflare Network Firewall обеспечивает единые политики сетевой безопасности во всей WAN-сети клиента, включая головной офис, филиалы и виртуальные частные облака, и позволяет за секунды развернуть точечные правила фильтрации по всему миру, причём всё это из единой панели управления.

Cloudflare Network Firewall развёртывается и настраивается в составе Magic Transit. Весь входящий трафик, проходящий через периферийные дата-центры Cloudflare и предназначенный для префиксов, защищённых Magic Transit, можно фильтровать средствами Cloudflare Network Firewall.

Примечание: подписи на этом изображении могут отражать предыдущее название продукта.

В правилах Cloudflare Network Firewall администраторы могут сопоставлять и фильтровать сетевой трафик не только по типичному набору из 5 параметров (IP-адрес и порт источника и назначения, протокол), содержащемуся в заголовке IP-пакета, но и по другим параметрам пакета, таким как длина IP-пакета, длина заголовка IP, TTL и так далее. Кроме того, при настройке правил Network Firewall можно использовать географическую информацию, например название дата-центра Cloudflare, регион и страну, где он расположен (геоблокировка).

Дополнительные сведения о Cloudflare Network Firewall и его настройке см. в Знакомство с Magic Firewall ↗ и документация Cloudflare Network Firewall.

Поставщик облачной защиты от DDoS может отслеживать угрозы в трафике постоянно (модель развёртывания always-on) или перенаправлять трафик только при обнаружении атаки (модель on-demand). Этот выбор влияет на время реакции и время до устранения атаки. В некоторых случаях он также сказывается на задержке.

В модели развёртывания по требованию входящий трафик отслеживается и измеряется на периметре сети для обнаружения объёмных атак. В обычном режиме, или «мирное время», весь трафик напрямую достигает приложений и инфраструктуры без задержек и перенаправлений. Трафик перенаправляется к облачному провайдеру очистки только при активной DDoS-атаке. Во многих случаях клиенту требуется самостоятельно звонить поставщику услуг для перенаправления трафика, что увеличивает время реакции.

Режим always-on представляет собой подход к защите от DDoS, не требующий от клиента никаких действий во время атаки. Трафик организации всегда проходит проверку на угрозы через дата-центры облачного провайдера, даже в мирное время. Это сокращает время от обнаружения атаки до её отражения, и работа сервиса не прерывается.

Из всех подходов и вариантов развертывания наиболее полную защиту обеспечивает режим always-on, при котором защита работает постоянно.

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

Это связано с тем, что приём трафика через anycast гарантирует его доставку для проверки только в ближайший дата-центр Cloudflare. При наличии дата-центров в сотни городов по всему миру ↗, то расстояние, скорее всего, будет небольшим. Это устраняет эффект тромбона.

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

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

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

• Magic Transit включает встроенный сетевой файрвол, который помогает клиентам постепенно отказаться от локальных файрволов и перейти на масштабируемую сетевую безопасность по модели «как услуга».

• Помимо защиты и маршрутизации трафика внешних сервисов предприятия (то есть маршрутизируемого в интернете трафика «север-юг»), клиенты могут подключать и защищать внутренний трафик «восток-запад» между подразделениями предприятия с помощью Cloudflare WAN.

Если вы хотите узнать больше о Magic Transit, Cloudflare WAN или Cloudflare Network Firewall, свяжитесь с нами, чтобы получить демонстрацию ↗.