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

Устранение неполадок состояния туннеля

Это руководство поможет вам диагностировать и устранить распространённые проблемы работоспособности туннелей в Cloudflare WAN. Проверки работоспособности туннелей отслеживают конечные точки ваших туннелей GRE и IPsec (в панели управления Cloudflare они также называются коннекторами) и направляют трафик по наиболее оптимальным маршрутам.

Используйте следующую таблицу, чтобы сопоставить симптом с наиболее вероятной причиной и первым действием:

• Dashboard: Статус работоспособности туннеля по дата-центрам и объем трафика по туннелю (Перейти в Insights > Работоспособность сети > Работоспособность сети)
• API: Статус работоспособности туннеля через API проверки работоспособности туннеля Cloudflare WAN
• Network Analytics: Объем трафика, количество пакетов и распределение по протоколам через Network Analytics
• Из вашей сети: Traceroute и MTR от конечной точки вашего туннеля до Cloudflare. Поскольку конечные точки Cloudflare используют anycast, этот тест проверяет путь только до ближайшего дата-центра. Чтобы протестировать конкретные регионы, используйте Cloudflare Traceroute API и запускайте traceroute из определенных локаций Cloudflare к вашей сети.

• Корреляция между событиями работоспособности туннеля и инцидентами в сети Cloudflare
• Решения о пересылке для каждого пакета (какой дата-центр переслал какой пакет через какой туннель)
• Исторические данные зондов проверки работоспособности за пределами срока хранения на панели управления

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

1. Тип проверки работоспособности: Если вы используете межсетевой экран с отслеживанием состояния (например, Palo Alto Networks, Check Point, Cisco или Fortinet), измените тип проверки работоспособности с Reply к Запрос.
2. Защита anti-replay: Отключите защиту от повторного воспроизведения (anti-replay) на маршрутизаторе или установите окно повторного воспроизведения равным 0.
3. настройки MTU: убедитесь, что MTU настроен правильно (обычно 1476 для GRE, 1400-1450 для IPsec).
4. Параметры IPsec: Убедитесь, что ваши криптографические параметры совпадают с Поддерживаемая конфигурация Cloudflare.
5. Направление проверки работоспособности: По умолчанию Cloudflare WAN использует Двунаправленный.
6. Правила Cloudflare Network Firewall (менее распространённые): Убедитесь, что трафик ICMP от IP-адреса Cloudflare ↗ разрешён.

Работоспособность сети ↗ странице в панели управления Cloudflare отображаются три состояния работоспособности туннеля:

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

Панель управления работоспособностью туннеля показывает состояние работоспособности для каждого дата-центра и каждого туннеля. Каждый дата-центр Cloudflare независимо отслеживает работоспособность каждого туннеля.

Еще одна частая путаница возникает из-за того, что на панели управления отображается надпись «100% degraded», которую ошибочно принимают за 100% потерю пакетов. Обратите внимание, что это разные вещи.

Когда возникает состояние degraded:

Если зонд проверки работоспособности не проходит, Cloudflare отправляет ещё два дополнительных зонда. Если часть зондов проходит успешно, а часть нет, туннель переходит в состояние degraded для этого дата-центра. Для такого перехода достаточно нескольких секунд периодической потери пакетов.

Что проверить:

Обратите внимание на дата-центры, которые показывают трафик в Объем трафика (1 ч) столбец. Дата-центр со статусом degraded при нулевом или минимальном трафике носит информационный характер: это указывает на проблему маршрута между конкретным дата-центром Cloudflare и вашей сетью, но не влияет на ваш трафик, если через этот дата-центр не проходит трафик.

Время восстановления:

Туннели остаются в состоянии Degraded как минимум пять минут, даже если проверки работоспособности сразу же начинают проходить успешно. Переход из Degraded в Healthy требует стабильного прохождения проверок работоспособности в течение длительного периода и может занять до 30 минут. Подробнее о том, как туннели переходят между состояниями, см. Поведение при восстановлении ниже.

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

• Degraded: Добавляет 500,000 в приоритет маршрута
• Down: Добавляет 1,000,000 в приоритет маршрута

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

