Трафик с перебоями не соответствует правилам файервола

Проблема

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

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

Устранение неисправностей

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

1. Асимметричная маршрутизация

Когда Cato не имеет видимости полного потока, ему может не хватать необходимой информации для точной классификации данных в соответствующее приложение. Следовательно, даже если есть правило файервола, разрешающее определённый протокол, например HTTPS, асимметричная маршрутизация может привести к ошибочной классификации потока как TCP. К сожалению, эта ошибочная классификация может привести к блокировке соединения, так как оно не соответствует разрешённому правилу файервола. Для дальнейшего расследования рекомендуется выполнить трассировку маршрута как от источника до пункта назначения, так и в обратном направлении, когда возникает проблема. Сравнив прямые и обратные пути, мы можем подтвердить, является ли это действительно причиной проблемы.

2. Перекрывающиеся пользовательские приложения

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

3. Задержка осведомленности пользователей

Когда пользователь впервые подключается к сети Cato, механизмы осведомленности о пользователе на основе AD и Identity-Agent требуют несколько секунд, чтобы сопоставить исходный IP-адрес с соответствующим именем пользователя. В течение этого короткого периода начальный пользовательский трафик может обрабатываться по неожиданному правилу межсетевого экрана. Однако, как только осведомленность о пользователе успешно идентифицирует имя пользователя, будет применено соответствующее правило межсетевого экрана.

4. Полное доменное имя в правиле

Ещё один распространённый сценарий, когда внешне похожие соединения обрабатываются Cato по-разному (блокируются или разрешаются), это использование полных доменных имён (FQDN) в правилах файервола или в пользовательской категории/приложении. Прежде чем углубляться в детали, давайте рассмотрим два события. Оба источника имеют один и тот же IP-адрес источника и направлены на один и тот же IP-адрес и порт, но с разными результатами - одно разрешено, другое заблокировано.

Просмотр правил файервола

В приведённом примере соединение либо блокируется, либо разрешается на основе правила WAN файервола.

Для дальнейшего расследования выполните следующие действия:

• Перейдите в раздел WAN файервола в СМС и найдите соответствующие правила.

• Становится очевидным, что правило 1 соответствует событию мониторинга (Разрешить). Это правило специально разрешает подключения, классифицируемые как "Внутренние веб-серверы". Кликнув по правилу, вы увидите, что "Внутренние веб-серверы" являются частью пользовательской категории.

• В отличие от него, правило 5 соответствует событию блокировки. Она предназначена для блокировки HTTP(s) трафика и других сервисов.

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

• Перейдите в Ресурсы > Категории > Пользовательские категории

• В списке пользовательских категорий найдите и выберите категорию "Внутренние веб-серверы".

• В подробностях категории наблюдается, что член категории "Внутренние веб-серверы" соответствует полному доменному имени (FQDN) webserver.dyow-homelab.com.

• Это означает, что разрешено соответствие соединений с FQDN. (Для того чтобы Cato правильно идентифицировала имя хоста, мы должны просмотреть запрос/ответ DNS)
  

• Любое соединение, не соответствующее точному FQDN, будет отклонено. Например, если посещаемый веб-сайт включает "www", то www.webserver.dyow-homelab.com (согласно DNS-запросу) не совпадет с определённым полным доменным именем (FQDN) в CMA. Чтобы решить эту проблему, можно определить объект домена вместо этого. Это позволит соответствовать всем поддоменам, которые включают определённый домен. Дополнительную информацию см. в Cato WAN Firewall.
  
• В приведенном выше примере заблокированного соединения пользователь попытался получить доступ к серверу, используя его IP-адрес назначения вместо полного доменного имени. В данном случае из-за отсутствия запроса/ответа DNS, Cato не смог определить имя хоста, и правило не сработало.
• В ситуациях, когда происходит прямой доступ по IP без предшествующего запроса DNS, Cato использует свой DNS-кэш, чтобы попытаться сопоставить домен с заданным IP. Если в кэше отсутствуют домены, Cato будет не в состоянии связать его с именем хоста или полным доменным именем. В результате соединение в вышеприведенном примере будет заблокировано.
• Следовательно, когда правило межсетевого экрана «Разрешить» настроено для соответствия на основе Полного доменного имени (FQDN), клиент должен получить доступ к серверу, используя его доменное имя, чтобы обеспечить непрерывное подключение.
  
  Примечание: Если вы используете внутренний DNS-сервер, убедитесь, что все его DNS-запросы маршрутизированы через Cato Cloud, независимо от настроенного целевого домена. Для рекомендаций по DNS обратитесь к Лучшие-практики-для-DNS-и-вашей-учетной-записи-Cato 

Альтернативные решения

В случае, если ошибки правила брандмауэра продолжают возникать, даже после доступа на сайт с помощью имени домена и DNS-запросы/ответы действительно проходят через Cato, могут быть реализованы следующие решения:

• DNS-кэш на ПК пользователя может отличаться от DNS-кэша в точке присутствия PoP, что приведет к тому, что Cato не сможет связать IP-адрес сервера с полным доменным именем. В случаях, когда используется внутренний DNS-сервер, время жизни (TTL) DNS может быть сокращено, и поэтому ПК будет вынужден чаще генерировать DNS-запросы.
• Используйте комбинацию IP/порта в пользовательском приложении/категории, используемой в правиле брандмауэра, которое соответствует серверу. В приведенном выше примере настройте пользовательское приложение на IP-адрес 192.168.2.25 и порт 8080. Это позволит принудительно выполнять соответствие правила, даже если есть несоответствия в DNS-кэше или отсутствуют DNS-запросы через облако Cato.