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

Проверки работоспособности туннеля

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

Зонд проверки работоспособности туннеля состоит из ICMP (Internet Control Message Protocol) ↗ полезная нагрузка инкапсулируется в протокол проверяемого туннеля. Например, если это туннель IPsec (Internet Protocol Security), ICMP-пакет ↗ шифруется внутри пакета Encapsulating Security Payload (ESP) туннеля.

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

Cloudflare WAN использует два типа проверок работоспособности:

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

Вы можете просматривать результаты проверки работоспособности туннеля через API. Cloudflare объединяет эти результаты на основе отдельных результатов проверок работоспособности с серверов Cloudflare.

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

Серверы глобальной сети Cloudflare выполняют проверки работоспособности конечных точек вне сетевых пространств имён клиента и, как правило, обращаются к конечным точкам за пограничным маршрутизатором, на котором завершается туннель. Во время onboarding вы указываете IP-адреса для настройки этих проверок.

Зонд проверки работоспособности туннеля имеет следующие атрибуты.

Зонд проверки работоспособности туннеля проверяет, может ли Cloudflare успешно подключиться к определённому адресу или конечной точке через туннель. Цель, это адрес, доступность которого нужно проверить. Она необязательна, а значения по умолчанию зависят от направления проверки работоспособности (см. Направление с дополнительной информацией).

Зонд проверки работоспособности туннеля может иметь одно из двух направлений: однонаправленное или двунаправленное.

Однонаправленный зонд проверки работоспособности остаётся инкапсулированным в одном направлении и поступает к источнику через туннель (от Cloudflare к источнику). Ответ возвращается в Cloudflare без инкапсуляции и маршрутизируется за пределами туннеля согласно стандартным правилам маршрутизации маршрутизация ↗.

По умолчанию целью выступает общедоступный маршрутизируемый источник, указанный в качестве customer_endpoint на туннеле, если он есть. В противном случае вы можете использовать пользовательскую цель.

Двунаправленный зонд остается инкапсулированным в обоих направлениях. Зонд входит через туннель, и ответ также выходит через туннель в инкапсулированном виде. ICMP-ответ от вашего маршрутизатора, предназначенный для anycast IP-адреса в сети Cloudflare, поступает в ближайший дата-центр Cloudflare и попадает на один из серверов с использованием Equal-Cost Multi-Path (ECMP), что обеспечивает передачу ответа по наиболее эффективному пути.

Адресация пакетов по умолчанию

По умолчанию Cloudflare указывает в качестве адреса назначения этих пакетов сторону Cloudflare из поля адреса интерфейса, заданного для туннеля, а в качестве адреса источника использует сторону клиента туннеля. Например, если адрес интерфейса равен 10.100.0.8/31, Cloudflare направляет пакет для 10.100.0.9 и получает его из 10.100.0.8.

Диапазоны адресов интерфейса

Поле адреса интерфейса принимает либо /30 или /31 Диапазон CIDR:

• /31 диапазон: Указанный вами IP-адрес относится к стороне Cloudflare, а другой IP-адрес относится к стороне клиента. Например, если адрес интерфейса 10.100.0.8/31, затем 10.100.0.8 является стороной Cloudflare, а 10.100.0.9 является клиентской стороной.
• /30 диапазон: Указанный вами IP-адрес относится к стороне Cloudflare, а другой IP-адрес (за исключением широковещательного и сетевого идентификаторов) относится к стороне клиента. Например, если адрес интерфейса 10.100.0.9/30, затем 10.100.0.9 является стороной Cloudflare, а 10.100.0.10 является клиентской стороной.

Вы также можете настроить двунаправленную проверку работоспособности с пользовательской публичной целью: такой подход рекомендуется при настройке туннеля Azure Active Standby.

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

См. Добавить туннели чтобы узнать, как настроить двунаправленные или однонаправленные проверки работоспособности.

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

• Настройка целевого IP-адреса проверки работоспособности туннеля на адрес в пределах 172.64.240.252/30 диапазон префиксов.
• Применение маршрута на основе политики, соответствующего пакетам, у которых исходный IP-адрес совпадает с настроенной целью проверки работоспособности туннеля (например 172.64.240.253/32), и направьте их обратно в Cloudflare через туннель.

