INTEGRITY Dokumentace

← Cloudflare One / cloudflare-one / networks / connectors / cloudflare-tunnel / private-net / cloudflared

Připojení privátního hostname

Namísto správy statických seznamů IP adres a tras můžete uživatele připojit k privátním aplikacím HTTP i jiným než HTTP pomocí jejich hostname (například wiki.internal.local). Trasy privátního hostname jsou užitečné zejména tehdy, když má aplikace neznámou nebo efemérní IP adresu, což se často stává, když infrastrukturu poskytuje externí poskytovatel cloudu.

  1. Požadavky wiki.internal.local

  2. DNS dotaz

  3. Vrátí token IP adresu a poté přepíše cíl na skutečnou IP adresu.

    172.64.128.0/20
  4. Trasa hostname

  5. Předává provoz do vaší privátní sítě, nebo ho odesílá (egress) do veřejného internetu

  6. Privátní hostitel

    wiki.internal.local · 10.0.0.50

Když uživatel požaduje privátní hostname, Cloudflare Gateway přiřadí počáteční přeložená IP adresa a směrovat provoz přes váš tunel na správnou privátní IP adresu. Ve výchozím nastavení se tato IP adresa čerpá z veřejného rozsahu IPv4 vlastněného společností Cloudflare (172.64.128.0/20) místo prostoru Carrier-Grade NAT (CGNAT), takže to nespustí Omezení Local Network Access v Google Chrome. Můžete také nakonfigurovat vlastní rozsah pokud je v konfliktu s vaší stávající sítí. Podrobnosti o architektuře a toku paketů najdete v našem blogový příspěvek s oznámením ↗.

Podporované on-rampy/off-rampy

Tabulka níže shrnuje produkty Cloudflare One, které jsou kompatibilní se směrováním privátních hostname. Pokyny k interpretaci tabulky najdete v legendě tabulky.

✅ Produkt funguje bez výhrad
🚧 Produkt lze použít s určitými omezeními
❌ Produkt nelze použít

Konektivita zařízení

Koncoví uživatelé se mohou připojit k privátním hostname pomocí následujících vstupních bodů provozu:

Metoda on-ramp Kompatibilita
Cloudflare One Client ✅
Soubory PAC ✅
Browser Isolation ✅
Cloudflare Mesh ✅
Cloudflare WAN 🚧1

Dostupnost funkcí

Klientské režimy
Traffic and DNS mode
Systém Dostupnost Minimální verze klienta
Windows ✅ 2025.4.929.0
macOS ✅ 2025.4.929.0
Linux ✅ 2025.4.929.0
iOS ✅ 1.11
Android ✅ 2.4.2
ChromeOS ✅ 2.4.2

Poznámky pod čarou

  1. Není kompatibilní s Směrování ECMP. Aby směrování založené na hostitelském názvu fungovalo, musí dotazy DNS i výsledný síťový provoz dorazit do Cloudflare přes stejný tunel IPsec/GRE.
    ↩

Konektivita privátní sítě

Směrování privátních hostname funguje s níže uvedenými off-rampami. Ostatní off-rampy provozu vyžadují trasy založené na IP adresách.

Connector Kompatibilita Minimální verze
cloudflared ✅ 2025.7.0
Cloudflare Mesh ✅ 2026.6.822.0 (Linux)
Cloudflare WAN ❌

Připojení privátního hostname

Tato část se zabývá tím, jak povolit vzdálený přístup k aplikaci s privátním hostname pomocí cloudflared.

Předpoklady

Než se budete moci připojit k soukromým hostname, musíte povolit proxy Gateway.

  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.

Vaše zařízení musí do Cloudflare také přeposílat následující provoz:

Kroky konfigurace se liší v závislosti na vašem on-ramp zařízení:

Cloudflare One Client

  1. Ve svém WARP profil zařízení, nakonfigurujte Split Tunnels tak, aby počáteční přeložené IP adresy procházejí tunelem WARP. Konfigurace závisí na vašem Režim Split Tunnels:

    • Režim vyloučení: Odstranit 100.64.0.0/10 ze seznamu Split Tunnels. Doporučujeme opětovné přidání rozsahů IP adres které nejsou výslovně používány pro služby Cloudflare One. Tím se snižuje riziko konfliktu se stávajícími konfiguracemi privátní sítě, které mohou využívat adresní prostor CGNAT.
    • Režim Include: Přidejte položky Split Tunnel pro následující IP adresy:
      • IPv4: 172.64.128.0/20
      • IPv6: 2606:4700:0cf1:4000::/64

      Toto je výchozí rozsah. Můžete nakonfigurovat vlastní počáteční přeložený rozsah IP adres pro IPv4, pokud je v konfliktu s vaší stávající sítí.

  2. V Local Domain Fallback, odstraňte doménu nejvyšší úrovně pro svůj privátní hostname. Tím nastavíte WARP tak, aby odesílal DNS dotaz Cloudflare Gateway k překladu.

