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

Trasy

Mesh node je ve výchozím nastavení dosažitelný jen prostřednictvím vlastního Mesh IP. Aby byla dostupná i další zařízení v podsíti za uzlem: servery, databáze, tiskárny nebo zařízení IoT, která nemohou spouštět Cloudflare One Client : přidejte trasu k uzlu. Uzel Mesh podporuje dva typy tras:

• Trasy CIDR : přesměruje provoz pro rozsah IP adres, soukromý (například 10.0.0.0/24) nebo veřejně, prostřednictvím uzlu.
• Trasy hostname : přitáhne provoz pro hostname k uzlu místo k IP adrese. To funguje pro privátní hostname (například wiki.internal.local), což je užitečné, pokud má aplikace neznámou nebo efemérní IP adresu, a také veřejný hostname (například www.example.com), což směruje provoz daného hostname přes uzel, odkud odchází přes veřejnou IP adresu uzlu.

Když přidáte trasu, Mesh node funguje jako brána: provoz směřující na inzerovaný CIDR nebo hostname se přesměruje na daný node, který jej doručí příslušnému hostiteli v lokální síti (případně jej odešle na veřejný internet).

Podporovány jsou trasy CIDR IPv4 i IPv6. Trasy IPv6 vyžadují, aby uzlu Mesh profil zařízení je nakonfigurován tak, aby používal MASQUE; nebudou fungovat, pokud profil zařízení místo toho používá WireGuard.

• Bez tras : Zařízení ve vaší síti Mesh mohou dosáhnout pouze samotného uzlu prostřednictvím jeho IP adresy Mesh. Tímto způsobem jsou dostupné služby běžící přímo na uzlu.
• S trasami : Zařízení ve vaší síti Mesh mohou dosáhnout jakéhokoli hostitele v podsíti za uzlem. Použijte tuto možnost, pokud máte infrastrukturu, na které nelze spustit 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

Pomocí tras CIDR můžete přesměrovat provoz z vašeho uzlu sítě Mesh na zařízení ve vaší místní síti.

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"

Aby provoz dosáhl vámi inzerovaného rozsahu CIDR, musí být tento rozsah směrován přes Cloudflare jak na uzlu Mesh, tak na klientských zařízeních.

V profilu zařízení uzlu Mesh se ujistěte, že inzerované trasy CIDR procházejí přes Cloudflare:

• Režim Include (doporučeno pro uzly Mesh): Přidejte CIDR do svého seznamu zahrnutí.
• Režim vyloučení: Odeberte CIDR (nebo jeho nadřazený rozsah) ze svého seznamu vyloučení.

Pokud například inzerujete 10.0.0.0/24 a váš seznam vyloučení Split Tunnels obsahuje 10.0.0.0/8, musíte odebrat 10.0.0.0/8 a znovu přidejte části 10.0.0.0/8 rozsah, který nechcete směrovat přes Cloudflare.

Stejnou konfiguraci Split Tunnel zopakujte i v profilech zařízení používaných vašimi klientskými zařízeními a zajistěte, aby inzerované trasy CIDR směřovaly přes Cloudflare.

Uzel Mesh přeposílá příchozí provoz z Cloudflare zařízením v podsíti. Nicméně pro zpětný provoz (odpovědi ze zařízení v podsíti zpět ke klientům Mesh), zařízení v podsíti potřebují trasu zpět k uzlu 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

Způsob konfigurace závisí na tom, kde je nainstalován uzel Mesh:

Pokud je uzel Mesh výchozí bránou podsítě (nebo je nainstalován na směrovači), není potřeba žádná další konfigurace. Veškerý provoz ze zařízení v podsíti se přirozeně směruje přes tento uzel.

Pokud je uzel Mesh běžným hostitelem v podsíti, nakonfigurujte směrovač podsítě tak, aby provoz Mesh odesílal přes tento uzel. Přidejte statickou trasu:

• Cíl: 100.96.0.0/12 (rozsah IP Mesh)
• Další skok: Lokální IP adresa podsítě uzlu Mesh (například 10.0.0.1)

Tím je zajištěno, že odpovědi klientům Mesh jsou přeposílány uzlu Mesh k doručení přes Cloudflare.

Když máte Mesh nodes na více pobočkách, zařízení v jedné podsíti se přes Cloudflare mohou dostat k zařízením v jiné podsíti.

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

