← Cloudflare One / cloudflare-one / networks / connectors / cloudflare-mesh

Маршруты

По умолчанию узел Mesh доступен только по своему собственному Mesh IP. Чтобы сделать доступными другие устройства в подсети за узлом (серверы, базы данных, принтеры, устройства IoT, на которых нельзя запустить Cloudflare One Client : добавьте маршрут к узлу. Узел Mesh поддерживает два типа маршрутов:

• Маршруты CIDR : перенаправляют трафик для диапазона IP-адресов, частного (например, 10.0.0.0/24) или общедоступным, через узел.
• Маршруты хоста : привлекают трафик для имени хоста к узлу вместо IP-адреса. Это работает для частный имя хоста (например, wiki.internal.local), что полезно, когда у приложения неизвестный или временный IP-адрес, а также публичный имя хоста (например, www.example.com), который направляет трафик этого имени хоста через узел и выводит его через публичный IP-адрес узла.

Когда вы добавляете маршрут, узел Mesh выступает в роли шлюза: трафик, предназначенный для анонсируемого CIDR или имени хоста, направляется на этот узел, который доставляет его нужному хосту в локальной сети (или отправляет в публичный интернет).

Поддерживаются маршруты CIDR как для IPv4, так и для IPv6. Для маршрутов IPv6 требуется, чтобы узел Mesh профиль устройства настроено на использование MASQUE; они не будут работать, если профиль устройства использует WireGuard.

• Без маршрутов : Устройства в вашей Mesh могут обращаться только к самому узлу по его IP-адресу Mesh. Таким способом доступны службы, работающие непосредственно на узле.
• С маршрутами : Устройства в вашей Mesh могут обращаться к любому хосту в подсети за узлом. Используйте этот вариант, если у вас есть инфраструктура, на которой невозможно запустить Cloudflare One Client.

flowchart LR
  subgraph subnet["Subnet 10.0.0.0/24"]
    node["Mesh node <br> 10.0.0.1"]
    db["Database <br> 10.0.0.50"]
    printer["Printer <br> 10.0.0.100"]
  end
  client["Client device <br> 100.96.0.10"] --> CF((Cloudflare)) --> node
  node --> db
  node --> printer

Используйте маршруты CIDR, чтобы перенаправлять трафик с узла Mesh на устройства в вашей локальной сети.

curl "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/teamnet/routes" \
	--request POST \
	--header "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \
	--json '{
		"network": "10.0.0.0/24",
		"tunnel_id": "{mesh_node_id}",
		"comment": "Staging subnet"
	}'

curl "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/teamnet/routes/$ROUTE_ID" \
	--request PATCH \
	--header "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \
	--json '{
		"network": "10.0.0.0/24",
		"comment": "Updated description"
	}'

curl "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/teamnet/routes/$ROUTE_ID" \
	--request DELETE \
	--header "Authorization: Bearer $CLOUDFLARE_API_TOKEN"

Чтобы трафик доходил до анонсируемого вами CIDR, диапазон должен маршрутизироваться через Cloudflare как на узле Mesh, так и на клиентских устройствах.

В профиле устройства узла Mesh убедитесь, что анонсируемые маршруты CIDR проходят через Cloudflare:

• Режим Include (рекомендуется для узлов Mesh): добавьте CIDR в список включения.
• Режим Exclude: Удалите CIDR (или его родительский диапазон) из списка исключений.

Например, если вы анонсируете 10.0.0.0/24 и ваш список исключений Split Tunnel содержит 10.0.0.0/8, вам нужно удалить 10.0.0.0/8 и повторно добавьте части 10.0.0.0/8 диапазон, который вы не хотите маршрутизировать через Cloudflare.

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

Узел Mesh пересылает входящий трафик от Cloudflare устройствам в подсети. Однако для обратный трафик (ответы от устройств подсети обратно клиентам Mesh), устройствам подсети нужен обратный маршрут к узлу Mesh.

