Микротик и Старлинк на судне. Проблемы и решения

Приветствую! Продолжаю тему использования старлинка в судовых условиях в связке с микротиком. И в этой статье буду описывать проблемы, которые возникают во время эксплуатации Микротика на судне, а также решения этих проблем.

Как оказалось, использовать MikroTik на судне - это ещё то удовольствие. Вроде бы всё настроил и забыл, но нет. Периодически что-то, да происходит. В моём случае, не имея достаточного опыта работы с ним, начали появляться некоторые проблемы, которые я не предусмотрел заранее.

Настройка микротика. Если вам нужна информация, как настраивать микротик под старлинк, то читайте статью: "Starlink REV4 + Mikrotik. Контроль интернет трафика на судне с помощью Микротика".

В этой статье я не только опишу проблемы и решения, но также постараюсь добавлять её свежими знаниями по мере получения опыта работы с микротиком.

1. RADIUS сервер микротика не отвечает

Итак, первая значительная проблема, которая случилась - это "упал" RADIUS сервер. При попытке подключения интернета, а именно логи́на под своим профилем, выдаёт сообщения "RADIUS server is not responding" или "Web browser did not send challenge response (try again, enable JavaScript". Кроме этого в него невозможно зайти с браузера по IP адресу (выдаёт неправильный логин или пароль).

RADIUS сервер микротика не отвечает

И здесь я сделал ошибку, перезагрузил микротик, чтобы попытаться восстановить работу радиус сервера. Таким действием я стёр старые логи. Вместо этого нужно было сначала посмотреть логи на наличие ошибок. Оказалось, что у микротика закончилась внутренняя память "Out of disk space!" free-hdd-space: 500.0KiB, при том, что вся память составляет около 16Мб (total-hdd-space: 16.0MiB). И соответственно из-за этого "упал" радиус сервер.

Проверка содержимого файловой системы на наличие больших файлов (команда в терминале):

/file print detail

Можно также просто зайти в файловую систему микротика (раздел Files) и визуально поискать файлы большого размера.

Файл logsqldb в каталоге flash/user-manager

При поиске причины недостаточного объёма внутренней памяти был обнаружен файл logsqldb в каталоге flash/user-manager с размером 2645.0 KiB (около 2.7 Мб). Ниже предлагаю ознакомиться с вариантами решения данной проблемы.

За что отвечает файл logsqldb?

Файл logsqldb в каталоге flash/user-manager накапливает данные логирования работы User Manager, включая историю сессий, авторизаций и других событий. Если в системе не настроено ограничение объёма логов или регулярная их очистка, файл может быстро увеличиваться в размерах, особенно на устройствах с большим количеством пользователей или частыми авторизациями.

Почему файл logsqldb стал таким большим?

1. Большое количество пользователей и авторизаций: Если через User Manager проходит много пользователей, и каждый раз записывается информация о сессиях, логах, это быстро заполняет доступное место.
2. Долгое время хранения логов: По умолчанию система может не очищать старые логи, поэтому они копятся со временем.
3. Ограниченный объем памяти устройства: Устройство имеет всего 16 Мб внутренней памяти, что делает его уязвимым к переполнению из-за таких больших файлов.
4. Нет автоматической очистки: MikroTik не очищает логи автоматически. Нужно вручную выполнять очистку или настроить скрипт.

Почему это вызвало сбой RADIUS сервера?

Когда внутреннее хранилище устройства заполнено, RouterOS перестает нормально работать. Некоторые процессы (например, RADIUS, который использует User Manager для авторизации) требуют свободного места для временных файлов или операций записи.

Сообщение Out of disk space! указывает на критическое состояние, при котором многие функции системы могут быть нарушены.

Как настроить автоматическую очистку логов?

Для предотвращения подобной ситуации можно настроить автоматическую очистку логов с помощью скрипта и планировщика. Вот пример:

1. Создайте скрипт для очистки логов:

/system script set clear_user_manager_logs source="