Зонд проверки работоспособности туннеля может быть одного из двух типов: request и reply. Для каждого типа адрес источника и назначения зависит от направления. См. Добавить туннели чтобы узнать, как изменить этот параметр.

При проверке работоспособности в стиле request зонд полезной нагрузки представляет собой ICMP-запрос.

Для однонаправленного зонда адресом источника служит сторона туннеля Cloudflare (публично маршрутизируемый адрес), а адресом назначения служит исходный маршрутизатор (также публично маршрутизируемый). Исходный маршрутизатор получает зонд, формирует ICMP-ответ с обратными адресами источника и назначения и отправляет его вне туннеля.

Для двунаправленного зонда адресом источника служит адрес интерфейса стороны туннеля Cloudflare (приватно маршрутизируемый адрес), а адресом назначения служит адрес интерфейса туннеля (также приватно маршрутизируемый). Исходный маршрутизатор получает зонд, формирует ICMP-ответ с обратными адресами источника и назначения и отправляет его в туннель.

При проверке работоспособности в стиле reply зонд полезной нагрузки представляет собой ICMP-ответ.

Для однонаправленного зонда адресом назначения служит сторона туннеля Cloudflare (публично маршрутизируемый адрес), а адресом источника служит исходный маршрутизатор (также публично маршрутизируемый). Исходный маршрутизатор получает зонд и отправляет его обратно в качестве ответа, без изменений, вне туннеля.

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

flowchart TB
accTitle: Bidirectional request style
accDescr: Shows the flow of a bidirectional request-style tunnel health check probe and response between Cloudflare and the origin.
   subgraph Tunnel Healthcheck Probe
   cloudflare(Cloudflare) --- bare_echo_request([ICMP Echo Request])
   bare_echo_request --> tunnel[Tunnel]
   tunnel --- encapsulated_echo_request([Tunnel Protocol < ICMP Echo Request >])
   encapsulated_echo_request --> Internet([Internet])
   Internet --- encapsulated_echo_request_2([Tunnel Protocol < ICMP Echo Request >])
   encapsulated_echo_request_2 --> origin_tunnel(Tunnel)
   origin_tunnel --- received_bare_echo_request([ICMP Echo Request])
   received_bare_echo_request --> origin(Origin)
   end
   subgraph Tunnel Healthcheck Response
   origin --> bare_echo_reply([ICMP Echo Reply])
   bare_echo_reply --- origin_tunnel_2(Tunnel)
   origin_tunnel_2 --- encapsulated_echo_reply([Tunnel Protocol < ICMP Echo Reply >])
   encapsulated_echo_reply --- Internet_2([Internet])
   Internet_2 --> encapsulated_echo_reply_2([Tunnel Protocol < ICMP Echo Reply >])
   encapsulated_echo_reply_2 --> tunnel_2[Tunnel]
   tunnel_2 --> bare_echo_reply_2([ICMP Echo Reply])
   bare_echo_reply_2 --> cloudflare
   end

flowchart TB
accTitle: Bidirectional reply style
accDescr: Shows the flow of a bidirectional reply-style tunnel health check probe and response between Cloudflare and the origin.
   subgraph Tunnel Healthcheck Probe
   cloudflare(Cloudflare) --- bare_echo_probe([ICMP Echo Reply])
   bare_echo_probe --> tunnel[Tunnel]
   tunnel --- encapsulated_echo_probe([Tunnel Protocol < ICMP Echo Reply >])
   encapsulated_echo_probe --> Internet([Internet])
   Internet --- encapsulated_echo_probe_2([Tunnel Protocol < ICMP Echo Reply >])
   encapsulated_echo_probe_2 --> origin_tunnel(Tunnel)
   origin_tunnel --- received_bare_echo_reply([ICMP Echo Reply])
   received_bare_echo_reply --> origin(Origin)
   end
   subgraph Tunnel Healthcheck Response
   origin --> bare_echo_reply([ICMP Echo Reply])
   bare_echo_reply --- origin_tunnel_2(Tunnel)
   origin_tunnel_2 --- encapsulated_echo_reply([Tunnel Protocol < ICMP Echo Reply >])
   encapsulated_echo_reply --- Internet_2([Internet])
   Internet_2 --> encapsulated_echo_reply_2([Tunnel Protocol < ICMP Echo Reply >])
   encapsulated_echo_reply_2 --> tunnel_2[Tunnel]
   tunnel_2 --> bare_echo_reply_2([ICMP Echo Reply])
   bare_echo_reply_2 --> cloudflare
   end