Cloudflare Mesh

Chcete-li nasměrovat provoz hostname na uzel Mesh místo na cloudflared tunel přidejte trasa hostname k uzlu. Výše uvedená počáteční přeložená IP adresa musí procházet přes Cloudflare jak u profilu uzlu Mesh, tak u profilu klientského zařízení. U privátního názvu hostitele musí navíc uzel umět tento název hostitele přeložit, a to prostřednictvím místního souboru hosts nebo zásady resolveru Gateway. Přečtěte si Trasy hostname.

Cloudflare WAN

  1. Ujistěte se, že výše uvedená počáteční přeložená IP adresa směrovat přes Cloudflare WAN na Cloudflare.
  2. Nasměrujte DNS resolver pro vaši síť Cloudflare WAN do Cloudflare Gateway.

1. Připojte aplikaci ke Cloudflare

  1. Přihlaste se do Cloudflare dashboardu a přejděte na Sítě > Tunnels.

    Přejděte na Tunnels ↗

  2. Vyberte Vytvořit tunel.

  3. Zadejte název tunelu. Doporučujeme zvolit název, který vystihuje typ prostředků, jež chcete přes tento tunel připojit (například enterprise-VPC-01).

  4. Vyberte Create Tunnel.

  5. Zvolte svůj operační systém, poté zkopírujte instalační příkaz a spusťte jej v terminálu na svém origin serveru.

  6. Počkejte, až se tunel připojí. Jakmile bude spojení navázáno, vyberte Pokračovat.

  1. Po připojení tunelu přejděte do jeho Trasy kartu a vyberte Přidat trasu, pak vyberte Privátní hostname.

  2. Zadejte plně kvalifikovaný název domény (FQDN), který reprezentuje vaši aplikaci (například wiki.internal.local).

    Omezení formátu hostname

    • Limit znaků: Musí mít méně než 255 znaků.
    • Podporované zástupné znaky: Jeden zástupný znak (*) je povolen a musí představovat úplný DNS label. Příklad: *.internal.local
    • Nepodporované zástupné znaky: Následující formáty zástupných znaků nejsou podporované:
      • Částečné zástupné znaky, jako například *-dev.internal.local nebo dev-*.internal.local.
      • Zástupné znaky uprostřed, například foo*bar.internal.local nebo foo.*.internal.local.
      • Více zástupných znaků v hostname, například *.*.internal.local.
    • Ořezávání zástupných znaků: Zástupné znaky na začátku (*) jsou oříznuty a je předpokládána implicitní tečka (.) se předpokládá. Například *.internal.local se uloží jako internal.local ale bude odpovídat všem subdoménám na úrovni zástupného znaku (pokrývá foo.internal.local ale ne foo.bar.internal.local).
    • Odstranění teček: Počáteční a koncové tečky (.) jsou povoleny, ale jsou oříznuty.

  3. Vyberte Save.

2. Nakonfigurujte překlad DNS

Když Gateway přijme požadavek na váš privátní hostname, musí tento hostname přeložit na privátní IP adresu. To lze nakonfigurovat dvěma způsoby, podle topologie vaší sítě.

Scénář A: Použít systémový resolver (výchozí)

Standardně cloudflared používá privátní překladač DNS nakonfigurovaný na svém hostitelském počítači (například v /etc/resolv.conf na Linuxu).

Pokud počítač, na kterém běží cloudflared už dokáže přeložit wiki.internal.local na jeho privátní IP adresu pomocí místního systémového resolveru, není nutná žádná další konfigurace. Můžete přeskočit na Krok 3.

Scénář B: Použít konkrétní privátní DNS server (pokročilé)

Pokud potřebujete cloudflared použít konkrétní interní server DNS odlišný od výchozího resolveru hostitele, musíte tento server DNS výslovně připojit ke Cloudflare přes Trasa IP/CIDR. Také budete muset nakonfigurovat Zásada resolveru Gateway a směrovat dotazy na tento konkrétní privátní DNS server.

  1. Chcete-li vytvořit trasu IP/CIDR pro server DNS:

    1. Přejděte na Sítě > Trasy.

      Přejděte na Trasy ↗

    2. Vyberte Přidání trasy CIDR.

    3. Zadejte soukromou IP adresu interního DNS překladače.

    4. Vyberte Cloudflare Tunnel, který se připojuje k síti, ve které se tento server DNS nachází.

    5. Vyberte Vytvořit.

  2. Chcete-li vytvořit zásadu resolveru:

    1. Přejděte na Zásady provozu > Zásady resolveru.
    2. Vyberte Vytvořit zásadu.
    3. Vytvořte výraz, který odpovídá privátnímu hostname:
      SelektorOperátorHodnota
      Hostvwiki.internal.local
    4. V části Nakonfigurujte vlastní DNS resolvery, zadejte privátní IP adresu svého interního serveru DNS.
    5. V rozbalovací nabídce vyberte - Private možnost směrování a virtuální síť přiřazené tunelu, který jste vybrali v předchozím kroku.
    6. Vyberte Vytvořit zásadu.

