Проблема
Эта статья описывает причину, по которой, несмотря на переход к одной и той же цели, некоторые соединения блокируются Cato, а другие разрешаются.
Например, ниже представлено обнаружение событий, где один и тот же источник пытался подключиться к одному и тому же IP-адресу назначения по тому же протоколу. Однако, в то время как одно соединение было заблокировано, другое было разрешено.
Устранение неполадок
В этом разделе мы рассмотрим несколько распространённых сценариев, которые могут привести к тому, что соединение будет обрабатываться Cato по-разному. Понимание этих сценариев имеет важное значение для оптимизации и эффективного устранения неполадок с подключением. Давайте подробно рассмотрим каждый из них ниже.
1. Асимметричная маршрутизация
Когда Cato не имеет видимости полного потока, ему может не хватать необходимой информации для точной классификации данных в соответствующее приложение. Следовательно, даже если есть правило файервола, разрешающее определённый протокол, например HTTPS, асимметричная маршрутизация может привести к ошибочной классификации потока как TCP. К сожалению, эта ошибочная классификация может привести к блокировке соединения, так как оно не соответствует разрешённому правилу файервола. Для дальнейшего расследования рекомендуется выполнить трассировку маршрута как от источника до пункта назначения, так и в обратном направлении, когда возникает проблема. Сравнив прямые и обратные пути, мы можем подтвердить, является ли это действительно причиной проблемы.
2. Перекрывающиеся пользовательские приложения
При работе с соединением, влияющим на пользовательское приложение, важно провести тщательную проверку его определения. Слишком упрощённое определение пользовательского приложения может привести к непоследовательному определению приложения Cato. Если есть правило файервола, разрешающее подключения к пользовательскому приложению, но из-за того, как оно определено, его идентификация становится непоследовательной, что приводит к периодической блокировке соединения. Поэтому, когда вы работаете с подключениями, предназначенными для пользовательских приложений, мы рекомендуем следовать лучшим практикам, изложенным в Работа-с-Пользовательскими-Приложениями, чтобы обеспечить единообразное поведение.
3. Задержка осведомленности пользователей
Когда пользователь впервые подключается к сети Cato, механизмы осведомленности о пользователе на основе AD и Identity-Agent требуют несколько секунд, чтобы сопоставить исходный IP-адрес с соответствующим именем пользователя. В течение этого короткого периода начальный пользовательский трафик может обрабатываться по неожиданному правилу межсетевого экрана. Однако, как только осведомленность о пользователе успешно идентифицирует имя пользователя, будет применено соответствующее правило межсетевого экрана.
4. Тайм-аут идентификации приложения (HTTP/1.1)
Современные браузеры открывают несколько TCP соединений одновременно через HTTP/1.1 для улучшения производительности загрузки страницы. Некоторые из этих соединений остаются неактивными ненадолго после установки — сразу не отправляется HTTP запрос, что означает, что имя хоста назначения еще не видно. Когда Cato обрабатывает трафик через сайт Socket, он оценивает каждое соединение по мере его поступления. Если имя хоста назначения отсутствует во время оценки, трафик не будет совпадать ни с одним из правил фаервола, которые используют FQDN или Домен в качестве условия совпадения, даже если такое правило правильно настроено.
Это ожидаемое поведение, характерное для трафика HTTP/1.1, обрабатываемого через сайт Socket (режим офисной работы). Это не происходит с клиентом SDP, который предоставляет контекст назначения перед тем, как трафик будет перенаправлен. Ниже представлены условия, которые могут привести к этой проблеме:
Только HTTP веб-сайт
Браузер открывает запасное TCP-соединение (поведение HTTP/1.1 – Chrome открывает до 6 параллельных соединений)
На этом запасном соединении не отправляется запрос HTTP GET в течение 1 секунды
Предлагаемое решение
Если вы используете Firefox, вы можете установить
network.http.max-persistent-connections-per-serverна 1 вabout:configОбновите правило фаервола, чтобы использовать IP-адрес назначения вместо FQDN/Домен.
Альтернативно, если сервер назначения это поддерживает, HTTP/2 устраняет это поведение, так как использует одно мультиплексированное соединение и не открывает неактивные параллельные TCP-соединения.
5. Полное доменное имя в правиле
Ещё один распространённый сценарий, когда внешне похожие соединения обрабатываются 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 обратитесь к Лучшие-Практики-для-DNS-и-вашей-учетной-записи-Cato
Альтернативные решения
В случае, если ошибки правила брандмауэра продолжают возникать, даже после доступа на сайт с помощью имени домена и DNS-запросы/ответы действительно проходят через Cato, могут быть реализованы следующие решения:
DNS-кэш на ПК пользователя может отличаться от DNS-кэша в точке присутствия PoP, что приведет к тому, что Cato не сможет связать IP-адрес сервера с полным доменным именем. В случаях, когда используется внутренний DNS-сервер, время жизни (TTL) DNS может быть сокращено, и поэтому ПК будет вынужден чаще генерировать DNS-запросы.
Используйте комбинацию IP/порта в пользовательском приложении/категории, используемой в правиле брандмауэра, которое соответствует серверу. В приведенном выше примере настройте пользовательское приложение на IP-адрес 192.168.2.25 и порт 8080. Это позволит принудительно выполнять соответствие правила, даже если есть несоответствия в DNS-кэше или отсутствуют DNS-запросы через облако Cato.