Туннели переходят между состояниями асимметрично, чтобы предотвратить частые колебания состояния:

• Из исправного состояния в ухудшенное/отключенное: Быстро переключается при обнаружении сбоев. Туннель может перейти напрямую из состояния Healthy в состояние Down, если все повторные попытки зонда завершились неудачей.
• Из Down в Degraded: Требуется три последовательных успешных зонда проверки работоспособности.
• Из Degraded в Healthy: Требуется, чтобы частота сбоев была ниже 0.1% на протяжении 30 последовательных зондов.

Инструкции по мониторингу состояния туннеля см. в Проверить работоспособность туннеля в панели управления.

Тип проверки работоспособности:

Направление проверки работоспособности:

• Панель управления показывает туннель со статусом Down или Degraded
• Реальный пользовательский трафик успешно проходит через туннель
• Частота сбоев проверки работоспособности составляет 100%, несмотря на то что соединение работает

Брандмауэры с отслеживанием состояния (такие как Palo Alto Networks, Check Point, Cisco и Fortinet) отбрасывают пакеты проверки работоспособности. По умолчанию Cloudflare отправляет ICMP Reply пакеты в качестве зондов проверки работоспособности.

Брандмауэры с отслеживанием состояния проверяют эти пакеты и ищут соответствующий ICMP Запрос в своей таблице сессий. Если соответствующий запрос отсутствует, брандмауэры отклоняют такой ответ как «несоответствующий состоянию».

Изменить тип проверки работоспособности с Reply к Запрос:

1. Перейдите в Connectors страницу.

   Перейдите в Connectors ↗

2. В Туннели IPsec/GRE, выберите Изменить на затронутом туннеле.

3. В разделе Тип проверки работоспособности, измените с Reply к Запрос.

4. Выберите Обновите туннель.

Если вы используете Запрос проверки работоспособности Cloudflare отправляет ICMP echo request. Механизм проверки с отслеживанием состояния вашего брандмауэра распознаёт этот запрос как легитимный и автоматически пропускает ответ ICMP reply.

• Туннели были Healthy до включения Cloudflare Network Firewall
• После добавления правил Cloudflare Network Firewall проверки работоспособности завершаются ошибкой
• Блокировка трафика ICMP приводит к немедленным сбоям проверки работоспособности

Cloudflare Network Firewall обрабатывает весь трафик, включая пробы проверки работоспособности Cloudflare. Если вы создадите правило, блокирующее трафик ICMP, вы также заблокируете пакеты проверки работоспособности, которые Cloudflare отправляет для отслеживания состояния туннеля.

Добавьте правило Allow для ICMP-трафика с IP адресов Cloudflare до любые правила блокировки:

1. Перейдите в Политики Firewall страницу.

   Перейдите в Политики Firewall ↗

2. Создайте новую политику со следующими параметрами:

3. Расположите это правило до любые правила, блокирующие трафик ICMP.

Подробнее см. в Правила Cloudflare Network Firewall и проверки работоспособности конечных точек.

• Туннель IPsec часто переключается между состояниями healthy и down
• Периодическая потеря пакетов в туннеле
• Трафик работает некоторое время, а затем прекращается без изменений конфигурации
• В журналах маршрутизатора отображаются пакеты, отброшенные по следующим причинам:
  • "replay check failed"
  • "invalid sequence number"
  • "invalid SPI" (Security Parameter Index)

На маршрутизаторе включена защита anti-replay. В IPsec она рассчитана на то, что пакеты от одного отправителя будут приходить строго по порядку.

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

Отключите защиту anti-replay на маршрутизаторе:

Для большинства маршрутизаторов:

Найдите в настройках IPsec параметр anti-replay (защита от повторного воспроизведения) и отключите его.

Если вы можете задать только размер окна защиты от повторов:

Задайте для окна защиты от повторов значение 0 чтобы фактически отключить проверку.

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

Включите защиту от replay-атак в панели управления Cloudflare. Это направляет весь трафик туннеля через один сервер, сохраняя правильные порядковые номера, но за счёт потери преимуществ anycast.

1. Перейдите в Connectors страницу.

   Перейдите в Connectors ↗