Všechna zařízení zaregistrovaná ve vaší organizaci Zero Trust se ve výchozím nastavení mohou připojit k vaší privátní síti přes Cloudflare Tunnel. Gateway můžete nakonfigurovat tak, aby kontroloval váš síťový provoz a na základě identity uživatele a stavu zařízení přístup buď blokoval, nebo povolil. Více o návrhu zásad se dozvíte v Zabezpečení první aplikace.

Abyste uživatelům Cloudflare One Client zabránili v přístupu k celé vaší privátní síti, doporučujeme vytvořit obecná bloková zásada Gateway pro váš soukromý IP prostor. Poté můžete přidat zásady Povolit s vyšší prioritou (v Access nebo Gateway), které uživatelům udělí přístup ke konkrétním aplikacím nebo IP adresám.

Můžete vytvořit Self-hosted aplikace Access pro váš soukromý název hostitele a nakonfigurujte Zásady Access v dané aplikaci. Tato možnost umožňuje spravovat přístup uživatelů společně s vašimi aplikacemi SaaS a dalšími webovými aplikacemi.

Možnost 2: Zásady brány firewall Gateway

Pokud dáváte přednost zabezpečení aplikace pomocí tradičního modelu firewallu, můžete vytvořit síťové zásady Gateway pomocí SNI nebo SNI Domain selektor. Pro další vrstvu ochrany přidejte zásadu Gateway DNS, která povolí nebo zablokuje Host nebo Doména od překladu.

Příklady síťových zásad

Následující příklad se skládá ze dvou zásad: první umožňuje vybraným uživatelům přístup k vaší aplikaci, druhá blokuje veškerý ostatní provoz.

  1. Povolit zaměstnance společnosti
Selektor Operátor Hodnota Logika Akce
SNI v wiki.internal.local And Allow
User Email matches regex .*@example.com
  1. Obecná zásada blokování
Selektor Operátor Hodnota Akce
Cílová IP adresa v 10.0.0.0/8 Block

Příklad zásady DNS

Selektor Operátor Hodnota Logika Akce
Host v wiki.internal.local And Allow
User Email matches regex .*@example.com

4. Otestujte připojení

Koncoví uživatelé se nyní k aplikaci dostanou přes její privátní hostname. Chcete-li se například připojit k privátní webové aplikaci, otevřete prohlížeč a přejděte na wiki.internal.local.

Řešení potíží

Pokud se nemůžete připojit, ověřte následující:

  1. Potvrzení překladu DNS: Ze zařízení ověřte, že se vám daří úspěšně přeložit privátní název hostitele:

    nslookup wiki.internal.local
    Server:		127.0.2.2
Address:	127.0.2.2#53

Non-authoritative answer:
Name:	wiki.internal.local
Address: 172.64.128.48

    Dotaz by se měl přeložit pomocí DNS proxy WARP a vrátí Gateway počáteční přeloženou IP adresu. Pokud se dotaz nepodaří přeložit nebo vrátí jinou IP adresu, zkontrolujte své Local Domain Fallback konfigurace a Zásady resolveru Gateway.

  2. Zkontrolujte protokoly Gateway: Zkontrolujte své Síťové protokoly Gateway a zjistit, zda připojení neblokuje nějaká zásada.

  3. Ověřit stav tunelu: Ověřte, že je váš tunel funkční a připojený, a to kontrolou stav tunelu.

  4. Otestovat konektivitu k počáteční přeložené IP adrese: Když se připojujete k aplikaci pomocí jejího privátního názvu hostitele, mělo by zařízení navázat připojení k počáteční přeložená IP adresa:

    curl -v4 http://wiki.internal.local
    * Trying 172.64.128.48:80...
* Connected to wiki.internal.local (172.64.128.48) port 80
...

    Pokud požadavek selže, ověřte, že počáteční přeložená IP adresa směruje přes tunel WARP. Můžete si také zkontrolovat protokoly tunelu potvrdit, že se požadavky směrují na privátní IP adresu aplikace.

Omezení

Google Chrome omezuje přístup k privátním 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.

Iframy

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:

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é.

Alternativní řešení

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