Aby to fungovalo:

1. Každý Mesh node musí inzerovat lokální subnet jako Trasa CIDR aby Cloudflare věděl, na který uzel má provoz přeposílat.
2. CIDR bloky vzdálené podsítě musí na každém uzlu směrovat provoz přes Cloudflare. V nastavení uzlu Mesh Split Tunnel konfiguraci přidejte CIDR vzdálené pobočky do seznamu zahrnutí (nebo ho odeberte ze seznamu vyloučení).
3. Router každé pobočky potřebuje statické trasy směrující vzdálené podsítě na místní uzel Mesh:

Směrovač pobočky A:

• Cíl: 192.168.1.0/24 → Další skok: 10.0.0.1 (místní uzel Mesh)
• Cíl: 100.96.0.0/12 → Další skok: 10.0.0.1

Směrovač pobočky B:

• Cíl: 10.0.0.0/24 → Další skok: 192.168.1.1 (místní uzel Mesh)
• Cíl: 100.96.0.0/12 → Další skok: 192.168.1.1

Pro produkční nasazení typu site-to-site zvažte povolení vysoká dostupnost na každém uzlu. HA zajišťuje failover pro trasy CIDR inzerované daným uzlem: pokud aktivní replika přestane fungovat, Cloudflare povýší standby repliku, aby provoz do podsítě mohl dál plynule pokračovat.

Chcete-li filtrovat dotazy DNS z podsítě pomocí Cloudflare Gateway:

1. Nakonfigurujte DNS na svém routeru: Nasměrujte DNS svého routeru na IP adresy resolveru Gateway:

   • 172.64.36.1
   • 172.64.36.2

2. Přidání IP tras do routeru: Na svém routeru přidejte statické trasy směrující IP adresy resolveru Gateway na lokální IP adresu vašeho uzlu Mesh. Tím se DNS provoz dostane k Cloudflare přes tento uzel.

   • Cíl: 172.64.36.1 → Další skok: 10.0.0.1 (místní uzel Mesh)
   • Cíl: 172.64.36.2 → Další skok: 10.0.0.1

3. Nakonfigurujte Split Tunnels: Ujistěte se, že následující IP adresy jsou směrovány přes uzel Mesh ve vaší Split Tunnels konfigurace:

   • IP adresa interního resolveru DNS dané podsítě
   • Rozsah počátečních přeložených IP adres Gateway: 172.64.128.0/20 (IPv4) a 2606:4700:0cf1:4000::/64 (IPv6)

Gateway zaznamenává dotazy DNS se soukromou zdrojovou IP adresou zařízení, ze kterého požadavek pochází. To můžete využít k vytvoření zásady resolveru pro interní DNS záznamy.

Namísto inzerování rozsahu IP adres můžete přitahovat provoz pro konkrétní hostname na uzel Mesh. Když uživatel požaduje daný hostname, Cloudflare Gateway přiřadí počáteční přeložená IP adresa a směruje provoz přes uzel.

• Privátní hostname (například wiki.internal.local): uzel doručí provoz na privátní IP adresu aplikace v místní síti. Užitečné, pokud má aplikace neznámou nebo dočasnou IP adresu.
• Public hostname (například www.example.com): uzel odesílá provoz do veřejného internetu pomocí vlastní veřejné IP adresy. Díky tomu můžete uzel Mesh použít jako vyhrazený výstup pro daný hostname.

Trasy hostname nahrazují virtuální sítě jako způsob přístupu k prostředkům: protože je hostname globálně jedinečný, překrývající se hostname nejsou podporovány a hostname lze v jednu chvíli směrovat pouze na jeden uzel nebo tunel.

Podrobnější pohled na tok paketů při směrování podle hostname najdete v blogový příspěvek s oznámením ↗.

• Spusťte podporovanou verzi Mesh node. Směrování podle hostname vyžaduje, aby uzel Mesh běžel na linuxové verzi Cloudflare One Client 2026.6.822.0 nebo novější.

• Nakonfigurujte u uzlu Mesh profil zařízení k použití MASQUE. Směrování podle hostname nefunguje, pokud profil zařízení místo toho používá WireGuard.

