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

Обзор

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

Симптомы

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

  • Доменное имя внутреннего сервера не может быть разрешено
  • Внутренний сервер недоступен
  • Несоответствие правила брандмауэра WAN
  • Клиенты SDP не могут получить доступ к внутренним ресурсам
  • Ресурс удаленной переадресации портов (RPF) недоступен
  • Хост мониторинга LAN недоступен

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

  • Проблемы с маршрутизацией
  • Ошибочная конфигурация перенаправления DNS
  • Ошибочная конфигурация брандмауэра WAN
  • Перекрытие с сетью Клиента SDP
  • Вмешательство безопасности
  • Проблемы с подключением хоста назначения

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

Примечание

Примечание: Убедитесь, что у вас есть правило брандмауэра WAN (даже временно созданное для устранения неполадок) с включённым отслеживанием событий.

Для решения проблем, связанных с доступом к внутренним серверам через Доступ через Браузер, обратитесь к статье Устранение неполадок доступа через браузер

Просмотрите события брандмауэра WAN, IPS и Антивируса, выбрав соответствующий предустановленный режим в CMA. Установите фильтры, чтобы сузить круг интересующего трафика и проверьте, был ли поток заблокирован брандмауэром WAN или механизмами IPS/AM. Поле правило покажет соответствующее правило, которое соответствует трафику.

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

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

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

Проверка журналов аудита

Проверьте журнал аудита на наличие измененных журналов, которые могли повлиять на доступ к внутренним ресурсам. Это включает в себя правила брандмауэра WAN, настройки AM/IPS и проверку TLS.

Устранение проблем разрешения доменных имен серверов

Проверка разрешения DNS

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

В вашей учетной записи могут быть два сценария для разрешения внутреннего DNS:

  • Если в организации используется IP-адрес частного DNS-сервера, подтвердите, могут ли затронутые пользователи достигать DNS-сервера внутри сети. Если нет, устраните неполадки подключения к DNS-серверу, аналогично Устранению проблем с недоступным внутренним сервером
  • Если в учетной записи используются стандартный сервер DNS Cato 10.254.254.1, определенный учетной записью сервер DNS или хорошо известный публичный DNS (8.8.8.8, 1.1.1.1 или 9.9.9.9), переходите к устранению неполадок перенаправления DNS на следующем этапе.

Проверка перенаправления DNS

Потоки трафика, которые зависят от внутренних доменных имен (например, pc1.domain.net), должны иметь правильно настроенное перенаправление DNS в CMA. Также важно, чтобы Cato перехватывал потоки DNS, чтобы иметь возможность правильно разрешать доменные имена.

Перенаправление DNS может работать только в том случае, если DNS-запросы направлены на определенные серверы DNS, как объясняется в Устранение проблем перенаправления DNS.

Устранение проблем с недоступным внутренним сервером

Проверка таблицы маршрутизации Cato

Таблица маршрутизации может быть использована для проверки доступности маршрутов, метрик и других аспектов:

  • Ищите IP-адрес ресурса в строке поиска и подтвердите, что существует соответствующий маршрут через правильный сайт.
  • Если маршрут не найден, это означает, что Cato не знает об этом маршруте и не может маршрутизировать трафик до этой цели. Чтобы решить эту проблему, см. Устранение проблем маршрутизации
  • Если есть маршруты к одной и той же цели, подтвердите, что динамические диапазоны BGP не пересекаются с другими статическими маршрутами. Предпочтение отдается маршрутам с меньшей метрикой.
  • BGP также может рекламировать избыточные маршруты с разных площадок. Предпочтительнее маршрут с меньшей метрикой, включая Вес, длина AS или MED. См. Понимание полей таблицы маршрутизации.
  • Чтобы устранить проблемы с метрикой, см. Устранение проблем маршрутизации

Проверка маршрутизации на основе политики IPSec

Если внутренний ресурс доступен через IPSec, убедитесь, что корректные диапазоны определены в разделах политики IPSec и Сети страницы, как это объясняется в Руководстве по устранению неполадок IPSEC.

Если настроена маршрутизация на основе политики, все селекторы трафика должны совпадать как на Cato, так и на IPSec межсетевом экране / маршрутизаторе, чтобы обеспечить соединение с внутренними ресурсами.

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

Если внутренний ресурс находится за сокетом или vSocket, проверьте значение Последняя активность узла на странице Известные хосты на сайте. См. Отображение известных хостов для сайта

Хосты, которые недавно не были замечены сайтом, могут быть выключены или не подключены к сети.

Выполните захват пакетов из веб-интерфейса и определите любые возможные проблемы в сети LAN.

Проверка потоков TLS

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

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

Устранение неполадок несоответствия правила брандмауэра WAN

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

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

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

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

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

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

  • Какие приложения или сервисы настроены в "неправильном" согласованном правиле брандмауэра.
  • Указаны ли какие-либо из этих приложений/сервисов в поле сопоставленные приложения из события FW.

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

В приведенном ниже примере трафик SMB соответствует Правилу №1 вместо Правила №2. Это потому, что Правило №1 включает услугу TCP (включенную в сопоставленные приложения), даже если окончательное приложение (поле приложения) - это SMB.

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

Проверка настроенного имени домена

Если правило брандмауэра содержит объект Домен или Полное доменное имя (FQDN), проверьте, что в поле Имя домена в событии FW. Объект Домен/Полное доменное имя (FQDN) в правиле брандмауэра должен быть таким же, как это поле.

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

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

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

