← Cloudflare One / cloudflare-one / traffic-policies

Pořadí vynucování

S Cloudflare Gateway můžete povolit a nakonfigurovat libovolnou kombinaci zásad DNS, sítě a HTTP.

flowchart TB
    %% Accessibility
    accTitle: Gateway order of enforcement
    accDescr: Flowchart describing the order of enforcement for Gateway policies.

 subgraph Resolution["Resolution"]
        dns2["1.1.1.1"]
        dns4["Custom resolver"]
        dns3["Resolver policies <br>(Enterprise users only)"]
        internal["Internal DNS"]
  end
 subgraph DNS["DNS"]
        dns1["DNS policies"]
        Resolution
  end
 subgraph HTTP["HTTP policies"]
        http1{{"Do Not Inspect policies"}}
        http2["Isolate policies  <br>(with Browser Isolation add-on)"]
        http3["Allow, Block, Do Not Scan, Quarantine, and Redirect policies, DLP, and anti-virus scanning"]
        https["HTTP or HTTPS?"]
  end
 subgraph Proxy["Proxy"]
        HTTP
        network1["Network policies"]
        nonhttp["Non-HTTP(S) traffic"]
  end
 subgraph Egress["Egress"]
        egress1["Egress policies <br>(Enterprise users only)"]
  end
    start(["Traffic"]) --> dns0[/"DNS query"/] & http0["Network connections"]
    dns0 ----> dns1
    dns1 -- Resolved by --> dns2
    dns1 --> dns3
    dns3 -- Resolved by --> dns4
    dns2 -----> internet(["Internet"])
    dns4 -----> internet
    dns4 ---> cloudflare["Private network services <br>(Cloudflare Tunnel, Cloudflare WAN, Cloudflare Mesh)"]
    http1 -- Do Not Inspect --> internet
    http1 -- Inspect --> http2
    http2 --> http3
    http0 --> magic["Cloudflare Network Firewall (Enterprise users only)"]
    magic --> egress1
    egress1 --> tcp["Check for origin availability (TCP SYN)"]
    tcp --> network1
    http3 --> internet
    https -- HTTPS --> http1
    https -- HTTP --> http2
    network1 --> https & nonhttp
    dns3 -- Resolved by --> internal & dns2
    nonhttp -----> internet

    https@{ shape: hex}
    http0@{ shape: lean-r}

Když se uživatel připojuje k serveru přes Gateway, Gateway nejprve naváže spojení TCP s cílovým serverem na portu, který uživatel požadoval. Protože provoz TCP prochází přes Cloudflare jako proxy, spojení, které Gateway naváže s origin serverem, je nezávislé na spojení, které si uživatelé navazují s Gateway. To znamená, že Gateway přiřadí uživatelovu spojení novou zdrojovou IP adresu a port a žádné údaje z uživatelova TCP handshake se nepřenášejí do TCP handshake s origin serverem.

Pokud se TCP připojení k cílovému serveru zdaří, Gateway uplatní zásady. Pokud zásady Gateway připojení povolí, Gateway uživatele k cílovému serveru připojí. Pokud zásady Gateway připojení zablokují, Gateway připojení ukončí a mezi uživatelem a cílovým serverem nebude přenášet žádná data. Pokud se TCP připojení k cílovému serveru nezdaří, Gateway neuplatní žádné zásady a bude opakovat TCP připojení od uživatele k serveru.

