INTEGRITY Dokumentace

← Cloudflare One / cloudflare-one / access-controls / applications / non-http

Zabezpečení soukromé IP adresy nebo hostname

Aplikaci Access typu self-hosted můžete nakonfigurovat tak, aby spravovala přístup ke konkrétním IP adresám nebo hostname ve vaší privátní síti.

Předpoklady

Přidejte svou aplikaci do Access

  1. V Cloudflare dashboard ↗, přejděte na Zero Trust > Řízení přístupu > Aplikace.

  2. Vyberte Vytvořit novou aplikaci.

  3. Vyberte Vlastní hosting a soukromé.

  4. Chcete-li přidat aplikaci pomocí její privátní IP adresy:

    1. Vyberte Přidat privátní IP.

    2. V IP adresa, zadejte privátní IP adresu nebo rozsah CIDR, který představuje aplikaci (například 10.0.0.1 nebo 172.16.0.0/12).

    3. V Port, zadejte jeden port nebo rozsah portů používaný vaší aplikací (například 22 nebo 8000-8099).

      Seznamy portů oddělené čárkou (například 80, 443) nejsou podporovány. Chcete-li k určité IP adrese přidat více portů, můžete vybrat Přidat privátní IP a zopakujte IP adresu s druhým portem. Případně vytvořte novou aplikaci Access pro druhý port.

  5. Chcete-li přidat aplikaci pomocí jejího privátního hostname:

    1. Vyberte Přidat privátní hostname.
    2. V Hostname, zadejte privátní hostname aplikace (například wiki.internal.local). Můžete použít zástupné znaky se soukromými hostname pro ochranu více částí aplikace, které sdílejí kořenovou cestu.
    3. V Port, zadejte jeden port nebo rozsah portů používaný vaší aplikací (například 22 nebo 8000-8099).

    • Vlastní blokovací stránky: Vyberte, co uživatelé uvidí, když jim bude odepřen přístup k aplikaci.

      • Výchozí nastavení Cloudflare: Znovu načtěte přihlašovací stránka a zobrazí zprávu o blokování pod logem Cloudflare Access. Výchozí zpráva zní That account does not have access, nebo můžete zadat vlastní zprávu.
      • Redirect URL: Přesměrování na zadaný web.
      • Vlastní šablona stránky: Zobrazit vlastní blokovací stránka hostovaný v Cloudflare One.
    • Následující nastavení se vztahují pouze na soukromé hostname a vyžadují Dešifrování TLS Gateway:

  6. Vyberte Vytvořit.

Uživatelé se nyní mohou připojit k vaší privátní aplikaci po ověření pomocí Cloudflare Access.

Ověřovací tok

Průběh ověřování závisí na protokolu dané aplikace.

Aplikace HTTPS

Pokud Dešifrování TLS Gateway je zapnuto a uživatel přistupuje k aplikaci HTTPS na portu 443, Cloudflare Access zobrazí přihlašovací stránku v prohlížeči a vydá token aplikace k vašemu origin serveru. Jde o stejný ověřovací postup založený na cookies, jaký používá self-hosted veřejné aplikace.

Pokud Dešifrování TLS Gateway je vypnuto, správa relací je zpracováváno v Cloudflare One Client místo v prohlížeči.

Aplikace využívající nešifrované HTTP

U aplikací poskytovaných přes nešifrované HTTP na portu 80, Cloudflare Access zobrazí přihlašovací stránku v prohlížeči a vydá token aplikace, stejně jako u aplikací HTTPS s dešifrováním Gateway TLS. Dešifrování Gateway TLS zde není potřeba, protože provoz už je nešifrovaný.

Ostatní aplikace, které nepoužívají HTTP

U aplikací, které nejsou HTTP ani HTTPS (například SSH, RDP nebo libovolné TCP/UDP), spravuje relaci Cloudflare One Client. Uživatelé obdrží Authentication required vyskakovací oznámení z Cloudflare One Client. Když uživatel oznámení vybere, Cloudflare One Client otevře okno prohlížeče s přihlašovací stránkou Access.

Ujistěte se, že váš operační systém povoluje oznámení pro Cloudflare One Client. Pokud máte zapnutý režim soustředění, nerušit nebo sdílení obrazovky, zařízení nemusí oznámení zobrazovat. Chcete-li na zařízeních macOS se softwarem DisplayLink zapnout oznámení klienta, může být nutné povolit systémová oznámení při zrcadlení displeje. Další informace najdete v dokumentace k systému macOS ↗.

Pořadí priority

Zásady Access oproti zásadám Gateway

Cloudflare ve výchozím nastavení vyhodnotí zásady aplikace Access až po vyhodnocení všech Síťové zásady Gateway. Chcete-li vyhodnocovat aplikace Access před nebo po konkrétních zásadách Gateway:

  1. V Cloudflare dashboard ↗, přejděte na Zero Trust > Zásady provozu > Zásady brány firewall. V Síť, vytvořit síťovou zásadu s následující konfigurací:

    Selektor Operátor Hodnota Akce
    Přístup k privátní aplikaci je Present Allow

  2. Aktualizujte zásady pořadí priority pomocí dashboardu nebo API.

Privátní hostname vs. privátní IP

Aplikace Access definovaná soukromým hostname má přednost před aplikací Access definovanou soukromou IP adresou. Předpokládejme například, že aplikace App-1 směřuje na wiki.internal.local a App-2 směřuje na 10.0.0.1, ale wiki.internal.local se překládá na 10.0.0.1. Uživatelé, kteří přejdou na wiki.internal.local nikdy neodpovídá aplikaci App-2, ta bude povolena nebo blokována výhradně na základě zásad Access pro aplikaci App-1 (a Zásady Gateway).

Omezení

Browser Isolation není kompatibilní s aplikacemi, které neběží na 443 porty

Browser Isolation není kompatibilní s self-hosted privátní aplikace které používají privátní IP adresy nebo hostname na jiných portech než 443. Pokud se pokusíte získat přístup k self-hosted aplikacím na jiných než 443 porty povede k zobrazení blokovací stránky Gateway.

Chcete-li používat Browser Isolation pro aplikaci na privátní IP adrese s ne-443 port, nakonfigurujte aplikace privátní sítě místo toho.

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í: