Интеграция с оборудованием

Раздел описывает интеграцию СмИТ Биллинг с сетевым оборудованием: NAS/BRAS-серверами, коммутаторами, VoIP-шлюзами, IPTV-системами и абонентским оборудованием.

flowchart LR
    subgraph net["Сеть оператора"]
        NAS["Сервер доступа
выдаёт адрес, считает трафик"]
        SW["Коммутатор
порт = квартира"]
        CPE["Оборудование
у клиента"]
    end
    subgraph bill["Биллинг"]
        AUTH["Проверка учётной записи"]
        SESS["Учёт сессий"]
        CARD["Карточка клиента"]
        MON["Состояние оборудования"]
    end
    CPE --> SW --> NAS
    NAS -->|"запрос на вход"| AUTH
    AUTH -->|"разрешено: адрес и скорость"| NAS
    NAS -->|"объём и длительность"| SESS
    SW -->|"номер порта"| CARD
    SESS --> CARD
    NAS -.->|"опрос доступности"| MON
    SW -.->|"опрос портов"| MON

Интернет-оборудование (NAS/BRAS)

Порядок подключения сервера доступа (NAS) к биллингу:

1. Завести NAS — Оборудование → NAS → «Добавить»: IP-адрес, с которого NAS шлёт RADIUS-запросы, тип устройства, RADIUS-secret. Для мгновенного отключения клиентов — CoA-пароль и порт (обычно 3799).
2. Настроить RADIUS на NAS — адрес сервера биллинга, порты авторизации (1812) и учёта (1813), тот же secret; разрешить CoA-запросы с адреса биллинга.
3. Перезапустить RADIUS — кнопкой «Перезапустить RADIUS» в списке NAS: список доверенных устройств FreeRADIUS читает только при старте.
4. Привязать IP-пулы — вкладка «IP-пулы» в карточке NAS.
5. Проверить — подключить тестового клиента с назначенным тарифом: сессия должна появиться в колонке «Онлайн», а после «Отсоединить» в карточке клиента — завершиться.

Поддерживаемое интернет-оборудование

Биллинг работает с любым сервером доступа, который поддерживает RADIUS (RFC 2865/2866), а для мгновенного отключения клиентов — CoA/Disconnect (RFC 5176).

• MikroTik RouterOS Проверено в эксплуатации: PPPoE, IPoE/DHCP, Hotspot; отключение через CoA или SSH; автоконфиг на вкладке «Развёртывание»
• Другие BRAS и маршрутизаторы с RADIUS Cisco, Juniper, Huawei, Eltex, ZTE и др. — атрибуты скорости и фильтров задаются в тарифе в синтаксисе производителя
• Коммутаторы с DHCP Option 82 Авторизация по порту коммутатора — см. «OPT82-авторизация»

NAS — назначение и роль в биллинге

NAS (Network Access Server) — устройство, которое физически терминирует абонентскую сессию (PPPoE, IPoE, DHCP) и отправляет RADIUS-запросы в биллинг. Запись хранится в таблице nas, редактируется на странице /admin/equipment/Nas/.

Зачем NAS заводится в БД

Запись nas в биллинге решает четыре задачи:

1. RADIUS-доверие (clients.conf)

FreeRADIUS принимает Access-Request только от IP, перечисленных в clients.conf. Этот файл генерируется при старте контейнера app-freeradius-1 из таблицы nas (см. docker/freeradius/entrypoint.sh) — каждая enabled-запись становится client <name> { ipaddr=<IP>; secret=<SECRET> }. Без записи в БД ваш роутер физически не сможет авторизовать клиентов.

2. Привязка клиента к серверу доступа (Users.NAS_ID)

Когда клиент авторизуется, FreeRADIUS заполняет Users.NAS_ID ID сервера, через который пришёл запрос. Это нужно для:

• CoA Disconnect — при блокировке/смене тарифа биллинг шлёт CoA только на «правильный» NAS;
• Sync RADIUS-сессий — задача nas_sync опрашивает NAS по SSH/SNMP и сверяет сессии;
• СОРМ-выгрузки — поле GATEWAY идентифицирует через какой шлюз шёл трафик клиента.

3. Назначение IP-пулов (nas.PULL_ID и связанные)

NAS имеет 4 поля привязки к пулам: основной (PULL_ID), белый (WHITE_PULL_ID), NAT (NAT_PULL_ID), Hotspot (HOTSPOT_PULL_ID). FreeRADIUS при авторизации выбирает свободный IP из соответствующего пула. Можно строить chain-цепочки (ip_pull.NEXT_PULL_ID) — когда основной пул заполнен, выдача переходит во вспомогательный.

4. Развёртывание / автоконфиг (buttons_nas.html)

Поля TELNET_IP / TELNET_LOGIN / TELNET_PASSWORD / TELNET_PORT / TELNET_TYPE (ssh или telnet) используются вкладкой «Развёртывание» в карточке NAS — там можно с UI запустить cfg_init / cfg_fill / cfg_make / cfg_upload. Это ssh-команды через скрипт ssh_send, генерирующие конфиг роутера на основании текущих клиентов и пулов.

Где это поле используется

Нужно ли вам это

Запись NAS в БД нужна всегда, как только у вас есть хоть один сервер доступа который шлёт RADIUS-запросы:

• Без записи — FreeRADIUS отвергает запрос с ошибкой ignoring request from unknown client;
• Любая модификация (новый NAS, смена IP, смена secret) требует правки в БД через UI и перезапуска FreeRADIUS (кнопка «Перезапустить RADIUS» в списке NAS);
• Если у вас один большой роутер на офис — это одна запись. Если 5 OLT-головок и 3 BRAS — это 8 записей.

Что делать со старыми/неиспользуемыми NAS

Хорошие индикаторы что NAS-запись «мёртвая»:

1. enabled=false — выключен в UI, но строка не удалена;
2. 0 RADIUS-сессий за последние 30 дней (см. дашборд /admin/equipment/nas_status/ → колонка «Активность»);
3. 0 клиентов на нём (Users.NAS_ID = ваш_id);
4. не упоминается ни в одной NAS-цепочке (nas.PULL_ID не используется другими).

Перед удалением:

• Если NAS — реальное оборудование, временно выключенное (на профилактике, заменён на новый и отдан на склад) — оставить с enabled=false. Не удалять. Возможно потом вернёте в работу.
• Если NAS точно списан и не упомянут в полях USERS_RADIUSAUTH, RADIUS_SESSIONS, nas_radius_params — можно удалять. Удаление через UI кнопкой 🗑.
• FK-защита: на nas ссылаются с NO ACTION клиентские поля users.NAS_ID и usluga.NAS_ID, служебные журналы (NAS_RADIUS_PARAMS, NAS_STATUS_LOG, EVENTS_STACK, VOIP_LOG, SENSORS_LOG), привязка к организации, карта сети и мониторинг, а также сам nas через NEXT_NAS_ID (цепочка пулов). Если на этом NAS есть хоть один клиент — удаление заблокируется: сначала переведите Users на другой NAS или обнулите NAS_ID. У USERS_RADIUSAUTH внешнего ключа нет — эта таблица удалению не мешает.

Редактирование NAS — модальное окно

Начиная с, все операции с NAS-устройствами выполняются в модальном окне (без перехода на отдельную страницу). Кнопка в строке таблицы открывает полнофункциональное окно редактирования.

Модальное окно содержит 6 вкладок:

• Основное — название, IP-адрес, маска, тип NAS, адрес установки (с поиском), включён / производственный.
• RADIUS — shared secret, CoA-пароль/порт, пароль пользователей, флаги NetFlow и поведения при блокировке.
• Авторизация — 11 методов авторизации (логин, MAC, OPT82, IP, VLAN и др.).
• Управление — параметры SSH/Telnet-подключения: тип, IP, порт, логин, пароль.
• IP-пулы — привязка пулов: основной, NAT, белый, Hotspot, DNS, VLAN-пул, следующий NAS.
• OSS / Скрипты — пути скриптов, интерфейсы для MikroTik / Cisco / Redback.

Онлайн-клиенты NAS

Начиная с, в столбце Онлайн таблицы NAS отображается кликабельная ссылка с числом активных сессий. Клик открывает модальное окно со списком клиентов, подключённых через данный NAS прямо сейчас.

Модальное окно «Онлайн на NAS» показывает до 200 активных сессий:

• # — порядковый номер строки.
• Клиент — имя клиента, ссылка на карточку открывается в новой вкладке.
• Логин — учётная запись (Users.login).
• IP — назначенный клиенту IP-адрес.
• Начало сессии — время старта из USERS_RADIUSAUTH.RADIUS_START.
• Обновление — время последнего Accounting-Update.

Кнопка Обновить перезагружает данные без закрытия окна. Если сессий больше 200 — отображается подсказка о лимите.

Дашборд состояния NAS (Sidebar → «Состояние NAS»)

Отдельная страница /admin/equipment/nas_status/ предоставляет real-time мониторинг всех NAS-устройств: текущее состояние (UP/DOWN), uptime за 7/30 дней, простой за 24 часа, и историю последних 50 событий.

Дашборд показывает:

• Текущее состояние каждого enabled NAS: 🟢 UP / 🔴 DOWN / ⏸ выключен
• Uptime за последние 7 и 30 дней (%)
• Sparkline 24h — 24 столбика по часам (зелёный = up, оранжевый = частичный простой, красный = ≥50% downtime)
• Затронутые клиенты — клик на цифру открывает модалку онлайн-клиентов
• SLA-индикатор — порог настраивается через VpnConst NAS_SLA_TARGET_PCT (99.5) и NAS_SLA_WARNING_PCT (99.0)
• Auto-refresh — 30с / 60с / 5мин (выбор через тулбар)
• Алерт-баннер при DOWN — список упавших NAS с длительностью и счётчиком клиентов
• CSV-экспорт истории за 24h / 7d / 30d (endpoint /admin/equipment/nas_status/export/)

В список NAS добавлены KPI-карточки и чипы-фильтры:

• KPI-cards: Всего NAS / UP / DOWN / Онлайн клиентов
• Чипы со счётчиками: Все · UP · DOWN · Без RADIUS · Без SSH · PROD · Выключенные
• Колонка «Состояние»: тултип с длительностью простоя
• Progress-bar «Онлайн»: зелёный <75%, оранжевый 75–90%, красный ≥90%
• Подсветка строк: DOWN — красноватый фон, выключенные — opacity, без RADIUS/SSH — оранжевая полоса слева
• Кнопка «Перезапустить RADIUS» в toolbar + автоматический warning-bar при флаге radius_dirty в кеше

Коммутаторы (Switch) в биллинге — назначение и роль

Коммутатор (Switch) в СмИТ Биллинг — это запись в БД, отражающая физический сетевой коммутатор / OLT (PON-головку), через который клиент подключён к сети провайдера. Запись хранится в таблице switch, редактируется на странице /admin/equipment/Switch/.

Зачем коммутатор хранится в БД

Запись switch в биллинге решает три задачи:

Привязка клиента к точке физического подключения

Поле Users.SWITCH_ID указывает «через какой коммутатор работает данная учётная запись». Эта информация используется в:

• СОРМ-выгрузках — куда и через какое оборудование подключён клиент (ABONENT_USER, GATEWAY);
• Карточке клиента — оператор видит «клиент сидит в доме X на свитче Y» и не лезет в маршрутизаторы;
• Печатных формах и техподдержке — чтобы техник, выезжающий на объект, знал точку подключения.

OPT82-авторизация (привязка по порту)

Таблица SWITCH_PORTS хранит список портов конкретного коммутатора и привязки к учёткам. При OPT82-авторизации (см. раздел ниже) FreeRADIUS получает из DHCP Option 82 IP коммутатора + номер порта, парсит их по шаблонам из Типа коммутатора и находит клиента в SWITCH_PORTS без логина/пароля.

Это самый «технологический» способ использования коммутатора в биллинге: реально влияет на авторизацию.

Связь с IP-пулом (ip_pull.SWITCH_ID)

Можно привязать конкретный IP-пул к конкретному свитчу — тогда выдача IP-адресов клиентам этого свитча идёт только из назначенного пула. Используется в небольших сегментированных сетях, где хочется строго контролировать какой кусок адресации работает с какой железкой.

Где это поле используется

Нужно ли вам это

Зависит от модели работы вашего ISP:

• Если используете OPT82-авторизацию — записи коммутаторов обязательны. Без правильно заполненного switch + SWITCH_PORTS + SwitchType с шаблонами Option 82 авторизация работать не будет.
• Если авторизация по логину/паролю или MAC — записи нужны только для отображения в карточке клиента: «он подключён через свитч X». Удобно технику, но никакой логики на свитче не висит. Можно поддерживать «по желанию».
• Если у вас PON-сеть (оптика) — OLT-головки часто заводятся в switch для отображения, но фактическая авторизация идёт по MAC ONT через RADIUS, а не через OPT82. Тогда запись OLT в БД полезна для документации, но не для логики.

Что делать со старыми/неиспользуемыми коммутаторами

В аудите чистоты БД (журнал dev_reports) часто встречаются записи коммутаторов с users_on_it=0 и cp_on_it=0 — то есть ни один клиент через них не привязан. Перед удалением проверьте:

1. OLT/PON-головки (имя содержит «OLT», «GPON», «BDCOM», «ELTEX_LTE», тип SwitchType с PON-полями) — не удалять без подтверждения сетевиков. Это реальное оборудование в сети, на нём могут позже появиться клиенты.
2. Старые маленькие коммутаторы доступа (D-Link, SNR на 24 порта) — если им больше 5 лет и у них нет ни одного клиента, чаще всего это рудимент после декомиссии. Можно удалять после подтверждения от инженера, что эта железка реально снята.
3. Тестовые записи (имя совпадает с IP, тип не указан, дом не указан) — обычно безопасно удалять.

Удаление выполняется через UI /admin/equipment/Switch/ кнопкой 🗑 в строке. SQL-каскад: switch защищён NO ACTION на FK из users.SWITCH_ID, CONNECTION_POINTS.SWITCH_ID, ip_pull.SWITCH_ID, SWITCH_ORGANIZATION.switch_id, monitoring_device.switch_id и netmap_node.switch_id — то есть удаление заблокируется, если есть хотя бы одна привязка. Это safety net.

Редактирование коммутаторов — модальное окно

Коммутаторы (/admin/equipment/Switch/) редактируются в модальном окне с двухколоночным макетом: слева — название и IP, справа — адрес установки (с поиском), этаж, помещение.

Начиная с, в таблице коммутаторов добавлена колонка Тип — отображает привязанный тип коммутатора (бейдж с названием). Тип определяет регулярные выражения для парсинга Option 82 и используется при OPT82-авторизации.

На телефоне модальное окно раскрывается на весь экран и выезжает снизу — это касается всех модальных окон биллинга, не только коммутаторов. Шапку можно потянуть пальцем вниз, чтобы закрыть панель.

Организации коммутатора

Один коммутатор в доме может обслуживать клиентов нескольких компаний, поэтому организация у коммутатора — набор, а не единственный выбор: в модальном окне это чекбоксы, а не выпадающий список. Связь хранится в таблице SWITCH_ORGANIZATION (как у NAS).

В списке /admin/equipment/Switch/ организации показаны второй колонкой бейджами с фирменным цветом компании:

Что из этого следует на практике:

• Колонка показывается не всегда. Только при включённой мульти-организации и режиме «Все организации» в шапке. Если выбрана одна компания, колонка вырождается в один и тот же бейдж и только съедает ширину — та же логика, что в NAS, тарифах и финоперациях.
• Список фильтруется по вашему доступу. Сотрудник видит коммутаторы своих организаций; чужое оборудование в списке не появляется. Тот же фильтр действует в модальном окне «Добавить устройство» и в «Автопоиске» мониторинга — иначе чужое железо оставалось бы видно в обход списка.
• Коммутаторы без организаций видны всем. Это сделано намеренно: «ничьё» оборудование иначе пропало бы у всех сразу, и назначить ему компанию было бы негде.
• Ссылка на карточку. Адрес /admin/equipment/Switch/?edit=<id> открывает список и сразу разворачивает модальное окно нужного коммутатора — так на него ссылаются панель клиента и мониторинг.

Типы коммутаторов

Справочник типов коммутаторов /admin/equipment/SwitchType/ — настройка правил парсинга DHCP Option 82 для каждого типа оборудования. Используется при авторизации клиентов по коммутатору.

С добавление и редактирование типов выполняется в модальном окне с двумя вкладками: Основные (название, признак «Порты с 0») и Opt82 (поля парсинга). Изменения сохраняются без перезагрузки страницы.

Параметры Opt82

Каждая запись задаёт регулярные выражения для извлечения данных из поля Option 82:

• PARS_SWIP — парсинг IP-адреса коммутатора
• PARS_PORT — парсинг номера порта
• PARS_VLAN / PARS_S-VLAN — парсинг VLAN / S-VLAN (QinQ)
• PARS_MAC — парсинг MAC-адреса
• PARS_PARAM — дополнительные параметры
• PARS_GPON_MODEM_PORT — номер GPON-порта модема
• PARS_HW_SERIAL — серийный номер устройства
• Порты с 0 — нумерация портов начинается с 0 (не с 1)

OPT82-авторизация

OPT82 (DHCP Option 82) — механизм авторизации клиентов по физическому расположению в сети: система определяет, к какому коммутатору и на какой порт подключён клиент, без необходимости знать его логин или MAC-адрес.

Как это работает

1. Клиент подключает устройство к порту коммутатора и посылает DHCP-запрос.
2. Коммутатор добавляет в DHCP-пакет поле Option 82 — информацию о своём IP-адресе и номере порта (формат зависит от производителя).
3. DHCP-запрос попадает на NAS/BRAS, который перенаправляет его в FreeRADIUS биллинга.
4. FreeRADIUS парсит Option 82 с помощью регулярных выражений из Типа коммутатора (PARS_SWIP, PARS_PORT, PARS_VLAN).
5. Извлечённый IP коммутатора и номер порта ищутся в таблице SwitchPorts → находится привязанная учётная запись клиента (Users).
6. Биллинг авторизует клиента и возвращает RADIUS-атрибуты (IP из пула, скорость и т.д.).

Шаг 1 — Тип авторизации в учётной записи клиента

В карточке клиента откройте вкладку Учётные записи → кнопка редактирования учётной записи → вкладка Основные. В поле Тип авторизации выберите по OPT82.

Доступные типы авторизации (поле auth_type в таблице Users):

• по ip static — по статическому IP
• через веб — веб-авторизация
• любая через RADIUS — стандартный RADIUS (логин/пароль)
• по OPT82 — авторизация по порту коммутатора ← выбрать этот
• по ip+radius — комбинированный
• по vpn pptp, pppoe — PPPoE/PPTP

Шаг 2 — Привязка к порту коммутатора

В той же карточке учётной записи перейдите на вкладку Сеть. Здесь три поля для OPT82:

• SWITCH — выберите коммутатор из справочника (/admin/equipment/Switch/). Список фильтруется по мере ввода.
• PORT — номер физического порта на коммутаторе (целое число).
• VLAN — VLAN-тег (опционально, если сеть использует VLAN-сегментацию).

После сохранения в таблице SwitchPorts создаётся запись: switch_id + port_num → user_id. Именно по ней FreeRADIUS находит клиента при авторизации.

Шаг 3 — Коммутатор в справочнике

Перейдите в Оборудование → Коммутаторы (/admin/equipment/Switch/). Убедитесь, что коммутатор добавлен с корректным IP-адресом — именно этот IP будет извлекаться из Option 82 и сравниваться с записями справочника.

Поля коммутатора:

• Название — произвольное имя для отображения.
• IP-адрес — IP коммутатора (должен совпадать с тем, что он пишет в Option 82).
• Адрес установки — физический адрес из справочника Адреса (опционально, для удобства).
• Этаж / Помещение — уточнение расположения.

Шаг 4 — Тип коммутатора (шаблоны парсинга)

Перейдите в Оборудование → Типы коммутаторов (/admin/equipment/SwitchType/). Каждый производитель по-своему кодирует данные в Option 82. Тип коммутатора задаёт регулярные выражения для их извлечения.

Проверьте, что для вашего оборудования создан тип с правильно заполненными полями PARS_SWIP (IP коммутатора) и PARS_PORT (номер порта). Если данных недостаточно — добавьте PARS_VLAN для VLAN-авторизации.

Шаг 5 — Флаги OPT82 на NAS

В карточке NAS (Оборудование → NAS → вкладка Авторизация) включите нужные флаги:

• auth_opt82_switch_ip — авторизация по IP коммутатора из Option 82.
• auth_opt82_port — уточнение по номеру порта.
• auth_opt82_vlan — уточнение по VLAN.

Обычно включают все три для максимальной точности идентификации.

Итоговая схема привязки

Мониторинг оборудования

Страница /admin/equipment/monitoring/ (сайдбар «Оборудование → Мониторинг оборудования») показывает состояние управляемых коммутаторов: отвечают ли они, сколько портов поднято, насколько надёжно работали последние сутки и месяц, и — главное — кто из клиентов сидит на каждом порту.

Что делает раздел

Биллинг раз в 5 минут опрашивает включённые устройства по SNMP (celery-задача equipment-poll). Из опроса берутся три вещи:

• Отвечает ли устройство — переход UP↔DOWN записывается в журнал событий и уходит алертом в Telegram;
• Порты — сколько интерфейсов поднято из общего числа (IF-MIB);
• MAC-таблица портов (FDB) — снимается отдельной командой и сопоставляется с учётными записями клиентов.

Карта раздела

- Мониторинг оборудования
  - Опрос
    - SNMP IF-MIB
    - Раз в 5 минут
    - Внеочередной опрос кнопкой
  - Состояние
    - В сети / Не отвечает
    - Журнал событий UP-DOWN
    - Надёжность 24ч / 7д / 30д
    - Telegram-алерт на падение
  - Порты
    - Сколько поднято
    - MAC-таблица FDB
    - Кто сидит на порту
    - Ручная привязка MAC
  - Доступ
    - Группы управления
    - Колонка организации
    - Чужие клиенты скрыты

Таблица устройств

Сверху — счётчики (всего / в сети / не отвечают / неизвестно) и автообновление страницы: выключено, 30 секунд, 60 секунд или 5 минут. Ниже таблицы — журнал последних 50 событий UP/DOWN с длительностью простоя; события чужих организаций в него не попадают.

Как поставить устройство на мониторинг

1. Кнопка «Добавить устройство» — выбрать коммутатор из справочника (показываются только те, у кого заполнен IP и кого ещё нет в мониторинге), задать SNMP community и интервал опроса.
2. Кнопка «Автопоиск» — биллинг сам опрашивает по SNMP все коммутаторы с IP, которых ещё нет в мониторинге, и показывает ответившие: модель и число портов. Дальше их можно завести одной кнопкой.

Кем заняты порты

Клик по счётчику портов («10 / 28») открывает снимок MAC-таблицы коммутатора: какой MAC на каком порту, в каком VLAN, какому клиенту он принадлежит, логин учётной записи, выданный IP и когда MAC был замечен.

В шапке — сводка: сколько портов активно, сколько MAC найдено, сколько сопоставлено с клиентами и сколько скрыто как чужие. Поле поиска фильтрует по порту, MAC, ФИО, логину и IP.

Клик по имени клиента открывает боковую панель — баланс, тариф, контакты, последняя сессия — прямо поверх таблицы портов, без ухода со страницы. В панели, в блоке «Последняя сессия», оборудование показано ссылками: «Шлюз» ведёт на карточку NAS, «Коммутатор» — на карточку коммутатора с номером порта и VLAN.

Данные в таблице — снимок последнего снятия FDB, а не «живой» опрос. Обновить его можно кнопкой «Обновить MAC портов» в самой модалке или иконкой 🖧 в строке устройства.

Если клиент не сопоставлен

Сопоставление автоматическое: MAC с порта ищется среди MAC-адресов учётных записей. Формат при этом не важен — AA:BB:CC:DD:EE:FF, aa-bb-cc-dd-ee-ff и aabbccddeeff считаются одним и тем же адресом.

flowchart LR
    SW["Коммутатор"] -->|"SNMP: FDB"| MACS["MAC на портах"]
    MACS --> NORM["Приводим MAC
к единому виду"]
    NORM --> FIND{"Есть учётная запись
с таким MAC?"}
    FIND -->|"да"| LINK["Строка связана
с клиентом"]
    FIND -->|"нет"| FREE["не сопоставлен"]
    FREE -->|"кнопка «Привязать»"| PICK["Выбрать учётную запись"]
    PICK --> SAVE["MAC записывается
в карточку учётки"]
    SAVE --> LINK

Строка остаётся «не сопоставленной» в двух случаях: у учётной записи не заполнен MAC, либо на порту виден MAC роутера клиента, а в карточке записан MAC компьютера. Тогда рядом со строкой есть кнопка «Привязать»: поиск учётной записи по логину, ФИО или номеру договора, выбор — и MAC записывается в карточку. Дальше связь держится сама, а действие попадает в аудит (в записи виден и прежний MAC).

Права и разграничение по организациям

Раздел разделяет смотреть и управлять:

Разграничение по организациям действует на трёх уровнях:

• Список устройств и журнал событий — только железо ваших организаций (и «ничьё», у которого организации не заданы);
• Личность клиента на порту — MAC, VLAN и номер порта видны всем, это сетевые данные, а ФИО и логин чужого клиента заменяются на «— другая организация»;
• Добавление и автопоиск — работают в границах ваших организаций.

Как связаны объекты

flowchart TB
    ORG["Организация"]
    SW["Коммутатор
switch"]
    NAS["NAS
nas"]
    MD["Устройство мониторинга
monitoring_device"]
    LOG["Журнал событий
device_status_log"]
    FDB["MAC на портах
switch_port_mac"]
    USR["Учётная запись
users"]
    AB["Клиент
abonents"]

    ORG -->|"обслуживает"| SW
    ORG -->|"обслуживает"| NAS
    SW -->|"наблюдается"| MD
    NAS -->|"наблюдается"| MD
    MD -->|"переходы UP/DOWN"| LOG
    MD -->|"снимок FDB"| FDB
    FDB -->|"MAC совпал"| USR
    USR -->|"принадлежит"| AB
    AB -->|"относится к"| ORG

Устройство мониторинга (MONITORED_DEVICE) не дублирует железо: оно только хранит параметры опроса и ссылается на уже заведённый коммутатор или NAS. Своей организации у него нет — она берётся у того железа, за которым оно наблюдает. Поэтому чтобы устройство корректно разделилось между компаниями, организации задаются в карточке коммутатора (см. Организации коммутатора).

Телефония

Телефония в СмИТ Биллинг — это две разные вещи:

• Учёт звонков VoIP-абонентов через RADIUS. У FreeRADIUS есть отдельный виртуальный сервер телефонии (порты 2812/2813). Шлюз или АТС запрашивает разрешение на звонок; биллинг проверяет, не заблокирован ли абонент, находит направление вызова и услугу с ценой, возвращает разрешённое время разговора по балансу, а по окончании звонка принимает учёт.
• Телефония для поддержки и продаж — подключение оператора (Mango Office и др.), запись и расшифровка звонков, голосовая почта, звонок клиенту из карточки. Описано в разделах Настройки: связь и сервисы → Голосовая связь и Поддержка → Голосовая почта.

IPTV

СмИТ Биллинг интегрируется с IPTV-платформами для автоматического управления аккаунтами клиентов, ТВ-пакетами и блокировками. Интеграция работает в двух режимах:

• Событийный — при блокировке/разблокировке клиента или переключении услуги биллинг мгновенно синхронизирует состояние с IPTV-платформой.
• Периодический — ежедневная полная сверка через Celery Beat для устранения рассинхронизаций.

TVIP Media (TMS)

TVIP TMS — IPTV/OTT middleware для управления телевизионными услугами, клиентами и STB-приставками. Подключение через REST API с HTTP Basic Auth.

Настройка: Настройки → Интеграции → TVIP Media

Возможности интеграции с TVIP Media:

• Автоматическое создание аккаунтов клиентов (логин = номер договора)
• Подписка/отписка от ТВ-пакетов при смене тарифа или переключении услуг
• Блокировка/разблокировка аккаунта при отрицательном балансе
• Отправка команд на STB-приставки (обновление каналов, перезагрузка)
• Получение списка доступных ТВ-пакетов через API

LFStream (Смотрёшка)

LFStream («Смотрёшка») — OTT-платформа доставки ТВ-контента. Биллинг заводит аккаунты клиентов, подписывает и отписывает их на ТВ-пакеты. Настройка: Настройки → IPTV → LFStream (/admin/iptv/settings/).

Два режима подключения

Коды пакетов: панель и API считают по-разному

Панель оператора нумерует пакеты длинными кодами вида 65e87bfd572648971816eccc, прямой API — короткими: 209, 6017. Маппинги услуг заводились через панель, поэтому при переходе на API подписка ушла бы с чужим кодом. Приводит их в порядок команда:

manage.py lfstream_sync_packages            # показать, что изменится
manage.py lfstream_sync_packages --apply    # записать коды из API
manage.py lfstream_sync_packages --match --apply   # плюс подобрать замену тем,
                                                   # у кого кода в API нет

Команда ищет каждый пакет в каталоге API по названию (слово «Тариф», регистр и пометка «Архив» не мешают) и подставляет его код. Старый код остаётся в аудите — вернуться можно.

Логин аккаунта в Смотрёшке — smtv+номер договора. Существующие аккаунты (заведённые ранее) находятся по логину и не дублируются.

Создание аккаунта новому абоненту

Опция «Создавать аккаунт IPTV новому абоненту» (карточка «Биллинг IPTV») при подключении ТВ-услуги абоненту без аккаунта у провайдера заводит его автоматически. При выключенной опции подписка пропускается, пока аккаунт не создан. Email аккаунта — smtv‹договор›@‹домен›, домен задаётся полем «Домен email для авто-аккаунтов» (по умолчанию smit34.ru). ⚠ Панель отклоняет несуществующие домены, поэтому домен должен быть реальным.

Маппинг IPTV-пакетов

Для каждого IPTV-провайдера необходимо настроить соответствие между услугами биллинга и пакетами во внешней системе. Настройка: Настройки → IPTV-пакеты.

Таблица маппинга содержит:

Кнопка Загрузить пакеты запрашивает актуальный список ТВ-пакетов у выбранного провайдера через API и добавляет строки в таблицу.

Синхронизация

Биллинг синхронизирует данные с IPTV-платформами в следующих случаях:

Все API-вызовы логируются в таблице iptv_api_log для мониторинга и отладки.

Логи синхронизации с IPTV-платформами:

docker compose logs celery | grep iptv_sync
# Просмотр API-логов в Django shell:
from billing.models.iptv import IptvApiLog
IptvApiLog.objects.filter(success=False).order_by('-created_at')[:10]

Другие поддерживаемые IPTV-платформы

Помимо интегрированных TVIP Media и LFStream «Смотрёшка» в витрине провайдеров (/admin/iptv/settings/) показаны платформы, для которых интеграция может быть добавлена:

• Смартила — OTT-платформа для операторов.
• Infomir Ministra (Stalker) — middleware для STB-приставок MAG.
• Микроимпульс — Smart Media Platform, IPTV/OTT.
• 24часаТВ — OTT-агрегатор каналов «под ключ».
• LIME HD — бесплатное эфирное OTT-ТВ.

Абонентское оборудование

Роутеры, ONT-терминалы и приставки, выданные клиентам, учитываются в модуле Склад: у какого клиента какое оборудование, продано оно или передано в аренду, кто его выдал и когда вернули. Удалённая настройка оборудования клиента по протоколу TR-069 (CWMP) в биллинге не поддерживается.

Камеры

Видеонаблюдение реализовано собственным модулем биллинга (/admin/video/) — продажа услуги «под ключ»: объект → проект (воронка) → камеры и оборудование → recurring-подписки → документы → личный кабинет. Биллинг управляет подписками клиентов: активация/деактивация доступа к камерам, тарификация, отдельный видео-счёт, блок камер при отрицательном балансе. Медиа-слой — MediaMTX/go2rtc, архив в GCS.

Аренда оборудования

Аренда ведётся в модуле Склад → «Деньги: продажа и аренда»: при передаче оборудования клиенту в аренду ему подключается ежемесячная услуга с ценой аренды из карточки позиции, при возврате — услуга снимается. Оборудование у клиента видно на вкладке клиента и в отчётах склада.

NAS Развёртывание (OSS)

Вкладка «Развёртывание» в карточке NAS позволяет управлять конфигурацией MikroTik и другого оборудования.

Общая схема работы

1. Инициализация    → rtsh cfg init <scheme>   → создаёт структуру каталогов
2. Заполнение данных → rtsh cfg fill <ip>       → заполняет .ini из биллинга
3. Скачать текущую   → rtsh cfg download        → загружает конфиг с оборудования
4. Генерация новой   → rtsh cfg make            → генерирует .cfg из .ini + .tmplt
5. Загрузка          → rtsh cfg upload          → загружает конфигурацию на NAS
6. Сохранение        → rtsh cfg save            → коммит в git-историю

Под-вкладки

Управление

5 шагов развёртывания + дополнительные команды (status, diff, log, acl upload).

Настройка (INI файлы)

Редактирование .ini файлов конфигурации: main.ini, firewall.ini, netflow.ini, pppoe.ini. Ссылка «Отобразить доступные параметры» показывает все поддерживаемые ключи.

Шаблоны (.tmplt)

Редактирование Jinja2-шаблонов для генерации конфигурации: firewall_address_list.cfg.tmplt, firewall_filter.cfg.tmplt, firewall_nat.cfg.tmplt, netflow.cfg.tmplt, pppoe.cfg.tmplt.

Upload cfg

Файлы сгенерированной конфигурации для загрузки на NAS. Появляются после rtsh cfg make.

Download cfg

Файлы текущей конфигурации, скачанные с оборудования через rtsh cfg download. Только для просмотра.

Модальное окно вывода команд

При нажатии на любую кнопку (rtsh cfg init, fill, make и др.) открывается модальное окно с выводом команды в реальном времени. Кнопки «Скачать вывод» и «Закрыть».

OSS утилиты

Утилиты для управления конфигурациями NAS-устройств.

rtsh — главная утилита

Расположение: /usr/local/bin/rtsh (bash-скрипт).

rtsh cfg init <scheme_name>  — инициализировать каталог управления
rtsh cfg fill <ip>          — заполнить .ini данными из биллинга
rtsh cfg make               — сгенерировать конфигурацию из .ini + .tmplt
rtsh cfg upload             — загрузить конфигурацию в оборудование
rtsh cfg download           — скачать конфигурацию с оборудования в ./cur/
rtsh cfg save <comment>     — сохранить в git-историю
rtsh cfg diff [ref]         — показать изменения
rtsh cfg status             — текущее состояние
rtsh cfg log                — журнал изменений
rtsh acl upload             — загрузить ACL-листы на оборудование
rtsh list scheme            — список доступных схем

OSS команды

18 скриптов в /usr/local/bin/oss/:

OSS схемы (44 шт.)

Расположение: /usr/local/share/oss/. Каждая схема содержит набор .ini шаблонов, .tmplt шаблонов и скриптов для конкретного типа оборудования.

Структура каталогов NAS

/var/oss/<nas_name>/
├── main.ini             ← основной конфиг (IP, секрет, порты)
├── firewall.ini         ← настройки файрвола
├── netflow.ini          ← настройки NetFlow
├── pppoe.ini            ← настройки PPPoE
├── tmplt/               ← Jinja2 шаблоны
│   ├── firewall_address_list.cfg.tmplt
│   ├── firewall_filter.cfg.tmplt
│   ├── firewall_nat.cfg.tmplt
│   ├── netflow.cfg.tmplt
│   └── pppoe.cfg.tmplt
├── upload/              ← сгенерированные .cfg (после cfg make)
├── cur/                 ← текущий конфиг с NAS (после cfg download)
├── bin/                 ← скрипты схемы
├── ubin/                ← пользовательские скрипты
├── utmplt/              ← пользовательские шаблоны
├── uinit.d/             ← пользовательские init-скрипты
└── .git/                ← история изменений

Docker конфигурация

• Dockerfile — COPY oss_tools/ (rtsh, oss_bin, oss_share) + apt install git rsync
• Volume oss_data:/var/oss — данные сохраняются между перезапусками
• /run_script/ — endpoint для выполнения команд (POST → start, GET → stream stdout)
• Gunicorn — WORKERS=1, THREADS=8 (для корректной работы /run_script/)