← Cloudflare One / cloudflare-one / networks / connectors / cloudflare-wan / configuration / third-party

Cisco Meraki MX (статическая маршрутизация)

В этом руководстве приведены пошаговые инструкции по настройке устройств Cisco Meraki MX для установления туннелей IPsec VPN к Cloudflare WAN. Оно предназначено для сетевых инженеров, знакомых с администрированием Cisco Meraki и имеющих действующую подписку на Cloudflare WAN.

Замените все имена объектов и IP-адреса в примерах ниже в соответствии со своей средой.

После создания туннеля получите идентификатор IKE и предварительный ключ:

После создания туннеля получите идентификатор IKE и предварительный ключ:

Режим: Routed

• Требование к прошивке: Минимальная требуемая версия прошивки для этой конфигурации: MX 19.2.7.
• Совместимость оборудования: Более старое оборудование Meraki может быть физически неспособно работать с версией 19.2.7. Для этой архитектуры требуется поддержка VPN на основе маршрутов. См. Ограничения прошивки продукта ↗ чтобы определить, поддерживает ли ваша платформа MX версию встроенного ПО 19.2.7 или более позднюю.
• Конфигурация Active/Standby: Резервные туннели, связанные с VPN-подключениями, отличными от Meraki, работают в режиме Active/Standby. Оба туннеля устанавливаются, но Meraki направляет трафик только через основной пир IPsec VPN и автоматически переключается на резервный пир IPsec VPN на основе зондов мониторинга туннеля.
  • Резервирование Anycast и туннелей: Хотя туннели IPsec VPN на платформе MX работают в режиме Active/Standby, высокая доступность обеспечивается на сетевом уровне: IP-адреса удалённой конечной точки Cloudflare анонсируются через BGP anycast по всей глобальной сети Cloudflare, что даёт встроенную географическую и логическую избыточность.
• Поддержка VPN на основе маршрутов: хотя эта версия часто ассоциируется с определёнными облачными интеграциями, версия 19.2.7 поддерживает Route-Based IPsec VPN и для сторонних устройств в целом, включая Cloudflare WAN.
• Резервирование и Multi-Uplink: Эта документация посвящена именно конфигурациям туннелей Active/Standby.
  • Multi-Uplink IPsec VPN: Meraki Multi-Uplink IPsec VPN ↗ функция выходит за рамки этого руководства.
• Защита anti-replay: Cloudflare рекомендует отключение защиты от повторного воспроизведения (Anti-Replay Protection) для оптимальной производительности с Cloudflare WAN. Платформа Cisco Meraki MX не позволяет администраторам отключить эту функцию.
  • Это известное ограничение платформы Meraki.
  • В средах с высоким джиттером или доставкой пакетов не по порядку в базовой сети (сети интернет-провайдера) это может приводить к периодическим потерям пакетов на стороне MX в туннелях IPsec VPN.
• MSS Clamping: Cloudflare рекомендует определённый максимальный размер сегмента (MSS) clamping значения с учётом накладных расходов IPsec, чтобы избежать фрагментации.
  • Meraki Dashboard не предоставляет доступное пользователю поле для изменения значения MSS clamping для туннелей VPN сторонних производителей.
  • Клиентам необходимо обратиться в техническую поддержку Meraki, чтобы запросить ручное изменение значения MSS на серверной стороне (примерно 1360, значение может отличаться) для конкретной сети или туннеля.
• Область действия ISP: Приведённая конфигурация проверена для одного интернет-провайдера (ISP). Логику можно расширить для поддержки резервных интернет-провайдеров, но настройка с несколькими подключениями (multihoming) выходит за рамки этого руководства.

• Эта настройка требует Unified Routing dataplane для поддержки Automatic Return Routing.
• Вы уже настроили туннели IPsec и статические маршруты в панели управления Cloudflare.
• Вы получили локальный идентификатор (FQDN/имя хоста) и создали предварительный общий ключ (PSK) для каждого туннеля IPsec в панели управления Cloudflare.
• Вы понимаете важность MSS clamping и корректируя ее на основе трафика, проходящего через IPsec туннели Cloudflare WAN.

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

• Значения адресов интерфейса IPv4 (в нотации Classless Inter-Domain Routing (CIDR))
• Anycast-адреса Cloudflare
• Local ID (FQDN/hostname)
• Pre-shared keys
• Удалённые подсети

На платформе MX термин «Private subnets» обозначает удалённые сети, которые устройство MX маршрутизирует через IPsec-туннели.

