Поиск и устранение неполадок оценки сетевых правил

Обзор

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

Симптомы

Неудача в оценке трафика по сетевым правилам может проявляться по-разному. Администратор может заметить следующие симптомы:

• Неправильный общедоступный IP-адрес источника
• Несоответствие сетевых правил
• Выбрана неправильная интерфейса WAN
• Ускорение TCP применяется или пропущено
• Несоответствие приоритета QoS
• Трафик разрывает связи для Вне Облака или Альтернативного WAN

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

• Несоответствие пользовательского или встроенного приложения
• Несоответствующий домен
• Неправильно выбран выходной PoP
• Нездоровые соединения WAN
• Заблокированное или неустановленное приложение приводит к фиксированному приоритету QoS
• Неправильный порядок сетевых правил

Первоначальная оценка

Просмотрите события брандмауэра, выбрав в CMA пресеты Межсетевой экран Интернета или Межсетевой экран WAN. Установите фильтры, чтобы сузить интересующий трафик. Анализируйте соответствующие поля, такие как Связанные приложения, Приложение, Приложение Cato, Имя выходного PoP, Общедоступный IP-адрес источника, IP-адрес назначения, Имя домена, Сетевое правило, и Ускорение TCP , которые помогут вам определить возможную основную причину проблемы.

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

• Веб-приложения могут сообщить общедоступный IP-адрес источника, отличный от того, который настроен в сетевом правиле. Если поля Имя выходного PoP и Общедоступный IP-адрес в событии фаервола не являются ожидаемыми, см. Поиск и устранение неполадок Неправильный общедоступный IP-адрес источника
• Проверьте, является ли поле Сетевое правило в событии фаервола ожидаемым. Если нет, продолжите с Поиск и устранение неполадок Несоответствие сетевых правил
• Если потоки трафика не используют настроенное основное WAN-соединение или они не сбалансированы, как настроено в основном транспортном разделе Сетевого правила, см. Поиск и устранение неполадок Выбрана неправильная интерфейса WAN
• Если поле ускорения TCP из события фаервола не является ожидаемым настроенным значением в сетевом правиле, см. Поиск и устранение неполадок, когда Ускорение TCP применяется или пропущено
• Если трафику присвоен неправильный Приоритет QoS 255 согласно событию фаервола, см. Поиск и устранение неполадок Несоответствие приоритета QoS
• Если TLS соединения не удаются, когда Вне Облака или Альтернативный WAN выбраны в качестве транспорта в сетевом правиле, см. Поиск и устранение неполадок Вне Облака или Alt-WAN прерывания трафиковых соединений 

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

Поиск и устранение неполадки Неправильный общедоступный IP-адрес источника

Существуют случаи, когда необходимо определить конкретный общедоступный IP-адрес источника для доступа к ограниченному Интернет-сервису, как описано в Как настроить правило выхода. Если служба сообщает о неожиданном общедоступном IP-адрес источника, выполните следующие шаги.

Просмотр нескольких выходных IP-адресов

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

В этом примере сетевое правило может направлять трафик из PoP Нью-Йорка или PoP Чикаго. Если источник физически ближе к PoP Нью-Йорка, Cato попытается направить специфический трафик из PoP Нью-Йорка. Если назначение недоступно из PoP Нью-Йорка, тогда Cato направляет трафик из PoP Чикаго.

Чтобы изменить это поведение, см. Изменение выбора PoP Исходящего трафика.

Недоступные IP-адреса исходящего трафика

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

Чтобы изменить это поведение, см. Изменение выбора PoP Исходящего трафика.

Проверка изменений сетевого правила

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

Вышеуказанное поведение обычно встречается с VoIP трафиком, когда поток SIP остается активным в течение длительного времени. Чтобы решить эту проблему, можно перезагрузить VoIP телефон, что вызовет создание нового потока SIP, который будет маршрутизироваться в соответствии с измененным исходящим IP сетевого правила.

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

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

Анализ событий файервола