:local logFile [/file find name=\"flash/user-manager/logsqldb\"];

:if ([:len \$logFile] > 0) do={

    /file remove \$logFile;

    :log info \"User Manager logs cleared to free up disk space.\";

} else={

    :log warning \"logsqldb file not found, no action taken.\";

}"

Проверка скрипта

Проверка скрипта:

/system script print

Если рядом с вашим скриптом есть флаг I, то он недействителен. Проверьте его корректность.

2. Запустите скрипт вручную:

/system script run clear_user_manager_logs

При активации скрипта файл logsqldb может удалиться, это нормально. Потом он заново создастся при логировании пользователей. Если он не создается, то необходимо перезапустить микротик.

3. Проверьте логи:

/log print where message~"logs"

Если скрипт выполнен успешно, появится сообщение:

info: User Manager logs cleared to free up disk space.

4. Настройте планировщик для регулярного выполнения:

Добавьте задачу, которая будет запускать скрипт, например, раз в неделю:

/system scheduler add name="weekly_log_cleanup" interval=1w on-event=clear_user_manager_logs

5. Проверьте планировщик:

/system scheduler print

Пример результата:

name="weekly_log_cleanup" start-date=nov/28/2024 start-time=00:00:00 interval=1w on-event=clear_user_manager_logs

6. Измените интервал при необходимости: Если вам нужно запускать скрипт чаще (например, ежедневно), измените интервал:

/system scheduler set weekly_log_cleanup interval=1d

Я использовал данный скрипт, запустил его вручную и RADIUS сервер снова начал работать. Также я настроил планировщик, чтобы чистка производилась автоматически раз в 7 дней. 

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

Дополнительные меры для контроля логов:

Ограничение уровня логирования

Настройте минимально необходимый уровень логирования для User Manager:

/tool user-manager logging set level=critical

Это уменьшит количество записываемых событий.

Регулярная оптимизация базы данных

Для уменьшения размера базы данных рекомендуется периодически выполнять очистку старых сессий и оптимизацию:

/tool user-manager database clear-session

/tool user-manager database clear-log

Мониторинг дискового пространства

Настройте мониторинг, чтобы система предупреждала, если свободное место становится слишком маленьким:

Создайте скрипт:

/system script add name="check_disk_space" source="

:if ([/system resource get free-hdd-space] < 1000) do={

    :log warning \"Low disk space on device!\";

}"

Настройте выполнение каждые 10 минут:

/system scheduler add name="disk_monitor" interval=10m on-event=check_disk_space

Эти меры помогут предотвратить переполнение диска в будущем, сохранив работоспособность RADIUS сервера и всей системы.

Убедитесь, что ваша система не имеет конфликтов задач и что скрипты не удаляют важные файлы, проверяя их перед запуском.

В итоге можно сделать вывод, что периодически необходимо следить за размером файловой системы Микротика и предотвращать её переполнение. Можете использовать скрипты или вручную мониторить объем файлов. Кстати, микротик был запущен около двух месяцев назад до возникновения проблемы.

2. Перегрузка Wi-Fi усилителей и роутер Старлинка

Заметил такой момент, что периодически вылетает один Wi-Fi усилитель, который подвязан к роутеру Tp-Link на микротике. Его приходится перезагружать примерно раз в неделю. В основном это происходит из-за перегрузки сети через основной роутер старлинка. 

То есть устройство, которое подключено к роутеру старлинка напрямую (без ограничения трафика) и на нём сделать, например, Speed Test, таким образом может "положить" усилитель. Думаю выход здесь один - этого не делать (не перегружать сеть) пока судно находится в переходе на лимитном трафике.

Кстати, если вас интересует процесс установки и настройки старлинка на судне, то рекомендую прочитать статью "Starlink на судне. Опыт эксплуатации глобального интернета на судне".

Пока на этом всё. По мере возникновения проблем с микротиком статья будет пополняться. Если у вас возникли проблемы с микротиком или есть чем поделиться из личного опыта, то пишите в комментариях к статье. Буду очень признателен.

Надеюсь статья была для вас полезной. Спасибо за внимание!