• Povolte proxy Gateway s TCP, UDP a ICMP:

  1. Přejděte na Zásady provozu > Nastavení provozu.
  2. V Proxy a kontrola, zapněte Povolit předávání provozu přes Secure Web Gateway.
  3. Vyberte TCP.
  4. Vyberte UDP (vyžadováno pro směrování provozu přes proxy na interní DNS resolvery).
  5. (Doporučeno) Chcete-li proxovat provoz pro diagnostické nástroje, jako je ping a traceroute, vyberte ICMP. Také možná budete muset aktualizovat systém a umožněte provoz ICMP přes cloudflared.

  1. Přidejte následující oprávnění do svého cloudflare_api_token ↗:

     • Zero Trust Write

  2. Zapněte proxy TCP a/nebo UDP pomocí cloudflare_zero_trust_device_settings ↗ prostředek:

     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 nyní bude proxovat provoz ze zaregistrovaných zařízení, s výjimkou provozu vyloučeného ve vašem nastavení split tunelu. Další informace o tom, jak Gateway předává provoz, najdete v Proxy Gateway.

• Následující rozsahy IPv4 směrujte přes Cloudflare v Split Tunnel konfigurace obě profil zařízení uzlu Mesh a profily klientských zařízení. V režimu Include přidejte každý rozsah. V režimu Exclude se ujistěte, že žádný z nich (ani jejich nadřazené rozsahy) není vyloučen.

  Účel	IPv4
  Rozsah IP adres zařízení Mesh	100.96.0.0/12
  Rozsah zdrojových IP adres Cloudflare	100.64.0.0/12

  Rozsah směrování hostname (token IP) (172.64.128.0/20) a všechny rozsahy IPv6 Cloudflare One jsou automaticky směrováno přes Cloudflare a není třeba je přidávat ručně.

• Odstraňte doménu nejvyšší úrovně hostname z Local Domain Fallback na klientských zařízeních, takže dotaz DNS se odesílá k vyřešení do 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"
	}'

Pro privátní hostname, Gateway musí být schopen tento hostname přeložit na jeho privátní IP adresu. Způsob konfigurace závisí na tom, zda rozlišování DNS a provoz aplikace používají stejný connector nebo jiný connectory.

Mesh node ve výchozím nastavení překládá hostname pomocí DNS resolveru nakonfigurovaného na svém hostitelském počítači (například v /etc/resolv.conf na Linuxu): stejným způsobem cloudflared ano. Pokud uzel dokáže tímto resolverem přeložit název hostitele na jeho privátní IP adresu, další konfigurace není potřeba.

Pokud uzel nedokáže hostname přeložit sám, nejjednodušší možností je přidat záznam do souboru hosts uzlu (například /etc/hosts na Linuxu), který mapuje hostname na jeho privátní IP adresu. Na rozdíl od Cloudflare Tunnel uzel Mesh ne vyžadují, abyste provozovali vyhrazený DNS server:

10.0.0.50 wiki.internal.local

Potřebujete pouze Gateway zásada resolveru když musí být dotaz DNS odeslán na jiný connector než provoz aplikace. Interní DNS server se může nacházet za jedním uzlem Mesh nebo Cloudflare Tunnel, zatímco aplikace je dostupná přes jiný. V takovém případě:

1. Přidejte Trasa CIDR pro IP adresu DNS serveru, aby k němu Gateway mohl přistupovat přes connector, na kterém DNS server běží (uzel Mesh nebo Cloudflare Tunnel).
2. Vytvořte zásada resolveru která odesílá DNS dotazy pro daný hostname (nebo jeho doménu) na tento interní DNS server.

Pro veřejný hostname, rozlišování zajišťuje uzel Mesh: Gateway odešle DNS dotaz uzlu, ten jej přeloží prostřednictvím svého upstream poskytovatele DNS a poté paket nasměruje do cíle a opustí síť pod vlastní veřejnou IP adresou. Není potřeba žádný interní server DNS ani zásada resolveru.

Po přidání trasy hostname ji zabezpečte buď pomocí Self-hosted aplikace Access nebo Síťové zásady Gateway. Podrobnosti a příklady najdete v Připojení privátního hostname.

