← Cloudflare One / cloudflare-one / networks / connectors / cloudflare-wan / reference

Туннели GRE и IPsec

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

Cloudflare WAN использует два протокола инкапсуляции: Generic Routing Encapsulation (GRE) и IPsec. GRE не отслеживает состояние (stateless) и проще в настройке, но не шифрует трафик. IPsec шифрует трафик и подтверждает подлинность источника, обеспечивая более высокий уровень защиты. Оба протокола создают туннели: логические соединения точка-точка между Cloudflare и вашей сетью. Cloudflare развёртывает конечные точки туннелей на серверах глобальной сети в пределах вашего пространства имён, а вы настраиваете конечные точки туннелей на маршрутизаторах в своём дата-центре.

Чтобы учесть дополнительные данные заголовка, добавляемые инкапсуляцией, необходимо изменить максимальный размер сегмента (MSS) в соответствии со стандартной маршрутизируемой в интернете максимальной единицей передачи (MTU), которая составляет 1500 байт.

Инструкции см. в Задайте максимальный размер сегмента.

Эта диаграмма показывает поток трафика в Cloudflare WAN.

sequenceDiagram
accTitle: Tunnels and encapsulation
accDescr: This diagram shows the flow of traffic with Cloudflare WAN.
participant A as Client machine
participant B as Cloudflare Cloudflare WAN
participant C as Origin router
A->>B: Payload <br> Protocol <br> IP header
Note left of A: Ingress <br> traffic
B->>C: Payload <br> Protocol <br> IP header <br> GRE <br> IP header
C->>A: IP header <br> Protocol <br> Payload
Note right of C: Egress <br> traffic

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

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

Для туннелей IPsec маршрутизатор клиента согласовывает создание туннеля IPsec с Cloudflare с помощью Протокол Internet Key Exchange (IKE). Поскольку IPsec работает с отслеживанием состояния (требует общих ключей и параметров сессии), первоначальное согласование выполняет один сервер Cloudflare, после чего сведения о туннеле (селекторы трафика, ключи и так далее) распространяются на все дата-центры Cloudflare. В результате трафик для этого туннеля IPsec может обрабатывать любой сервер Cloudflare, даже если настройку согласовал только один из них.

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

flowchart LR
accTitle: Anycast tunnel
accDescr: Multiple servers in data center preparing packets to send through anycast tunnel.

a(User)

subgraph 1
direction LR
b(Cloudflare global <br> network server)
c(Cloudflare global <br> network server)
d(Cloudflare global <br> network server)
e(Cloudflare global <br> network server)
f(Cloudflare global <br> network server)
g(Cloudflare global <br> network server)
h(Cloudflare global <br> network server)
end

subgraph 2
i("Acme router <br> 198.51.100.1")
j("FTP server <br> (203.0.113.100)")
end

subgraph 3
x("Acme router <br> 198.51.100.1")
z("FTP server <br> (203.0.113.100)")
end

a --> 1== Cloudflare anycast GRE <br> single endpoint ==>i --> j

1== Cloudflare anycast IPsec <br> single endpoint ==>x --> z

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

Сведения о настройке туннеля IPsec см. в Настройка конечных точек туннеля. Чтобы узнать больше о параметрах конфигурации, которые Cloudflare WAN использует для создания туннеля IPsec, продолжайте чтение.

Для установки туннеля IPsec Cloudflare WAN использует следующие этапы:

• Initial Exchange (IKE_SA_INIT): узлы IKE согласовывают параметры ассоциации безопасности IKE (SA) и устанавливают общий секрет для получения ключа, а также, если это уместно, сообщают о поддержке постквантового обмена ключами с RFC 9370 ↗. Когда защита от понижения версии протокола включено, Cloudflare также отправляет IKE_SA_INIT_FULL_TRANSCRIPT_AUTH уведомление в ходе этого обмена, чтобы указать на поддержку полной аутентификации транскрипта. После этого обмена у сторон есть защищённый канал связи, но они ещё не аутентифицировали друг друга.
• Intermediate Exchange (IKE_INTERMEDIATE): если оба узла поддерживают RFC 9370, они выполняют дополнительный обмен ключами с использованием ML-KEM (Module-Lattice-based Key-Encapsulation Mechanism), постквантового алгоритма обмена ключами, указанного в draft-ietf-ipsecme-ikev2-mlkem ↗. Это создаёт гибридный общий секрет, объединяя секрет, полученный с помощью классического алгоритма Диффи-Хеллмана (установленного во время IKE_SA_INIT) с постквантовым ML-KEM для защиты от «собрать сейчас, расшифровать позже» ↗ атаки.
• Auth Exchange (IKE_AUTH): с использованием ключей, установленных как для IKE_SA_INIT и IKE_INTERMEDIATE обмена узлы IKE взаимно аутентифицируют друг друга. После аутентификации они устанавливают ассоциацию безопасности IKE (SA). Затем узлы согласовывают и устанавливают туннель IPsec, известный как Child SA.
• Rekeying: Периодически или в результате ручного вмешательства для IKE SA может выполняться rekey, генерирующий новые SA со свежими ключами для сессии. Эта операция rekey выполняется как для IKE SA (для обновления плоскости управления), так и для Child SA (для обновления плоскости данных). При использовании гибридного обмена (RFC 9370) процесс rekey для IKE SA снова выполнит параллельные классический (DH) и постквантовый (ML-KEM) обмены, чтобы обеспечить сохранение устойчивости к квантовым компьютерам.

