> ## Documentation Index
> Fetch the complete documentation index at: https://docs.axottle.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Egress Guard

> Контроль опасных исходящих портов на нодах: фиксированный каталог категорий, статус применения и сверка дрейфа.

Egress Guard — намеренно компактный контроль опасного исходящего трафика с нод. Вы включаете и выключаете категории из фиксированного каталога опасных портов; панель компилирует выбор в версионированный набор правил с контрольным хэшем, агент устанавливает правила на ноде и возвращает хэш того, что **фактически** установлено в ядре. Панель считает защиту применённой только когда желаемый и фактический хэши совпали.

<Info>Для кого: администратор панели / SRE. Требуемые права: сессия администратора; на ноде нужен агент с поддержкой firewall-операций.</Info>

<Note>
  Не путайте Egress Guard с «external transit egress blocks» — это другая функция: VLESS-переходы (egress-хопы) в графе Connection Unit, см. [Маршрутизация Connection Units](/ru/connection-units/routing).
</Note>

## Принцип «сохранено ≠ применено»

Изменения сначала сохраняют желаемую политику. Состояние её применения по нодам отображается отдельно во вкладке **Применение**.

## Каталог категорий

Каталог фиксированный — свободного списка портов в стандартном интерфейсе нет, и это осознанно:

| Категория                                 | Порты                                           | Действие по умолчанию                            |
| ----------------------------------------- | ----------------------------------------------- | ------------------------------------------------ |
| Почтовый SMTP                             | TCP 25, 465, 587, 2525                          | Блокируется (reject) — **включено по умолчанию** |
| UDP-амплификация                          | UDP 17, 19, 69, 111, 137, 161, 389, 1900, 11211 | Блокируется (drop) — включено по умолчанию       |
| Удалённое администрирование (SSH/RDP/VNC) | —                                               | Только детекция                                  |
| Базы данных                               | —                                               | Только детекция                                  |
| IoT-цели сканирования                     | —                                               | Только детекция                                  |
| Proxyware / майнинг / подозрительное      | —                                               | Только детекция                                  |

* Действия: `drop`, `reject`, `detect` (детекция не ставит правило в firewall — только питает детекторы).
* **DNS (53) и NTP (123) сознательно никогда не блокируются** — вместо блокировки за ними наблюдает детектор аномального fan-out.
* Переопределение портов доступно только в расширенном режиме; политика с неизвестными категориями, действиями или портами отклоняется.

## Как работает сверка

* Политика хранится одной записью с версией (каждое сохранение поднимает версию) и флагом `auto_reapply`.
* Примерно каждые 5 минут панель обходит все ноды: если желаемый хэш изменился или правила ещё не применялись — отправляет применение; иначе выполняет дешёвое чтение состояния, которое ловит дрейф, случившийся вне панели (ручной сброс правил, перезагрузка ноды).
* **Автопочинка дрейфа выполняется только при включённом `auto_reapply`** — и никогда в том же проходе, который сам только что применял правила (защита от циклов). При выключенном флаге дрейф просто фиксируется и остаётся на решение оператора.
* Нода, чей агент не поддерживает firewall-операции, показывается как `unsupported`, а не «применено».
* Статусы по нодам: `pending`, `applied`, `drift`, `failed`, `unsupported`, `unknown` — в интерфейсе сортируются от худшего к лучшему. Изменения политики и действия сверки пишутся в аудит-лог.

## Настройка

<Steps>
  <Step title="Посмотрите каталог и текущую политику">
    Откройте **Безопасность → Egress Guard**.
  </Step>

  <Step title="Сохраните политику">
    Включите нужные категории и нажмите **Сохранить политику**.
  </Step>

  <Step title="Примените сейчас (по желанию)">
    Перейдите во вкладку **Применение** и нажмите **Сверить сейчас**.
  </Step>
</Steps>

## Проверка

* После изменения политики дождитесь плановой сверки или нажмите **Сверить сейчас**.

<Check>Защита действует на ноде, если его статус — `applied`, то есть хэш правил в ядре ноды совпал с желаемым.</Check>

## Откат

* Снять блокировку: выключите категорию или переведите её в `detect`, сохраните политику и нажмите **Сверить сейчас**.
* Автопочинку дрейфа можно отключить флагом `auto_reapply` — панель перестанет самовольно возвращать правила и будет лишь сообщать о дрейфе.

## Ограничения и риски

* Категории `detect` не защищают трафик — они только наблюдают.
* Между сохранением политики и её применением есть окно (до одного цикла сверки).
* На нодах без поддержки firewall у агента защита не применяется — статус `unsupported` требует обновления или донастройки агента.

<AccordionGroup>
  <Accordion title="Нода висит в drift">
    Откройте вкладку **Применение** и нажмите **Сверить сейчас**. Если включена автопочинка, панель повторно применит желаемое состояние.
  </Accordion>

  <Accordion title="Нода показывает unsupported">
    Агент на ноде не имеет firewall-возможности. Проверьте версию агента и его capabilities на странице ноды.
  </Accordion>

  <Accordion title="Сохранил политику, а status по-прежнему pending">
    Это нормально сразу после сохранения. Дождитесь цикла сверки или нажмите **Сверить сейчас**.
  </Accordion>
</AccordionGroup>

Связанные страницы: [Маршрутизация Connection Units](/ru/connection-units/routing), [Журнал и аудит](/ru/panel/journal-and-audit).

<Note>Проверено для версии Axottle текущей ветки. Дата проверки: 2026-07-11.</Note>