INTEGRITY Документация

← Cloudflare One / cloudflare-one / networks / connectors / cloudflare-tunnel / private-net / cloudflared

Подключите частное имя хоста

Вместо управления статическими списками IP-адресов и маршрутами вы можете подключать пользователей к частным HTTP- и не-HTTP-приложениям по их именам хостов (например, wiki.internal.local). Маршруты для приватных имен хостов особенно полезны, когда у приложения неизвестный или временный IP-адрес, что часто бывает при развертывании инфраструктуры сторонним облачным провайдером.

  1. Запросы wiki.internal.local

  2. DNS-запрос

  3. Возвращает токен-IP, а затем переписывает адрес назначения на настоящий IP-адрес.

    172.64.128.0/20
  4. Маршрут хоста

  5. Перенаправляет трафик в вашу частную сеть либо выводит его в публичный интернет

  6. Частный хост

    wiki.internal.local · 10.0.0.50

Когда пользователь запрашивает приватное имя хоста, Cloudflare Gateway назначает исходный разрешённый IP-адрес для маршрутизации трафика через ваш туннель на нужный приватный IP-адрес. По умолчанию этот IP-адрес выбирается из публичного диапазона IPv4, принадлежащего Cloudflare (172.64.128.0/20) а не пространство Carrier-Grade NAT (CGNAT), поэтому это не вызывает Ограничения Local Network Access в Google Chrome. Вы также можете настроить пользовательский диапазон если он конфликтует с вашей существующей сетью. Подробное описание архитектуры и прохождения пакетов см. в нашем запись в блоге с анонсом ↗.

Поддерживаемые точки входа и выхода

В таблице ниже перечислены продукты Cloudflare One, совместимые с маршрутизацией по приватным именам хостов. Пояснения по чтению таблицы приведены в её легенде.

✅ Продукт работает без оговорок
🚧 Продукт можно использовать с некоторыми оговорками
❌ Продукт нельзя использовать

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

Конечные пользователи могут подключаться к частным именам хостов, используя следующие on-ramps:

Способ точки входа Совместимость
Cloudflare One Client ✅
PAC-файлы ✅
Browser Isolation ✅
Cloudflare Mesh ✅
Cloudflare WAN 🚧1

Доступность функций

Режимы клиента
Режим Traffic and DNS
Система Доступность Минимальная версия клиента
Windows ✅ 2025.4.929.0
macOS ✅ 2025.4.929.0
Linux ✅ 2025.4.929.0
iOS ✅ 1.11
Android ✅ 2.4.2
ChromeOS ✅ 2.4.2

Сноски

  1. Несовместимо с Маршрутизация ECMP. Чтобы маршрутизация по имени хоста работала, DNS-запросы и результирующий сетевой трафик должны поступать в Cloudflare через один и тот же туннель IPsec/GRE.
    ↩

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

Маршрутизация частных имён хостов работает с off-ramps, перечисленными ниже. Другие off-ramps для трафика требуют маршрутов на основе IP-адресов.

Connector Совместимость Минимальная версия
cloudflared ✅ 2025.7.0
Cloudflare Mesh ✅ 2026.6.822.0 (Linux)
Cloudflare WAN ❌

Подключите частное имя хоста

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

Предварительные требования

Прежде чем подключаться к частным именам хостов, необходимо включить прокси Gateway.

  1. Перейдите в Политики трафика > Настройки трафика.
  2. В Прокси и проверка, включите Разрешить Secure Web Gateway проксировать трафик.
  3. Выберите TCP.
  4. Выберите UDP (требуется для проксирования трафика к внутренним DNS-резолверам).
  5. (Рекомендуется) Чтобы проксировать трафик для диагностических инструментов, таких как ping и traceroute, выберите ICMP. Вам также может понадобиться обновить вашу систему чтобы разрешить трафик ICMP через cloudflared.

  1. Добавьте следующее разрешение в свой cloudflare_api_token ↗:

    • Zero Trust Write

  2. Включите прокси TCP и/или UDP с помощью cloudflare_zero_trust_device_settings ↗ ресурс:

    resource "cloudflare_zero_trust_device_settings "global_warp_settings" {
	account_id            = var.cloudflare_account_id
  gateway_proxy_enabled = true
	gateway_udp_proxy_enabled = true
}

Теперь Cloudflare проксирует трафик с зарегистрированных устройств, за исключением трафика, исключенного в вашем настройки Split Tunnel. Подробнее о том, как Gateway перенаправляет трафик, см. в Gateway proxy.

Ваши устройства также должны перенаправлять в Cloudflare следующий трафик:

Шаги настройки зависят от используемого on-ramp устройства:

Клиенты Cloudflare One

  1. В своём WARP профиль устройства, настройте Split Tunnels так, чтобы Исходные разрешённые IP-адреса направляются через туннель WARP. Конфигурация зависит от вашего Режим Split Tunnels:

  2. В Local Domain Fallback, удалите домен верхнего уровня своего приватного имени хоста. Это настроит WARP, чтобы он отправлял DNS-запрос в Cloudflare Gateway для разрешения.

