← Cloudflare Magic Transit / magic-transit / reference

Управление трафиком

Когда трафик поступает в сеть Cloudflare, ему нужно достичь нужного пункта назначения в вашей инфраструктуре: конкретного дата-центра, офиса или облачной среды. Управление трафиком определяет, как Cloudflare принимает эти решения по маршрутизации.

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

• Доставка Magic Transit для Отказ в обслуживании (DoS) и Cloudflare Network Firewall отфильтрованный интернет-трафик от дата-центра входа, где трафик поступил в сеть, до вашей публично адресуемой граничной сети (edge/border network).
• Передача пакетов Magic Transit между туннелями IPsec/GRE, интерконнектами, Cloudflare Load Balancer, а также Zero Trust подключения, такие как Cloudflare One Client, Remote Browser Isolation, Доступ, а также Gateway.

Magic Transit Virtual Network поддерживает маршрутизацию трафика Magic Transit через anycast-туннели с использованием GRE и Internet Protocol Security (IPsec) или CNI с Dataplane v2. Вы можете добавлять записи в таблицу маршрутизации Magic Transit Virtual Network через настройку статических маршрутов или через маршруты, полученные благодаря BGP-пирингу (бета).

В таблице маршрутизации Magic Transit Virtual Network разрешены следующие диапазоны адресов IPv4:

• BYOIP публичное адресное пространство, подключённое к Cloudflare Magic Transit.
• Cloudflare арендованные IP-адреса назначенный вашему аккаунту.

Если трафик не соответствует ни одному маршруту, настроенному в виртуальной сети, Cloudflare применяет поведение по умолчанию в зависимости от типа адреса назначения:

• Публичные (доступные из интернета) адреса: Трафик выходит в интернет.
• Частные адреса (RFC 1918 ↗ или CGNAT/RFC 6598 ↗): трафик отбрасывается (null routing), так как приватные адреса не маршрутизируются в публичном интернете, а у Cloudflare нет пути для их доставки без подходящего маршрута.

Magic Transit направляет трафик по маршрутам туннелей на основе приоритетов записей маршрутов.

• Чем меньше значение, тем выше приоритет.
• Если значения приоритета для записей префикса совпадают, Cloudflare использует многопутевая маршрутизация с равной стоимостью (ECMP) переадресацию пакетов для маршрутизации трафика. Вы можете применить необязательное весовое значение к статическим маршрутам, чтобы изменить распределение туннелей ECMP.
• Маршрутизация Cloudflare применяет правило longest prefix match. Более специфичный статический маршрут (например, /30) всегда имеет приоритет над менее специфичным (например, /29), независимо от приоритета туннеля, если вы не удалите более специфичный маршрут.
• Когда у маршрутов BGP и статических маршрутов совпадают префикс и приоритет, Cloudflare соблюдает приоритет, отдавая предпочтение статическим маршрутам перед маршрутами BGP. Это гарантирует, что вручную настроенные статические маршруты сохраняют приоритет, если вы явно не понизите его для них.

Значение приоритета для статических маршрутов настраивается непосредственно как часть объекта маршрута в Cloudflare панели управления или через API. Например:

В этом примере туннели с приоритетом 100 имеют приоритет перед туннелями с приоритетом 200 так как меньшие значения имеют более высокий приоритет.

При необходимости можно назначить веса, чтобы эффективнее распределять трафик между несколькими туннелями. Значения веса определяют долю трафика: чем выше вес, тем больше трафика получает туннель. Максимальное значение веса составляет 256.

В следующем примере TUNNEL_2_IAD скорее всего, получит вдвое больше трафика, чем TUNNEL_1_IAD.

Помимо приоритета, привязка статических маршрутов к определённым географическим регионам также влияет на то, как направляется трафик. См. Ограничение маршрутов конкретными регионами для дополнительных сведений.

Когда BGP анонсирует маршрут, Cloudflare автоматически добавляет его в таблицу маршрутизации Magic Transit Virtual Network с приоритетом по умолчанию, равным 100 который применяется к все регионы. Однако если существует статический маршрут с тем же префиксом и приоритетом, статический маршрут всегда имеет приоритет над маршрутом BGP. Задайте другой приоритет для статических маршрутов (больше или меньше, чем 100) в зависимости от того, чему вы хотите отдать приоритет. Чем меньше значение, тем выше приоритет.

Кроме того, если существует несколько маршрутов BGP с одинаковой длиной префикса и приоритетом, ECMP распределяет трафик между ними, используя маршрутизация с равной стоимостью по нескольким путям (ECMP).

Cloudflare поддерживает traffic engineering с помощью BGP community и AS prepending. С помощью этих методов маршрутизации можно задавать приоритеты маршрутов и выполнять traffic engineering сразу через несколько интерконнектов.

Приоритет маршрута BGP по умолчанию равен 100. Этот базовый приоритет можно скорректировать с помощью community. Например, если маршрут помечен community 13335:60010 его приоритет установлен на 10. Это делает его приоритет выше значения по умолчанию, равного 100 так как более низким числовым значениям приоритета отдаётся предпочтение.

Для настройки базового приоритета маршрута поддерживаются следующие значения community:

• 13335:60010: Задайте базовый приоритет маршрута равным 10
• 13335:60050: Задайте базовый приоритет маршрута равным 50
• UNSET: Задайте базовый приоритет маршрута равным 100
• 13335:60150: Задайте базовый приоритет маршрута равным 150
• 13335:60200: Задайте базовый приоритет маршрута равным 200
• 13335:60901: Задайте базовый приоритет маршрута равным 501000
• 13335:60902: Задайте базовый приоритет маршрута равным 1001000

Указание нескольких community с базовым приоритетом в одном сообщении об обновлении префикса является ошибкой конфигурации. В этом случае Cloudflare отдаёт предпочтение наивысшему приоритету (наименьшему целочисленному значению).

За каждое дополнительное упоминание вашего ASN в полученном AS-пути Cloudflare добавляет 10 к базовому приоритету маршрута. При увеличении номера приоритета маршрут становится менее предпочтительным.

Например, если ваш ASN 65000 то BGP UPDATE к Cloudflare будет:

# No change to base priority.
AS_PATH: 65000 65200

# Add 10 to base priority for 1 prepend of 65000
AS_PATH: 65000 65000 65200

# Add 20 to base priority for 2 prepend of 65000
AS_PATH: 65000 65000 65000 65200

Cloudflare корректирует приоритет маршрута при использовании AS prepending с сообществами (communities). Например, если маршрут помечен 13335:60150, базовый приоритет устанавливается равным 150. Если вы дважды применяете prepend к своему ASN, Cloudflare добавляет 10 для каждого prepend, увеличивая приоритет маршрута до 180.

Режим Unified Routing представляет собой более новую плоскость данных Cloudflare One, которая использует единую инфраструктуру маршрутизации для всех поддерживаемых типов подключений. В режиме Unified Routing трафик направляется через Cloudflare One Client, Cloudflare Tunnel, IPsec, GRE и Cloudflare Network Interconnect (CNI) в рамках единой системы, что упрощает настройку подключений Cloudflare One.

В дашборде Magic Transit режим маршрутизации отображается там же, где вы управляете маршрутами:

• Режим маршрутизации: Unified : ваш аккаунт работает на едином уровне данных и поддерживает новые функции маршрутизации.
• Режим маршрутизации: Legacy : ваш аккаунт использует предыдущий уровень данных и не поддерживает все функции единой маршрутизации.

Unified Routing представляет собой будущее выделенной overlay-сети, которая обеспечивает работу Magic Transit и сетевого подключения Cloudflare One.

Для клиентов Magic Transit главная причина обратить внимание на Unified Routing заключается в оценке BGP для туннелей IPsec/GRE, что зависит от Unified Routing.

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

Unified Routing сейчас доступен в режиме closed beta. Чтобы зарегистрироваться:

• Существующие клиенты Cloudflare WAN или Magic Transit: Cloudflare рекомендует оценить новую функциональность применительно к вашему сценарию использования в непроизводственном аккаунте. Обратитесь в свою команду по работе с аккаунтом, чтобы включить Unified Routing.
• Новые клиенты: Обратитесь в свою команду по работе с аккаунтом, чтобы включить Unified Routing в рамках proof-of-concept для вашего сценария использования.

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

Если вы ограничиваете область действия маршрута определённым регионом дата-центров Cloudflare, он отображается в таблице маршрутизации Magic Transit Virtual Network только в этом регионе, наряду со всеми глобальными маршрутами без региональной привязки. Логика приоритизации маршрутов и ECMP применяется как к маршрутам с региональной привязкой, так и к глобальным.

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

В следующей таблице приведён пример использования географической привязки для маршрутов:

Если для одного и того же префикса существует несколько маршрутов с одинаковым приоритетом и эти маршруты закреплены за разными географическими регионами (например, WNAM и ENAM), трафик, поступающий в сеть в конкретном регионе (например, в WNAM), выходит через маршрут, закреплённый за этим же регионом.

У Cloudflare девять географических регионов:

Настройте область действия для своего трафика в Код региона раздел при добавлении или изменении статического маршрута. См. Создать статический маршрут и Измените статический маршрут, где это описано подробнее.

Чтобы Cloudflare могла направлять ваш трафик из нашей глобальной сети в ваши дата-центры через anycast-туннели, укажите свои префиксы и туннели, с которыми они должны быть связаны. Используйте таблицу ниже в качестве образца.

Минимальный анонсируемый префикс составляет /24, однако, поскольку Cloudflare использует anycast-туннели как внешнюю обертку для вашего трафика, Cloudflare может маршрутизировать префиксы в пределах этого /24 на разные конечные точки туннеля. Например, вы можете отправлять x.x.x.0/29 в дата-центр 1 и x.x.x.8/29 в дата-центр 2. Это полезно, если вы работаете в среде с ограниченными IP-ресурсами.

Если подключено несколько /24 подсетей, входящих в более крупный непрерывный блок, можно настроить сводный статический маршрут для соответствующей суперсети (например, /23 или /22) вместо того чтобы добавлять каждый /24 по отдельности. Это устраняет необходимость настраивать каждый /24 маршрут, поскольку весь трафик будет направляться через одни и те же GRE-туннели.

Например, если у вас есть два туннеля:

• 192.0.2.0/24
• 192.0.3.0/24

Их можно объединить в единое 192.0.2.0/23.

См. Добавить туннели чтобы узнать больше о настройке туннелей GRE.

Equal-cost multi-path routing использует хеши, рассчитанные на основе пакет ↗ данные для определения выбранного маршрута. Хеш всегда использует IP-адреса источника и назначения. Для пакетов TCP и UDP хеш также включает порты источника и назначения. Алгоритм ECMP делит хеш каждого пакета на количество равнозначных следующих переходов. Модуль (остаток от деления) определяет маршрут, по которому пойдет пакет.

Использование ECMP имеет ряд последствий:

• Маршрутизация по путям с одинаковой стоимостью выполняется по вероятностному принципу.
• Пакеты одной сессии с одинаковыми источником и назначением имеют одинаковый хеш. Такие пакеты также используют один и тот же следующий переход.
• Изменение числа равнозначных next hop может привести к тому, что трафик пойдёт через другие туннели. Например, к этому же может привести динамическая смена приоритетов, вызванная событиями проверки работоспособности.

Благодаря этому ECMP обеспечивает балансировку нагрузки между туннелями с одинаковым префиксом и приоритетом.

Эта диаграмма показывает, как ECMP равномерно распределяет трафик между двумя маршрутами с одинаковым префиксом и приоритетом.

