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

Исходящий трафик через Cloudflare Tunnel

Некоторые сторонние сервисы принимают подключения только с определенных исходных IP-адресов, перечисленных в списке контроля доступа (ACL). Если IP-адрес не Cloudflare (например, адрес вашего интернет-провайдера или облачного провайдера, такого как AWS) уже есть в их allowlist, вы можете направить трафик через Cloudflare Tunnel так, чтобы он выходил с тем же IP-адресом. Это называется привязкой исходного IP (source IP anchoring): она позволяет сохранить существующие исходящие IP-адреса без покупки выделенные исходящие IP-адреса Cloudflare.

Например, предположим, что ваш банковский сервис по адресу app.bank.com ожидает трафик с IP-адреса AWS. Вы устанавливаете cloudflared в вашем окружении AWS и добавьте маршрут с общедоступным именем хоста для app.bank.com. Когда пользователи подключаются к app.bank.com через Cloudflare One Client Gateway применяет ваши сетевые политики и направляет отфильтрованный трафик через Cloudflare Tunnel в AWS. Затем трафик выходит в публичный интернет через ваш исходящий IP-адрес AWS.

    flowchart LR
      subgraph aws["AWS VPC"]
				cloudflared["cloudflared"]
      end
			subgraph cloudflare[Cloudflare]
			  gateway["Gateway"]
			end
			subgraph internet[Internet]
				resolver[1.1.1.1]
				app[Application]
			end
      warp["Cloudflare One
				Client"]--"app.bank.com"-->gateway--"Network traffic"-->cloudflared
			gateway<-.DNS lookup.->resolver
			aws--AWS egress IP -->app

Чтобы узнать больше о том, как Gateway применяет политики исходящего трафика на основе имени хоста, см. Блог Cloudflare ↗.

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

Подключите свою приватную сеть к Cloudflare с помощью cloudflared. Например, если вы хотите, чтобы трафик выходил из AWS, подключите закрытый блок CIDR вашего AWS VPC.

Чтобы направить публичное имя хоста через Cloudflare Tunnel:

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

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

2. Выберите Создать маршрут по имени хоста.

3. В Имя хоста, введите публичное имя хоста, представляющее приложение (например, app.bank.com). Имя хоста должно быть доступно из публичного интернета.

4. Для Tunnel, выберите Cloudflare Tunnel, который используется для подключения частной сети к Cloudflare.

5. Выберите Создать маршрут.

В своём WARP Split Tunnels конфигурации направьте следующие IP-адреса через туннель WARP в Gateway.

Когда пользователи подключаются к маршруту с публичным именем хоста, Gateway назначает исходный разрешённый IP-адрес к DNS-запросу из следующего диапазона:

• IPv4: 172.64.128.0/20
• IPv6: 2606:4700:0cf1:4000::/64

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

Сетевой движок Gateway работает на уровнях 3 и 4 модели Модель OSI ↗, где доступны только IP-адреса, а не имена хостов. Первоначально разрешённый IP-адрес служит сигналом: когда IP-адрес назначения пакета попадает в этот диапазон, Gateway определяет, что этот IP-адрес соответствует маршруту для публичного имени хоста, и направляет трафик через соответствующий Cloudflare Tunnel.

Чтобы направить первоначально разрешенные IP-адреса через Cloudflare One Client:

В своём 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, если он конфликтует с вашей существующей сетью.

Блок CIDR вашей частной сети также должен маршрутизироваться через туннель WARP. Подробный пример настройки см. в Подключите частную сеть.

Вы можете создать Политики Network Gateway чтобы фильтровать HTTPS-трафик к вашему публичному имени хоста на порту 443. Например, чтобы ограничить app.bank.com чтобы доступ через исходящий IP-адрес AWS могли получить только определённые пользователи или группы, создайте две политики: одну, разрешающую доступ авторизованным пользователям, и вторую, блокирующую всех остальных.

1. Разрешить сотрудников компании:

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

2. Заблокировать всех остальных на порту 443:

   Селектор	Оператор	Значение	Действие
   SNI	in	app.bank.com	Block

Gateway не поддерживает фильтрацию на основе имени хоста для трафика на портах, отличных от443 порты. Чтобы заблокировать трафик к app.bank.com на всех портах, используйте IP-адрес назначения селектор и укажите публичный диапазон IP-адресов app.bank.com.

На устройстве откройте браузер и перейдите по адресу app.bank.com.

Можно выполнить поиск по app.bank.com в вашем Журналы DNS Gateway; Сведения об ответе DNS раздел должен отображать публичные разрешённые IP-адреса, а также исходный разрешённый IP-адрес. Также можно проверить свои Журналы Cloudflare Tunnel чтобы убедиться, что запросы маршрутизируются через туннель к публичным разрешённым 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 флаг для Отключено. Этот подход подходит для отдельных пользователей, но не для развёртывания в масштабах всей организации.