flowchart TB
accTitle: Unidirectional echo request
accDescr: Shows the flow of a unidirectional echo request health check from Cloudflare to the origin and back.
   cloudflare(Cloudflare) --- bare_echo_probe([ICMP Echo Request])
   bare_echo_probe --> tunnel[Tunnel]
   tunnel --- encapsulated_echo_probe([Tunnel Protocol < ICMP Echo Request >])
   encapsulated_echo_probe --> Internet([Internet])
   Internet --- encapsulated_echo_probe_2([Tunnel Protocol < ICMP Echo Request >])
   encapsulated_echo_probe_2 --> origin_tunnel(Tunnel)
   origin_tunnel --- received_bare_echo_reply([ICMP Echo Request])
   received_bare_echo_reply --> origin(Origin)
   origin --- received_bare_echo_reply_2([ICMP Echo Reply])
   received_bare_echo_reply_2 --> Internet_2([Internet])
   Internet_2 --> cloudflare

flowchart TB
accTitle: Unidirectional echo reply
accDescr: Shows the flow of a unidirectional echo reply health check from Cloudflare to the origin and back.
   cloudflare(Cloudflare) --- bare_echo_probe([ICMP Echo Reply])
   bare_echo_probe --> tunnel[Tunnel]
   tunnel --- encapsulated_echo_probe([Tunnel Protocol < ICMP Echo Reply >])
   encapsulated_echo_probe --> Internet([Internet])
   Internet --- encapsulated_echo_probe_2([Tunnel Protocol < ICMP Echo Reply >])
   encapsulated_echo_probe_2 --> origin_tunnel(Tunnel)
   origin_tunnel --- received_bare_echo_reply([ICMP Echo Reply])
   received_bare_echo_reply --> origin(Origin)
   origin --- received_bare_echo_reply_2([ICMP Echo Reply])
   received_bare_echo_reply_2 --> Internet_2([Internet])
   Internet_2 --> cloudflare

Каждый центр обработки данных Cloudflare, настроенный для обработки вашего трафика, отправляет зонды проверки работоспособности туннеля. Частота отправки этих зондов Cloudflare зависит от туннеля и местоположения. Вы можете настроить эту частоту отдельно для каждого туннеля, изменив health_check частоту с API или дашборд. Вы можете задать частоту как низкий, mid, или высокий, с mid используется по умолчанию.

Фактическая формула расчета скорости учитывает количество серверов в дата-центре Cloudflare или, для динамически выделяемых пространств имен, количество серверов, на которых развернуто пространство имен клиента. Скорость является динамической и зависит от размера сети Cloudflare.

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

Существует три состояния работоспособности туннеля: healthy, degraded и down.

Исправным туннелям отдается предпочтение перед туннелями с ухудшенным состоянием, а туннелям с ухудшенным состоянием отдается предпочтение перед отключенными.

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

• Если хотя бы 0.1% проверок состояния туннеля не проходят за предыдущие пять минут (при этом сбоев не менее двух), Cloudflare WAN считает канал нестабильным и переводит туннель в состояние degraded (если он ещё не в состоянии down).
• Cloudflare WAN требует двух последовательных сбоев, чтобы потеря одного пакета не приводила к штрафу.
• После этого Cloudflare WAN сразу переводит статус туннеля в состояние degraded и применяет штраф к приоритету.

