← Cloudflare One / cloudflare-one / networks / connectors / cloudflare-tunnel / troubleshoot-tunnels

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

Используйте эту процедуру устранения неполадок, если у конечных пользователей, использующих Cloudflare One Client, возникают проблемы с подключением к приватной сети через Cloudflare Tunnel.

Графический интерфейс Cloudflare One Client должен отображать Connected и Your Internet is protected.

Если Cloudflare One Client застрял в состоянии Disconnected состояние или часто переключается между Connected и Disconnected, см. Unable to connect WARP.

Этот шаг нужен только в том случае, если пользователи обращаются к вашему приложению через приватное имя хоста (например, wiki.internal.local).

• Если вы используете пользовательские политики резолвера чтобы обрабатывать частный DNS, перейдите в логи DNS Gateway (Insights > Журналы > Журналы DNS-запросов) и найдите DNS-запросы к этому имени хоста.

• Если вы используете Local Domain Fallback чтобы обрабатывать частный DNS, перейдите в логи Network Gateway (Insights > Журналы > Журналы сети) и найдите порт 53 трафик на IP-адрес вашего DNS-сервера.

Если соответствующие журналы Gateway отсутствуют, это означает, что WARP не смог перенаправить запрос на ваш частный DNS-сервер. Проверьте политики распознавателя или конфигурацию Local Domain Fallback и обратитесь к Как WARP обрабатывает DNS-запросы.

Далее проверьте свои сетевые журналы Gateway (Insights > Журналы > Журналы сети) показывают трафик на целевой IP-адрес.

Если Cloudflare One Client подключён, но журналы сети отсутствуют, это означает, что IP-адреса вашей частной сети не проходят через Cloudflare One Client. Это можно подтвердить, поиск в таблице маршрутизации на устройстве для IP-адреса вашего приложения. Трафик к вашему приложению должен направляться через интерфейс Cloudflare One Client. Если используется другой интерфейс, проверьте конфигурацию Split Tunnel.

Чтобы проверить, произошло ли событие блокировки Gateway:

1. Перейдите в Insights > Журналы и выберите Журналы DNS-запросов, Журналы сети, или Журналы HTTP-запросов.
2. Примените следующие фильтры:
   • Электронная почта: адрес электронной почты пользователя
   • Событие: Заблокировано
   • Диапазон даты и времени: Период времени, в течение которого пользователь получил доступ к приложению

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

1. Чтобы определить, какая политика была фактически применена:
   1. Перейдите в Insights > Журналы и выберите Журналы DNS-запросов, Журналы сети, или Журналы HTTP-запросов.
   2. Примените следующие фильтры:
      • Электронная почта: адрес электронной почты пользователя
      • Диапазон даты и времени: Период времени, в течение которого пользователь получил доступ к приложению
   3. В поле поиска отфильтруйте по IP-адресу или FQDN назначения.
   4. В результатах выберите запись журнала и запомните её Policy Name значение.
2. Перейдите в Политики трафика > Политики Firewall и сравните порядок применения совпавшей политики по сравнению с ожидаемой политикой.
3. Сравните значения журнала Gateway с ожидаемыми критериями политики.
   • Если несовпадающее значение относится к идентификации, проверить реестр пользователя и проверьте значения, которые передаются в Gateway от вашего IdP. Cloudflare обновляет реестр, когда пользователь регистрируется в Cloudflare One Client. Если данные пользователя устарели, попросите его повторно аутентифицировать клиент (Профиль > Информация об аккаунте > Повторная аутентификация)¹.

• Если несовпадающее значение относится к состоянию устройства, просматривать результаты проверки состояния устройства для устройства пользователя. Убедитесь, что устройство проходит проверки состояния, настроенные в политике.

В разделе Политики трафика > Настройки трафика, убедитесь, что Разрешить Secure Web Gateway проксировать трафик включено для трафика TCP, UDP и ICMP. UDP необходим для проксирования DNS-трафика и других UDP-пакетов, а ICMP необходим для ping и другие административные функции.

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

Убедитесь, что вы можете подключиться к приложению напрямую из cloudflared хост-машина:

telnet test.example.com 443

PS C:\Users\JohnDoe> Test-NetConnection test.example.com -port 443

Вы также можете использовать инструмент для захвата пакетов, например tcpdump или Wireshark, чтобы проверить, доходит ли трафик с устройства пользователя до cloudflared и направляет его к вашему приложению. Трафик к вашему приложению будет содержать исходный IP-адрес cloudflared хост.

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

2. Проверьте, должен ли сервер приложения инициировать подключение к устройству пользователя. Если да, это ограничение cloudflared и вместо этого следует развернуть Cloudflare Mesh чтобы разрешить двунаправленный трафик.

Если возникла проблема с Проверка TLS, пользователь получит Insecure Upstream ошибка при обращении к приложению из браузера. Вероятно, при обращении к приложению не из браузера ошибки не будет.

Клиенты, у которых есть Logpush включена, могут проверить Набор данных HTTP Gateway для любых хостнеймов с повышенной частотой 526 Коды состояния HTTP.

Чтобы устранить неполадки проверки TLS:

1. Создайте временную политику Gateway HTTP, которая отключает проверку TLS для всего трафика к приложению. Например:

   Селектор	Оператор	Значение	Действие
   IP-адрес назначения	in	10.2.3.4/32	Do Not Inspect

2. Если Do Not Inspect политика позволяет пользователю подключиться, проверив, что TLS-сертификат, используемый вашим приложением, доверен публичным CA а не самоподписанным. Cloudflare Gateway не может согласовать TLS с приложениями, использующими самоподписанные сертификаты. Дополнительные сведения см. в Ограничения проверки TLS.

   Чтобы обойти эту проблему:

   • Вариант 1: Создайте постоянный Do Not Inspect HTTP-политика для этого приложения.
   • Вариант 2: Клиенты, которые используют свой собственная инфраструктура сертификатов для проверки могут по своему усмотрению создать Разрешить Pass Through политика позволяет нашему прокси-серверу принимать согласование TLS от вашего приложения. Это позволит запросам корректно проходить без необходимости в Do Not Inspect политика.
   • Вариант 3: Если ваше приложение использует HTTPS или другие распространённые протоколы, вы можете добавить опубликованное приложение к вашему Cloudflare Tunnel и укажите noTLSVerify к true. Это позволит cloudflared чтобы доверять вашему самоподписанному сертификату.