Определите соответствующие поля, такие как Связанные приложения, Приложение, Приложение Cato, IP-адрес назначения, Имя домена и Сетевое правило из события файервола. Эта информация поможет вам устранить причину несоответствия сетевого правила.

Проверка исключений сетевого правила

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

Проверка пользовательского приложения

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

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

Проверка встроенного приложения

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

• Какие приложения настроены в 'неверно' совпадающем сетевом правиле.
• Присутствуют ли какие-либо из этих приложений в поле Связанные приложения из события файервола.

Идентификация приложения - это многоступенчатый процесс, который начинается с идентификации протокола, а затем всех возможных сопоставимых приложений, включенных в поле Связанные приложения. Любое приложение 'связанное приложение', идентифицированное в потоке, независимо от решения о конечном приложении (поле Приложение) будет совпадать с сетевым правилом.

В приведенном ниже примере доступ к portal.azure.com соответствует правилу №7 вместо правила №8. Это связано с тем, что правило №7 включает приложение Microsoft Azure (включено в Связанные приложения), даже если конечное приложение (поле Приложение) - это Azure Front Door.

Чтобы устранить это ожидаемое поведение, см. Порядок сетевых правил

Проверка имени домена

Если сетевое правило содержит объект доменного имени или FQDN, проверьте, что указано в поле Имя домена в событии файервола. Объект домена/FQDN в сетевом правиле должен точно совпадать с этим полем.

Имейте в виду, что FQDN - это точное совпадение полностью квалифицированного домена. Например, Полное доменное имя (FQDN) example.com соответствует только example.com.

С другой стороны, Домен - это домен верхнего уровня (TLD) или второго уровня (SLD), который соответствует всем поддоменам. Например, домен example.com соответствует www.example.com и host.example.com.

Могут возникнуть случаи, когда Cato не может определить правильное доменное имя из потоков HTTP, TLS или DNS. Чтобы решить эти типы проблем, см. Решение проблем с доменным именем

Устранение неполадок выбранного неправильного интерфейса WAN

Этот раздел описывает сценарий, когда Cato выбран в качестве транспорта с обоими интерфейсами WAN, настроенными в развертывании Active/Active. Для получения дополнительной информации о маршрутизации, основанной на политике, см. Как Cato выбирает лучший транспорт или соединение

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

Если требуется развертывание Active/Active, роль основного интерфейса должна быть установлена как Автоматический или обе роли основного и вторичного интерфейсов должны быть настроены, как показано на снимке экрана ниже. Установка роли вторичного интерфейса как Нет приведет к отсутствию перехода трафика, если основной интерфейс становится недоступным. См. Маршрутизация трафика через интерфейсы Socket

Просмотр сетевой аналитики

Виджет Средняя пропускная способность покажет среднюю активность полосы пропускания для каждого WAN-канала. Это может служить индикатором для подтверждения, что Сетевое правило выбирает правильное WAN-соединение или правильно балансирует трафик. На скриншоте ниже показано, что Сетевое правило было изменено для выбора WAN2 в качестве основного транспорта.

Важно контролировать производительность подключения через WAN-канал, особенно по утрате пакетов, джиттеру и расстоянию. Как объяснено в Активное/Активное распределение трафика, если одна ссылка не соответствует минимальным порогам качества канала, она будет считаться неисправной и не будет выбрана для распределения трафика, даже если канал WAN выбирается в качестве основного транспорта.

Обзор веб-интерфейса сокета

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

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

Проверка конфигурации WAN-канала

Если все активные/активные каналы находятся в порядке, проверьте конфигурацию пропускной способности для каждого WAN-канала в CMA. В приведенном ниже примере связь WAN1 сконфигурирована на пропускную способность 100 Мбит/с по входящему/исходящему трафику, а связь WAN2 - на 20 Мбит/с по входящему/исходящему трафику. Это приведет к отправке большего количества трафика на WAN1 в пропорции 100:20 или 5:1 для обоих направлений - входящего и исходящего.