flowchart LR
  client["Client device <br> 100.96.0.10"] -- request --> CF((Cloudflare)) -- request --> node["Mesh node <br> 10.0.0.1"]
  node --> db["Database <br> 10.0.0.50"]
  db -. "response: <br> needs route to node" .-> node -. response .-> CF -. response .-> client

Способ настройки зависит от того, где установлен узел Mesh:

Если узел Mesh является шлюзом по умолчанию для подсети (или установлен на маршрутизаторе), дополнительная настройка не требуется: весь трафик от устройств подсети автоматически проходит через этот узел.

Если узел Mesh является обычным хостом в подсети, настройте маршрутизатор подсети так, чтобы трафик Mesh отправлялся через этот узел. Добавьте статический маршрут:

• Назначение: 100.96.0.0/12 (диапазон IP-адресов Mesh)
• Next hop: Локальный IP-адрес подсети узла Mesh (например, 10.0.0.1)

Это гарантирует, что ответы клиентам Mesh пересылаются на узел Mesh для доставки через Cloudflare.

Когда у вас есть узлы Mesh на нескольких сайтах, устройства из одной подсети могут обращаться к устройствам в другой подсети через Cloudflare.

flowchart TD
  subgraph siteA["Site A — 10.0.0.0/24"]
    serverA["Server <br> 10.0.0.50"] --- nodeA["Mesh node <br> 10.0.0.1"]
  end
  subgraph siteB["Site B — 192.168.1.0/24"]
    serverB["Server <br> 192.168.1.50"] --- nodeB["Mesh node <br> 192.168.1.1"]
  end
  nodeA <--> CF((Cloudflare))
  nodeB <--> CF

Чтобы это работало:

1. Каждый узел Mesh должен анонсировать локальную подсеть как Маршрут CIDR чтобы Cloudflare знал, на какой узел перенаправлять трафик.
2. CIDR-адреса удалённой подсети должны маршрутизироваться через Cloudflare на каждом узле. В настройках вашего узла Mesh Split Tunnel конфигурации добавьте CIDR удаленного сайта в список включения (или удалите его из списка исключения).
3. Маршрутизатору каждого сайта требуются статические маршруты, направляющие удалённые подсети на локальный узел Mesh:

Маршрутизатор сайта A:

• Назначение: 192.168.1.0/24 → Next hop: 10.0.0.1 (локальный узел Mesh)
• Назначение: 100.96.0.0/12 → Next hop: 10.0.0.1

Маршрутизатор сайта B:

• Назначение: 10.0.0.0/24 → Next hop: 192.168.1.1 (локальный узел Mesh)
• Назначение: 100.96.0.0/12 → Next hop: 192.168.1.1

Для производственных развертываний типа site-to-site рассмотрите возможность включения высокая доступность на каждом узле. HA обеспечивает отказоустойчивость для маршрутов CIDR, анонсируемых узлом: если активная реплика выходит из строя, Cloudflare продвигает резервный узел, чтобы трафик к подсети продолжал поступать.

Чтобы отфильтровать DNS-запросы из подсети с помощью Cloudflare Gateway:

1. Настройте DNS на вашем маршрутизаторе: Направьте DNS вашего маршрутизатора на IP адреса резолвера Gateway:

   • 172.64.36.1
   • 172.64.36.2

2. Добавление IP-маршрутов в маршрутизатор: На своём маршрутизаторе добавьте статические маршруты, направляющие IP адреса резолвера Gateway на локальный IP адрес узла Mesh. Это позволяет DNS трафику достигать Cloudflare через этот узел.

   • Назначение: 172.64.36.1 → Next hop: 10.0.0.1 (локальный узел Mesh)
   • Назначение: 172.64.36.2 → Next hop: 10.0.0.1

3. Настройте Split Tunnels: Убедитесь, что следующие IP-адреса маршрутизируются через Mesh-узел в вашем Split Tunnels конфигурация:

   • Внутренний IP-адрес DNS-резолвера подсети
   • Диапазон изначально разрешённых IP-адресов Gateway: 172.64.128.0/20 (IPv4) и 2606:4700:0cf1:4000::/64 (IPv6)

