mikrotik скрипт запись в лог
Полезные скрипты для MikroTik RouterOS
Перезагрузка роутера, при зигрузке CPU
Копирование и применение последней актуальной понфигурации
То есть забираем по FTP lastconfig.backup и восстанавливаемся с него. FTP пользователь должен быть настроен, желательно с ограничением доступа по IP. Обратите внимание, что к FTP подключаемся по IP-адресу локального физического интерфейса, который доступен только между роутерами.
Этот скрипт ставим в планировщик на несколько минут позже выполнения скрипта резервного копирования.
И последний скрипт — применение настроек на резервном сервере. В нем также используется МАС для идентификации роутера.
Здесь меняем имя роутера, ip-адрес LAN-интерфейса и приоритет VRRP на меньший, чтобы роутер сделать слейвом. Запуск этого скрипта нужно поставить в автозагрузку. Изменения будут происходить на резервном сервере после копирования и применения последней актуальной конфигурации.
Резервное копирование
Проверка статуса роутера и выключение интерфейса
Подключение к динамическим серверам или сервисам, на примере pptp-соединения
Проверка синтаксиса скрипта
Настройка на 2 провайдера:
Блокировка трафика по времени:
Если нужно запретить трафик по времени ночью, скажем с 22:00 до 10:00 утра:
0) Стандартный способ – использовать два правила с временными промежутками 22:00:00-23:59:59 и 00:00:00-10:00:00
1) Использовать через запрет – Где-то в конце есть правило, которое запрещает, а конкретным правилом разрешать.
2) Использовать шедулер –
также создаём правило в файрволе, но не указываем конкретное время –
Mikrotik скрипты, работа с логами
Данная заметка касается применения скриптов для своевременного оповещения об аварии.
Скрипт должен записать сообщение в основной лог микротика и отправить сообщение на почту.
/system scripts
/system scheduler
:if ([/interface eoip get [find name=»EoIP_my_001″] running]=false) do= <
/log warning («EoIP down»)
/tool e-mail send to=»xxxx@xxxx.xxx» from=»yyyy@yyyy.yy>»
server=»10.10.10.10″ subject=»Host is down.»
>
Скрипт запускает через встроенный Scheduler с нужным интервалов времени.
Вместо оповещения, можно сделать конкретное действие, добавить else для обработки если true, вопрос фантазии.
/system scheduler add name=schedule3 on-event=script_name_for_run interval=00:03:00 policy=read,write
P.S. Изменить кол-во сообщение в логе и очистить предыдущие можно таким образом:
/system logging action set disk-lines-per-file=1
/system logging action set disk-lines-per-file=100
Первая строчка устанавливаем размер лога в 1 запись, тем самым удаляет все что было до этого, вторая соответственно выставляет длину лога в 100 записей.
Комментарии:
Скрипты могучая вещь, да и вообще микроты молодцы. Сейчас интересуюсь как сделать так чтобы канал распределялся динамически, т.е. имеем 10 мбит., нугрузки нет, отдаем всем ровно, появилось много клиентов, делим так чтобы никто не мог на себя забрать все и скажем оставался какой-нибудь резерв.
Sancho
2016-05-18 19:33:59
Не понятно, почему нельзя очистить логи. Может быть не туда смотрю? Нужно не забывать про SNTP, чтобы потом в этих логах разобраться.
admin
2015-09-28 18:07:47
Не знаю, может быть в другой версии работало, но перестало, сейчас верно так: /system logging action set memory memory-lines=1 /system logging action set memory memory-lines=100
MikroTik Скрипт: Уведомление о успешном входе на устройство или простой парсер журнала MikroTik
Статья будет больше интересна специалистам использующим небольшой парк устройств (не использующим отдельный сервер, для системы мониторинга или логирования), домашним пользователям, тем кто в первый раз подступается к написанию скриптов устройства и тем у кого нет времени/желания разбираться.
Пример email с событиями вход/выход пользователей
Написать свой скрипт меня сподвигло желание упростить монструозные скрипты, которые можно найти по этому запросу в интернете, выполняющие это несложное действие (пример скрипта с Wiki MikroTik), а так же показать почему инженеры MikroTik сделали невозможным простой способ парсинга, если вы не житель Лондона. 🙂
Статья разбирает пример уведомления о входе и выходе пользователя с устройства MikroTik, но так же покажет примеры:
Организация времени в журнале устройства;
Парсинг журнала устройства, поиск событий по критериям;
Отправка уведомлений на электронную почту;
Отправка сообщения Telegram.
Предыстория. Почему скрипты парсинга логов MikroTik «монструозны»?
Под монструозностью будем понимать большой объем логики скрипта и конструкции вида:
Они показывают умение администратора «оптимизировать» код, но здорово усложняют возможности понимания скриптов другими пользователями.
Но самую огромную роль в усложнение логики этого скрипта внесла сама компания MIkroTik, с интересной логикой журнала на устройстве. 🙂
Что может быть проще конструкции: «найди все события по времени старше последнего запуска с темой «account», запущенной простым казахстанцем (UTC+06)?
Это даже будет работать, ровно до 23:59:59 текущего дня. А после 12 ночи, скрипт превратится в тыкву А вот после 00:00:00 система начнет вываливать все события предыдущего дня. Почему?
Инженеры MikroTik большие оригиналы решившие сделать хранение записей журнала следующим образом: система хранит в журнале события сегодняшнего дня только с параметром времени, а чтобы не путаться, когда сменяется день, перезаписывает время событий добавляя дату, во все события «вчерашнего» дня. Для пользователя, в журнале событий все события отображаются дата/время, но сама система, событиям текущего дня присваивает только время.
Ну и где здесь оригинальность? А оригинальность в том, что MikroTik считает началом нового дня время 00:00:00 по UTC±0:00. Игнорируя часовой пояс самого устройства, т.е. у меня (UTC+06), до 6 утра, выдавались все уведомления за предыдущий день. В 06:00:00 Микротик перезаписывал всем событиям дату и скрипт снова начинал корректно работать.
Так что если вы не житель Лондона (UTC±0:00), для парсинга журнала устройства по времени вам приходилось использовать костыли, решая логикой скрипта проблему организации времени на устройстве.
Костыли делать мне не хотелось (в частности однажды это могут исправить), поэтому подумалось над вариантом который был бы проще в работе и проще в понимании другими пользователями.
Логика скрипта
Помимо параметров время события, текст события, MikroTik использует уникальный параметр id события, который мы будем использовать (.id уникален до перезапуска устройства, потом отчет начинается заново, с 0).
Формируем текст email, записывая новой строкой сообщение журнала MikroTik;
Формируем текст Telegram сообщения, используя %0D%0A для переноса строки;
Отправляем сформированное сообщение на email;
Отправляем сформированное сообщение в Telegram;
Записываем в ParseLogAccountEndArrayID последний ID сообщения с темой «account» (EndArrayID).
Создать скрипт
Для запуска скрипта необходимы разрешения: read, write, test, policy.
Код скрипта
Добавление скрипта в Планировщик
Для запуска скрипта необходимы разрешения: read, write, test, policy.
Или выполните в терминале:
Заключение
Надеюсь приведенный скрипт будет вам полезен, вы поймете как легко и просто парсить журнал устройства MikroTik выставляя триггеры по теме сообщения, или тексту сообщения.
Пример Telegram сообщения
Возможные темы сообщений в журнале устройства, можно увидеть попытавшись создать правило Logging:
Для парсинга текста сообщений используйте регулярные выражения и команду вида:
[/log find where message
Установив более частое время проверки скрипта, вы можете выполнить дополнительные действия при входе/выходе пользователя, например автоматическое создание резервной копии (для тех кто любит править Firewall в пятницу вечером, забывая устанавливать MikroTik Safe Mode) или что еще подскажет воображение.
Мой скрипт выглядит проще, чем что я находил в интернете и доступен к оптимизации, если вы любите оптимизировать код в минимальное количество строк.
Если вы используете множество скриптов на вашем устройстве, указывать параметры почты и Telegram бота, в каждом из скриптов нерационально, особенно если возникнет необходимость изменить параметры. Я использую в своих скриптах вызов скриптов функций: «Отправить Email» и «Отправить сообщение Telegram», возможно и Вам это тоже будет полезно, упрощая управление устройством MikroTik.
Работа скрипта проверена на: hAP ac lite, RouterOS 6.47.8 (stable).
UPD 11.12.2020: Выставляйте права на запуск скрипта в Scheduler и на сам скрипт, как указано в статье: read, write, test, policy. Излишние права (выставляются по умолчанию новому скрипту) могут привести к появлению ошибки «could not run script ParseLogAccountEvents: not enough permissions«. Проверяйте журнал устройства.
Пишем скрипт для MikroTik об успешном входе на устройстводля.
Статья будет больше интересна специалистам использующим небольшой парк устройств (не использующим отдельный сервер, для системы мониторинга или логирования), домашним пользователям, тем кто в первый раз подступается к написанию скриптов устройства и тем у кого нет времени/желания разбираться.
Пишем скрипт об успешном входе на устройстводля MikroTik.
Написать свой скрипт меня сподвигло желание упростить монструозные скрипты, которые можно найти по этому запросу в интернете, выполняющие это несложное действие (пример скрипта с Wiki MikroTik), а так же показать почему инженеры MikroTik сделали невозможным простой способ парсинга, если вы не житель Лондона.
Статья разбирает пример уведомления о входе и выходе пользователя с устройства MikroTik, но так же покажет примеры:
Предыстория. Почему скрипты парсинга логов MikroTik «монструозны»?
Под монструозностью будем понимать большой объем логики скрипта и конструкции вида:
Они показывают умение администратора «оптимизировать» код, но здорово усложняют возможности понимания скриптов другими пользователями.
Но самую огромную роль в усложнение логики этого скрипта внесла сама компания MIkroTik, с интересной логикой журнала на устройстве. 🙂
Что может быть проще конструкции: «найди все события по времени старше последнего запуска с темой «account», запущенной простым казахстанцем (UTC+06)?
Это даже будет работать, ровно до 23:59:59 текущего дня. А после 12 ночи, скрипт превратится в тыкву А вот после 00:00:00 система начнет вываливать все события предыдущего дня. Почему?
Инженеры MikroTik большие оригиналы решившие сделать хранение записей журнала следующим образом: система хранит в журнале события сегодняшнего дня только с параметром времени, а чтобы не путаться, когда сменяется день, перезаписывает время событий добавляя дату, во все события «вчерашнего» дня. Для пользователя, в журнале событий все события отображаются дата/время, но сама система, событиям текущего дня присваивает только время.
Ну и где здесь оригинальность? А оригинальность в том, что MikroTik считает началом нового дня время 00:00:00 по UTC±0:00. Игнорируя часовой пояс самого устройства, т.е. у меня (UTC+06), до 6 утра, выдавались все уведомления за предыдущий день. В 06:00:00 Микротик перезаписывал всем событиям дату и скрипт снова начинал корректно работать.
Так что если вы не житель Лондона (UTC±0:00), для парсинга журнала устройства по времени вам приходилось использовать костыли, решая логикой скрипта проблему организации времени на устройстве.
Костыли делать мне не хотелось (в частности однажды это могут исправить), поэтому подумалось над вариантом который был бы проще в работе и проще в понимании другими пользователями.
Логика скрипта
Помимо параметров время события, текст события, MikroTik использует уникальный параметр id события, который мы будем использовать (.id уникален до перезапуска устройства, потом отчет начинается заново, с 0).
Создать скрипт
Для запуска скрипта необходимы разрешения: read, write, test, policy.
Код скрипта
Добавление скрипта в Планировщик
Для запуска скрипта необходимы разрешения: read, write, test, policy.
Или выполните в терминале:
Заключение
Надеюсь пишем скрипт для MikroTik будет вам полезен, вы поймете как легко и просто парсить журнал устройства MikroTik выставляя триггеры по теме сообщения, или тексту сообщения.
Возможные темы сообщений в журнале устройства, можно увидеть попытавшись создать правило Logging:
Для парсинга текста сообщений используйте регулярные выражения и команду вида:
[/log find where message
Установив более частое время проверки скрипта, вы можете выполнить дополнительные действия при входе/выходе пользователя, например автоматическое создание резервной копии (для тех кто любит править Firewall в пятницу вечером, забывая устанавливать MikroTik Safe Mode) или что еще подскажет воображение.
Мой скрипт выглядит проще, чем что я находил в интернете и доступен к оптимизации, если вы любите оптимизировать код в минимальное количество строк.
Работа скрипта проверена на: hAP ac lite, RouterOS 6.47.8 (stable).
Писать скрипты для Mikrotik RouterOS — это просто
блокировать все TCP соединения на порт 80 по адресу example.com
блокировать все TCP соединения на порт 80 по любому адресу из списка с именем DenyThis
Текст скрипта нужно добавить в репозиторий скриптов, находящийся в разделе /system scripts.
Скрипт выполняется построчно. Каждая строка имеет следующий синтаксис:
[prefix] — «:» — для глобальных комманд, с символа «/» начинается командная строка, которая будет выполняться относительно корня конфигурации, префикс может отсутствовать, тогда командная строка выполняется относительно текущего раздела конфигурации;
[path] — путь до требуемого раздела конфигурации, по которому происходит переход перед выполнением команды;
command — непосредственно действие, выполняемое командной строкой;
[uparam] — безымянный параметр команды;
[param=[value]] — именованные параметры и их значения.
Итак, первым делом, определим параметры работы скрипта в виде переменных. Переменная объявляется командами :local и :global, соответственно получаем локальную переменную, доступную только внутри своей зоны видимости, или глобальную, которая добавляется в список переменных окружения ОС и будет доступна откуда угодно. Локальные переменные живут, пока выполняется их зона видимости, глобальные — пока мы не удалим их.
Переменная DNSList содержит массив доменов, с которым мы хотим работать. Переменная ListName содержит строку, которой будет называться полученный address-list. Переменная DNSServers — содержит массив адресов DNS-серверов, прописанных на роутере или полученных от провайдера при подключении, плюс «восьмёрки» на случай, если на роутере не используется служба DNS, который будет использоваться для получения информации о записях доменов.
В цикле «для каждого» обойдём массив доменов и отрезолвим их IP-адреса на каждом DNS-сервере на случай, если разные DNS отдают разные IP. Конструкцияслужит для отлова runtime-ошибок. Если не использовать её, то скрипт может прервётся при ошибке резолва несуществующего или ошибочного адреса.
перейдём в раздел конфигурации /ip dns cahe all. Там содержатся DNS-кэш роутера в виде таблицы Name — Type — Data — TTL. Выполним отбор по типу — нам требуются только A-записи. И результат отбора обойдём в цикле «для каждого». Это и будет главным циклом нашего скрипта.
Создадим переменные, обновляемые в каждом цикле: два флага — bNew, исключающий дублирования, match, показывающий, входит ли текущая запись кэша в наш список доменов; переменная cacheName содержит поле Name текущей записи кэша, то есть домен.
Обойдём список доменов и для каждого проверим, содержится ли в строке cacheName подстрока в виде домена из этого списка.
Если содержится, установим значение флага match в true.
В заключающем этапе если текущий адрес требует добавления (match установлен в true), то мы его добавляем в список адресов. Коментарий к добавляемой записи будет содержать домен, к которому она относится. При этом выполняем несколько проверок. Если address-list пустой, то добавляем сразу, если что-то там есть, проверяем, нет ли там уже записи с таким IP-адресом и если нет — добавляем.
Список адресов нужно периодически обновлять. Для этого в RouterOS есть диспетчер заданий. Задание можно добавить из консоли или из графического интерфейса winbox
Сценарии работы со списком адресов не ограничиваются созданием правил в фаерволе. Поэтому приведу несколько примеров. Можно выполнять в консоли, можно добавлять мышкой в winbox’е.
Чёрный список:
Статический маршрут до данных узлов
Сбор информации о клиентах
UPD: специально по просьбе turone внёс изменения в скрипт, чтобы адреса DNS-серверов брались из системы.
UPD 24.08.2016: заметил, что в новых версиях RouterOS (начиная с 6.36) появилась возможность указывать в адрес-листах DNS-имена. Так что теперь ценность данного скрипта лишь образовательная.