← Cloudflare One / cloudflare-one / troubleshooting / wan

IPsec

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

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

Возможно, ваш периметровый межсетевой экран блокирует трафик, необходимый для установления туннеля IPsec. Убедитесь, что межсетевой экран разрешает:

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

Согласование IKE завершается ошибкой, если параметры фазы 1 (IKE) или фазы 2 (IPsec) не совпадают между конечной точкой вашего туннеля и Cloudflare. Типичный симптом: ошибки «no proposal chosen» в журналах вашего устройства.

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

Сбои аутентификации на этапе 1 указывают на несовпадение PSK. Чтобы устранить проблему:

1. Перейдите в Connectors и выберите свой туннель.

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

2. Выберите Создать новый PSK.

3. Скопируйте новый PSK точно, не добавляя лишних пробелов или символов.

4. Обновите конечную точку своего туннеля с новым PSK.

Cloudflare использует для IKE ID формат FQDN. Если конечная точка вашего туннеля ожидает другой формат peer identity (например, IP-адрес), аутентификация завершится ошибкой, даже если PSK указан верно.

Убедитесь, что конечная точка вашего туннеля настроена на прием идентификатора узла в формате FQDN. Чтобы найти FQDN своего туннеля, перейдите в Connectors, выберите туннель и проверьте его данные.

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

Это самая распространённая проблема IPsec. Защита от повторного воспроизведения (anti-replay) ожидает, что пакеты от одного отправителя будут поступать по порядку. Из-за anycast-архитектуры Cloudflare туннельный трафик исходит от тысяч серверов, у каждого из которых свой счётчик последовательности. Это приводит к тому, что конечная точка вашего туннеля отбрасывает пакеты как поступившие не по порядку.

Отключите защиту anti-replay на конечной точке туннеля или задайте окно повторов равным 0. Подробное объяснение см. в Защита anti-replay.

Брандмауэры с отслеживанием состояния (такие как Palo Alto Networks, Check Point, Cisco и Fortinet) отбрасывают стандартный Reply пакеты проверки работоспособности, поскольку в их таблице сессий нет соответствующего ICMP-запроса.

Изменить тип проверки работоспособности с Reply к Запрос. Подробные шаги см. в Устранение неполадок состояния туннеля.

При односторонних проверках работоспособности Cloudflare отправляет зонды через туннель, но ответы возвращаются через публичный интернет (Direct Server Return). Если ваш интернет-провайдер блокирует ICMP-пакеты, отправляемые в ответ Cloudflare, проверки работоспособности завершаются ошибкой, даже если трафик туннеля работает нормально.

Если у вас включён исходящий трафик, рассмотрите переход на двунаправленные проверки работоспособности, чтобы и зонд, и ответ проходили через туннель. Подробности настройки см. в Устранение неполадок состояния туннеля.

Если вы используете VPN на основе политик (где селекторы трафика задают конкретные префиксы, а не 0.0.0.0/0), проверки работоспособности в стиле Reply не работают. Reply-проверки работоспособности адресованы самим себе на IP-адреса Cloudflare, которые находятся вне селекторов трафика вашего туннеля.

Вместо этого используйте проверки работоспособности в стиле Request. Настройте loopback-адрес на конечной точке туннеля в качестве цели проверки работоспособности. Цель должна быть маршрутизируемой и охватываться селекторами трафика туннеля (доменом шифрования). Дополнительные сведения см. в Устранение неполадок состояния туннеля.

• Туннель поочерёдно переходит в состояния healthy и нездоровое
• Периодическая потеря пакетов в туннеле
• Трафик работает некоторое время, а затем прекращается без изменений конфигурации

Из-за anycast-архитектуры Cloudflare пакеты приходят с разных серверов с разными счетчиками последовательности. Защита от replay-атак воспринимает это как replay-атаку и периодически отбрасывает пакеты.

Отключите защиту anti-replay на конечной точке туннеля или задайте окно повторов равным 0. Подробное объяснение см. в Защита anti-replay.

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

Cloudflare никогда не инициирует rekey, а только отвечает на запросы. Все попытки rekey должны исходить от вашей конечной точки туннеля. Если ваше устройство получает ответ TEMPORARY_FAILURE во время rekey, настройте Dead Peer Detection (DPD) с действием «restart», чтобы устройство автоматически восстанавливало сеанс IKE. Без перезапуска DPD устройство может застрять в цикле неудачных попыток rekey.

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

Пакеты, превышающие MTU туннеля, фрагментируются или отбрасываются, что вызывает перебои с подключением. Убедитесь, что MTU задан правильно: обычно 1476 для туннелей GRE и 1400-1450 для туннелей IPsec. Подробные инструкции см. в MTU и MSS.

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

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

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

2. Выберите Создание задания Logpush.

3. Выберите Журналы IPsec в качестве набора данных.

См. документация Logpush с дополнительной информацией о функциях, включая доступные поля в наборе данных.

Дополнительные сведения см. в полной документации по Cloudflare WAN.