2. В Туннели IPsec/GRE, выберите Изменить на вашем туннеле IPsec.

3. Включить Защита от повторного воспроизведения.

4. Выберите Обновите туннель.

Если маршрутизаторы Cisco IOS/IOS-XE выдают ошибку «invalid SPI»:

Включите восстановление ISAKMP после недействительного SPI, чтобы помочь маршрутизатору повторно синхронизировать ассоциации безопасности:

configure terminal
crypto isakmp invalid-spi-recovery
exit

Подробное объяснение того, зачем нужна эта настройка, см. в Защита anti-replay.

• Работоспособность туннеля падает до Degraded или Down периодически
• Проблемы совпадают с интервалами повторного согласования ключей IPsec (обычно раз в несколько часов)
• Туннель восстанавливается автоматически через 1-3 минуты
• В журналах маршрутизатора отображается успешное завершение процедуры rekey

Когда конечная точка туннеля инициирует rekey IPsec, новые Security Associations (SA) должны распространиться по сети Cloudflare. Задержки распространения rekey были значительно сокращены и в большинстве развертываний встречаются редко. Тем не менее в некоторых конфигурациях кратковременная деградация туннеля во время rekey все еще возможна.

Cloudflare никогда не инициирует rekey, а только отвечает на запросы. Все попытки rekey должны исходить от вашей конечной точки туннеля. Если ваше устройство получает ответ TEMPORARY_FAILURE во время rekey, для восстановления оно должно заново установить сеанс IKE.

Это ожидаемое поведение, туннель восстановится автоматически. Чтобы минимизировать влияние:

1. Настройте Dead Peer Detection (DPD) с перезапуском: Установите для действия DPD конечной точки туннеля значение "restart", чтобы сессия IKE автоматически восстанавливалась при сбое rekey с ошибкой TEMPORARY_FAILURE. Без DPD restart устройство может зависнуть в цикле неудачных rekey.

2. Увеличьте интервалы rekey: Настройте более длительное время жизни SA на конечной точке туннеля, чтобы снизить частоту rekey. Типичные значения: 8-24 часа для IKE SA и 1-8 часов для IPsec SA.

3. Настройте чувствительность проверки работоспособности: Если кратковременная деградация во время rekey вызывает срабатывание оповещений, рассмотрите возможность снижения частоты проверок работоспособности:

   1. Перейдите в Connectors страницу.
   Перейдите в Connectors ↗
   2. В Туннели IPsec/GRE, выберите Изменить на туннеле.
   3. Изменить Частота проверки работоспособности к Низкая.

4. Распределение времени rekey: Если у вас несколько туннелей, настройте разное время жизни SA, чтобы rekey не происходил одновременно для всех них.

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

Для двунаправленных проверок работоспособности запрос и ответ должны проходить через туннель в обе стороны. Ваш маршрутизатор должен:

1. Принимать пакеты ICMP, предназначенные для IP-адресов интерфейса туннеля
2. Направьте ответ ICMP обратно через туннель в Cloudflare

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

Для туннелей IPsec:

Настройте селекторы трафика, чтобы принимать пакеты для адресов туннельных интерфейсов. Например, если адрес туннельного интерфейса 10.252.2.27/31:

• Разрешите трафик к/от 10.252.2.26 (со стороны Cloudflare)
• Разрешите трафик к/от 10.252.2.27 (на вашей стороне)

Для всех типов туннелей:

Убедитесь, что ваш межсетевой экран разрешает трафик ICMP на интерфейсе туннеля. Многим межсетевым экранам требуются явные правила, разрешающие служебный трафик (включая ping) на интерфейсах туннеля.

Подробную информацию о работе двунаправленных проверок работоспособности см. в Проверки работоспособности туннеля.

• Статус туннеля показывает Down и никогда не становится исправным
• Трафик через туннель не проходит
• В журналах маршрутизатора отображаются сбои согласования IKE

Установление туннеля IPsec может завершиться ошибкой из-за нескольких несоответствий в конфигурации:

1. Убедитесь, что криптографические параметры соответствуют конфигурации, поддерживаемой Cloudflare:

   Фаза 1 (IKE)