flowchart TD
    %% Accessibility
    accTitle: How Gateway proxy works
    accDescr: Flowchart describing how the Gateway proxy uses the Happy Eyeballs algorithm to establish TCP connections and proxy user traffic.

    %% Flowchart
    A[User's device sends TCP SYN to Gateway] --> B[Gateway sends TCP SYN to origin server]
    B --> C{{Origin server responds with TCP SYN-ACK?}}
    C -->|Yes| E[TCP handshakes completed]
    C -->|No| D[Connection fails]
    E --> F{{Connection allowed?}}
    F -->|Allow policy| G[Gateway proxies traffic bidirectionally]
    F -->|Block policy| H[Connection blocked by firewall policies]

    %% Styling
    style D stroke:#D50000
    style G stroke:#00C853
    style H stroke:#D50000

Připojení k Zero Trust se vždy zobrazí ve vašem protokoly síťových relací Zero Trust bez ohledu na úspěšnost připojení. Protože Gateway nekontroluje neúspěšná připojení, neobjeví se ve vašich Protokoly aktivity Gateway.

Protože Gateway odesílá TCP SYN na cílový server ještě před vyhodnocením zásad, zásady Gateway typu Network nebo HTTP Block nezabrání tomu, aby počáteční TCP SYN dorazil na cílový server. Pokud potřebujete zabránit odesílání paketů TCP SYN na konkrétní cílové IP adresy, můžete vytvořit Cloudflare Network Firewall pravidlo pro blokování provozu na úrovni paketů. Jak ukazuje vývojový diagram vynucování, Cloudflare Network Firewall vyhodnocuje provoz dříve, než Gateway zkontroluje dostupnost originu.

Chcete-li zablokovat pakety TCP SYN pro konkrétní cíl:

1. V Cloudflare dashboard ↗, přejděte na Zero Trust > Zásady brány firewall > Vlastní zásady.
2. Vyberte Přidat zásadu.
3. Vytvořte pravidlo s cílovou IP adresou nebo rozsahem CIDR, který chcete blokovat. Pokud chcete například blokovat veškerý provoz do 10.0.0.0/8, použijte výraz ip.dst in {10.0.0.0/8} s Block jako akci.
4. Vyberte Přidat novou zásadu.

Další informace o vytváření pravidel filtrování paketů najdete v Přidání zásad.

Gateway uplatňuje vaše zásady v následujícím pořadí:

1. Zásady DNS se selektory vyhodnocovanými před překladem
2. Zásady resolveru (pokud jsou k dispozici)
3. Zásady DNS se selektory vyhodnocovanými po překladu
4. Zásady egress (pokud je to relevantní)
5. Síťové zásady
6. Zásady HTTP

Zásady DNS a resolveru fungují samostatně. Pokud například web zablokujete zásadou DNS, ale nevytvoříte odpovídající zásadu HTTP, uživatelé k němu budou moci nadále přistupovat, pokud znají jeho IP adresu.

U proxovaných Provoz HTTP/3, Gateway aplikuje vaše zásady v následujícím pořadí:

1. Zásady DNS
2. Síťové zásady
3. Zásady HTTP

Gateway nejprve vyhodnocuje zásady DNS v pořadí překladu DNS, poté v pořadí priority.

Když Gateway přijme dotazy DNS, nejprve vyhodnotí zásady se selektory před rozpoznáním (pre-resolution), poté dotaz DNS rozpozná a následně vyhodnotí zásady se selektory po rozpoznání (post-resolution). To znamená, že přednost mají zásady, jejichž selektory se vyhodnocují ještě před rozpoznáním DNS. Následující sada zásad například zablokuje example.com:

I přes explicitní zásadu Allow zařazenou jako první má přednost zásada 2, protože Doména selektor se vyhodnocuje před překladem DNS.

Pokud zásada obsahuje selektory jak před rozlišením, tak po rozlišení, Gateway vyhodnotí celou zásadu až po rozlišení DNS. Informace o tom, kdy je který selektor vyhodnocen, najdete v seznam selektorů DNS.

Gateway vyhodnocuje síťové zásady v pořadí priority.

Gateway uplatňuje zásady HTTP na základě kombinace typ akce a pořadí priority:

1. Všechny zásady Do Not Inspect se vyhodnocují jako první, v pořadí podle priority.
2. Pokud se neshoduje žádná zásada, všechny zásady Isolate se vyhodnocují v pořadí podle priority.
3. Všechny zásady Allow, Block a Do Not Scan se vyhodnocují v pořadí podle priority.
4. Vyhodnocuje se tělo HTTP požadavku, včetně Data Loss Prevention (DLP), antivirové kontroly a sandboxingu souborů.

Toto pořadí vynucování umožňuje Gateway nejdřív určit, zda má dojít k dešifrování. Pokud web odpovídá zásadě Do Not Inspect, Gateway ho automaticky propustí a obejde tak všechny ostatní zásady HTTP.

Gateway dále kontroluje dešifrovaný provoz oproti vašim zásadám Isolate. Když uživatel odešle požadavek, který spustí zásadu Isolate, je požadavek přesměrován na vzdálený prohlížeč.

Gateway dále vyhodnocuje všechny zásady Allow, Block a Do Not Scan. Tyto zásady platí jak pro izolovaný, tak pro neizolovaný provoz. Pokud například example.com je izolován a example.com/subpage se blokuje, Gateway zablokuje podstránku (example.com/subpage) uvnitř vzdáleného prohlížeče.

Nakonec Gateway zkontroluje tělo HTTP požadavku: porovná ho se zásadami DLP a spustí antivirové skenování a File sandboxing. Pokud jsou nastaveny zásady DLP Block, výsledná akce Gateway se nemusí shodovat s akcí, kterou původně zaznamenala. Další informace najdete v Priorita zásad DLP.

Když zásady resolveru jsou přítomny, Gateway nejprve vyhodnotí veškeré zásady DNS se selektory pre-resolution a poté směruje veškeré dotazy DNS podle pořadí priority vašich zásad resolveru a nakonec vyhodnotí veškeré zásady DNS s post-resolučními selektory.

Pokud provoz neodpovídá žádné explicitní zásadě Allow ani Block, Gateway použije následující výchozí nastavení:

Protože výchozím chováním je povolit neshodující se provoz, řídí se Gateway permisivním modelem. Chcete-li přejít na restriktivní model (ve výchozím stavu blokovat, povolovat pouze výjimkami), vytvořte v příslušném tvůrci zásad obecnou zásadu Block s nejnižší prioritou a nad ni přidejte konkrétní zásady Allow.

Pořadí priority určuje prioritu jednotlivých zásad v nástroji pro tvorbu zásad DNS, sítě nebo HTTP. Gateway vyhodnocuje zásady vzestupně, počínaje nejnižší hodnotou.

Pořadí priority řídí princip první shody: jakmile provoz odpovídá zásadě Povolit nebo Blokovat, vyhodnocování se zastaví a žádná další zásada už rozhodnutí nemůže přepsat. Cloudflare proto doporučuje přiřadit nejvyšší prioritu nejkonkrétnějším zásadám a výjimkám a nejnižší prioritu nejobecnějším zásadám.

V dashboardu Cloudflare jsou zásady seřazeny podle priority od shora dolů v seznamu. Zásady začínají prioritou 1 a počítejte směrem nahoru. Pořadí priority zásad můžete upravit přetažením jednotlivých zásad v dashboardu.

Chcete-li aktualizovat prioritu zásady pomocí Cloudflare API, použijte Aktualizujte pravidlo Zero Trust Gateway endpoint k aktualizaci precedence .

V konfiguracích Gateway se zásadami DLP nejprve Gateway filtruje a zaznamenává provoz podle prvního nalezeného pravidla a teprve poté prohledá tělo HTTP požadavku, zda neobsahuje odpovídající obsah. Kvůli tomuto principu prvního nalezeného pravidla může Gateway u daného provozu zaznamenat jedno rozhodnutí a následně provést rozhodnutí opačné. Pokud je například provoz nejprve povolen zásadou Allow HTTP a poté zablokován zásadou DLP Block, Gateway zaznamená původní akci Allow, přestože požadavek nakonec zablokuje.

Pokud provoz Gateway směřuje na soukromou IP adresu chráněnou jako aplikace Access, tento provoz bude i tak vyhodnocen podle zásad Access cílové aplikace, i když se dříve shodovala zásada Gateway Allow. Zásady Gateway Block, které se na provoz vztahují, ukončí veškeré další vyhodnocování zásad. Toto chování je očekávané. Zásada Gateway Allow zásady Access nepřepisuje ani neobchází.

Předpokládejme, že máte seznam zásad uspořádaný v následujícím pořadí priority:

• Zásady DNS:

  Priorita	Selektor	Operátor	Hodnota	Akce
  1	Host	je	example.com	Block
  2	Host	je	test.example.com	Allow
  3	Doména	matches regex	.\	Block

• Zásady HTTP:

  Priorita	Selektor	Operátor	Hodnota	Akce
  1	Host	je	example.com	Block
  2	Host	je	test2.example.com	Do Not Inspect

• Síťové zásady:

  Priorita	Selektor	Operátor	Hodnota	Akce
  1	Cílový port	je	80	Block
  2	Cílový port	je	443	Allow
  3	SNI Domain	je	test.example.com	Block

Když uživatel přejde na https://test.example.com, Gateway provádí následující operace:

1. Vyhodnocení požadavku DNS podle zásad DNS:

   1. Zásada #1 neodpovídá test.example.com : přejděte k ověření zásady č. 2.
   2. Zásada #2 odpovídá, takže překlad DNS je povolen.
   3. Zásada #3 se nevyhodnocuje, protože již došlo k explicitní shodě.

2. Vyhodnocení požadavku HTTPS podle síťových zásad:

   1. Zásada #1 neodpovídá, protože port 80 se používá pro standardní HTTP, nikoli HTTPS.
   2. Zásada #2 odpovídá, takže je požadavek povolen a přeposlán přes proxy na upstream server.
   3. Zásada #3 se nevyhodnocuje, protože již došlo k explicitní shodě.

3. Vyhodnocení požadavku HTTPS podle zásad HTTP:

   1. Zásada #2 se vyhodnocuje jako první, protože Do Not Inspect má vždy přednost nad Allow a Block. Jelikož neexistuje shoda, přejděte ke kontrole zásady č. 1.
   2. Zásada #1 neodpovídá test.example.com. Protože neexistují žádné odpovídající zásady Block, požadavek projde filtrem HTTP.

Uživatel se proto může připojit k https://test.example.com.

Při uspořádávání zásad v Cloudflare dashboard ↗, Gateway automaticky vypočítá prioritu přeuspořádaných zásad.

Pokud přes API vytváříte zásadu a priorita v ní není výslovně definována, Gateway zásadám přiřadí prioritu počínaje 1000. Pokaždé, když se na konec pořadí přidá nová zásada, Gateway vypočítá aktuální nejvyšší prioritu v účtu a přičte náhodné celé číslo mezi 1 a 100 k 1000 tak, aby nyní měla v účtu nejvyšší prioritu. Chcete-li prioritu zásady aktualizovat ručně, použijte Aktualizujte pravidlo Zero Trust Gateway endpoint. Precedenci zásady můžete nastavit na jakoukoli hodnotu, která ještě není použita.

Změna pořadí v dashboardu Cloudflare nebo přes API může při použití Terraform.

Pořadí vykonávání zásad Gateway můžete spravovat pomocí Terraformu. Ve verzi 5 poskytovatele Terraform Cloudflare mohou uživatelé Gateway uvést své zásady v souboru Terraform s libovolnou požadovanou celočíselnou hodnotou priority. Cloudflare doporučuje začít prioritou 1000 a mezi prioritou každé zásady ponechte extra prostor pro budoucí zásady. Například:

resource "cloudflare_zero_trust_gateway_policy" "policy_1" {
  account_id = var.cloudflare_account_id
  # other attributes...
  precedence = 1000
}

resource "cloudflare_zero_trust_gateway_policy" "policy_2" {
  account_id = var.cloudflare_account_id
  # other attributes...
  precedence = 2000
}

resource "cloudflare_zero_trust_gateway_policy" "policy_3" {
  account_id = var.cloudflare_account_id
  # other attributes...
  precedence = 3000
}

Chcete-li se vyhnout chybám ve výpočtu priority při přeuspořádávání zásad pomocí Terraformu, přesouvejte zásady jednu po druhé před spuštěním terraform plan a terraform apply. Pokud používáte současně Terraform i Cloudflare dashboard nebo API, synchronizujte své zásady pomocí terraform refresh než změníte pořadí zásad v Terraformu. Případně můžete nastavit svůj účet na pouze pro čtení na Cloudflare dashboardu, čímž povoluje změny pouze pomocí API nebo Terraformu.