flowchart LR
accTitle: Tunnels diagram
accDescr: This example has three tunnel routes, with traffic equally distributed across two paths.

subgraph Cloudflare
direction LR
B[Cloudflare <br> data center]
C[Cloudflare <br> data center]
D[Cloudflare <br> data center]
end

Z("Load balancing for some <br> priority tunnels uses ECMP <br> (hashing on src IP, dst IP, <br> scr port, dst port)") --- Cloudflare
A((User)) --> Cloudflare --- E[Anycast IP]
E[Anycast IP] --> F[/"GRE Tunnel 1 / <br> priority 1 / <br> ~50% of flows"/] --> I{{Customer <br> data center/ <br> network 1}}
E[Anycast IP] --> G[/"GRE Tunnel 2 / <br> priority 1 / <br> ~50% of flows"/] --> J{{Customer <br> data center/ <br> network 2}}
E[Anycast IP] --> H[/GRE Tunnel 3 / <br> priority 2 / <br> 0% of flows/] --o K{{Customer <br> data center/ <br> network 3}}

Отказ маршрутизатора клиента

Если проверки состояния Magic Transit определяют, что Tunnel 2 неработоспособен, Magic Transit динамически понижает приоритет этого маршрута, и единственным маршрутом с наивысшим приоритетом остаётся Tunnel 1. В результате Magic Transit перенаправляет трафик с Tunnel 2, и весь трафик идёт через Tunnel 1.

flowchart LR
accTitle: Tunnels diagram
accDescr: This example has Tunnel 2 unhealthy, and all traffic prioritized to Tunnel 1.

subgraph Cloudflare
direction LR
B[Cloudflare <br> data center]
C[Cloudflare <br> data center]
D[Cloudflare <br> data center]
end

Z(Tunnel health is <br> determined by <br> health checks that <br> run from all Cloudflare <br> data centers) --- Cloudflare
A((User)) --> Cloudflare --- E[Anycast IP]
E[Anycast IP] --> F[/"Tunnel 1 / <br> priority 1 / <br> ~100% of flows"/]:::green --> I{{Customer <br> data center/ <br> network 1}}
E[Anycast IP] --> G[/Tunnel 2 / <br> priority 3 / <br> unhealthy / 0% of flows/]:::red --x J{{Customer <br> data center/ <br> network 2}}
E[Anycast IP] --> H[/Tunnel 3 / <br> priority 2 / <br> 0% of flows/] --o K{{Customer <br> data center/ <br> network 3}}
classDef red fill:#EE4B2B,color: black
classDef green fill:#00FF00,color: black

Сбой промежуточного интернет-провайдера (ISP)

Если Magic Transit определяет, что Tunnel 1 тоже неработоспособен, приоритет этого маршрута также понижается, и наивысший приоритет остаётся у Tunnel 3. В этом случае весь трафик направляется через Tunnel 3.

flowchart LR
accTitle: Tunnels diagram
accDescr: This example has Tunnel 1 and 2 unhealthy, and all traffic prioritized to Tunnel 3.

subgraph Cloudflare
direction LR
B[Cloudflare <br> data center]
C[Cloudflare <br> data center]
D[Cloudflare <br> data center]
end

Z(Lower-priority tunnels <br> are used when <br> higher-priority tunnels <br> are unhealthy) --- Cloudflare
A((User)) --> Cloudflare --- E[Anycast IP]
E[Anycast IP]  -- Intermediary <br> network issue -->  F[/Tunnel 1 / <br> priority 3 / <br> unhealthy / 0% of flows/]:::red --x I{{Customer <br> data center/ <br> network 1}}
E[Anycast IP]  -- Intermediary <br> network issue -->  G[/Tunnel 2 / <br> priority 3 / <br> unhealthy / 0% of flows/]:::red --x J{{Customer <br> data center/ <br> network 2}}
E[Anycast IP] -->  H[/Tunnel 3 / <br> priority 2 / <br> 100% of flows/]:::green --> K{{Customer <br> data center/ <br> network 3}}
classDef red fill:#EE4B2B,color: black
classDef green fill:#00FF00,color: black

