Files
MikrotikManager/deploy/PRODUCTION-ROUTEROS-273.md
T

73 lines
6.5 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
# 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, не перезапускать маршрутизатор. Результат записать
отдельно: отключение ещё не выполнялось и причинная связь не доказана.