• Если за последнюю секунду не проходят все проверки состояния хотя бы по трём образцам, Cloudflare WAN немедленно переводит туннель из состояния healthy или degraded в состояние down и начисляет штраф к приоритету маршрутов, проходящих через этот туннель.
• Определение состояния Down имеет приоритет над определением состояния Degraded. Это означает, что туннель может находиться только в одном из следующих состояний: Down, Degraded или Healthy.

Когда Cloudflare WAN обнаруживает неработоспособный маршрут, он применяет к нему следующие штрафы:

• Degraded: Добавьте 500,000 в приоритет.
• Down: Добавьте 1,000,000 в приоритет.

Значения штрафов за отказ намеренно завышены, чтобы они всегда превышали значения приоритета, назначенные во время конфигурация маршрутизации.

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

Если дата-центр Cloudflare недоступен, глобальная сеть Cloudflare перестаёт анонсировать ваши префиксы, и Cloudflare направляет ваши пакеты в следующий ближайший дата-центр. Чтобы проверить статус системы для глобальной сети и панели управления Cloudflare, см. Cloudflare System Status ↗.

Пока туннель находится в состоянии down, серверы глобальной сети продолжают отправлять зонды с той же периодичностью, что описана выше. Как только зонд возвращает статус healthy, сервер глобальной сети, получивший этот пакет, сразу отправляет ещё два зонда. Если оба зонда также возвращают healthy, Cloudflare WAN переводит статус туннеля в состояние degraded (так как три подряд успешных зонда уже не соответствуют условию состояния down).

Туннели в состоянии Degraded переходят в Healthy, если доля сбоев за предыдущие 30 зондов составляет менее 0.1%. Этот переход может занять до 30 минут.

Система проверки работоспособности туннелей Cloudflare WAN позволяет туннелю быстро переходить из состояния healthy в состояние degraded или down, но при обратном переходе из degraded или down в healthy это происходит намного медленнее. Такое поведение называется гистерезисом и предотвращает изменения маршрутизации из-за флаппинга и других кратковременных сбоев сети.

Рассмотрим два туннеля и связанные с ними приоритеты маршрутизации. Обратите внимание: чем меньше значение маршрута, тем выше приоритет.

• Tunnel 1, приоритет маршрута 100
• Tunnel 2, приоритет маршрута 200

Когда оба туннеля находятся в состоянии healthy, приоритет маршрутизации направляет весь трафик исключительно на Tunnel 1, поскольку приоритет его маршрута равен 100 выше приоритета Tunnel 2. Tunnel 2 не получает никакого трафика, кроме зондов проверки работоспособности туннеля. Проверки работоспособности конечных точек проходят только через Tunnel 1 к месту назначения внутри исходной сети.

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

Если сервер глобальной сети не получает корректные ICMP-пакеты ответа на эти два дополнительных зонда, он помечает Tunnel 1 статусом down и понижает приоритет Tunnel 1 до 1,000,100. Приоритет затем переходит к Tunnel 2, и Cloudflare WAN немедленно направляет пакеты, поступающие на этот глобальный сетевой сервер, в Tunnel 2.

Предположим, что проблема с подключением, из-за которой состояние работоспособности Tunnel 1 стало down, устранена. При следующем интервале проверки работоспособности сервер глобальной сети, инициировавший проверку, получает успешный зонд и сразу же отправляет ещё два зонда, чтобы подтвердить работоспособность туннеля.

Когда все три пробы завершаются успешно, Cloudflare WAN переводит туннель из состояния down в состояние degraded. В рамках этого перехода Cloudflare уменьшает штраф к приоритету для этого маршрута, поэтому его приоритет становится 500,100. Поскольку у Tunnel 2 приоритет 200, трафик продолжает проходить через Tunnel 2.

Серверы глобальной сети продолжают опрашивать Tunnel 1. Как только доля отказов проверки состояния в течение пяти минут опускается ниже 0.1%, Cloudflare WAN присваивает туннелю статус исправного. После этого Cloudflare полностью восстанавливает приоритет маршрутизации Tunnel 1 до 100, и управление трафиком возвращает поток данных в Tunnel 1.

Сведения об устранении проблем с состоянием туннеля см. в Устранение неполадок состояния туннеля.