Обзор
Обеспечение бесперебойного доступа к внутренним ресурсам критически важно для поддержания продуктивности и безопасности в сети. Однако различные факторы могут нарушить доступ, что приведет к плохому пользовательскому опыту и затруднениям в рабочем процессе. Этот план действий нацелен на предоставление всестороннего руководства для устранения неполадок с доступом к внутренним ресурсам через сеть WAN в Cato Cloud.
Симптомы
Невозможность доступа к внутренним ресурсам может проявляться в нескольких аспектах. Администратор может отметить следующие симптомы:
Доменное имя внутреннего сервера не может быть разрешено
Внутренний сервер недоступен
Несоответствие правила брандмауэра WAN
Клиенты SDP не могут получить доступ к внутренним ресурсам
Ресурс удаленной переадресации портов (RPF) недоступен
Хост мониторинга LAN недоступен
Возможные причины
Проблемы с маршрутизацией
Ошибочная конфигурация перенаправления DNS
Ошибочная конфигурация брандмауэра WAN
Перекрытие с сетью Клиента SDP
Вмешательство безопасности
Проблемы с подключением хоста назначения
Первичная оценка
Заметка:
Убедитесь, что у вас есть правило брандмауэра WAN (даже временно созданное для устранения неполадок) с включённым отслеживанием событий.
Для решения проблем, связанных с доступом к внутренним серверам через Доступ через браузер, обратитесь к статье Устранение неполадок доступа через браузер
Просмотрите события брандмауэра WAN, IPS и Антивируса, выбрав соответствующий предустановленный режим в CMA. Установите фильтры, чтобы сузить круг интересующего трафика и проверьте, был ли поток заблокирован брандмауэром WAN или механизмами IPS/AM. Поле правило покажет соответствующее правило, которое соответствует трафику.
Обязательно ознакомьтесь с соответствующим разделом о решении неполадок, следуя этим начальным шагам оценки:
Проверьте, разрешимо ли доменное имя сервера, запустив команды nslookup или dig из командной строки. Если ответ DNS не получен, перейдите к Устранение неполадок разрешения доменного имени сервера
Проверьте, доступен ли IP-адрес сервера, запустив команду ping. Убедитесь, что ICMP разрешен по правилу брандмауэра WAN перед выполнением этого теста. Если ответ на ping не получен, перейдите к Устранение неполадок недоступного внутреннего сервера
Если события IPS или Антивирус показывают, что любой из этих механизмов блокирует доступ к внутреннему серверу, перейдите к Решение ложных срабатываний блокировок IPS/Антивирус
Проверьте, является ли совпадающее правило в событии брандмауэра WAN ожидаемым. Если нет, продолжайте с Устранение неполадок Несоответствие Правила Брандмауэра
Если только Клиенты SDP подвергаются воздействию, а пользователи за Сайтами нет, перейдите к Устранение неполадок Клиент SDP не достигает внутренних ресурсов
Если воздействованный внутренний ресурс доступен через Удаленную Переадресацию Портов, перейдите к Устранение неполадок внутренних ресурсов RPF
Если воздействованный сервер отслеживается мониторингом LAN, проверьте Устранение неполадок недоступного хоста мониторинга LAN
Устранение неполадок
Шаги для устранения неполадок, с которыми может столкнуться администратор, перечислены ниже. Эти шаги предназначены для выявления возможных причин возникновения проблем. Шаги по разрешению будут выделены позже в плане действий.
Проверка журналов аудита
Проверьте журнал аудита, чтобы найти любые измененные журналы, которые могли повлиять на доступ к внутренним ресурсам. Это включает в себя правила брандмауэра 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, проверьте значение Последняя активность узла на странице Известные хосты на сайте. См. Отображение известных хостов для сайта
Хосты, которые недавно не были замечены сайтом, могут быть выключены или не подключены к сети.
Выполните захват пакетов из веб-интерфейса и определите любые возможные проблемы в ЛВС.
Проверка потоков 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 Client Can't Connect to Remote WAN Resources.
Пользователи 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. Подтвердите, что событие сгенерировано, это подтвердит, что внешний IP Cato доступен. Обратите внимание, что IP-адрес назначения - это внешний публичный IP, настроенный в правиле RPF.
Заметка:
Примечание: Входящие события RPF могут иногда отображать Отображаемое имя, даже если трафик не инициирован пользователем. Это ожидаемое поведение.
Поля события на платформе Cato извлекают метаданные из туннеля, хоста, и пользовательского агента, а не только из потока трафика. Таким образом, если пользователь сопоставлен на устройстве позади сокета или туннеля, его имя может появиться в событии — даже для входящего трафика.
Это отличается от того, как политики файервола или маршрутизации интерпретируют трафик (что зависит от направления), но нормально для корреляции событий.
Анализ событий блокировки по геолокации
Просмотрите любые события, направленные на внутренний IP-адрес внутреннего сервера. Убедитесь, что нет ограничения блокировки по геолокации, препятствующего подключению к внутреннему серверу. Если данное условие выполняется, отредактируйте политику географических ограничений для входящих соединений, чтобы разрешить страну источника.
Проверка активности внутреннего ресурса
Проверьте значение Последняя известная активность на странице Известные хосты на сайте. См. Отображение известных хостов для сайта
Хосты, которые недавно не были замечены сайтом, могут быть выключены или не подключены к сети.
Выполните захват пакетов из веб-интерфейса и определите любые возможные проблемы в ЛВС.
Устранение неполадок с недоступным хостом мониторинга ЛВС
Анализ событий соединения
Просмотрите события Соединения, выбрав предустановку Недоступные хосты ЛВС в CMA. События "Хост недоступен" будут сгенерированы, когда определённый хост в ЛВС больше недоступен.
Проверка доступности локального хоста
Подтвердите, что определённый локальный хост может быть пингован из веб-интерфейса сокета. Если пинг успешен, проверьте следующее:
LAN мониторинг зонды – это пакеты ICMP, исходящие из 10.254.254.1, поэтому важно убедиться, что наблюдаемый хост имеет маршрут обратно к шлюзу ЛВС сокета для ответа.
Если устройство запускает локальный файервол, необходимо разрешить ICMP с IP-адреса 10.254.254.1.
Выполните захват пакетов из веб-интерфейса и определите любые возможные проблемы в ЛВС.
Решение обнаруженных проблем
Решение проблем маршрутизации
Если маршрут к внутреннему ресурсу не найден в таблице маршрутизации, проверьте и решите следующие проблемы:
Если BGP настроен для сайта, убедитесь, что маршруты объявляются соседом. См. Показать статус BGP. Важно проверить префиксы BGP, которые объявляет локальный маршрутизатор, и подтвердить, что Cato их получает.
Если BGP-сеанс не активен, устраните проблему отключения. См. BGP-сеанс отключен
Убедитесь, что сайт, размещающий диапазон, доступен. См. Устранение проблем с подключением сайта
Если значение метрики маршрута в таблице маршрутизации приводит к неправильным решениям о маршрутизации, проверьте и устраните следующее:
Значения метрик туннеля обычно устанавливаются Cato. Избыточные маршруты должны иметь одинаковую метрику туннеля, если они исходят от одного типа сайта, например, IPsec или Socket Site.
Значение веса можно настроить в CMA, Сеть > Сайт > Настройки Сайта > BGP. Значение метрики, настроенное на этой странице, будет отображаться как вес в таблице маршрутизации. Изменение метрики для сайта позволит исправить неправильные решения о маршрутизации для избыточных маршрутов.
Значения длины AS и дискриминационной метрики получены от внешнего маршрутизатора. При необходимости их нужно изменить на этом устройстве.
Устранение ложных срабатываний Система предотвращения вторжений (IPS)/Антивирусных блокировок
Если интересный трафик блокируется Система предотвращения вторжений (IPS)/Антивирус, вы можете добавить разрешенные списки с областью WAN как для настроек IPS, так и для Антивирус.
Решение проблемы пересекающегося пользовательского приложения
Убедитесь, что пользовательское приложение включает правильные IP-адреса, Домен, Порт и Протокол. Логики в выборе пользовательского приложения для идентификации нет, поэтому пользовательское приложение должно быть уникально определено для избежания пересечения с другим пользовательским приложением. Чтобы получить дополнительную информацию, см. Работа с пользовательскими приложениями
Порядок правил брандмауэра
Помните, что правила брандмауэра оцениваются в зависимости от их порядка, поэтому важно определить более специфические правила до более общих правил. Например, правила межсетевого экрана, которые определяют пользовательское приложение, встроенное приложение, домен, полное доменное имя (FQDN) или пользовательский сервис должны быть расположены выше правил, содержащих категории, пользовательские категории или услуги.
На скриншоте ниже Правило №1 содержит пользовательский сервис, который включает диапазоны IP для twitter.com, и размещено выше Правила №2, которое содержит категории приложений. Правило #1 является более конкретным, чем Правило #2, и будет более подходящим для трафика, направленного на twitter.com. Это также отключит ускорение TCP и решит любые проблемы маршрутизации Off-Cloud или Alt-WAN, принимая в учет, что Правило #1 является простым.
Решение проблем несоответствия доменных имен
Проблемы соответствия правил межсетевого экрана, основанные на Доменной/полном доменном имени (FQDN), могут быть решены следующим образом:
Для протоколов, таких как HTTP/S, CATO может определить домен назначения, используя следующие источники:
HTTP Имя хоста заголовок (когда инспекция TLS включена)
SNI поле во время рукопожатия TLS
Разрешение DNS, где имя домена определяется из DNS-запросов и ответов
Важно убедиться, что домен, указанный в правиле брандмауэра, совпадает во всех этих источниках. Примечание: только домен с наилучшим совпадением (оцененный сверху вниз) отображается как Имя домена в событиях файервола.
Для других протоколов, таких как SSH или SMB, которые не передают домен в открытом виде, Cato полагается исключительно на перехват DNS для ассоциации трафика с доменом или Полным доменным именем (FQDN). Это особенно критично при использовании частного DNS, так как нам нужно убедиться, что DNS-запросы/ответы проходят через Cato. См. Лучшие практики для DNS и вашей учетной записи Cato
DoH (DNS over HTTPS) и 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