← Cloudflare One / cloudflare-one / traffic-policies / egress-policies

Селекторы хоста

Политики Egress оцениваются на 4-м уровне (https://www.cloudflare.com/learning/ddos/glossary/open-systems-interconnection-model-osi/ ↗) модели OSI, где доступны только IP-адреса, а не имена хостов. Приложение, Content Categories, Домен, а также Host селекторам необходимо сопоставлять трафик по имени хоста, поэтому Gateway использует двухэтапный процесс:

1. Когда Gateway получает DNS-запрос для имени хоста, соответствующего одному из этих селекторов, он сначала разрешает запрос во временный исходный разрешённый IP-адрес. По умолчанию этот IP-адрес берётся из публичного диапазона, принадлежащего Cloudflare (172.64.128.0/20 для IPv4, или 2606:4700:0cf1:4000::/64 для IPv6). Вы можете настроить пользовательский диапазон IPv4 если он конфликтует с вашей существующей сетью.
2. Когда трафик поступает с этим временным IP-адресом назначения, Gateway определяет, какому имени хоста принадлежит соединение, применяет нужную политику исходящего трафика и заменяет временный IP-адрес на настоящий IP-адрес назначения перед отправкой трафика.

Для работы этих селекторов требуется дополнительная настройка.

Чтобы включить селекторы для вашего аккаунта:

curl "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/gateway/configuration" \
	--request PATCH \
	--header "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \
	--json '{
		"settings": {
				"host_selector": {
						"enabled": true
				}
		}
	}'

Трафик должен быть направлен в Gateway одним из следующих способов:

Трафик от неподдерживаемых способов подключения разрешается с использованием настроек Gateway по умолчанию. Если вы используете DNS-локации для отправки DNS-запросов в Gateway (по IPv4, IPv6, DNS over TLS или DNS over HTTPS), Gateway не возвращает исходный разрешенный IP-адрес, и селекторы хостов не применяются.

Чтобы настроить организацию Zero Trust на использование селекторов Host с политиками Egress:

1. Убедитесь, что на устройства ваших пользователей развёрнута следующая версия Cloudflare One Client:

   • Компьютеры: Cloudflare One Client версии 2025.4.929.0 или более поздней версии
   • iOS: Cloudflare One Client версии 1.11 или более поздней версии
   • Android и Chrome OS: Cloudflare One Client версии 2.4.2 или более поздней версии.

   Если вам нужно поддерживать устройства с более ранними версиями WARP, добавьте и разверните на устройствах следующую пару ключ-значение в Файл конфигурации WARP (mdm.xml в Windows и Linux, либо com.cloudflare.warp.plist на macOS):

   <array>
   	<dict>
   +		<key>doh_in_tunnel</key>
   +		<true/>
   	</dict>
   </array>

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

   • Режим Exclude: Удалите 100.64.0.0/10 из списка Split Tunnels. Мы рекомендуем повторное добавление диапазонов IP-адресов которые явно не используются для сервисов Cloudflare One. Это снижает риск конфликтов с существующими конфигурациями частной сети, которые могут использовать адресное пространство CGNAT.
   • Режим Include: Добавьте записи Split Tunnel для следующих IP-адресов:
     • IPv4: 172.64.128.0/20
     • IPv6: 2606:4700:0cf1:4000::/64

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

Cloudflare One Client должен быть настроен на Режим Traffic and DNS для корректной маршрутизации трафика, затронутого этими селекторами.

Для Приложение, Content Categories, Домен, а также Host селекторов Gateway фиксирует IP-адрес назначения на этапе первоначального разрешения DNS, описанном выше. Политика исходящего трафика не изменяет этот IP-адрес, поэтому адрес назначения, к которому подключается Gateway, не зависит от расположения дата-центра исходящего трафика или выбранного вами выделенного исходящего IP-адреса.

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

Это может повлиять на вас, если вы используете селекторы исходящего трафика типа Domain или Host, ваши пользователи находятся за пределами региона, связанного с вашим исходящим IP-адресом, а место назначения применяет географические ограничения или контроль доступа на основе IP-адреса.

Начиная с 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 должен быть объявлен local-network-access разрешение, чтобы запрос браузера отображался в родительском фрейме:

• Chrome 142-144: Используйте allow="local-network-access" атрибут элемента iframe.
• Chrome 145+: Это разрешение было разделено на allow="local-network" и allow="loopback-network".

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

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

• Переопределение классификации адресного пространства IP (Chrome 146+): Используйте LocalNetworkAccessIpAddressSpaceOverrides ↗ Политика Chrome Enterprise для изменения классификации первоначально разрешённого диапазона IP-адресов в пространстве CGNAT (например, 100.80.0.0/16) как публичный. Это наиболее точечное решение, поскольку оно меняет классификацию только для изначально разрешённого диапазона IP-адресов, а не отключает проверки безопасности полностью.
• Разрешить определённые URL-адреса (Chrome 140+): Используйте LocalNetworkAccessAllowedForUrls ↗ Политика Chrome Enterprise для исключения определённых веб-сайтов из проверок Local Network Access. Обратите внимание, что https://* это допустимое значение для отключения проверок для всех URL-адресов.
• Разрешить определённые URL-адреса (Chrome 146+): Используйте LocalNetworkAllowedForUrls ↗ Политика Chrome Enterprise, которая заменяет собой LocalNetworkAccessAllowedForUrls начиная с Chrome 146.
• Отказаться от ограничений Local Network Access (Chrome 142-152): Используйте LocalNetworkAccessRestrictionsTemporaryOptOut ↗ Политика Chrome Enterprise для полного отказа от ограничений Local Network Access. Это временная политика, которая будет удалена после выхода Chrome 152.
• Отключить feature flag в Chrome: Перейдите в chrome://flags и задайте Local Network Access Checks флаг для Отключено. Этот подход подходит для отдельных пользователей, но не для развёртывания в масштабах всей организации.

Если домен соответствует Политика DNS Override, Gateway не будет применять исходное сопоставление IP-адреса для этого домена. Это означает, что селекторы исходящего трафика на основе хоста (Application, Content Categories, Domain и Host) не будут применяться к трафику, направленному на переопределенный домен. Трафик к этим доменам будет использовать метод исходящего трафика Cloudflare по умолчанию.

Селекторы хоста не поддерживают типы DNS-записей HTTPS. Если домен использует записи HTTPS для установления соединения, Gateway не может сопоставить DNS-запрос с именем хоста для оценки политики Egress. Трафик к таким доменам будет использовать метод исходящего трафика Cloudflare по умолчанию, а не соответствовать политике Egress на основе хоста.

Если вам нужно применить исходящие политики к домену, использующему записи HTTPS, используйте селектор на основе IP-адреса (например, IP-адрес назначения) вместо этого.