# 14. Фильтр: конфигурация подсистем [← Оглавление](../README.md) · [← Раздел 13: Фильтр: первоначальная настройка и CLI](13.md) --- ## 14.1. Консольный порт: скорость, тайм-аут неактивности В секции настройки консольного порта (`system / serial`) доступны два параметра: | Параметр | Описание | Рекомендация | | ---------------------- | ----------------------------------------------- | --------------------------- | | **Скорость порта** | Скорость консольного соединения (по умолчанию 115200) | Не менять | | **Тайм-аут неактивности** | Время до автоматического отключения неактивного пользователя | 5–30 минут (не `never`) | По умолчанию тайм-аут неактивности составляет **5 минут**. Можно увеличить до 15 или 30 минут. Значение `never` **не рекомендуется** — при его установке пользователь не будет отключаться по тайм-ауту, что может привести к проблемам (аналогично проблеме SSH-сессий — см. [раздел 14.3.1](#1431-лимит-сессий-20-опасность-never-для-auto-logout)). ## 14.2. Management-интерфейс: IP, gateway, DNS, allowed IP В секции management-интерфейса (`system / mng-if`) настраиваются параметры удалённого доступа к фильтру: | Параметр | Описание | | --------------- | ----------------------------------------------------------------- | | **IP-адрес** | Адрес management-интерфейса в подсети управления | | **Gateway** | Шлюз по умолчанию (обычно .254 — криптошлюз «Континент») | | **Name servers**| Список DNS-серверов (можно указать несколько через пробел) | | **Allowed IP** | Список адресов/подсетей, которым разрешён удалённый доступ | > **Осторожно:** изменение IP-адреса или allowed IP с последующим `apply` может привести к **потере удалённого доступа** к устройству, если вы подключены по SSH. Единственным способом восстановления в таком случае будет подключение через физическую консоль. ### 14.2.1. Добавление/удаление записей: `+=` и `-=` Для параметров, принимающих списки значений (DNS-серверы, allowed IP и др.), доступны операторы поэлементного изменения: | Оператор | Действие | Пример | | -------- | --------------------------------- | ----------------------------------- | | `+=` | Добавить запись к существующему списку | `nameservers += 8.8.8.8` | | `-=` | Удалить запись из списка | `nameservers -= 8.8.8.8` | Альтернативный способ — задать весь список одной строчкой через пробел: ```text nameservers 192.168.1.45 8.8.8.8 8.8.4.4 ``` Также можно использовать режим многострочного ввода через скобки (см. [раздел 13.8 — «мышеловка»](13.md)). ## 14.3. Терминал (SSH): auto-logout, prompt, нумерация строк В секции терминала (`system / terminal`) настраиваются параметры SSH-доступа: | Параметр | Описание | | --------------------- | ------------------------------------------------------ | | **auto-logout** | Время автоматического отключения неактивной SSH-сессии | | **prompt** | Текст приглашения командной строки | | **Нумерация строк** | Отображение номера введённой команды (инкрементируется с каждым вводом) | При вводе значения prompt необходимо использовать **кавычки**, если значение содержит спецсимволы (дефис `-` и др.). ### 14.3.1. Лимит сессий (20), опасность `never` для auto-logout Значение `never` для auto-logout **категорически не рекомендуется**. Причина: 1. При нестабильном соединении SSH-сессии **обрываются**, но не закрываются на стороне фильтра; 2. «Мёртвые» сессии **накапливаются**, не удаляясь по тайм-ауту; 3. При достижении лимита в **20 сессий** вы **не сможете** подключиться к устройству по SSH; 4. Единственный способ восстановления — подключение через физическую консоль. Рекомендуется оставлять auto-logout со значением по умолчанию или устанавливать разумный тайм-аут. ## 14.4. Пользователи: создание, удаление, уровни доступа, пароли (secret 0 / 15) Управление пользователями осуществляется в секции `system / users`: | Команда | Действие | | ------------------------------------------ | --------------------------- | | `create user <имя> level secret 0 <пароль>` | Создать пользователя (пароль в открытом виде) | | `create user <имя> level secret 15 <хэш>` | Создать пользователя (пароль в виде хэша) | | `no user <имя>` | Удалить пользователя | Параметры пароля: | Формат | Описание | | ------------ | ----------------------------------------------------- | | **secret 0** | Пароль задаётся в открытом виде (plain text) | | **secret 15**| Ожидается хэш пароля | В конфигурации пароли **хранятся в хэшированном виде** — при просмотре конфигурации открытые пароли не отображаются. Пользователь по умолчанию (`admin` / `econat`) может быть удалён. Рекомендуется создать новых пользователей и удалить дефолтного. ## 14.5. TACACS+: авторизация, fallback на локальную базу Фильтр поддерживает внешнюю авторизацию через **TACACS+**. Через TACACS+ работает только **авторизация** (и, возможно, аккаунтинг). Ключевые параметры: | Параметр | Описание | Важность | | --------------------- | -------------------------------------------------------------- | -------- | | **Fallback (fb on)** | При недоступности TACACS+ авторизовать через локальную базу | **Критично** | | **Service type** | Тип сервиса (shell) — должен совпадать с настройкой на TACACS-сервере | Важно | | **Protocol** | Протокол — должен совпадать с настройкой на TACACS-сервере | Важно | | **Серверы** | IP-адрес/доменное имя + secret для каждого сервера TACACS+ | — | > **Важно:** параметр **`fb on`** (fallback) должен быть **включён**. Если он выключен и пользователь отсутствует на TACACS-сервере (или сервер недоступен), авторизация через CLI будет **невозможна**. ## 14.6. NTP: до 3 серверов, период обновления В секции NTP (`system / ntp`) настраивается синхронизация времени: - Можно указать до **3 NTP-серверов**; - Настраивается **период обновления** времени. Для проверки статуса синхронизации используется команда `show ntp`. Вывод команды может быть не вполне интуитивным — значение `0x24` в статусе указывает на успешную синхронизацию. > **Примечание:** в будущих прошивках логика работы со временем планируется к изменению. Вместо задания временного сдвига в отдельных подсистемах будет единая настройка временной зоны для всего устройства, а в подсистемах — выбор между UTC и локальным временем. ## 14.7. SNMP: community (read-only), traps, allow-ip Настройки SNMP (`system / snmp`) стандартны: | Параметр | Описание | | --------------- | ----------------------------------------------------------- | | **Community** | Строка community, работает **только на чтение** (read-only). Задавать параметры через SNMP нельзя | | **Traps** | Включение/выключение отправки SNMP-трапов | | **Allow IP** | Список адресов/подсетей, которым разрешён SNMP-доступ (по умолчанию — отовсюду) | | **Description** | Описание устройства | | **Hostname** | Имя устройства | | **Contact** | Контактная информация | ## 14.8. Системное журналирование (syslog) Системное журналирование настраивается в секции `system / syslog` и позволяет отправлять события с фильтра на внешние серверы (СПХД). ### 14.8.1. Внешние лог-серверы (до 2), hostname, time shift | Параметр | Описание | | ----------------- | ------------------------------------------------------------ | | **Enable/disable**| Включение/выключение системного логирования | | **Серверы** | До **2 внешних серверов** (IP-адрес + порт) | | **Hostname** | Имя устройства, которое будет отображаться в syslog-сообщениях на внешнем сервере | | **Time shift** | Временной сдвиг относительно UTC (в минутах) для логов | В рамках **пилотного проекта** (Урал) системные логи на внешний сервер не сохранялись. В **федеральном проекте** они должны сохраняться на **СПХД** (серверы предварительного хранения данных), обеспечивая ретроспективный анализ событий на всех устройствах площадки — это крайне полезная возможность, которой часто не хватало на пилоте. > **Примечание:** в будущих прошивках параметр time shift планируется заменить на выбор между UTC и локальным временем, а временная зона будет настраиваться единообразно для всего устройства. ### 14.8.2. Уровни логирования по подсистемам (1=ошибки, 2=предупреждения, 3=информация) Для каждой подсистемы фильтра можно индивидуально настроить **уровень подробности** журналирования: | Уровень | Название | Содержимое | Рекомендация | | ------- | -------------- | --------------------------------------------------- | ------------------------- | | **1** | Ошибки | Ошибки и критически важные сообщения | По умолчанию, достаточно для большинства случаев | | **2** | Предупреждения | Предупреждения + всё из уровня 1 | Включать при траблшутинге | | **3** | Информация | Информационные сообщения + всё из уровней 1–2 | Только при диагностике | По умолчанию для всех подсистем установлен **уровень 1**. Повышать уровень (2 или 3) рекомендуется **только на время диагностики**, поскольку: - объём логов при уровне 2–3 **очень большой**; - внутренние логи на устройстве **забиваются быстро**; - разбираться в детальных логах **сложно**. Не все подсистемы, указанные в конфигурации, реально существуют в прошивке проекта ТСПУ (например, BRAS отсутствует) — для несуществующих подсистем настройка не имеет эффекта. ### 14.8.3. Подсистема `all` — максимальный уровень для всех Условная подсистема **`all`** позволяет быстро установить уровень логирования для **всех** подсистем одновременно: ```text verbose all 3 ← установить максимальный уровень для всех подсистем ``` Правило выбора уровня: для каждой подсистемы выбирается **наибольший** из двух значений — установленного для `all` и установленного индивидуально. Например, если `all = 2` и для конкретной подсистемы задано `3`, будет использоваться `3`. ### 14.8.4. Логирование команд пользователя (уровень fatal) Все команды, введённые пользователем, логируются с уровнем **fatal**. Это не означает, что происходит что-то критическое — уровень fatal выбран специально, чтобы команды пользователя **всегда записывались** в логи, независимо от текущих настроек подробности. Это полезно для ретроспективного анализа: можно посмотреть, кто, когда и что настраивал на устройстве. ### 14.8.5. SNMP traps: только уровень fatal В SNMP отправляются трапы **только уровня fatal**. События уровней 1–3 (ошибки, предупреждения, информация) в SNMP-трапы **не попадают**. ## 14.9. Журналирование соединений (connection log) — через лог-интерфейс (DPDK) Журналирование соединений (connection log, в терминологии фильтра — «NAT translation log») позволяет логировать каждую создаваемую на устройстве сессию: какой абонент, на какой ресурс, по какому порту обращался. Ключевые особенности: - Логи отправляются на внешний сервер в специальном формате; - В отличие от syslog, connection log по умолчанию отправляется через **лог-интерфейс** (DPDK), а не через management-интерфейс; - Лог-интерфейс **не имеет IP-адреса** в традиционном смысле — адрес генерируется программно. Пропинговать лог-интерфейс извне **невозможно**: на нём нет сущности, обрабатывающей входящие пакеты. Это сделано для **повышения производительности** — интерфейс отдан под управление DPDK; - Формат логирования настраивается в соответствующей секции конфигурации. > **Примечание:** в проекте ТСПУ журналирование соединений в текущей конфигурации может не использоваться. ## 14.10. Журналирование протоколов (debug logger) — отправка на SPFS Секция **debug logger** (несмотря на название «debug», это штатная функциональность) отвечает за отправку **протокольных логов** — результатов распознавания протоколов движком DPI — на серверы **SPFS** для дальнейшего формирования очищенных списков блокировки (подробнее о полном цикле — в [разделе 8](08.md)). ### 14.10.1. Выбор протоколов (all / конкретные) | Параметр | Описание | | ----------------- | ----------------------------------------------------------- | | **Enable** | Включение секции debug logger | | **Protocols** | Список протоколов для логирования: `all` (все) или конкретные (Telegram, WhatsApp и др.) | | **Server + port** | Адрес и порт SPFS-сервера | | **Gateway** | Шлюз по умолчанию для отправки | | **Source port** | Порт источника, с которого отправляются логи | | **Log interface** | Интерфейс для отправки: `log` (по умолчанию) или `management` | По умолчанию протоколы установлены в **`all`** — логируются все распознаваемые протоколы. Можно указать только конкретные протоколы, если требуется сузить объём логирования. Лог-интерфейс для отправки по умолчанию — **log** (DPDK). Переключение на management **не рекомендуется**, так как производительность отправки значительно снизится. ### 14.10.2. Количество пакетов на протокол (по умолчанию 30, рекомендуется 3) Параметр **количества пакетов** определяет, сколько пакетов из каждой распознанной сессии отправляется в лог: | Значение | Описание | Рекомендация | | ------------- | ------------------------------------------------- | ------------------- | | **0** | Без ограничения (отправляются первые 30 пакетов) | По умолчанию | | **3** | Отправляются первые 3 пакета | **Рекомендуется** | | **30** | Максимальное количество | Избыточно | Значение **30** (фактически — значение по умолчанию при параметре 0) генерирует **избыточный объём** лог-трафика. По результатам тестирования на Урале, для корректного распознавания достаточно **3 пакетов** — это значение рекомендуется для production-эксплуатации. --- [← Оглавление](../README.md) · [← Раздел 13: Фильтр: первоначальная настройка и CLI](13.md) · [Раздел 15: Фильтр: настройка интерфейсов и общих параметров →](15.md)