feat(mcp): подготовить сервер и доступ к приёмке

2026-11-03 03:12:03 +07:00
commit bf3d50e1ff
@@ -0,0 +1,72 @@
+# Production273 — отказы входа RouterOS (2026-10-16)
+
+Диагностика production выполнена только чтением. Пароли, пользователи, службы,
+firewall, задания RouterOS и контейнеры не изменялись. Секреты не включены.
+
+## Наблюдения
+
+- `nov-gw01.rtnt.top`, server ID3: RouterOS **7.24.4 stable**.
+- Рядом зафиксированы `500 / too many concurrent logins (6)` и `401 Unauthorized`
+  на `/interface`, `/interface/gre`, `/routing/bgp/session`. Последние отказы серии:
+  **2026-10-16 01:11:40–44 по Новосибирску** (2026-10-15 18:11:40–44 UTC).
+- В последних15 минутах на01:27: traffic30/30 ok, gre_bgp30/30 ok,
+  internet_path3/3 ok, ошибок этих заданий нет.
+- Тот же сохранённый пароль успешно использован для system/resource, user/active,
+  ip/service, interface/gre (3 записи), routing/bgp/session (3 записи).
+  Пользователь приложения: full, disabled=false, address пустой, api/rest-api
+  разрешены. Это подтверждает текущий доступ, но не объясняет каждый старый401.
+- FTP/Telnet включены. В кольце журнала01:26:00–01:26:47:10 отказов входа
+  с посторонних адресов —9 FTP и1 Telnet; отказов с адреса приложения в этой
+  выборке нет. Следующий снимок показывает **7 внешних Telnet-соединений**.
+  Подбор учётных данных наблюдается; успешный посторонний вход не установлен.
+- У www/www-ssl/api/api-ssl max-sessions=20. Число6 в ошибке нельзя автоматически
+  отождествлять с этим параметром или количеством TCP-соединений приложения.
+- user/active содержит много старых rest-api записей с адреса приложения;
+  api запись в момент чтения одна. По одному списку нельзя доказывать утечку
+  живых TCP-соединений или принудительно удалять записи.
+- RouterOS scheduler `evofw-sync`: enabled, interval1m, run-count625.
+  В доступном кольце01:26–01:30:866 изменений от scheduler, из них860 добавлений
+  address-list и6 изменений filter rule. Два script/job в снимке, включая начатый
+  01:22:08. Скрипты не выгружались и не менялись; связь с отказами не доказана.
+- Общий HTTP/HTTPS Agent backend ограничивает сокеты до2 **на origin**.
+  Одно задание планировщика защищено от повторного запуска; разные задания
+  работают одновременно. Шесть одновременных REST-запросов из основного процесса
+  приложения не установлены.
+
+## Вывод и границы
+
+Неверный пароль как причина текущего доступа не подтвердился. RouterOS явно
+сообщил о насыщении механизма входа;401 возникали рядом, затем без изменения
+пароля прекратились. Связь с внешним подбором, продлением REST-сессии или локальным
+scheduler необходимо различить дальнейшим наблюдением.15 минут успеха не доказывают
+устранение причины.
+
+[Официальная документация REST](https://manual.mikrotik.com/docs/developer-guides/rest-api/)
+описывает внутренний API login, повторное использование логина10 минут и политики
+api/rest-api. Страница относится к7.26; поведение7.24.4 не считать идентичным
+без отдельного подтверждения.
+
+## Локальная правка
+
+- 500 с точным JSON detail `too many concurrent logins (...)` получает подсказку
+  «RouterOS занят: превышен лимит одновременных входов».
+- 401 больше не обозначается безусловно как неверный пароль: предлагается проверить
+  учётные данные, права API/REST и ограничения входа.
+- Исходные HTTP status/path/body сохранены; повторов чтения/записи не добавлено.
+  Другие500 не классифицируются как лимит входов.
+- 12 HTTP-проверок и профиль ros-file, backend production build, scoped ESLint,
+  diff check прошли. Локально, без push/deploy.
+
+## Следующий шаг, требующий разрешения
+
+Временно отключить **только** ftp (`*1`,21) и telnet (`*0`,23) на ID3.
+Перед записью повторно проверить имя/ID и исходный disabled каждой службы.
+Это отключит FTP/Telnet подключения; Winbox, HTTPS, API и маршрутизация сохраняются.
+Для этой диагностики production доступ предоставлен на чтение: запись требует
+отдельного разрешения владельца. Если эти службы нужны, согласовать доверенные адреса.
+
+После разрешения: сохранить исходные disabled, отключить две службы, проверить
+применение и REST-доступ; наблюдать обычный опрос не менее двух периодов продления
+REST-логина, сравнить ошибки и login failures. Не повышать max-sessions, не менять
+пароль, не удалять user/active, не перезапускать маршрутизатор. Результат записать
+отдельно: отключение ещё не выполнялось и причинная связь не доказана.