Počínaje Chrome 142 ↗, Local Network Access (LNA) omezuje požadavky z webů na lokální IP adresy. LNA je implementováno na úrovni enginu Chromium, takže to ovlivňuje všechny prohlížeče založené na Chromiu (například Microsoft Edge, Brave a Opera), nejen Google Chrome. To se může týkat účtů, jejichž Gateway rozsah počáteční přeložené IP adresy je stále čerpán z adresního prostoru Carrier-Grade NAT (CGNAT) (100.64.0.0/10), například starší výchozí rozsah 100.80.0.0/16, nebo vlastní rozsah nakonfigurovaný v rámci rozsahu CGNAT. Tyto prohlížeče považují takové adresy za patřící do místní sítě. Když web načtený z veřejné IP adresy odesílá dílčí požadavky na doménu přeloženou prostřednictvím počáteční přeložené IP adresy v tomto rozsahu, prohlížeč to vyhodnotí jako požadavek z veřejné sítě do místní sítě a zobrazí uživateli výzvu k povolení přístupu k zařízením v místní síti. Prohlížeč blokuje požadavky na tyto domény, dokud uživatel tuto výzvu nepotvrdí.

Nejčastěji k tomu dochází, když zásada egress odpovídá široce používaným doménám (například cloudfront.net nebo github.com), což způsobí, že se subrequesty z veřejných stránek přeloží do rozsahu CGNAT.

Účty používající aktuální výchozí počáteční přeložený rozsah IP adres (172.64.128.0/20) nejsou ovlivněny, protože tento rozsah je veřejný adresní prostor Cloudflare, nikoli CGNAT. Pokud byl váš účet vytvořen před touto změnou výchozího nastavení nebo pokud jste nakonfigurovali vlastní rozsah v prostoru CGNAT, přečtěte si Nakonfigurujte počáteční přeložené IP adresy a přejít na rozsah mimo CGNAT, místo abyste se spoléhali na následující řešení v prohlížeči.

Níže uvedená řešení používají zásady Google Chrome Enterprise. Pokud vaše organizace spravuje jiný prohlížeč založený na Chromiu, vyhledejte odpovídající nastavení v dokumentaci zásad daného prohlížeče.

Pokud dotčený požadavek pochází z iframe (například z aplikace vložené do portálu třetí strany), musí tento iframe deklarovat local-network-access oprávnění, aby se výzva prohlížeče zobrazila v nadřazeném rámci:

• Chrome 142-144: Použijte allow="local-network-access" atribut na prvku iframe.
• Chrome 145+: Oprávnění bylo rozděleno do allow="local-network" a allow="loopback-network".

Pokud jsou iframy vnořené, musí odpovídající atribut obsahovat každý iframe v řetězci. Vzhledem k tomu, že aplikace třetích stran mají nad atributy vlastních iframů kontrolu, nemusí to být pro koncového uživatele konfigurovatelné.

Chcete-li se tomuto problému vyhnout, zvolte jednu z následujících možností:

• Přepsání klasifikace rozsahu IP adres (Chrome 146+): Použijte LocalNetworkAccessIpAddressSpaceOverrides ↗ Zásada Chrome Enterprise pro přeřazení počátečního přeloženého rozsahu IP adres v prostoru CGNAT (například 100.80.0.0/16) jako veřejné. Jde o nejcílenější řešení, protože mění pouze klasifikaci původně přeloženého rozsahu IP adres, aniž by úplně vypínalo bezpečnostní kontroly.
• Povolit konkrétní adresy URL (Chrome 140+): Použijte LocalNetworkAccessAllowedForUrls ↗ Zásada Chrome Enterprise pro výjimku konkrétních webů z kontrol Local Network Access. Mějte na paměti, že https://* je platná položka pro zakázání kontrol u všech URL adres.
• Povolit konkrétní adresy URL (Chrome 146+): Použijte LocalNetworkAllowedForUrls ↗ Zásada Chrome Enterprise, která nahrazuje LocalNetworkAccessAllowedForUrls počínaje verzí Chrome 146.
• Vypnutí omezení Local Network Access (Chrome 142 až 152): Použijte LocalNetworkAccessRestrictionsTemporaryOptOut ↗ Zásada Chrome Enterprise pro úplné zrušení omezení Local Network Access. Jde o dočasnou zásadu, která bude po vydání Chrome 152 odstraněna.
• Zakažte feature flag prohlížeče Chrome: Přejděte na chrome://flags a nastavte Local Network Access Checks příznak pro Disabled. Tento přístup je vhodný pro jednotlivé uživatele, nikoli však pro nasazení v celém podniku.