← Cloudflare One / cloudflare-one / traffic-policies

Порядок применения

С помощью Cloudflare Gateway вы можете включите и настройте любую комбинацию политик DNS, сети и 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}

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

Если TCP-соединение с сервером назначения устанавливается успешно, Gateway применяет политики. Если политики Gateway разрешают соединение, Gateway подключает пользователя к серверу назначения. Если политики Gateway блокируют соединение, Gateway завершает соединение и не передаёт данные между пользователем и сервером назначения. Если TCP-соединение с сервером назначения установить не удаётся, Gateway не применяет никаких политик и повторяет попытки TCP-соединения между пользователем и сервером.

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

Подключения к Zero Trust всегда отображаются в вашем журналы сетевых сессий Zero Trust независимо от успешности подключения. Поскольку Gateway не проверяет неудачные подключения, они не будут отображаться в вашем Журналы активности Gateway.

Поскольку Gateway отправляет пакет TCP SYN на сервер назначения ещё до оценки политик, политики Block уровня Network или HTTP в Gateway не предотвращают доставку исходного пакета TCP SYN до сервера назначения. Если необходимо запретить отправку пакетов TCP SYN на определённые IP-адреса назначения, можно создать Cloudflare Network Firewall правило, чтобы блокировать трафик на уровне пакетов. Как показано на блок-схема применения, Cloudflare Network Firewall проверяет трафик до того, как Gateway проверит доступность источника.

Чтобы блокировать пакеты TCP SYN, направленные к определённому узлу назначения:

1. В Панель управления Cloudflare ↗, перейдите в Zero Trust > Политики Firewall > Пользовательские политики.
2. Выберите Добавление политики.
3. Создайте правило с IP-адресом назначения или диапазоном CIDR, который нужно заблокировать. Например, чтобы заблокировать весь трафик к 10.0.0.0/8, используйте выражение ip.dst in {10.0.0.0/8} с Block действие.
4. Выберите Добавить новую политику.

Дополнительные сведения о создании правил фильтрации пакетов см. в Добавление политик.

Gateway применяет ваши политики в следующем порядке:

1. Политики DNS с селекторами, которые оцениваются до разрешения
2. Политики резолвера (если применимо)
3. Политики DNS с селекторами, которые оцениваются после разрешения
4. Политики Egress (если применимо)
5. Сетевые политики
6. Политики HTTP

Политики DNS и резолвера действуют независимо друг от друга. Например, если вы заблокируете сайт политикой DNS, но не создадите соответствующую политику HTTP, пользователи всё равно смогут открыть этот сайт, если знают его IP-адрес.

Для проксируемых Трафик HTTP/3, Gateway применяет ваши политики в следующем порядке:

1. Политики DNS
2. Сетевые политики
3. Политики HTTP

Gateway сначала оценивает политики DNS в порядке разрешения DNS, а затем в порядок приоритета.

При получении DNS-запросов Gateway сначала применяет политики с селекторами, оцениваемыми до разрешения имени, затем разрешает DNS-запрос и применяет политики с селекторами, оцениваемыми после разрешения имени. Это означает, что политики с селекторами, оцениваемыми до разрешения DNS, имеют приоритет. Например, следующий набор политик заблокирует example.com:

Несмотря на явную политику Allow, стоящую первой, приоритет имеет политика 2, поскольку Домен селектор проверяется до разрешения DNS.

Если политика содержит и селекторы до разрешения имени, и селекторы после разрешения имени, Gateway оценивает всю политику после разрешения DNS. Информацию о том, когда оценивается каждый селектор, см. в список DNS-селекторов.

Gateway оценивает политики Network в порядок приоритета.

Gateway применяет политики HTTP на основе сочетания тип действия и порядок приоритета:

1. Все политики Do Not Inspect оцениваются первыми, в порядке приоритета.
2. Если ни одна политика не совпадает, все политики Isolate оцениваются в порядке приоритета.
3. Все политики Allow, Block и Do Not Scan оцениваются в порядке приоритета.
4. Оценивается тело HTTP-запроса, включая проверку Data Loss Prevention (DLP), антивирусное сканирование и песочницу для файлов.

Такой порядок применения позволяет Gateway сначала определить, должна ли выполняться расшифровка. Если сайт соответствует политике Do Not Inspect, он автоматически пропускается через Gateway и обходит все остальные HTTP-политики.

Далее Gateway проверяет расшифрованный трафик на соответствие вашим политикам изоляции. Когда запрос пользователя запускает политику изоляции, этот запрос перенаправляется на удалённый браузер.

Далее Gateway применяет все политики Allow, Block и Do Not Scan. Эти политики распространяются как на изолированный, так и на неизолированный трафик. Например, если example.com изолируется и example.com/subpage заблокирован, Gateway заблокирует и вложенную страницу (example.com/subpage) внутри удалённого браузера.

Наконец, Gateway проверяет тело HTTP-запроса, сопоставляя его с политиками DLP, а также выполняет антивирусное сканирование и помещает файлы в песочницу. Если применяются политики блокировки DLP, действие, которое Gateway выполнит в итоге, может не совпадать с тем, что было изначально записано в журнал. Дополнительную информацию см. в Приоритет политик DLP.

Когда политики Resolver присутствуют, Gateway сначала оценивает политики DNS с селекторами pre-resolution, а затем направляет запросы DNS согласно порядок приоритета ваших политик DNS-резолвера и в последнюю очередь оценивает любые DNS-политики с селекторами, применяемыми после разрешения имени.

Если трафик не соответствует ни одной явной политике Allow или Block, Gateway применяет следующие настройки по умолчанию:

По умолчанию несовпавший трафик разрешается, поэтому Gateway работает по разрешительной модели. Чтобы перейти к ограничительной модели (блокировка по умолчанию, разрешение как исключение), создайте универсальную политику Block с самым низким приоритетом в соответствующем конструкторе политик и добавьте над ней отдельные политики Allow.

Порядок приоритета определяет приоритет отдельных политик в конструкторе политик DNS, сети или HTTP. Gateway оценивает политики в порядке возрастания, начиная с наименьшего значения.

Порядок приоритета соответствует принципу первого совпадения. Как только трафик соответствует политике Allow или Block, оценка прекращается, и ни одна из последующих политик не может изменить это решение. Поэтому Cloudflare рекомендует присваивать самым специфичным политикам и исключениям наивысший приоритет, а самым общим политикам, наименьший.

В панели управления Cloudflare политики упорядочены по приоритету сверху вниз списка. Приоритет политик начинается с 1 и считайте дальше. Порядок приоритета можно изменить, перетаскивая отдельные политики в дашборде.

Чтобы обновить приоритет политики с помощью Cloudflare API, используйте Обновите правило Zero Trust Gateway конечную точку, чтобы обновить precedence поле.

В конфигурациях Gateway с политиками DLP Gateway сначала фильтрует и логирует трафик по принципу первого совпадения, а затем проверяет тело HTTP-запроса на соответствующее содержимое. Из-за принципа первого совпадения Gateway может зафиксировать одно решение по трафику, а затем принять противоположное. Например, если трафик сначала разрешён политикой Allow HTTP, а затем заблокирован политикой DLP Block, Gateway запишет в лог исходное действие Allow, хотя запрос в итоге будет заблокирован.

Если трафик Gateway направляется на приватный IP-адрес, защищённый как приложение Access, этот трафик всё равно будет оценён политиками Access целевого приложения, даже если ранее сработала политика Gateway Allow. Политики Gateway Block, которые соответствуют трафику, прекращают дальнейшую оценку любых других политик. Это ожидаемое поведение: политика Gateway Allow не отменяет и не обходит политики Access.

Предположим, что у вас есть список политик, расположенных в следующем порядке приоритета:

• Политики DNS:

  Приоритет	Селектор	Оператор	Значение	Действие
  1	Host	является	example.com	Block
  2	Host	является	test.example.com	Allow
  3	Домен	matches regex	.\	Block

• Политики HTTP:

  Приоритет	Селектор	Оператор	Значение	Действие
  1	Host	является	example.com	Block
  2	Host	является	test2.example.com	Do Not Inspect

• Политики Network:

  Приоритет	Селектор	Оператор	Значение	Действие
  1	Порт назначения	является	80	Block
  2	Порт назначения	является	443	Allow
  3	SNI Domain	является	test.example.com	Block

Когда пользователь переходит на https://test.example.com, Gateway выполняет следующие операции:

1. Оценка DNS-запроса по DNS-политикам:

   1. Политика №1 не соответствует test.example.com : переходите к проверке политики №2.
   2. Политика №2 соответствует, поэтому DNS-запрос разрешается.
   3. Политика №3 не оценивается, поскольку явное совпадение уже было найдено.

2. Оценка HTTPS-запроса по сетевым политикам:

   1. Политика №1 не соответствует, потому что порт 80 используется для стандартного HTTP, а не HTTPS.
   2. Политика №2 соответствует, поэтому запрос разрешается и проксируется на вышестоящий сервер.
   3. Политика №3 не оценивается, поскольку явное совпадение уже было найдено.

3. Оценка HTTPS-запроса по HTTP-политикам:

   1. Политика №2 оценивается первой, поскольку Do Not Inspect всегда имеет приоритет над Allow и Block. Поскольку совпадение не найдено, переходите к проверке Policy #1.
   2. Политика №1 не соответствует test.example.com. Поскольку подходящих политик Block нет, запрос проходит через HTTP-фильтр.

Поэтому пользователь может подключиться к https://test.example.com.

При упорядочивании политик в Панель управления Cloudflare ↗, Gateway автоматически пересчитывает приоритет для переупорядоченных политик.

При использовании API для создания политики, если приоритет не задан явно, Gateway назначает политикам приоритет начиная с 1000. Каждый раз, когда новая политика добавляется в конец списка, Gateway вычисляет текущий наибольший приоритет в аккаунте и добавляет случайное целое число от 1 до 100 к 1000 чтобы теперь она имела максимальный приоритет в учётной записи. Чтобы вручную изменить приоритет политики, используйте Обновите правило Zero Trust Gateway конечная точка. Вы можете задать для приоритета политики любое значение, которое ещё не используется.

Изменение порядка в панели управления Cloudflare или через API может привести к проблемам конфигурации при использовании Terraform.

Порядок выполнения политик Gateway можно настроить с помощью Terraform. Начиная с версии 5 провайдера Terraform Cloudflare пользователи Gateway могут указывать политики в файле Terraform с произвольным целочисленным значением приоритета. Cloudflare рекомендует начинать с приоритета 1000 и добавляя дополнительный интервал между приоритетами каждой политики для будущих политик. Например:

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
}

Чтобы избежать ошибок вычисления приоритета при изменении порядка политик с помощью Terraform, перемещайте политики по одной, прежде чем запускать terraform plan и terraform apply. Если вы используете одновременно Terraform и панель управления Cloudflare или API, синхронизируйте свои политики с terraform refresh перед изменением порядка политик в Terraform. Либо вы можете настроить свой аккаунт так, чтобы доступно только для чтения в панели управления Cloudflare, разрешая изменения только через API или Terraform.