Перейти к основному содержимому

Управление политиками

Политика объединяет правила фаервола и host selector: правила определяют действие над трафиком, а селектор — хосты, на которых они работают. После сохранения CP компилирует новое поколение правил и отправляет его затронутым хостам.


Из чего состоит политика

  • Имя — название политики, например «Закрыть админ-порты».
  • Правила (Rules) — сами разрешения/запреты. Одна политика может содержать несколько правил.
  • Кому применяется (Host selector) — на какие машины действует. Разбор этой части — в отдельном гайде «Кому применяется политика».
  • Приоритет (Priority) — кто главнее, если несколько политик спорят за один и тот же трафик (см. ниже).
  • Область по интерфейсам (Interface scope) — на многоинтерфейсном хосте правила действуют либо на всех подключённых NIC (поле пустое), либо только на именованных. Пустое поле — обычный случай. Разбор — в гайде «Многоинтерфейсные хосты и per-interface политика».

Одно правило — из чего собирается

Новое правило добавляется через Rules → Add rule:

ПолеЗначенияНазначение
Directioningress / egressВходящий трафик (к машине) или исходящий (с машины)
Actionallow / deny / logРазрешить, запретить или записать событие и пропустить пакет
Protocoltcp / udp / icmp / anyТип трафика; any — любой
Dst portsнапр. 8080, 3000-4000На какие порты (можно диапазон)
Src portsнапр. 443С каких портов идёт трафик (обычно не нужно)
Match conditionsадреса/подсетиОграничить конкретными IP/сетями (необязательно)
Logвкл/выклЗаписывать срабатывания в журнал событий

Пример: Direction ingress, Action deny, Protocol tcp, Dst ports 8080 → «запретить входящие подключения на порт 8080». После сохранения правило применяется на машинах политики.

Дополнительные условия совпадения

Помимо базовых полей, правило (match) поддерживает:

  • Protocoltcp / udp / icmp / icmpv6 / any. Другие значения и неизвестные поля внутри match отклоняются с HTTP 400, а не расширяют правило.
  • Dst ports / Src ports — отдельные порты и диапазоны, напр. ["443","8000-8100"].
  • Dst CIDRs / Src CIDRs — подсети; поддерживаются IPv4 и IPv6 (v6-энфорс при QF_DROP_IPV6=false на хосте, по умолчанию v6 режется целиком).
  • Object-group по ссылке — вместо перечисления адресов/портов можно указать несколько групп: поля *_ip_set_ids / *_port_set_ids / *_host_set_ids принимают массив UUID, CP объединяет их адреса/порты. API также принимает singular-ключи с одним UUID.
  • TCP-флаги — проверка флагов: tcp_flags_mask + tcp_flags_match, например mask=SYN|ACK, match=SYN (только SYN).
  • State — состояние соединения (conntrack): new / established / related / invalid. Для одного состояния используется поле state, для набора — states, например ["established","related"]. Поток совпадает с любым из перечисленных состояний. related означает трафик, связанный с отслеживаемым потоком, например ICMP-ошибку со ссылкой на established-соединение. Правило без state не зависит от conntrack.
  • No-track (notrack) — при true поток, разрешённый этим правилом, не заносится в таблицу conntrack (экономит слоты LRU на высоко-объёмном stateless-трафике, напр. DNS). На вердикт (allow/deny) не влияет. ⚠️ notrack действует по НАПРАВЛЕНИЮ правила. conntrack двунаправлен (общий канонический ключ), поэтому чтобы поток не трекался целиком, notrack нужен на обоих правилах — ingress (dst_ports) и egress (src_ports); иначе ответное направление создаст запись через своё правило или default-allow.

После объединения object groups в одном правиле допускается не более 8 диапазонов source ports и 8 диапазонов destination ports. Большие ipset и hostset выносятся в LPM-trie; её ёмкость — 65 536 записей отдельно для IPv4 и IPv6 на бандл хоста. Если итоговый бандл превышает лимит, CP не отправляет его агенту: хост продолжает исполнять last-good generation, а несхождение поколений показывает неприменённую правку.

Пустой список в явно выбранной object group не означает «любой адрес/порт». ipset и portset должны содержать хотя бы один элемент — create/update с пустым spec возвращает HTTP 400. hostset динамический и может временно не выбирать ни одного хоста (либо у matched-хостов ещё нет dataplane-IP); тогда CP помечает constraint как unresolved, не выпускает новый bundle, а агент продолжает исполнять last-good generation. После появления хотя бы одного IP CP автоматически пересчитывает набор. Это отличается от отсутствующего поля match: только отсутствующее ограничение означает ANY.

⚠️ state=established зависит от conntrack. Таблица conntrack очищается при рестарте агента, ручном сбросе, LRU-вытеснении и смене QF_CONNTRACK_MAX. После очистки пакет существующей TCP-сессии без SYN не создаёт запись и не совпадает с state=established; он переходит к следующим правилам или к default ALLOW. Если ниже стоит catch-all deny, существующая сессия оборвётся. Нужное поведение после очистки следует закрепить stateless-правилом по протоколу, адресу и порту.


Кто главнее: приоритет и порядок

На одной машине может действовать несколько правил (из одной или разных политик). Когда для пакета подходит несколько — побеждает первое подходящее по приоритету:

  1. Сначала — политики с меньшим числом в Priority (меньше = главнее).
  2. Внутри политики — правила с меньшим Priority.