Диагностика применения или пропуска ускорения TCP

Как обсуждалось в Объяснение ускорения TCP от Cato, ускорение TCP может быть включено в сетевом правиле для ускорения TCP-соединений через WAN. Эта функция обычно применяется в определенных сценариях, и администратор может не иметь возможности отключить ее, даже если в правиле снята галочка с опции Ускорение TCP. Этот раздел адресует те сценарии и объясняет, как отключить функцию, когда это необходимо.

Когда ускорение TCP применяется

Ускорение TCP будет применено, когда сетевое правило использует исходящий IP-адрес или исходящее местоположение. Это заставляет PoP действовать в качестве прокси, что в свою очередь обеспечивает ускорение TCP для всех потоков трафика, соответствующих правилу. Флажок в сетевом правиле будет неактивен.

Отключение ускорения TCP в сетевом правиле не отключит функцию в следующих случаях:

• Инспекция TLS включена для учетной записи, что приведет к активации ускорения TCP для всего TLS-трафика, даже если он обходит TLS. Это объясняется тем, что PoP должен выступать в роли прокси для инспекции трафика на предмет вредоносных файлов и угроз.
• Сложное сетевое правило существует выше соответствующего сетевого правила с отключенным ускорением TCP
• Сетевое правило, в котором отключено ускорение TCP, само по себе является сложным.

Сложное сетевое правило (также известно как NG правило) – это сетевое правило, которое сам Socket не может оценить. Следовательно, Socket должен отправить трафик на PoP, чтобы выбрать правильное сетевое правило, которое, в свою очередь, позволяет ускорение TCP. Он может содержать: Приложения, Категории приложений, Сервисы, Пользовательские приложения или Объекты Домен/Полное доменное имя.

С другой стороны, простое правило может содержать следующие сущности, которые могут быть оценены Socket и не требуют участия PoP:

• В поле Источник/Назначение: Площадки, IP-адреса, Сетевые интерфейсы, Диапазон IP-адресов или Любое.
• В поле Приложение/Категория: Диапазон портов или Пользовательский сервис.

Когда Пропущено ускорение TCP

Ускорение TCP будет применяться только к TCP-трафику. В случае, если Ускорение TCP включено в сетевом правиле или применяется, как объяснено в предыдущем разделе, но поле Ускорение TCP в событии CMA равно 0, возможно, что асимметричная маршрутизация через облако Cato вызывает обнаружение потока трафика как Открытый режим.

Как объясняется в Асимметричная маршрутизация через Cato, Открытый режим — это режим соединения, в котором облако Cato не знает о начале потока TCP (3-фазное рукопожатие), что предотвращает применение TCP-ускорения. Мы рекомендуем работать с Поддержка Cato, чтобы определить основную причину создания потоков в Открытом режиме.

Отключение Ускорение TCP

Чтобы отключить ускорение TCP, простое правило без Исходящего IP или местоположения может быть размещено на вершине базы сетевых правил, как описано в Порядок сетевых правил. Как упоминалось выше, если трафик является TLS, инспекция TLS должна быть отключена для всей учетной записи.

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

Как объясняется в Когда потоку присваивается приоритет QoS 255, могут быть случаи, когда приоритет QoS, настроенный в сетевом правиле, отличается от приоритета, показанного в событии FW.

QoS приоритет 255 называется приоритетом по умолчанию для управление полосой пропускания. Существует несколько причин, почему потоку может быть присвоен приоритет QoS 255, независимо от конфигурации приоритета полосы пропускания в сетевом правиле:

• Cato оценивает сетевой профиль для каждого потока, и приоритет QoS 255 назначается, когда специфическое приложение еще не определено.
• Первые пакеты (до того, как поток идентифицирован) назначаются с приоритетом QoS 255.
• Заблокированные потоки назначаются с приоритетом QoS 255.

Устранение неполадок в соединениях трафика вне Облака или Alt-WAN  

