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

← Cloudflare One / cloudflare-one / access-controls / applications / non-http

Защита приватного IP-адреса или имени хоста

Вы можете настроить локально размещённое приложение Access для управления доступом к определённым IP-адресам или именам хостов в вашей частной сети.

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

Добавить приложение в Access

  1. В Панель управления Cloudflare ↗, перейдите в Zero Trust > Контроль доступа > Приложения.

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

  3. Выберите Самостоятельный хостинг и конфиденциальность.

  4. Чтобы добавить приложение по его приватному IP:

    1. Выберите Добавить частный IP.

    2. В IP-адрес, введите приватный IP-адрес или диапазон CIDR, представляющий приложение (например, 10.0.0.1 или 172.16.0.0/12).

    3. В Порт, введите один порт или диапазон портов, используемых вашим приложением (например, 22 или 8000-8099).

      Списки портов через запятую (например, 80, 443) не поддерживаются. Чтобы добавить несколько портов для конкретного IP-адреса, вы можете выбрать Добавить частный IP и повторите тот же IP-адрес с другим портом. Либо создайте новое приложение Access для другого порта.

  5. Чтобы добавить приложение по его приватному имени хоста:

    1. Выберите Добавить частное имя хоста.
    2. В Имя хоста, введите приватное имя хоста приложения (например, wiki.internal.local). Вы можете использовать подстановочные знаки с частными именами хостов для защиты нескольких частей приложения, использующих общий корневой путь.
    3. В Порт, введите один порт или диапазон портов, используемых вашим приложением (например, 22 или 8000-8099).

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

Теперь пользователи могут подключаться к вашему частному приложению после аутентификации через Cloudflare Access.

Поток аутентификации

Процесс аутентификации зависит от протокола приложения.

HTTPS-приложения

Если Расшифровка TLS Gateway включён и пользователь обращается к приложению HTTPS на порту 443, Cloudflare Access покажет страницу входа в браузере и выдаст токен приложения к вашему исходному серверу. Это тот же процесс аутентификации на основе cookie, который используется локально размещённые публичные приложения.

Если Расшифровка TLS Gateway отключён, управление сессиями обрабатывается в Cloudflare One Client вместо браузера.

HTTP-приложения с открытым текстом

Для приложений, обслуживаемых по незашифрованному HTTP на порту 80, Cloudflare Access показывает страницу входа в браузере и выдает токен приложения, так же, как для HTTPS-приложений с расшифровкой TLS в Gateway. Расшифровка TLS в Gateway не требуется, поскольку трафик уже не зашифрован.

Другие не-HTTP приложения

Для приложений, не использующих HTTP или HTTPS (например, SSH, RDP или произвольный TCP/UDP), сеанс управляется Cloudflare One Client. Пользователи получат Authentication required всплывающее уведомление от Cloudflare One Client. Когда пользователь выбирает это уведомление, Cloudflare One Client открывает окно браузера со страницей входа Access.

Убедитесь, что ваша операционная система разрешает уведомления для Cloudflare One Client. Если включены режим фокусировки, режим "не беспокоить" или демонстрация экрана, устройство может не показывать уведомления. Чтобы включить уведомления клиента на устройствах macOS с программным обеспечением DisplayLink, может потребоваться разрешить системные уведомления при дублировании экрана. Дополнительные сведения см. в документация по macOS ↗.

Порядок приоритета

Политики Access и Gateway

По умолчанию Cloudflare оценивает политики приложений Access только после оценки всех Политики Network Gateway. Чтобы оценивать приложения Access до или после определенных политик Gateway:

  1. В Панель управления Cloudflare ↗, перейдите в Zero Trust > Политики трафика > Политики Firewall. В Сеть, создать политику Network со следующей конфигурацией:

    Селектор Оператор Значение Действие
    Доступ к приватному приложению является Present Allow

  2. Обновите в политике порядок приоритета с помощью панели управления или API.

Приватное имя хоста против приватного IP-адреса

Приложение Access, заданное частным именем хоста, имеет приоритет над приложением Access, заданным частным IP-адресом. Например, предположим, что App-1 указывает на wiki.internal.local а App-2 указывает на 10.0.0.1, но wiki.internal.local разрешается в 10.0.0.1. Пользователи, которые переходят на wiki.internal.local никогда не будет соответствовать App-2. Доступ к нему будет разрешён или заблокирован исключительно на основе политик Access для App-1 (и Политики Gateway).

Ограничения

Browser Isolation несовместима с приложениями на не-443 порты

Browser Isolation несовместима с локально размещённые частные приложения которые используют частные IP-адреса или имена хостов на портах, отличных от 443. Попытка обращения к локально размещённым приложениям через порты, отличные от443 порты приведут к отображению страницы блокировки Gateway.

Чтобы использовать Browser Isolation для приложения на приватном IP-адресе с нестандартным443 порт, настройте приложение частной сети взамен.

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, конечный пользователь не всегда может это настроить.

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

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