Gateway регистрирует DNS-запросы с указанием частного исходного IP-адреса устройства, с которого исходит запрос. Это можно использовать для создания политики Resolver для внутренних DNS-записей.

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

• Частное имя хоста (например, wiki.internal.local) в этом случае узел доставляет трафик на частный IP-адрес приложения в локальной сети. Это полезно, если IP-адрес приложения неизвестен или временный.
• Public hostname (например, www.example.com) в этом случае узел передаёт трафик в общедоступный интернет, используя собственный публичный IP-адрес. Это позволяет использовать узел Mesh как выделенную точку выхода для этого имени хоста.

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

Более подробно о потоке пакетов при маршрутизации по имени хоста см. в запись в блоге с анонсом ↗.

• Запустите поддерживаемую версию узла Mesh. Для маршрутизации по имени хоста узел Mesh должен использовать клиент Cloudflare One для Linux версии 2026.6.822.0 или новее.

• Настройте для узла Mesh профиль устройства чтобы использовать MASQUE. Маршрутизация по имени хоста не работает, если профиль устройства использует WireGuard.

• Включите Gateway proxy с TCP, UDP и ICMP:

  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.

• Направьте следующие диапазоны IPv4 через Cloudflare в Split Tunnel конфигурация оба профиль устройства узла Mesh и ваших профилей клиентских устройств. В режиме Include добавьте каждый диапазон. В режиме Exclude убедитесь, что ни один из них (или их родительские диапазоны) не исключён.

  Назначение	IPv4
  Диапазон IP-адресов устройств Mesh	100.96.0.0/12
  диапазон исходных IP-адресов Cloudflare	100.64.0.0/12

  Диапазон маршрутизации по имени хоста (token IP) (172.64.128.0/20) и все диапазоны IPv6 Cloudflare One автоматически направляется через Cloudflare и не требуют добавления вручную.

• Удалите домен верхнего уровня имени хоста из Local Domain Fallback на клиентских устройствах, поэтому DNS-запрос отправляется в Cloudflare Gateway для разрешения.

curl "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/zerotrust/routes/hostname" \
	--request POST \
	--header "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \
	--json '{
		"hostname": "wiki.internal.local",
		"tunnel_id": "{mesh_node_id}",
		"comment": "Internal wiki"
	}'

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

По умолчанию узел Mesh разрешает имя хоста через DNS-сервер, настроенный на его хост-машине (например, в /etc/resolv.conf в Linux): так же, как cloudflared делает. Если узел уже может разрешать имя хоста в приватный IP-адрес через этот резолвер, дополнительная настройка не требуется.

Если узел не может самостоятельно разрешить имя хоста, проще всего добавить запись в файл hosts узла (например, /etc/hosts в Linux), сопоставляющей имя хоста с его приватным IP-адресом. В отличие от Cloudflare Tunnel, узел Mesh не требуют запуска выделенного DNS-сервера:

10.0.0.50 wiki.internal.local

Вам нужен только Gateway политика Resolver когда DNS-запрос должен быть отправлен на другой connector, чем трафик приложения. Внутренний DNS-сервер может находиться за одним узлом Mesh или Cloudflare Tunnel, тогда как приложение доступно через другой. В этом случае:

1. Добавьте Маршрут CIDR для IP-адреса DNS-сервера, чтобы Gateway мог обращаться к нему через коннектор, на котором работает DNS-сервер (узел Mesh или Cloudflare Tunnel).
2. Создайте политика Resolver который отправляет DNS-запросы для этого имени хоста (или его домена) на указанный внутренний DNS-сервер.

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

После добавления маршрута для имени хоста защитите его с помощью Самостоятельно размещённое приложение Access или Политики Network Gateway. Подробности и примеры см. в Подключите частное имя хоста.

Начиная с 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 флаг для Отключено. Этот подход подходит для отдельных пользователей, но не для развёртывания в масштабах всей организации.