Cloudflare Mesh

Чтобы направить трафик имени хоста к узлу Mesh вместо cloudflared туннель, добавьте маршрут по имени хоста к узлу. Исходный разрешённый IP-адрес, указанный выше, должен направляться через Cloudflare как в профиле узла Mesh, так и в профиле клиентского устройства. Для частного имени хоста узел также должен уметь разрешать это имя хоста (через локальный файл hosts или политику DNS-резолвера Gateway). См. Маршруты хоста.

Cloudflare WAN

  1. Убедитесь, что исходный разрешённый IP-адрес, указанный выше маршрутизировать через Cloudflare WAN в Cloudflare.
  2. Направьте DNS-резолвер для вашей сети Cloudflare WAN в Cloudflare Gateway.

1. Подключите приложение к Cloudflare

  1. Войдите в панель управления Cloudflare и перейдите в Сеть > Tunnels.

    Перейдите в Tunnels ↗

  2. Выберите Создать туннель.

  3. Введите имя туннеля. Рекомендуем выбрать имя, отражающее тип ресурсов, которые вы хотите подключить через этот туннель (например, enterprise-VPC-01).

  4. Выберите Create Tunnel.

  5. Выберите операционную систему, затем скопируйте команду установки и выполните её в терминале на вашем исходном сервере.

  6. Дождитесь подключения туннеля. После установления соединения выберите Продолжение.

  1. После подключения туннеля перейдите в его Маршруты и выберите Добавить маршрут, затем выберите Частное имя хоста.

  2. Введите полное доменное имя (FQDN), представляющее ваше приложение (например, wiki.internal.local).

    Ограничения формата имени хоста

    • Ограничение символов: Должно быть короче 255 символов.
    • Поддерживаемые подстановочные знаки: Один подстановочный знак (*) допускается, и она должна представлять собой полную DNS-метку. Пример: *.internal.local
    • Неподдерживаемые подстановочные знаки: Следующие форматы подстановочных знаков не поддерживаются:
      • Частичные подстановочные знаки, такие как *-dev.internal.local или dev-*.internal.local.
      • Подстановочные знаки в середине, например foo*bar.internal.local или foo.*.internal.local.
      • Несколько подстановочных знаков в имени хоста, например *.*.internal.local.
    • Усечение подстановочных знаков: Начальные подстановочные знаки (*) обрезаются, и неявная точка (.) принимается по умолчанию. Например, *.internal.local сохраняется как internal.local но будет соответствовать всем поддоменам на уровне wildcard (охватывает foo.internal.local но не foo.bar.internal.local).
    • Удаление точек: Начальные и конечные точки (.) разрешены, но обрезаются.

  3. Выберите Save.

2. Настройте разрешение DNS

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

Сценарий A: использование системного резолвера (по умолчанию)

По умолчанию cloudflared использует приватный DNS-резолвер, настроенный на своей хост-машине (например, в /etc/resolv.conf в Linux).

Если на машине, где запущен cloudflared уже может разрешать wiki.internal.local к его частному IP-адресу с помощью локального системного резолвера, дальнейшая настройка не требуется. Можно сразу перейти к Шаг 3.

Сценарий B: использование определённого частного DNS-сервера (расширенный)

Если вам нужно cloudflared чтобы использовать определённый внутренний DNS-сервер, отличный от резолвера узла по умолчанию, необходимо явно подключить этот DNS-сервер к Cloudflare через Маршрут IP/CIDR. Вам также потребуется настроить Политика Resolver в Gateway для маршрутизации запросов на этот конкретный приватный DNS-сервер.

  1. Чтобы создать маршрут IP/CIDR для DNS-сервера:

    1. Перейдите в Сеть > Маршруты.

      Перейдите в Маршруты ↗

    2. Выберите Добавление маршрута CIDR.

    3. Введите приватный IP-адрес вашего внутреннего DNS-резолвера.

    4. Выберите Cloudflare Tunnel, который подключается к сети, где находится этот DNS-сервер.

    5. Выберите Создание.

  2. Чтобы создать политику Resolver:

    1. Перейдите в Политики трафика > Резолвера политики.
    2. Выберите Создать политику.
    3. Создайте выражение, которое соответствует приватному имени хоста:
      СелекторОператорЗначение
      Hostinwiki.internal.local
    4. В разделе Настройте пользовательские DNS-резолверы, введите приватный IP-адрес вашего внутреннего DNS-сервера.
    5. В раскрывающемся меню выберите - Private параметр маршрутизации и виртуальная сеть назначенная туннелю, который вы выбрали на предыдущем шаге.
    6. Выберите Создать политику.

По умолчанию все устройства, зарегистрированные в вашей организации Zero Trust, могут подключаться к вашей частной сети через Cloudflare Tunnel. Вы можете настроить Gateway так, чтобы он проверял сетевой трафик и блокировал или разрешал доступ на основе личности пользователя и состояния устройства. Подробнее о проектировании политик см. в Защитите своё первое приложение.