В этом разделе рассматривается сценарий, когда TLS соединения не удается установить между сайтами, когда сетевое правило WAN настроено с использованием Вне Облака или Alt-WAN в качестве основного транспорта. Для устранения неполадок выполните следующие шаги.

Анализ потоков

Когда трафик корректно маршрутизируется через Вне Облака или Alt-WAN, потоки трафика не создадут событий FW в CMA, так как этот трафик не проходит через PoP.

Один из способов подтвердить, что трафик успешно маршрутизируется через Вне Облака или Alt-WAN, это вкладка SDWAN в веб-интерфейсе сокета. Определите активный поток трафика и в разделе Выбранный NIC вы увидите выбранный транспорт для интересующего трафика. Если ожидаемый транспорт не выбран, подтвердите, что Вне Облака или Alt-WAN настроены правильно.

Проверка порядка Сетевых Правил

Как объяснено в Сбой Подключения TLS через Вне Облака или Alt-WAN Линки, когда трафик использует TLS и инспекция TLS включена, порядок Сетевых Правил является важным фактором для обеспечения потока трафика по Вне Облака или Alt-WAN линкам.

Сокеты не могут оценивать сетевые правила и маршрутизировать пакеты через Вне Облака или Alt-WAN, когда правило, которое затрагивает трафик, находится ниже сложного правила. Чтобы устранить такую ожидаемую поведения, см. Порядок Сетевых Правил

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

Решение проблемы пересекающегося пользовательского приложения

Убедитесь, что пользовательское приложение включает правильные IP-адреса, домен, порт и протокол. Логики в выборе пользовательского приложения для идентификации нет, поэтому пользовательское приложение должно быть уникально определено для избежания пересечения с другим пользовательским приложением. Чтобы получить дополнительную информацию, см. Работа с пользовательскими приложениями

Порядок сетевых правил

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

На скриншоте ниже Правило №1 содержит пользовательский сервис, который включает диапазоны IP для twitter.com, и размещено выше Правила №2, которое содержит категории приложений. Правило №1 более специфично, чем Правило №2, и будет лучше соответствовать трафику, направленному на twitter.com. Это дополнительно отключит ускорение TCP и решит любые проблемы маршрутизации Вне Облака или Alt-WAN, так как правило №1 является простым правилом.

Решение проблем с доменными именами

Проблемы сопоставления сетевых правил на основе доменов/полного доменного имени FQDN можно разрешить следующим образом:

• Для таких протоколов, как HTTP/S, Cato может определить домен назначения, используя следующие источники:

  • Заголовок имени хоста HTTP (при включенной инспекции TLS)

  • Поле SNI во время рукопожатия TLS

  • Разрешение DNS, где имя домена узнаётся из DNS-запросов и ответов

• Важно убедиться, что домен, указанный в Сетевом правиле, соответствует всем этим источникам. Примечание: отображается только лучшее соответствующее имя домена (оцененное сверху вниз) в событиях Файервола как Имя домена. 

• Для других протоколов, таких как SSH или SMB, которые не передают домен в открытом виде, Cato полагается исключительно на перехват DNS для ассоциации трафика с доменом или Полным доменным именем (FQDN). Это особенно критично при использовании частного DNS, так как необходимо гарантировать, что DNS-запросы/ответы проходят через Cato. См. Лучшие практики для DNS и вашей учетной записи Cato

Изменение выбора точки присутствия PoP для исходящего трафика

Если вы хотите маршрутизировать все исходящие правила для учетной записи через точку присутствия PoP, которая находится ближе к пункту назначения, а не к источнику (поведение по умолчанию), пожалуйста, свяжитесь со службой поддержки Cato Networks, создав запрос в поддержку Cato.

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

Если другой VoIP протокол или любое другое Приложение требует всегда использовать тот же Исходящий IP, пожалуйста, свяжитесь с Поддержкой Cato Networks, отправив тикет в Поддержку Cato.

Отправка тикета в Поддержку Cato

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

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