Устранение неполадок подключения площадки IPsec

Обзор

Подключение имеет первостепенное значение для доступа к WAN через облако Cato для сетей за IPsec. Отсутствие подключения IPsec площадки может нарушить бизнес-функции. Этот план действий имеет целью направить устранение неполадок в этом сценарии.

Симптомы

Сбой в подключении IPsec может быть определен следующими способами. Администратор может заметить следующие симптомы:

IPsec Сайт отключен в CMA
История нестабильности соединения
Низкая производительность трафика, проходящего через соединение IPsec

Возможные причины

Ниже перечислены возможные причины, которые вы можете выявить в процессе устранения неполадок.

Подключение пиров
- Это включает в себя возможность для пиров достигать друг друга стабильно по L3 подоснове.
Несоответствие конфигурации IPsec
- Несоответствие наборов преобразований или Аутентификация может привести к тому, что Туннели вовсе не будут сформированы или будут провалены до завершения ключевого обновления
Производительность подосновы
- IPsec полагается на стабильное подосновное соединение для удовлетворительной производительности внутри туннеля.

Примечание: Для учетных записей с IPsec сайтами, если внешние IP-адреса правила RPF пересекаются с IP-адресами IPsec сайта, убедитесь, что правило исключает порты туннеля IPsec UDP/500 и UDP/4500.

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

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

Устранение неполадок отключенной или нестабильной площадки IPSec в CMA

Сбор информации из событий

Используя Главная > Страница событий в CMA, администратор может быстро получить историю событий соединения для сайтов IPsec в аккаунте. События можно отфильтровать до релевантных, выбрав предустановку 'Статус подключения сайтов' или отфильтровав по типу события 'Подключение' и подтипу 'Отключено'. Также вы можете отфильтровать по имени целевого сайта с полем 'Исходный сайт' или использовать значение протокола туннеля 'IPSEC' для фильтрации всех сайтов IPsec.

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

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

Просмотр истории соединений сайта IPsec

ВАЖНО: Если этот файл недоступен в CMA (файл не найден), это означает, что Фаза 1 (или IKE_SA в IKEv2) не была согласована с удаленным пиром. Убедитесь, что параметры IKE и аутентификации совпадают между двумя пирами.

Временная шкала, доступная в Сеть > Сайт > Настройки сайта > IPsec важна для устранения неполадок отключенных сайтов IPsec.

CSV файл, предоставленный кнопкой Хронология, даст историю соответствующих журналов туннеля. Эти журналы могут предоставить ясные индикации проблем, которые могут вызывать отсутствие соединения в соединении IPsec. Типичные примеры индикационных сообщений приведены ниже:

Сообщения, указывающие, что селекторы трафика не совпадают, свидетельствуют о несоответствии конфигурации между параметрами фазы 2 пиров, особенно что касается подсетей, которые будут доступны на каждой стороне IPsec соединения. Если вы видите ошибки, которые это предполагают, перейдите к Устранение несоответствия конфигурации IPsec.

Указанные выше сообщения также указывают на несоответствие конфигурации, на этот раз с нагрузками аутентификации. Конечно, для успешного соединения PSK должен соответствовать этим нагрузкам. Если это очевидно в любой попытке соединения, перейдите к Устранение несоответствия конфигурации IPsec.

Временная шкала выше показывает попытку соединения с настроенным пиром, который не получил ответа. Можно видеть в этой шкале времени, что никакого взаимодействия с пиром не произошло, и SA была закрыта из-за неактивности. Это обычно происходит, если отсутствует доступность L3 к удаленному пиру. В этих случаях ознакомьтесь с Устранение проблем с подключением пиров.

Полный список возможных сообщений об ошибках хронологии для IKEv1 и IKEv2 можно найти Вставьте отпечаток сертификата 40 символов.

Использование захватов пакетов для устранения неполадок

Примечание: при захвате пакетов IP PoP, который вы настроили для туннеля, будет скрыт за внутренним IP 10.x.y.z.

Также, на странице Сеть > Сайт > Настройки Сайта > IPsec находится инструмент захвата пакетов. Это поможет предоставить трассировку пакетов управляющего трафика между пирами. Вышеупомянутые проблемы также представлены в этих захватах пакетов.

TS_UNACCEPTABLE

Для не совпадающих подсетей в наборе преобразований информационные пакеты сообщат об ошибке. В этом примере IKEv2 информационное сообщение TS_UNACCEPTABLE является симптоматическим для несоответствия в конфигурации в наборе преобразований. Чтобы исправить эту проблему, перейдите по ссылке Решение несоответствия конфигурации IPsec.

NO_PROPOSAL_CHOSEN

Для несовпадающих параметров в ассоциации безопасности любые пиры будут включать ошибку в полезную нагрузку. В этом примере IKEv2 ошибка NO-PROPOSAL-CHOSEN четко указывает на то, что один из алгоритмов или группы DH, настроенные в CMA, не соответствуют конфигурации удаленного пира. Это может произойти во время начального установления туннеля или процесса повторного ключа.

AUTHENTICATION_FAILED