Таким образом, IKEv2 создаёт IKE SA, использующую определённые криптографические преобразования, а затем на основе этой IKE SA создаёт Child SA, которая использует уже свои криптографические преобразования. В следующем разделе конфигурации перечислено, какие из этих преобразований Cloudflare WAN в настоящее время поддерживает для IKE SA и Child SA.

Выберите из следующих параметров конфигурации, которые поддерживает Cloudflare WAN, в зависимости от того, что поддерживает ваш appliance.

Перечисленные ниже сторонние производители прошли тестирование и подтвердили совместимость с Cloudflare IPsec при постквантовом согласовании ключей:

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

Cloudflare WAN поддерживает следующие типы IKE ID для IPsec:

Кроме того, Cloudflare поддерживает тип IKE ID ID_IPV4_ADDR если выполняются следующие два условия:

1. Вы задаёте для туннеля IPsec customer_endpoint значение.
2. Комбинация cloudflare_endpoint и customer_endpoint уникален среди туннелей IPsec клиента.

Cloudflare поддерживает как VPN на основе маршрутов, так и VPN на основе политик, но мы рекомендуем использовать VPN на основе маршрутов.

Если VPN на основе маршрутов недоступны и приходится использовать VPN на основе политик, учитывайте следующие ограничения:

• Cloudflare поддерживает только один набор traffic selectors на Child SA.
• Политика должна охватывать проверки работоспособности в режиме reply (reply-style), то есть они должны соответствовать traffic selectors, иначе Cloudflare отбрасывает их, как и любой другой трафик от IPsec-туннеля, который не соответствует ни одной политике.
• Один туннель IPsec может содержать не более примерно 100 Child SA, поэтому количество различных политик на один туннель фактически ограничено.

Изначальная схема аутентификации IKEv2 предполагает, что каждая сторона подписывает только свои собственные исходящие сообщения, а не весь процесс согласования (handshake). Квантовый злоумышленник в канале связи ↗ может использовать это для создания «раздельного представления» рукопожатия, вынуждая конечные точки откатывать постквантовое соединение к классической криптографии, даже если обе стороны поддерживают постквантовый обмен ключами.

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

Как это работает:

• Если feature flag включён, Cloudflare (выступая в роли IKE responder) безусловно включает IKE_SA_INIT_FULL_TRANSCRIPT_AUTH уведомление в своём IKE_SA_INIT ответ.
• Если инициатор также поддерживает это расширение, обе стороны используют полную аутентификацию транскрипта, что усиливает защиту от атак понижения версии.
• Если инициатор не поддерживает это расширение, согласование выполняется по стандартной аутентификации IKEv2. Для эффективной защиты от понижения версии расширение должны поддерживать обе стороны.

Требования:

• Ваш инициатор IKEv2 должен поддерживать IKE_SA_INIT_FULL_TRANSCRIPT_AUTH уведомление, как определено в draft-ietf-ipsecme-ikev2-downgrade-prevention ↗.

Для устранения проблем с туннелем:

• Устранение неполадок состояния туннеля: Диагностируйте и устраняйте сбои проверок работоспособности
• Устранение неполадок с помощью логов IPsec: Используйте Logpush для анализа проблем с установлением соединения (handshake) IPsec

Для устранения проблем с туннелем:

• Устранение неполадок состояния туннеля: Диагностируйте и устраняйте сбои проверок работоспособности
• Устранение неполадок с помощью логов IPsec: Используйте Logpush для анализа проблем с установлением соединения (handshake) IPsec