Когда Magic Transit определяет, что Tunnel 1 и Tunnel 2 снова работоспособны, он повышает приоритет этих маршрутов, и трафик возвращается в обычный режим.

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

Например, рассмотрим сценарий с множеством TCP-соединений с очень низкой пропускной способностью и одним TCP-соединением с очень высокой пропускной способностью. Пакеты соединения с высокой пропускной способностью имеют одинаковый хеш и поэтому используют один и тот же туннель. В результате этот туннель задействует больше пропускной способности, чем остальные.

Использование пиринга BGP с таблицей маршрутизации Virtual Network в Cloudflare One или Magic Transit позволяет:

• Автоматизируйте процесс добавления и удаления сетей и подсетей.
• Используйте функции обнаружения сбоев и восстановления сессии.

С помощью этой функции вы можете:

• Установите сеанс eBGP между своими устройствами и сервисом Magic Transit при подключении через туннели CNI, GRE или IPsec.
• Защитите сессию с помощью аутентификации MD5, чтобы избежать ошибок конфигурации.
• Динамически обменивайтесь маршрутами между своими устройствами и таблицей маршрутизации Magic Transit Virtual Network.

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

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

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

• Время сходимости: Глобальная конвергенция маршрутов обычно завершается в течение 20 секунд.
• Видимость: вы можете отслеживать изученные маршруты и статус их распространения через панель управления Cloudflare или API.

Magic Transit Virtual Network использует централизованную control plane для распространения маршрутов, что аналогично работе BGP Route Reflector. Такая архитектура отделяет физическую BGP-сессию от глобального распространения маршрутов:

• Завершение сессии: Сессии пиринга BGP завершаются на периферийном узле Cloudflare, ближайшем к вашему маршрутизатору.
• Преобразование SDN: Входящие обновления BGP преобразуются в состояние программно-определяемой сети (SDN) и передаются централизованной функции ретрансляции.
• Глобальное распространение: Relay распространяет эти инструкции на все дата-центры Cloudflare по всему миру, обновляя локальную базу пересылки (FIB) на каждой площадке.

Data plane Cloudflare спроектирован с расчетом на высокую доступность. Если edge-локация теряет связь с централизованным relay, система переходит в Edge Resiliency Mode, имитируя поведение Non-Stop Forwarding (NSF):

• Непрерывность пересылки: Периферийные узлы продолжают маршрутизировать трафик, используя последнюю работоспособную таблицу пересылки (FIB). Трафик плоскости данных не прерывается.
• Удержание устаревших маршрутов: Так как в этом режиме FIB заморожена, решения о пересылке трафика остаются активными, даже если базовая сессия BGP с вашим маршрутизатором становится нестабильной или сбрасывается.
• Непрерывный мониторинг работоспособности: пока обновления BGP заморожены, проверки работоспособности туннеля продолжают выполняться. Они отправляются из всех дата-центров Cloudflare, поэтому периферия в любом входном узле может обнаружить обрыв физического соединения с вашим маршрутизатором. Если проверка работоспособности не проходит, входной узел на периферии снижает приоритет этого конкретного пути, чтобы трафик не терялся в никуда, несмотря на замороженное состояние маршрутизации.
• Заморозка обновлений: В этом состоянии глобальная плоскость управления заморожена. Новые обновления BGP, получаемые от вашего маршрутизатора, будут сохраняться локально на периферии и не будут распространяться глобально, пока не восстановится соединение с централизованным ретранслятором.
• Анонсирование Magic Transit на edge-сети: В этом замороженном состоянии ваши префиксы BYOIP продолжат анонсироваться на глобальной edge-сети Cloudflare. Вы можете вручную изменить статус анонсирования через API или Dashboard.

Как только соединение между периферией Cloudflare и централизованным ретранслятором восстанавливается, система автоматически выходит из режима Edge Resiliency и выполняет пересинхронизацию с отслеживанием состояния:

1. Синхронизация RIB-to-relay: Периферия Cloudflare передаёт на relay все текущие удерживаемые обновления BGP (текущее состояние RIB).
2. Глобальное обновление: Relay согласует эти обновления и распространяет любые изменения на остальную часть глобальной сети Cloudflare.
3. FIB unfreeze: Локальные таблицы пересылки на периферии Cloudflare размораживаются и обновляются последними проверенными инструкциями маршрутизации.

BGP-пиринг Magic Transit выполняется с таблицей маршрутизации Magic Transit Virtual Network (а не с глобальной интернет-сетью Cloudflare). BGP-пиры, настроенные согласно этому руководству, будут получать анонсы всех префиксов из таблицы маршрутизации Magic Transit Virtual Network, а также любых дополнительных префиксов, настроенных в on-ramp Список анонсируемых префиксов.

Если вместо этого вы хотите настроить публичный пиринг с Cloudflare ASN 13335 в одном из дата-центров Cloudflare, см. Настройка PNI и пиринга. На данный момент невозможно использовать BGP-пиринг Magic Transit Virtual Network и PNI на одном физическом порту interconnect.

Cloudflare перераспределяет маршруты, полученные от вашего устройства, в таблицу маршрутизации Magic Transit Virtual Network.

Все маршруты из таблицы маршрутизации Magic Transit Virtual Network анонсируются BGP-пирам. Каждый BGP-пир получает маршрут для каждого префикса вместе с полным AS_PATH, с выбранной стороной Cloudflare ASN ↗ добавляется в начало, чтобы peer мог точно выполнить предотвращение петель ↗.

Сессии пиринга BGP могут анонсировать соседу доступные префиксы и отзывать ранее анонсированные префиксы. Это распространение занимает не более нескольких минут.

Cloudflare использует следующие таймеры, которые нельзя настроить:

• Таймер ожидания: Задаёт максимальное время, в течение которого BGP-пир ожидает получения сообщения keepalive, update или notification, прежде чем объявить сессию BGP неактивной. Cloudflare использует меньшее из двух значений: таймер ожидания по умолчанию и значение, полученное от пира в сообщении OPEN.
• Таймер Keepalive: Системы BGP обмениваются keepalive-сообщениями, чтобы определить, доступен ли пиринговый маршрутизатор. Если keepalive-сообщения не получены в течение таймера ожидания, сессия считается неактивной, что означает, что пир больше не доступен на уровне протокола BGP.
• Таймер Graceful Restart: Показывает, сколько времени маршрутизатор ожидает, пока peer восстановит сессию BGP после инициирования graceful restart. Если peer не переподключается за это время, маршрутизатор объявляет сессию неактивной (down) и удаляет устаревшие маршруты.

BGP multipath поддерживается. Если BGP получает один и тот же префикс через два разных интерконнекта, Cloudflare распределяет трафик, предназначенный для этого префикса, по каждому интерконнекту в соответствии со стандартным поведением ECMP.

BGP Graceful Restart поддерживается в пассивном режиме (helper/aware). Cloudflare сохраняет состояние пересылки для перезапускающегося соседа.

В настоящее время поддержка BGP имеет следующие ограничения:

• ASN аккаунта Cloudflare и ASN вашего устройства должны отличаться. Поддерживается только eBGP.
• Cloudflare всегда добавляет маршруты с приоритетом 100.
• Bidirectional Forwarding Detection (BFD) не поддерживается.
• При использовании BGP с IPsec/CNI (бета-версия) необходимо задать на стороне Cloudflare ASN, равный 13335. Приватные ASN пока не поддерживаются.

Для клиентов Magic Transit протокол BGP с таблицей маршрутизации Magic Transit Virtual Network работает отдельно от анонсирования anycast-префиксов на периферийной сети Cloudflare. Отзыв anycast нужно контролировать существующими методами, описанными в Анонсирование префиксов.

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