В этом документе предполагается, что следующие подсети являются удалёнными подсетями:

• 172.16.10.0/24
• 172.16.11.0/24

Платформа MX использует мониторинг туннелей для переключения между основным и резервным туннелями IPsec VPN при отказе. Мониторинг туннелей определяет наличие подключения через туннели (не поддерживается для туннелей с включённым BGP). Мониторинг туннелей работает независимо от Dead Peer Detection, который определяет статус туннелей IPsec.

Зонды проверки работоспособности туннеля используются в дополнение к Dead Peer Detection для определения общей доступности ресурсов на удалённой стороне туннелей IPsec.

Meraki резервирует IP-адрес 192.0.2.3/32 (часть TEST-NET-1, определенной в RFC 5737 ↗) в качестве исходного IP-адреса для проверок монитора туннеля. Обратитесь к основные и резервные туннели IPsec ↗ для получения подробностей.

Как 192.0.2.3/32 выходит за рамки традиционного RFC 1918 ↗ адресное пространство, его нужно добавить в Unified Routing dataplane, связанный с вашей учетной записью Cloudflare.

Обратитесь в Cloudflare, чтобы запросить помощь с добавлением internal_authorized_prefixes опцию в свой аккаунт, с 192.0.2.3/32 включено.

Определите Политика HTTP и разрешите исходному IP-адресу зонда мониторинга туннеля обращаться к этому IP-адресу или URL (HTTP, порт 80/tcp).

В панели управления Cloudflare перейдите в Zero Trust > Политики трафика > Политики Firewall > HTTP.

1. Добавьте новое правило.
2. Для Policy Name, введите Meraki Tunnel Health Checks - HTTP Policy.
3. Создайте выражение типа Трафик.
4. Для Селектор, введите Source Internal IP is 192.0.2.3.
5. Для Действие, выберите Do Not Inspect.

Расположите эту политику в начале или ближе к началу свода правил HTTP-политик.

На следующей схеме показан поток трафика от зарезервированного IP-адреса мониторинга туннеля (192.0.2.3/32) по мере прохождения через туннели IPsec к Cloudflare WAN, а затем через Cloudflare Gateway при выходе запросов в интернет. Обратный путь полностью симметричен.