Устранение неполадок при отсоединении клиента SDP от внутренних ресурсов

В этом разделе рассматриваются вопросы, касающиеся исключительно клиентов SDP, не подключающихся к внутренним ресурсам.

Проверка перекрытия подсети домашней сети пользователя

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

Удаленные площадки с диапазоном IP-адресов 192.168.0.0/24, 192.168.1.0/24 или 10.0.0.0/24 могут легко пересекаться с диапазоном IP-адресов для домашних беспроводных маршрутизаторов, которые часто используют этот диапазон IP-адресов в качестве настроек DHCP по умолчанию.

Чтобы решить эту проблему, следуйте шагам, описанным в Клиент SDP не может подключиться к удаленным WAN-ресурсам.

Пользователи macOS и iOS не разрешают внутренние домены

Как объясняется в macOS Ventura и пользователи iOS не могут получить доступ к внутренним ресурсам через Cato, если Клиент SDP не может подключиться к внутренним ресурсам, используя доменное имя, но может достичь его по IP-адресу, возможно, перенаправление DNS не работает из-за использования DoH (DNS через HTTPS) или DoT (DNS через TLS) конечной точкой. Cato в настоящее время не поддерживает DoH/DoT.

Чтобы решить эту проблему, см. Решение проблем с перенаправлением DNS. Также можно определить сервер DNS Cato (10.254.254.1) в CMA в качестве единственного DNS-сервера для конечной точки.

Пользователи Android не разрешают внутренние домены

Как объясняется в устройства Android не могут получить доступ к внутренним ресурсам через Cato, если Клиент SDP не может подключиться к внутренним ресурсам, используя доменное имя, но может достичь его по IP-адресу, возможно, перенаправление DNS не работает из-за использования устройством Автоматического Приватного DNS (поведение по умолчанию), которое предполагает использование DoH/DoT для разрешения DNS. Это в настоящее время не поддерживается Cato.

Чтобы решить эту проблему, см. Решение проблем с перенаправлением DNS. Или можно отключить Приватный DNS на устройстве.

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

Анализ событий RPF

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

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

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

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

 

Анализ событий блокировки по геолокации

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

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

Проверьте значение Последняя известная активность на странице Известные хосты на сайте. См. Показать известные хосты для сайта

Хосты, которые сайт не видел в последнее время, могут быть выключены или не подключены к сети.

Запустите захват пакетов из WebUI и выявите возможные проблемы в ЛВС.

Устранение неполадок с недоступным хостом мониторинга ЛВС

Анализ событий соединения

Просмотрите события соединения, выбрав предустановку Недоступные хосты в локальной сети в CMA. Недоступные хосты события будут сгенерированы, когда определенный хост ЛВС больше не будет доступен.

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

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

  • LAN мониторинг зонды – это пакеты ICMP, исходящие из 10.254.254.1, поэтому важно убедиться, что наблюдаемый хост имеет маршрут обратно к шлюзу ЛВС сокета для ответа.
  • Если устройство запускает локальный файервол, необходимо разрешить ICMP с IP-адреса 10.254.254.1.

Запустите захват пакетов из WebUI и выявите возможные проблемы в ЛВС.

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

Решение проблем маршрутизации

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

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

  • Значения метрик туннеля обычно устанавливаются Cato. Избыточные маршруты должны иметь одинаковую метрику туннеля, если они исходят от одного типа сайта, например, IPsec или Socket Site.
  • Значение веса можно настроить в CMA, Сеть > Сайт > Настройки Сайта > BGP. Значение метрики, настроенное на этой странице, будет отображаться как вес в таблице маршрутизации. Изменение метрики для сайта позволит исправить неправильные решения о маршрутизации для избыточных маршрутов.
  • Значения длины AS и дискриминационной метрики получены от внешнего маршрутизатора. При необходимости их нужно изменить на этом устройстве.

Устранение ложных срабатываний Система предотвращения вторжений (IPS)/Антивирусных блокировок

Если интересный трафик блокируется Система предотвращения вторжений (IPS)/Антивирус, вы можете добавить разрешенные списки с областью WAN как для настроек IPS, так и для Антивирус.

 

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

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

Порядок правил брандмауэра

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

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

Решение проблем несоответствия доменных имен

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

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

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

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

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

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

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

Решение проблем перенаправления DNS

Вы можете использовать перенаправление DNS только тогда, когда DNS-запросы направлены на следующие DNS-серверы:

  • DNS-сервер Cato по умолчанию 10.254.254.1
  • DNS-серверы на уровне учетной записи, настроенные в разделе Сеть > Настройки DNS
  • Известные DNS-серверы, такие как 8.8.8.8, 1.1.1.1 и 9.9.9.9. Список известных DNS-серверов может варьироваться между точками присутствия. Например, Китай и Сидней.

DNS over HTTPS (DoH) и DNS over TLS не поддерживаются для перенаправления DNS, следовательно, они должны быть заблокированы в правилах брандмауэра, чтобы принудительно переместить DNS-запросы на UDP/53. Это решение особенно применимо к клиентам SDP на macOS, iOS и Android.

 

Предоставление кейсов в службу поддержки Cato

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

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

Была ли эта статья полезной?

Пользователи, считающие этот материал полезным: 0 из 0

0 комментариев