Ниже приведен другой пример IKEv2, в данный момент, в котором использованный для аутентификации PSK не совпал:

Односторонние Пакеты

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

В любом из вышеперечисленных случаев или других индикаторов несоответствия конфигурации между пирами в IKEv1 или IKEv2 перейдите на страницу Разрешение несоответствия конфигурации IPsec.

Устранение неполадок низкой производительности через VPN

Если на VPN наблюдается низкая производительность, это обычно выражается в потере пакетов, высокой задержке или частых отключениях.

Потеря пакетов будет видна на трафике, проходящем через туннель по приложениям, на которые она влияет, и может быть подтверждена тестированием ICMP-зондами от одного хоста к другому через IPsec-соединение.

Задержка и отключения туннеля также будут заметны в производительности приложений и могут быть определены через страницу Сеть > Мониторинг Сайта > Сетевая аналитика для конкретного сайта.

Если проблемы с производительностью обнаружены, перейдите на страницу Разрешение проблемы производительности подложки.

Потеря пакетов в Azure IPSec

При настройке IPSec с Azure пропускная способность туннеля и пакетов в секунду (PPS) определяются SKU VPN-шлюза и используемыми алгоритмами шифрования. Например, согласно документации Microsoft, шлюз VpnGw3 Generation2 при использовании GCMAES256 может обрабатывать до 140 000 пакетов в секунду (PPS).

Если трафик превышает эти пороги, Azure автоматически сбрасывает избыток пакетов, что может привести к заметному ухудшению производительности. Одним из распространенных симптомов является снижение пропускной способности, что может отражаться в сетевой аналитике CMA как падение объема трафика. Однако более точным способом диагностики этого является мониторинг метрик VPN-шлюза непосредственно в портале Azure, который предоставляет информацию в реальном времени о пропускной способности туннеля и значениях PPS для подключенного VPN.

Чтобы смягчить эту проблему, вы можете рассмотреть возможность обновления до более высокого SKU IPSec или развертывания Azure vSocket, которые могут увеличить емкость вашего VPN-туннеля и предотвратить потерю пакетов из-за перегрузки трафика.

Разрешение обнаруженных проблем

Разрешение подключения пира

В ситуациях, когда IPsec-пир не отправляет пакеты на PoP, как это демонстрируется через записи хронологии или захваты пакетов, убедитесь, что удаленный пир настроен на подключение к тому же IP-адресу, который был выделен туннелю в CMA.

Если эта конфигурация подтверждена, убедитесь, что удаленный пир может пересекать соединения, ограниченные NAT, отвечая на трафик на порту 4500, а также на порту 500. NAT-T (траверсирование NAT) должен быть включен на удаленном пире.

Если удаленное пир-устройство настроено на ответ на запросы ICMP через интернет, вы также можете протестировать его общую доступность, проверив ICMP-запросы к публичному IP-адресу устройства.

Проверка изменений состояния страницы - Если PoP испытывает проблемы, это может повлиять на туннель IPsec (каждый туннель подключен к одному Расположение PoP Cato). Вы можете мониторить Состояние PoP Cato на странице статуса.

Если удаленная сторона является облачным провайдером, например Azure или AWS, вы также можете проверить их страницы статуса.

Если устройство пира по-прежнему недоступно для этого Соединение IPsec, обратитесь к администратору, чтобы убедиться, что он общедоступен для Соединения IPsec.

Решение несоответствия Конфигурация IPsec

Убедитесь, что конфигурация пира для набора преобразований соответствует конфигурации на Сайт > IPsec странице.

Чтобы настроить сторону Cato в пировании, чтобы она соответствовала специфическому набору преобразований от пира, Редактировать конфигурацию, как описано в прикрепленной документации для IKEv1 и IKEv2.

Диапазоны IP (селекторы) на обеих сторонах туннеля должны совпадать. В CMA убедитесь, что диапазоны IP настроены следующим образом:

Локальные Диапазоны IP (Сторона Пира): Перейдите в Настройки Сайта > Сети и определите подсети, находящиеся за пиром IPsec (например, файервол или маршрутизатор).
Удаленные Диапазоны IP (Сторона Cato): Перейдите в Настройки Сайта > IPsec > Маршрутизация и определите локальные диапазоны IP, разрешенные для прохождения через туннель (обычно сети с других сайтов). Если это поле не настроено, туннель рассматривается как VPN на основе маршрутов с неявными селекторами 0.0.0.0 <> 0.0.0.0.

Некоторые поставщики требуют, чтобы все подсети, включенные в набор преобразований, были включены только в одно сообщение о наборе преобразований. Если это так для пира, администратор должен использовать расширенный параметр конфигурации 'IKEv2 Отправить Один TS за полезную нагрузку' в разделе Сайт > Расширенная конфигурация.

Решение Производительность туннеля

Целью для разрешения производительности туннеля является изолирование производительности от удаленного пользователя.

Проверьте способность удаленного пользователя ping публичных веб-серверов, таких как 8.8.8.8. Если задержка или потеря пакетов согласуется с туннелем, можно сделать вывод, что проблема существует в среде удаленного пользователя.

Повышение запросов в Поддержка Cato

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

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