flowchart LR
accTitle: Meraki tunnel monitoring with Cloudflare WAN
accDescr: Traffic flow from the tunnel monitoring source IP through the Meraki MX, IPsec tunnels, Cloudflare WAN, and Cloudflare Gateway to an HTTP target on the public internet.
 subgraph CPE["Cisco Meraki (CPE) Active/Standby Model"]
    direction TB
        FW["Cisco Meraki MX
        WAN: 203.0.113.100/24
        ---
        LAN: 192.168.125.1/24
        ---
        LAN Subnet: 192.168.125.0/24"]
        L7_Health_Check["L7 Health Check
        ---
        Internal Src IP: 192.0.2.3/32"]
  end
 subgraph T1["Active - IPsec Tunnel 1"]
    direction LR
        T1_CPE["CPE VTI 1
        Internal to MX"]
        T1_CF["Cloudflare VTI 1
        169.254.250.0/31"]
  end
 subgraph T2["Standby - IPsec Tunnel 2"]
    direction LR
        T2_CPE["CPE VTI 2
        Internal to MX"]
        T2_CF["Cloudflare VTI 2
        169.254.250.2/31"]
  end
 subgraph CF["Cloudflare WAN"]
    direction TB
        EP1["Anycast Endpoint 1
        162.159.135.1"]
        EP2["Anycast Endpoint 2
        172.64.135.1"]
  end
 subgraph CF_GW["Cloudflare Gateway"]
    direction TB
        GW["Policy
        Src IP 192.0.2.3
        Allow"]
  end
    L7HCT["HTTP Target"]

    T1_CPE === T1_CF
    T2_CPE === T2_CF
    FW <==> T1_CPE & T2_CPE
    T1_CF <==> EP1
    T2_CF <==> EP2

    L7_Health_Check -.-> FW
    FW -.-> T1_CPE
    FW -.-> T2_CPE
    T1_CPE -.-> T1_CF
    T2_CPE -.-> T2_CF
    T1_CF -.-> EP1
    T2_CF -.-> EP2
    EP1 -.-> GW
    EP2 -.-> GW
    GW -.-> L7HCT
    FW@{ shape: stadium}
    T1_CPE@{ shape: stadium}
    T1_CF@{ shape: stadium}
    T2_CPE@{ shape: stadium}
    T2_CF@{ shape: stadium}
    EP1@{ shape: stadium}
    EP2@{ shape: stadium}
    GW@{ shape: stadium}

Управление конфигурацией Meraki построено на двухуровневой иерархии. Объекты и связанные с ними настройки определяются одним из следующих способов:

• На уровне всей организации: Глобальные объекты, определённые один раз для всего тенанта.
• Специфичный для сети: Настройки, применяемые к отдельной площадке или устройству.

Конфигурация Non-Meraki VPN является объектом уровня Organization. Она передаётся на конкретные устройства MX при их привязке к соответствующему Network Tag. Эта модель наследования имеет решающее значение: именно тег определяет, какое физическое оборудование пытается установить туннели к Cloudflare.

Orbital Path Ventures это вымышленная компания, упоминаемая в конфигурации для представления организации, определённой в Meraki Dashboard.

Компания управляет одним устройством Meraki MX в своём филиале в Остине, штат Техас, которое связано с сетью с именем Orbital Path Ventures - Austin TX.

Network Tag с меткой Orbital_Path_AUS_Office связан с Orbital Path Ventures - Austin TX Сеть.

Перейдите в Сеть > Сети, затем выберите Organization.

• Orbit Path Ventures (подставьте имя вашей Organization).
• Сеть: Orbit Path Ventures - Austin TX (подставьте имя вашей Network).
• Тег: Orbital_Path_AUS_Office (подставьте Tag, связанный с именем Network).

При интеграции с Cloudflare WAN тег Meraki Network Tag определяет, какие устройства наследуют конфигурацию туннеля Cloudflare.

Конфигурация Non-Meraki VPN является глобальным объектом: любое устройство MX с соответствующим Network Tag пытается установить туннели к Cloudflare, используя одни и те же пиры IPsec VPN.

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

• Строгая корреляция туннелей: Поддерживайте соответствие 1 к 1 между парами резервных туннелей IPsec, определёнными в Cloudflare, и конкретным устройством MX, инициирующим эти туннели.
• Network Tags для конкретного сайта: Используйте детализированные теги для конкретных сайтов (например, Orbital_Path_AUS_Office) а не широких, общих тегов, чтобы конфигурацию туннеля унаследовал только нужный MX.
• Уникальные объекты peer для IPsec VPN: Создайте отдельные объекты Non-Meraki VPN peer на уровне Organization для разных физических географических местоположений. Используйте Доступность опцию, чтобы установить сопоставление 1 к 1.

Обратный трафик от Cloudflare WAN направляется на основе таблицы маршрутизации виртуальной сети Cloudflare (см. Управление трафиком для подробностей). Маршруты задаются на основе префикса MX LAN и соответствующих туннелей IPsec.

Маршрутизация по умолчанию на основе источника ↗ позволяет администратору создавать маршрут по умолчанию на основе адреса источника и указывать в качестве next hop устройство безопасности через Auto VPN или устройство в сети LAN.

Маршрутизацию по умолчанию на основе источника нельзя использовать вместе с конечными точками VPN, отличными от Meraki, включая Cloudflare WAN.

Определите приватные подсети в конфигурации IPsec VPN peer, чтобы контролировать, как устройства MX направляют трафик через соответствующие туннели.

То, какой трафик направляется через основной и резервный туннели VPN, определяют префиксы IP, заданные как приватные подсети в конфигурации IPsec VPN peer. Их можно увидеть в таблице маршрутизации соответствующего устройства MX.

В этом документе рассматриваются три топологии маршрутизации:

1. Только East/west:
   • Приватный трафик через Cloudflare WAN.
   • Интернет через локальный выход в интернет.
2. Интернет только через Cloudflare Gateway:
   • Направлять через Cloudflare WAN только интернет-трафик.
3. Весь трафик через Cloudflare WAN и Gateway:
   • Трафик East/west и интернет-трафик, маршрутизируемый через Cloudflare WAN.

Все три топологии рассматриваются в Peer-устройства IPsec VPN раздел.

Перейдите в Безопасность и SD-WAN > VPN между сайтами.

Выберите Hub (Mesh).

Включите режим VPN для локальной сети за устройствами MX.

От:

Кому:

Перейдите в Безопасность и SD-WAN > VPN между сайтами > Настройки на уровне всей организации.

Настройте HTTP-пробу проверки работоспособности уровня 7, которую платформа MX использует для определения доступности ресурсов через туннели IPsec VPN:

1. Выберите Настройте проверки работоспособности.

2. Укажите следующие значения:

   Название	Конечная точка
   Google	http://www.google.com

3. Выберите OK.

Конфигурации peer-устройств IPsec VPN приведены для следующих топологий:

• Только трафик East/west
• Интернет только через Cloudflare Gateway
• Весь трафик через Cloudflare WAN и Gateway

Для маршрутизации трафика east-west через Cloudflare WAN необходимо следующее:

• Маршруты Cloudflare, заданные для подсети LAN за устройством MX (192.168.125.0/24) через CF_WAN_TUN_01 и CF_WAN_TUN_02.
• Удалённые подсети (172.16.10.0/24 и 172.16.11.0/24) указанных как частные подсети на основных и резервных Peer-устройствах IPsec VPN Meraki.
• Префиксы адресов интерфейса IPv4, указанные на обоих CF_WAN_TUN_01 и CF_WAN_TUN_02 (169.254.250.0/31 и 169.254.250.2/31) указанных как частные подсети на основных и резервных Peer-устройствах IPsec VPN Meraki.

Это гарантирует, что:

• Cloudflare направляет трафик, предназначенный для подсети LAN за устройством MX, через CF_WAN_TUN_01 и CF_WAN_TUN_02.
• Устройство MX явно направляет трафик, предназначенный для удалённых подсетей (172.16.10.0/24 и 172.16.11.0/24) через основное и резервное Peer-устройство IPsec VPN соответственно.
• Устройство MX явно направляет пакеты ICMP Reply, связанные с проверками работоспособности туннеля Cloudflare, на IPv4-адреса интерфейса (169.254.250.0/31 и 169.254.250.2/31) указанного на CF_WAN_TUN_01 и CF_WAN_TUN_02 через основной и резервный узлы IPsec VPN соответственно.
• Интернет-трафик из подсети LAN за устройством MX маршрутизируется через аплинк WAN.
• Устройство MX устанавливает туннели IPsec к конечным точкам Cloudflare (162.159.135.1 и 172.64.135.1) через восходящий канал WAN.

Настройте следующее:

IPsec-туннели Cloudflare: автоматическая обратная маршрутизация:

Маршруты Cloudflare:

Частные подсети Meraki:

1. Выберите + Добавить узел.

2. Укажите следующие значения:

   Attribute	Значение
   Название	cf-wan-tun-01
   Версия IKE	IKEv2
   Публичный IP-адрес или имя хоста	162.159.135.1
   Local ID	bf6c493d03<REDACTED>.ipsec.cloudflare.com
   Remote ID	,
   Shared Secret	Cloudflare-WAN-T1-PSK-1234!
   Маршрутизация	Статический
   Частные подсети	169.254.250.0/31, 169.254.250.2/31, 172.16.10.0/24, 172.16.11.0/24
   Доступность	Orbital_Path_AUS_Office
   Tunnel Monitoring	Google Health Check
   Переключение при сбое напрямую в интернет	,
   IPsec Policy	,
   Preset	Custom
   Phase 1, Encryption	AES 256
   Phase 1, Authentication	SHA256
   Phase 1, Pseudo-Random Function	SHA256
   Phase 1, Diffie-Hellman group	14
   Phase 1, Lifetime (sec)	28800
   Phase 2, Encryption	AES256
   Phase 2, Authentication	SHA256
   Phase 2, PFS Group	14
   Phase 2, Lifetime (sec)	28800

3. Выберите Save.

1. Выберите --- значок в столбце настроек.

2. Выберите + Добавить вторичный узел.

3. Не выбирайте Наследовать конфигурации основного peer. Это обеспечивает Публичный IP-адрес или имя хоста, Local ID, Remote ID, а также Shared secret настроены с параметрами, необходимыми для успешного согласования туннеля IPsec CF_WAN_TUN_02.

4. Укажите следующие значения:

   Attribute	Значение
   Название	cf-wan-tun-02
   Версия IKE	IKEv2 (унаследовано)
   Публичный IP-адрес или имя хоста	172.64.135.1
   Local ID	0287844e9d<REDACTED>.ipsec.cloudflare.com
   Remote ID	172.64.135.1
   Shared Secret	Cloudflare-WAN-T2-PSK-1234!
   Маршрутизация	Статический (унаследовано)
   Частные подсети	169.254.250.0/31, 169.254.250.2/31, 172.16.10.0/24, 172.16.11.0/24 (унаследовано)
   Доступность	Orbital_Path_AUS_Office (унаследовано)
   Tunnel Monitoring	Google Health Check
   Переключение при сбое напрямую в интернет	,
   IPsec Policy	,
   Preset	Custom
   Phase 1, Encryption	AES 256
   Phase 1, Authentication	SHA256
   Phase 1, Pseudo-Random Function	SHA256
   Phase 1, Diffie-Hellman group	14
   Phase 1, Lifetime (sec)	28800
   Phase 2, Encryption	AES256
   Phase 2, Authentication	SHA256
   Phase 2, PFS Group	14
   Phase 2, Lifetime (sec)	28800

5. Выберите Save.

Убедитесь, что таблица маршрутизации устройства MX содержит маршруты для частных подсетей, заданных в конфигурации основного и резервного IPsec VPN peer.

Перейдите в Безопасность и SD-WAN > Мониторинг > таблица маршрутизации.

Таблица маршрутизации Meraki отражает маршруты через cf-wan-tun-01 и cf-wan-tun-02 следующим образом:

Meraki использует мониторинг туннеля, чтобы определить момент автоматического переключения на резервный узел IPsec VPN. Для оценки общего состояния туннелей IPsec Meraki использует Dead Peer Detection.

VPN-пиры не от Meraki поддерживают модель Active/Standby. Трафик передаётся через cf-wan-tun-01 пока не произойдёт переключение при сбое, после чего cf-wan-tun-02 становится активным. Трафик динамически возвращается к cf-wan-tun-01 как только его туннель снова подключится.

Тестирование переключения при сбое показывает, что трафик может прерываться на несколько секунд. Cloudflare зафиксировала отдельные случаи, когда переключение занимало от 15 до 20 секунд, но такие случаи редки.

Проверки состояния Cloudflare Tunnel фиксируют 100% отказов на туннеле, помеченном как резервный (standby). Это гарантирует, что трафик идет только через активный туннель.

Используйте Meraki Dashboard, чтобы определить статус туннелей IPsec:

1. Перейдите в Безопасность и SD-WAN > Мониторинг > VPN Status.
2. Прокрутите до Обзор раздел.
3. Выберите фильтр с меткой 2 IPsec-узла.

Активный туннель: cf-wan-tun-01:

Активный туннель: cf-wan-tun-02:

Активный туннель: cf-wan-tun-01:

Активный туннель: cf-wan-tun-02:

Активный туннель: cf-wan-tun-01:

Активный туннель: cf-wan-tun-02:

Проверьте таблицу маршрутизации MX, чтобы определить, какой трафик направляется через туннели IPsec, а какой маршрутизируется напрямую в интернет.

Перейдите в Безопасность и SD-WAN > Мониторинг > Таблица маршрутизации.

VPN Status сообщает, что проверки работоспособности не проходят на обоих туннелях:

Проверьте журналы и политику Cloudflare Gateway, чтобы определить, действительно ли HTTP-запросы, исходящие от 192.0.2.3/32 блокируются.

Если запрос блокируется, создайте правило, разрешающее HTTP-запросы мониторинга туннеля. См. HTTP-политика Cloudflare Gateway для получения подробностей.

Доступно в:

• Log Explorer
• Logpush > Журналы IPsec

Журналы IPsec помогают диагностировать различные проблемы, связанные с туннелями IPsec, в том числе:

• Использование неподдерживаемых настроек шифрования или целостности для Phase 1 или Phase 2: ищите сообщения, указывающие на No proposal chosen.
  • Убедитесь, что заданные значения шифрования или целостности для Phase 1 и Phase 2 поддерживаются Cloudflare WAN.
  • См. Поддерживаемые параметры конфигурации.
• Идентификатор IKE/IPsec: локальный или удалённый идентификатор не задан либо имеет неверные значения.
  • См. Руководство по интеграции со сторонним решением Palo Alto для примера локальной идентификации на основе FQDN.
• Сбой аутентификации: неверный предварительный общий ключ.

См. Настройка конечных точек туннеля для дополнительных сведений.

Убедитесь, что проверки работоспособности туннеля для обоих CF_WAN_TUN_01 и CF_WAN_TUN_02 настроены со следующими параметрами:

• Мониторинг подключения для отказоустойчивости WAN ↗
• Поведение маршрутизации MX ↗
• Обзор организации ↗
• Основные и резервные туннели IPsec VPN ↗
• VPN между сайтами ↗