Как только правило сработало — остальные для этого пакета не смотрятся.

Поведение по умолчанию: если ни одно правило не подошло, трафик пропускается. Фаервол закрывает только трафик, совпавший с явным правилом deny.

⚠️ Правило «запретить всё» без адреса или порта блокирует весь поддерживаемый трафик. Агент сохраняет исходящие соединения к IPv4-адресам Control Plane, разрешённым при его старте, но это не защищает SSH и другие административные каналы. Перед сохранением нужны разрешающие правила для них, проверка зоны влияния и этап наблюдения с действием log. Для обычной сегментации безопаснее ограничивать deny портами и адресами.


Создать политику — по шагам

  1. Открыть Policies → Новая политика.
  2. Задать имя и при необходимости приоритет.
  3. В блоке Селектор хостов → Лейблы задать область действия. При создании доступны лейблы; отдельные хосты и группы добавляются после первого сохранения.
  4. В блоке Правила добавить правила и заполнить действие, направление и условия.
  5. Сохранить политику. Пустой selector означает весь парк и требует подтверждения вводом имени политики.

После сохранения правила компилируются и отправляются выбранным хостам. Офлайн-хост получит новое поколение после подключения.


Зона влияния показывает изменения до применения

Для существующей политики изменения сначала сохраняются как черновик. После действия Зафиксировать изменение и посмотреть зону влияния консоль показывает затронутые хосты и добавленные, удалённые или изменённые правила. Черновик ещё не меняет enforcement. После проверки он применяется отдельным действием Применить.

Проверка особенно важна для политики, назначенной группе или всему парку. Новая политика сохраняется без черновика и отдельной зоны влияния, поэтому безопасный первый шаг для широкой области — действие log вместо deny.

REST API также предоставляет POST /policies/{id}/preview: он возвращает добавленные, удалённые и изменённые правила без применения.


Изменение и удаление

После изменения правил или селектора CP пересчитывает набор правил затронутых хостов. Подключённые хосты получают новое поколение; офлайн-хосты синхронизируются после подключения.

Изменение политики, её селектора или связанной группы объектов пересчитывает правила на всех затронутых хостах. Подключённые хосты получают новое поколение автоматически.


Версии и откат

Каждое сохранение (PUT) политики создаёт снимок предыдущего состояния.

  • GET /policies/{id}/versions — список версий.
  • POST /policies/{id}/versions/{v}/revert — восстановить выбранную версию; откат пересчитывает и рассылает правила так же, как обычное применение.

Кнопка Delete policy удаляет политику из следующего поколения правил всех затронутых хостов. До синхронизации офлайн-хост продолжает исполнять last-good generation.


Типовые сценарии

Закрыть порты на всей группе машин

  1. Создать группу «web-серверы», задать ей отличительные лейблы и добавить хосты.
  2. Создать политику с теми же лейблами в selector и безопасным правилом log.
  3. После первого сохранения открыть вкладку Редактирование и при необходимости добавить группу в таблице Группы. Это сохранит _groupId для отображения.
  4. Зафиксировать изменения, проверить Зону влияния и применить черновик.

Назначение группы сохраняет её текущие лейблы в selector. Поэтому блокировка применяется к участникам группы и к другим хостам с тем же набором эффективных лейблов. Новый участник наследует лейблы группы и обычно попадает под политику автоматически. Подробности — в руководстве по selector.

Политика на несколько групп

В таблице Группы добавляется несколько групп. Их блоки объединяются по OR: политика действует на хосты, которые соответствуют лейблам хотя бы одной группы.

Политика на группу + одну отдельную машину

Добавить группу в таблице Группы и машину в таблице Хосты. Политика действует на явно выбранную машину и на хосты, соответствующие лейблам группы.

Разрешить узкий доступ, запретить остальной

Внутри одной политики: правило allow с меньшим Priority (например разрешить порт 22 только из внутренней сети) + правило deny с большим Priority (запретить порт 22 отовсюду). Первым срабатывает более приоритетный allow для «своих», всем остальным достаётся deny.

Временно снять политику с машины

Во вкладке Редактирование снять строку в таблице Хосты или Группы, зафиксировать изменение и проверить зону влияния. Если удалено последнее условие, selector становится пустым и выбирает весь парк. В этом случае консоль потребует подтверждение, а безопасный способ отключить политику — удалить её. Через API временно отключённую область можно представить как {"anyOf":[]}.


Частые вопросы

Что произойдёт, если не заполнить Host selector? Пустой selector выбирает весь парк. Консоль потребует ввести имя политики для подтверждения. Selector {"anyOf":[]} через API не выбирает ни одного хоста.

Правило deny не срабатывает. Скорее всего выше по приоритету стоит allow, который перехватывает трафик первым. Разбирается по Priority правил и политик — меньше число = раньше проверяется.

Изменения долго не доходят до машины. Состояние доставки видно по поколениям и статусу хоста. Офлайн-хост получит правила после подключения; диагностика описана в справочнике статусов.

Хочу больше 8 диапазонов портов в одном правиле. В одном правиле — до 8 диапазонов портов на направление (техническое ограничение). Нужно больше — разбивается на несколько правил.

Что происходит с политикой после удаления группы? Control Plane удаляет из selector блок этой группы, но сохраняет политику. Если это был последний блок, остаётся {"anyOf":[]} и политика не выбирает ни одного хоста.