← Справочные архитектуры / reference-architecture / diagrams / network
Защита гибридных облачных сетей с помощью Cloudflare Magic Transit
Введение
Защита сетевой инфраструктуры от DDoS-атак требует уникального сочетания мощности и скорости. Объёмные атаки легко перегружают локальные аппаратные устройства защиты от DDoS и их каналы связи с ограниченной пропускной способностью.
Облачное решение для защиты от DDoS более гибкое, эффективное и масштабируемое, однако большинству решений на рынке не хватает глобального охвата сети и плотности центров очистки трафика, необходимых для поддержания хорошей производительности. Решениям защиты от DDoS с такими недостатками приходится перенаправлять трафик клиентов через немногочисленные центры очистки, часто расположенные за тысячи миль от точки, где трафик изначально попал в сеть, что добавляет значительную задержку и неизбежно снижает общую производительность и пропускную способность сети.
Cloudflare Magic Transit обеспечивает встроенную облачную защиту от DDoS-атак и ускорение трафика для всех ваших сетей, обращённых к интернету и обслуживающих входящий пользовательский трафик, независимо от места развёртывания: локально, в облаке или в комбинации того и другого (то есть в гибридной архитектуре). Благодаря дата-центрам в сотнях городов и суммарной мощности защиты от DDoS в сотни Тбит/с, Magic Transit способен обнаруживать и подавлять атаки вблизи источника их возникновения менее чем за 3 секунды в любой точке мира.
Подробности о том, как работает Magic Transit и как его можно использовать в различных сценариях, приведены в связанных материалах в конце документа: Cloudflare Magic Transit и Эталонная архитектура Magic Transit.
В этом документе на примере нескольких распространённых сценариев рассматриваются эталонные архитектуры применения Magic Transit для защиты гибридной облачной сетевой инфраструктуры.
Сценарий 1. Клиент использует BYOIP как для локальных, так и для облачных развертываний сети
В этом сценарии нужно защитить с помощью Magic Transit несколько сетевых префиксов /24 или больше. Эти сети развёрнуты как в локальных площадках, так и в регионах нескольких облачных провайдеров.
В качестве иллюстрации ниже приведён пример списка расположений сетей, обращённых в интернет, и соответствующих им IP-префиксов.
AWS VPC: 192.0.2.0/24
GCP VPC: 198.51.100.0/24
Azure vNet: 203.0.113.0/26
On-premise data center 1: 203.0.113.64/26
On-premise data center 2: 203.0.113.128/25
Примечание: подписи на этом изображении могут отражать предыдущее название продукта.
- Используя Border Gateway Protocol (BGP ↗), Cloudflare анонсирует защищенные префиксы IP-адресов клиента в интернете из всех глобальных дата-центров Cloudflare, что позволяет IP Anycast ↗, чтобы интернет-трафик, предназначенный для этих защищённых префиксов IP, всегда направлялся в дата-центр Cloudflare, ближайший к источнику трафика.
При этом локальные сети и сети облачных провайдеров перестают анонсировать те же самые префиксы со своих локальных и облачных пограничных маршрутизаторов. Это гарантирует, что весь интернет-трафик, предназначенный для IP-префиксов, защищённых Magic Transit, будет направляться через сеть Cloudflare.
Вместо этого можно анонсировать в интернет менее специфичные префиксы IP со своих пограничных маршрутизаторов. Тогда, если сервис Magic Transit когда-либо столкнется со сбоем, что маловероятно, трафик можно будет быстро перенаправить напрямую к точкам сети из интернета.
- Трафик, поступающий из интернета и предназначенный для защищённых IP-префиксов, принимается сетью Cloudflare по всему миру.
- Весь трафик очищается, то есть трафик DDoS-атак удаляется и нейтрализуется на месте в каждом дата-центре Cloudflare с помощью передовых и автоматизированных Подавление DDoS-атак технологий.
- Трафик, прошедший защиту от DDoS, подвергается дополнительной фильтрации на сетевом межсетевом экране с помощью встроенного Cloudflare Network Firewall сервис.
- Очищенный, отфильтрованный трафик направляется в защищённые сети либо через частные соединения, называемые Cloudflare Network Interconnect (CNI) либо через публичный интернет с помощью стандартных IP туннелей, таких как GRE или IPsec. Более подробную информацию об IP туннелях Magic Transit можно найти в документация Magic Transit Tunnels and Encapsulation.
- Обратный трафик сервера от защищённых префиксов IP к пользователям интернета маршрутизируется напрямую через интернет из мест размещения гибридного облака, минуя сеть Cloudflare. Это называется direct server return (DSR). Обратите внимание, что для использования DSR у вас должен быть BYOIP у вашего облачного провайдера.
Поскольку сервис Magic Transit представляет собой единое консолидированное облачное решение для защиты сети, работающее глобально в сети Cloudflare, ваши глобальные гибридные облачные сети, обращённые в интернет, надёжно защищены от DDoS-атак и других вредоносных атак независимо от того, где и в какой среде они развёрнуты.
Еще одно преимущество таких консолидированных, изначально облачных решений для защиты сети заключается в том, что сети, обращенные в интернет, можно легко переносить между разными гибридными облачными средами, не теряя при этом их защиту. Для этого достаточно изменить маршруты в конфигурации Magic Transit, чтобы направить трафик на новое местоположение.
Сценарий 2. Клиент арендует IP-адрес у Cloudflare как для локальных, так и для облачных развертываний сети
Если у вас нет собственных сетевых префиксов размером /24 или больше, но вы всё равно хотите использовать Magic Transit для защиты своих сетей, вы можете аренда IP-адресов от Cloudflare для назначения этим более мелким сетям. На следующей диаграмме показана архитектура такого развёртывания. Как и в предыдущем сценарии, эти клиентские сети развёрнуты как в локальной инфраструктуре, так и в регионах нескольких облачных провайдеров.
В качестве иллюстрации ниже приведён пример списка расположений сетей, обращённых в интернет, и соответствующих им IP-префиксов.
AWS VPC: 192.0.2.0/28
GCP VPC: 192.0.2.16/28
Azure vNet: 192.0.2.32/28
On-premise data center 1: 192.0.2.48/28
On-premise data center 2: 192.0.2.64/28
Примечание: подписи на этом изображении могут отражать предыдущее название продукта.
- Используя Border Gateway Protocol (BGP), Cloudflare анонсирует в интернете принадлежащие ей IP-префиксы, включая IP-адреса, которые вы арендуете.
[Шаги со 2 по 5 совпадают с шагами сценария 1, описанного выше]
- Обратный трафик сервера, у которого в качестве исходных IP адресов используются арендованные IP адреса Cloudflare, не может маршрутизироваться в интернет напрямую через граничные маршрутизаторы разных площадок. Этот трафик необходимо маршрутизировать обратно через сеть Cloudflare для выхода в интернет с помощью Magic Transit Egress функциональность. Его можно отправлять в сеть Cloudflare через те же CNI или IP-туннели, через которые проходил входящий (Ingress) трафик, используя такие методы маршрутизации, как policy-based routing (PBR) на ваших площадках.
- Исходящий трафик Magic Transit Egress проходит фильтрацию Network Firewall, прежде чем попасть в интернет к пользователям.
Сценарий 3. Клиент использует BYOIP для локальных сетей и арендует IP-адрес у Cloudflare для облачных развертываний сети
В этом сценарии можно развернуть более крупные локальные сети и более мелкие облачные сети. Локальным сетям вы назначаете собственные префиксы /24, а для облачных сетей арендуете IP адреса у Cloudflare.
В качестве иллюстрации ниже приведён пример списка расположений сетей, обращённых в интернет, и соответствующих им IP-префиксов.
AWS VPC: 192.0.2.0/28
GCP VPC: 192.0.2.16/28
Azure vNet: 192.0.2.32/28
On-premise data center 1: 198.51.100.0/24
On-premise data center 2: 203.0.113.0/24
Примечание: подписи на этом изображении могут отражать предыдущее название продукта.
- Используя Border Gateway Protocol (BGP), Cloudflare анонсирует в интернете как IP-префиксы клиента, так и собственные IP-префиксы Cloudflare.
[Шаги со 2 по 5 совпадают с шагами сценария 1, описанного выше]
- Обратный трафик сервера из ваших облачных сетей маршрутизируется обратно через сеть Cloudflare для выхода в интернет с помощью функции Magic Transit Egress. Его можно отправлять в сеть Cloudflare через те же CNI или IP туннели, через которые проходил входящий трафик, используя такие методы маршрутизации, как policy-based routing (PBR), на ваших физических площадках.
- Этот исходящий трафик Magic Transit Egress проходит фильтрацию Network Firewall перед маршрутизацией в интернет к пользователям.
- Обратный трафик сервера от локальных сетей к пользователям интернета передаётся напрямую (DSR), минуя сеть Cloudflare.
Примечание: Кроме того, клиенты могут направлять обратный трафик серверов локальных сетей через Cloudflare с помощью policy-based routing и функции Magic Transit Egress. Это добавляет дополнительный уровень безопасности и контроля для исходящего трафика за счет фильтрации Network Firewall. Например, так можно блокировать трафик к сомнительным IP-адресам и сайтам, запрещенным направлениям или странам.