mikrotik netwatch запуск скрипта
Полезные скрипты для 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) Использовать шедулер –
также создаём правило в файрволе, но не указываем конкретное время –
Netwatch MIkrotik – оповещение о падении сервера.
Что такое Netwatch Микротик?
Данный инструмент находится по меню Tools – Netwatch и выполняет функцию отслеживания состояния заданных ip-адресов, узлов и в зависимости от состояния сервера срабатывает скрипт.
В альянсе с возможностью отправить письмо о недоступности монтируемого узла через встроенный в Микротик инструмент Tools – Email получается востребованным инструментом.
1. Перейдем к настройке Netwatch.
Переходим в меню Tools – Netwatch.
В открывшемся окне «New Netwatch Host» на вкладке “Host” заполняем следующие поля:
Переходим на следующую вкладку “Up” :
Здесь необходимо добавить скрипт. Который будет отправлять сообщение на Email в случае, если адрес из вкладки “Host” станет ДОСТУПНЫМ.
Например, текст скрипта следующий:
На следующей вкладке “Down” пишем скрипт, который сработает при пропадании ping до host и отправит нам письмо с текстом о НЕДОСТУПНОСТИ указанного адреса сервера:
2. Настройка SMTP Mikrotik.
Осталось настроить SMTP Mikrotik для отправки почты. Допустим будем использовать почту от Yandex (данные для ввода почтовых серверов yandex или google спокойно ищутся в поисковике).
Переходим в Tools – Email.
В открывшемся окне “Email Settings” заполняем по порядку поля:
Нажимаем ОК и теперь будем вовремя получат уведомления о состоянии сервера.
Dual Wan и особенности реализации NetWatch в MikroTik
«Если в простой конфигурации микротик не работает, значит вы не умеете его готовить… или явно что-то упустили.»
Как работают вместе failover и netwatch. Взгляд изнутри.
Почти каждой более-менее подросшей компании начинает хотеться качества коммуникаций. Среди прочего, заказчику часто хочется отказоустойчивый «Dual WAN» и VoIP телефонию. Тоже отказоустойчивую, разумеется. Руководств и статей по каждой теме в отдельности написано много, но внезапно оказалось, что совместить первое и второе получается не у всех.
На Хабре уже есть статья «Mikrotik. Failover. Load Balancing» от vdemchuk. Как оказалось, она послужила для многих источником копипасты кода в маршрутизаторы.
Хорошее, рабочее решение, но SIP-клиенты из LAN, подключающиеся к внешней IP-АТС посредством NAT, при переключении теряли связь. Проблема известная. Связана она с работой Connection tracker, который запоминает имеющиеся соединения вовне, и сохраняет их состояние независимо от других условий.
Понять почему так происходит можно посмотрев на диаграмму packet flow:
Для транзитного трафика процедура обработки connection tracker выполняется всего в одной цепочке — prerouting, (т.е. до роутинга), до выбора маршрута и исходящего интерфейса. На этой стадии еще неизвестно, через какой интерфейс пакет пойдет в Интернет, и отследить src-ip при нескольких Wan-интерфейсах невозможно. Механизм фиксирует установленные соединения уже пост-фактум. Фиксирует и запоминает на время пока через соединение идут пакеты или пока не истечет заданный таймаут.
Описанное поведение характерно не только для маршрутизаторов MikroTik, но и для большинства Linux-based систем выполняющих NAT.
В результате, при обрыве связи через WAN1, поток данных послушно направляется через WAN2, только SOURCE IP прошедших через NAT пакетов остается неизменный — от интерфейса WAN1, т.к. в connection tracker уже есть соответствующая запись. Естественно, ответы на такие пакеты идут на интерфейс WAN1 уже потерявший связь с внешним миром. В итоге, связь как будто есть, но на самом деле её нет. При этом все новые соединения устанавливаются корректно.
Hint: увидеть с каких и на какие адреса делается NAT можно в колонках «Reply Src. Address» и «Reply Dst. Address». Отображение этих колонок включается в таблице «connections» с помощью правой кнопки мыши.
На первый взгляд выход выглядит довольно простым — при переключении сбросить ранее установленные SIP-соединения, чтобы они установились заново, уже с новым SRC-IP. Благо простой скрипт по просторам интернета бродит.
Три шага к фейлу
Шаг первый. Копипастеры добросовестно переносят конфиг для Failover recursive routing:
Шаг второй. Отследить событие переключения. Чем? «/tool netwatch», естественно! Попытка отследить падение шлюза WAN1 обычно выглядит так:
Шаг третий. Проверка.
Админ гасит первый аплинк WAN1 и вручную запускает скрипт. SIP-клиенты переподключились. Работает? Работает!
Админ включает обратно WAN1 и вручную запускает скрипт. SIP-клиенты переподключились. Работает? Работает!
В реальной обстановке такой конфиг работать отказывается. Неоднократное повторение шага №3 приводит админа в состояние озлобления и мы слышим «Не работает ваш микротик!». 
Разбор полётов
Всё дело в непонимании того, как происходит работа утилиты Netwatch. Применительно в отношении именно рекурсивного роутинга, утилита просто пингует заданный хост согласно основной таблице маршрутизации, используя активные маршруты.
Проведем эксперимент. Отключим основной канал WAN1 и посмотрим и интерфейс /tool netwatch. Мы увидим, что хост 8.8.8.8 по-прежнему имеет состояние UP.
Для сравнения опция check-gateway=ping, работает для каждого маршрута в отдельности в т.ч. рекурсивно, и делает сам маршрут активным либо НЕактивным.
Netwatch использует уже активные на данный момент маршруты. Когда что-либо происходит на линке до шлюза провайдера ISP1 (WAN1), маршрут до 8.8.8.8 через WAN1 становится неактивным, и netwatch игнорирует его, отправляя пакеты в новый default route. Failover играет злую шутку, и netwatch считает, что всё в порядке.
Второй вариант поведения netwatch, это двойное срабатывание. Механизм его таков: если пинги от netwatch попадут в таймаут check-gateway, то на один цикл проверки хост будет признан DOWN. Сработает скрипт переключения канала. SIP-соединения корректно перейдут на новый линк. Работает? Не совсем.
Скоро таблица маршрутизации перестроится, хост 8.8.8.8 получит статус UP, вновь сработает скрипт сброса SIP-соединений. Соединения второй раз переустановятся через WAN2.
В результате, при возвращении в строй ISP1 и переходе рабочего трафика на WAN1, SIP-соединения так и останутся висеть через ISP2 (WAN2). Чревато это тем, что при проблемах у на запасном канале система этого не заметит и телефонной связи не станет.
Решение
Для того, чтобы трафик на используемый для мониторинга хост 8.8.8.8 не заворачивался на ISP2, нам нужно иметь запасной маршрут до 8.8.8.8. На случай падения ISP1, создаем резервный маршрут с большим значением distance, например distance=10 и type=blackhole. Он и станет активным при пропадании линка до WAN1 Gateway:
/ip route add distance=10 dst-address=8.8.8.8 type=blackhole
В итоге имеем дополнение конфига всего лишь одной строкой:
Данная ситуация характерна именно при падении последней мили, когда шлюз ISP1 становится недоступным. Либо при использовании туннелей, которые более подвержены падениям в силу цепной зависимости.
Надеюсь, статья поможет вам избежать подобных ошибок. Выбирайте свежие мануалы. Будьте в курсе, и всё у вас «взлетит».
Настройка MikroTik Netwatch оповещения на E-Mail о падении хоста
В этой статье мы настроим оповещение о падении хоста с помощью утилиты Netwatch.
Что такое Netwatch?
Netwatch отслеживает состояние хостов в сети. Происходит это путем отправки ICMP пакетов к указанным IP-адресам. Для каждой записи в таблице Netwatch можно указать IP-адрес, интервал пинг и консольные скрипты. Основным преимуществом NetWatch является его способность выдавать произвольные консольные команды при изменении состояния хоста.
Если вы ищете понятный и удобный источник информации по микротикам, то вот он: курс «Настройка оборудования MikroTik». Это видеоучебник, где «без воды» собрана вся базовая информация по работе с MikroTik и RouterOS. Для новичков станет прямым руководствам, опытные инженеры смогут освежить и упорядочить знания. 162 видеоурока и 45 лабораторных работ, основанные на программе вендора MTCNA. Первые 25 уроков можно заказать бесплатно на странице курса.
Настройка
Первым делом настроим SMTP сервер на примере Gmail.
Вводим адрес smtp сервера Gmail:
Port:
Start TLS:
From:
User:
ваша почта (до знака @)
Password:
Должно получится так:
Можно сразу проверить отправку нажав на Send Email, далее заполняем верхние поля как здесь и не забываем ставить галочку TLS. После указываем адрес получателя, тему, содержание письма и нажимаем Send Email.
На кладке Host заполняем:
На вкладке Up прописываем скипт, который будет выполняться при появлении линка,
в нашем случаи будет отправке сообщения на Email
Текст скрипта следующий:
tool e-mail send to=mail@gmail.com subject=»Тема письма» body=»Текст письма»
На вкладке Down прописываем скрипт который будет выполняться при обрыве линка,
у нас так же пойдет оповещение на заданный Email.
tool e-mail send to=mail@gmail.com subject=»Тема письма» body=»Текст письма»
Теперь при обрыве\появлении линка вы первым можете узнать об этом.
Если вы ищете понятный и удобный источник информации по микротикам, то вот он: курс «Настройка оборудования MikroTik». Это видеоучебник, где «без воды» собрана вся базовая информация по работе с MikroTik и RouterOS. Для новичков станет прямым руководствам, опытные инженеры смогут освежить и упорядочить знания. 162 видеоурока и 45 лабораторных работ, основанные на программе вендора MTCNA. Первые 25 уроков можно заказать бесплатно на странице курса.
Mikrotik netwatch запуск скрипта
Как при помощи Netwatch и нехитрых скриптов обеспечить офис бесперебойным доступом в Интернет и быть в курсе происходящего.
Прежде всего определимся как и что мы переключаем. Например, у нас есть 2 интерфейса: pppoe-out1 — который соединяется с основным провайдером (ISP1) и ether7 — к которому подключен резервный канал или второй провайдер (ISP2).
Firewall
Работоспособность каналов будем определять путем проверки доступности DNS-серверов Google 8.8.8.8 и 8.8.4.4 через каждого из провайдеров (Можно использовать и другие, лишь бы достаточно надежные. Крайне не рекомендую использовать для этого DNS-серверы провайдера.). Для этого создадим в Firewall и Route следующие правила:
То есть блокируем трафик к 8.8.8.8 для ISP2 и 8.8.4.4 для ISP1.
Включаем NAT, если это ещё не сделано.
Routes и Mangle
Чтобы исключить путаницу запросов через разных провайдеров, будем маркировать входящие соединения от каждого провайдера и направлять исходящий трафик тому от которого пришел запрос.
Скрипты и Netwatch
Логика переключение проста — если адрес 8.8.8.8 недоступен, то ISP1 не работает и нужно отключить к нему маршрут и отправить уведомление о сбое через оставшийся маршрут для ISP2. Так как второго провайдера отключать нет смысла, то после проверки просто отправляем уведомление о его состоянии.
Проверку и вызов скриптов выполняем утилитой Netwatch.
Чтобы заработала отправка e-mail нужно указать учетную запись и SMTP-сервер через который мы хотим отправлять почту.