Фаза 2 (IPsec)

2. Проверьте Pre-Shared Key (PSK):

   • Пересоздайте PSK в панели управления Cloudflare
   • Скопируйте новый PSK точно (без лишних пробелов или символов)
   • Обновите свой роутер с новым PSK

3. Проверьте формат IKE ID: Cloudflare использует формат FQDN для IKE ID. Убедитесь, что маршрутизатор настроен на приём идентификатора узла в формате FQDN. Значение FQDN отображается в сведениях о туннеле в дашборде Cloudflare.

4. Проверьте правила межсетевого экрана: Убедитесь, что пограничный межсетевой экран разрешает следующее:

   • UDP port 500 (IKE)
   • UDP port 4500 (IKE NAT-T)
   • Протокол IP 50 (ESP)

Полный список поддерживаемых параметров см. в Поддерживаемые параметры конфигурации.

• Проверки работоспособности стабильно завершаются ошибкой в туннелях IPsec на основе политик
• Трафик, соответствующий селекторам трафика туннеля (домен шифрования), проходит в обычном режиме
• Туннели на основе маршрутов на одном устройстве работают корректно

Туннели IPsec на основе политик используют traffic selectors, чтобы определить, какие префиксы разрешены в туннеле. Проверки работоспособности типа Reply направляются на собственные IP-адреса Cloudflare. Эти адреса выходят за пределы traffic selectors туннеля (которые разрешают только адреса назначения в сети клиента), поэтому конечная точка туннеля отбрасывает пакеты проверки работоспособности.

Кроме того, некоторые межсетевые экраны (например, Check Point) могут помечать пакеты проверки работоспособности в стиле Reply как поддельные из-за их самоадресованного характера, даже в туннелях на основе маршрутов.

1. Изменить тип проверки работоспособности с Reply к Запрос.
2. Настройте loopback-адрес на конечной точке своего туннеля в качестве цели проверки работоспособности. Цель должна быть:
   • Доступно для маршрутизации с конечной точки туннеля
   • Покрывается селекторами трафика туннеля (домен шифрования)
3. Для двунаправленных проверок работоспособности убедитесь, что источник проверки (адрес интерфейса туннеля, настроенный в дашборде Cloudflare) также охвачен селектором трафика.

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

1. Account ID и Имя(-я) туннеля затронуты
2. Временные метки (по UTC), когда возникла проблема
3. Сведения о конфигурации туннеля:
   • Тип туннеля (GRE или IPsec)
   • Тип проверки работоспособности (запрос или ответ)
   • Направление проверки работоспособности (двунаправленное или однонаправленное)
   • Частота проверки работоспособности (низкая, средняя или высокая)
4. Информация о маршрутизаторе:
   • Производитель и модель
   • Версия прошивки/ПО
   • Конфигурация IPsec (очищена от PSK)
5. Наблюдаемые симптомы:
   • Статус работоспособности туннеля в панели управления
   • Затронут ли трафик пользователей
   • Сообщения об ошибках из журналов маршрутизатора

• Захваты пакетов с вашего маршрутизатора, показывающие трафик туннеля
• Журналы маршрутизатора охватывающий период времени, в течение которого возникла проблема
• Traceroute результаты от вашей сети до конечных точек Cloudflare
• Скриншоты панели управления работоспособностью туннеля
• Распределенная трассировка с помощью таких инструментов, как ping.pe ↗ чтобы проверить доступность из нескольких точек по всему миру

Соберите вывод следующих команд (синтаксис зависит от производителя):

• IPsec SA status: show crypto ipsec sa
• Статус SA IKE: show crypto isakmp sa
• Статус интерфейса туннеля: show interface tunnel <number>
• Таблица маршрутизации: show ip route

• Проверки работоспособности туннеля: Технические сведения о поведении проверки работоспособности
• Защита anti-replay: почему необходимо отключить anti-replay
• Настройка конечных точек туннеля: Инструкции по настройке туннеля
• Проверить работоспособность туннеля в панели управления: Руководство по навигации в панели управления
• Network Analytics: Инструменты анализа трафика