Чтобы запретить пользователям Cloudflare One Client доступ ко всей вашей частной сети, рекомендуем создать catch-all-политика блокировки Gateway для вашего частного IP-пространства. После этого вы можете добавить политики Allow с более высоким приоритетом (в Access или Gateway), которые предоставляют пользователям доступ к конкретным приложениям или IP-адресам.

Вы можете создать Самостоятельно размещённое приложение Access для вашего частного имени хоста и настройте Политики доступа в этом приложении. Эта опция позволяет управлять доступом пользователей наряду с вашими SaaS и другими веб-приложениями.

Вариант 2: политики брандмауэра Gateway

Если вы предпочитаете защищать приложение по традиционной модели межсетевого экрана, можно создать сетевые политики Gateway с помощью SNI или SNI Domain селектор. Для дополнительного уровня защиты добавьте политику DNS Gateway, чтобы разрешить или заблокировать Host или Домен разрешаться.

Примеры сетевых политик

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

  1. Разрешить сотрудников компании
Селектор Оператор Значение Логика Действие
SNI in wiki.internal.local И Allow
User Email matches regex .*@example.com
  1. Общая политика блокировки
Селектор Оператор Значение Действие
IP-адрес назначения in 10.0.0.0/8 Block

Пример политики DNS

Селектор Оператор Значение Логика Действие
Host in wiki.internal.local И Allow
User Email matches regex .*@example.com

4. Протестируйте соединение

Теперь конечные пользователи могут открыть приложение, перейдя на его частное имя хоста. Например, чтобы подключиться к частному веб-приложению, откройте браузер и перейдите по адресу wiki.internal.local.

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

Если подключиться не удается, проверьте следующее:

  1. Подтвердить разрешение DNS: На устройстве убедитесь, что вам удаётся успешно разрешить частное имя хоста:

    nslookup wiki.internal.local
    Server:		127.0.2.2
Address:	127.0.2.2#53

Non-authoritative answer:
Name:	wiki.internal.local
Address: 172.64.128.48

    Запрос должен разрешаться с использованием DNS-прокси WARP и верните Gateway исходный разрешённый IP-адрес. Если запрос не разрешается или возвращает другой IP-адрес, проверьте свои Local Domain Fallback конфигурация и Политики резолвера Gateway.

  2. Проверить журналы Gateway: Проверьте свои Журналы Network Gateway и проверьте, блокируется ли подключение какой-либо политикой.

  3. Проверить статус туннеля: Убедитесь, что ваш туннель исправен и подключён, проверив статус туннеля.

  4. Протестировать подключение к изначально разрешённому IP: Когда вы подключаетесь к приложению по его частному имени хоста, устройство должно устанавливать соединение с исходный разрешённый IP-адрес:

    curl -v4 http://wiki.internal.local
    * Trying 172.64.128.48:80...
* Connected to wiki.internal.local (172.64.128.48) port 80
...

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

Ограничения

Google Chrome ограничивает доступ к частным именам хостов

Начиная с Chrome 142 ↗, Local Network Access (LNA) ограничивает запросы с веб-сайтов к локальным IP-адресам. LNA реализован на уровне движка Chromium, поэтому это затрагивает все браузеры на основе Chromium (например, Microsoft Edge, Brave и Opera), а не только Google Chrome. Это может затронуть аккаунты, у которых Gateway диапазон исходных разрешённых IP-адресов по-прежнему выбирается из адресного пространства Carrier-Grade NAT (CGNAT) (100.64.0.0/10) например, устаревший диапазон по умолчанию 100.80.0.0/16, или пользовательский диапазон, настроенный в пространстве CGNAT. Такие браузеры относят подобные адреса к локальной сети. Когда сайт, загруженный с публичного IP-адреса, отправляет подзапросы к домену, который изначально был разрешён в IP-адрес из этого диапазона, браузер расценивает это как запрос из публичной сети в локальную и показывает пользователю запрос на разрешение доступа к устройствам локальной сети. Браузер блокирует запросы к этим доменам, пока пользователь не примет этот запрос.

Обычно это происходит, когда Политика Egress совпадает с часто используемыми доменами (например, cloudfront.net или github.com), из-за чего подзапросы с общедоступных страниц разрешаются в пространство CGNAT.

Учетные записи, использующие текущий стандартный начальный диапазон разрешенных IP-адресов (172.64.128.0/20) не затрагиваются, поскольку этот диапазон относится к публичному адресному пространству Cloudflare, а не к CGNAT. Если ваш аккаунт был создан до изменения этого значения по умолчанию или вы настроили собственный диапазон в пространстве CGNAT, обратитесь к Настройте начальные разрешённые IP-адреса и перейдите на диапазон адресов вне CGNAT, вместо того чтобы использовать следующие обходные пути для браузера.

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

Iframe

Если затронутый запрос исходит из iframe (например, из приложения, встроенного в сторонний портал), в iframe должен быть объявлен local-network-access разрешение, чтобы запрос браузера отображался в родительском фрейме:

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

Обходные пути

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