mikrotik скрипт переключения на резервный канал

Универсальный скрипт переключения 2-х каналов интернета Mikrotik

Около 2,5 лет назад писал статью на тему автоматического переключения канала Интернет на резервный. Скрипт, конечно, и по сей день работает «на отлично», но его внешний вид и некоторые нюансы…

Итак, встала задача улучшить скрипт, максимально устранив побочные эффекты. Что ж, приступим.

В нашем распоряжении Mikrotik RB850Gx2, для которого мы будем писать скрипт (его работоспособность также проверена на моделях RB450G и RB951G-2HnD).

Присвойте скрипту имя, например, script-check-inet

Что же будем в нем использовать?

Итак, для начала определим необходимые переменные:

где:
$firstInterface — имя нашего PPPoE-соединения основной линии связи.
$secondInterface — имя нашего Ethernet-соединения резервной линии.
$pingTo1 и $pingTo2 — IP-адреса ресурсов, которые будем «пинать».
$pingCount — количество пингов на каждый IP-адрес
$stableConnectFrom — процентное соотношение для определения «стабильности» Интернет-канала. Например, в нашем случае при потере свыше 30% пакетов пинга (`$pingStatus Создадим запись в шедулере

В поле `Name` введите имя записи, чтобы не запутаться.
Поле `Start Time` я выставил `00:00:00` для запуска ровно в полночь.
Интервал — 30 секунд
В поле `On Event` вписываем имя нашего скрипта — `script-check-inet`
И жмем «ОК».

Вот, собственно, и все!

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

Так как мы ввели дополнительную переменную `$firstInterfaceName`, то удалось изменить эту конструкцию и добились работоспособности скрипта на всех перечисленных устройствах.

UPD 2

Код скрипта в очередной раз был обновлен. esudnik обратил внимание на проблему большого количества потерянных пакетов при активном подключении к сети. Таким образом, мы ввели дополнительную переменную (`stableConnectFrom`), используемую для определения процентного соотношения «качества» линии.

В примере указано значение переменной равное «70». Это значит, если процент успешно отправленных пакетов будет ниже 70%, скрипт активирует резервный канал.

UPD 3

Как заметил icCE, при использовании скрипта на прошивке 6.36rc10, выходит ошибка:

Прошивке не нравится «* 100«. Решение проблемы было простым — обрамить вычисляемые значения в дополнительные скобки, получив

Источник

Резервирование Интернет-канала на Mikrotik

В данной инструкции мы рассмотрим пример настройки двух Интернет-каналов одновременно на роутере Mikrotik с целью отказоустойчивости — при разрыве соединения основной канал будет меняться на резервный. В нашем случае будет задействован один WAN Ethernet, второй — LTE. Итого, два провайдера и две сети.

Есть два способа настройки отказоустойчивости:

Мы рассмотрим оба варианта. Настройки выполним в программе winbox. Настройка в веб-интерфейсе аналогична.

Перед началом, убедитесь, что по отдельности микротик раздает Интернет от обоих провайдеров.

Маршруты с разным приоритетом

Раскрываем в меню IP:

. и переходим в Routes:

Добавляем 2 маршрута. Первый через одного Интернет провайдера со следующими настройками:

* мы указываем шлюз от нашего провайдера (в данном примере 1.1.1.1), задаем настройку проверки шлюза (Check Gateway) с помощью утилиты ping, задаем приоритет (Distance 10).

Для второго провайдера мы задаем, практически, аналогичные настройки:

* обратите внимание, что в отличие от первого маршрута, в данном указана большая дистанция и другой шлюз (для второго провайдера).

После удаляем старые маршруты. Должны остаться только те, что мы добавили.

Использование сценария, запускаемого в Netwatch

Данный метод поможет настроить резервирование канала, если один из провайдеров выдает динамические адреса в разных подсетях, например, подключение через 4G-модем.

1. Задаем описания

Сначала необходимо задать описание для маршрутов. Это понадобиться для сценария, который будет работать с последними через данные описания.

Раскрываем в меню IP:

. и переходим в Routes:

Открываем на редактирование оба маршрута через наших провайдеров и добавляем комментарий в разделе Comment:

2. Настраиваем узел для проверки канала

Мы настроим узел, который будет пинговать провайдер 1. Если пинг пропадает, то необходимо переключать активный Интернет-канал на провайдера 2. Также мы должны заблокировать возможность пинговать проверочный узел с провайдера 2.

И так, переходим к настройке маршрутов:

Добавляем новый маршрут к проверочному узлу, например 77.88.8.2 (DNS Яндекса):

* в данной настройке мы задали маршрут к проверочному узлу через шлюз 1.1.1.1 (в нашем примере это шлюз от провайдера 1).

Создаем новое правило для запрета пинга проверочного узла через провайдера номер 2:

. в качестве действия выбираем drop:

3. Настройка задания в Netwatch

Создаем новое правило. На вкладке Host прописываем следующее:

* в данном примере мы будем проверять узел 77.88.8.2 раз в минуту.

На вкладке Up пропишем:

/ip route set [find comment=»ISP_1″] disabled=no
/ip route set [find comment=»ISP_2″] disabled=yes

. а на вкладке Down следующее:

/ip route set [find comment=»ISP_1″] disabled=yes
/ip route set [find comment=»ISP_2″] disabled=no

Нажимае OK.

Проверка

Для проверки отказоустойчивости лучше всего отключить кабель основного провайдера (вытащить провод из WAN-разъема) — через небольшой промежуток времени Mikrotik должен начать раздавать Интернет второго провайдера. Проверить, что внешний канал изменился можно с помощью различных сайтов, например, 2ip.ru.

Читайте также

Данная информация также может быть полезной:

Источник

Mikrotik: скрипт переключения на резервный канал интернета

Хочу поделиться своим скриптом для перехода на резервный интернет, когда основной пропадает, и возврату на основной, как только он вновь заработает. Сразу скажу, каналы доступны по-одному, никакого load-balance тут не будет. Оба канала — PPP соединения (в моем случае один проводной, второй — 3G свисток). Скрипт сделан специально как наиболее гибкое средство мониторинга, так как другие варианты, в частности check-gateway, не совсем корректны для меня.

Основной принцип прост: поднятый VPN канал не означает, что интернет через него работает. Я проверяю, пингуя несколько внешних адресов. Можно придумать, когда и пинги не являются показателем работы, но эти случаи я опускаю, в скрипте можно указать любой другой способ проверки, под ситуацию. Другие особенности: резервный канал — мобильная сеть, и он подключается только при отсутствии основного канала, в остальное время интерфейс выключен. При возврате обратно на основной канал корректно проверяется его работоспособность. Методика, отличная от пинга с указанием интерфейса. Ну и route-distance у интерфейсов меняются динамически и всегда не равны, что дает возможность одновременной работы каналов, но трафик направляется только на один из них.

При понимании можно легко переделать скрипт, если провайдеры или один из них, дает статику.

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

Допустим, есть 2 PPP соединения ISP1 — основной, и ISP2 — резервный, оба настроены и работают по-отдельности. Выставляем на них dial-on-demand=no и add-default-route=yes, затем устанавливаем у ISP2 параметр default-route-distance на единицу больше, чем у ISP1. Настраиваем стандартные вещи, как NAT, маркировка пакетов и соединений для ответов по тому же интерфейсу, откуда пришел запрос, маршрутов для помеченных пакетов:

Также предположим, что локальный адрес роутера 192.168.xx.yy, а подсеть 192.168.xx.0/24. Эти данные, как и имена интерфейсов, нужно изменить на свои. Это не вся настройка, но обо всем по-порядку.

Определяем переменные: пишем названия интерфейсов в ifMain и ifRes, локальный адрес роутера в pingSrcAddr (далее будет понятно, зачем он нужен), и 3 внешних адреса, которые будут пинговаться для проверки канала в массив ip.

Разрешим запускаться только одной копии скрипта. Delay на случай запуска при старте RouterOS, даем время подняться соединениям.

Пропустим немного, и перейдем к основной части. Скрипт работает бесконечно, вернее, пока его не остановят или не случится ошибка. В бесконечном цикле он анализирует текущее состояние по переменной state и выполняет необходимые действия. Рассмотрим их.

Состояние 0 — когда работает основной канал. Раз в 15 секунд проверяем последовательно один из трех указанных адресов, если ответа нет — проверяем все 3 адреса. Глухо — инициируем переход на резервный канал. Тут жестко указано, что адресов в массиве — 3. Если это не так, придется подправить.

Состояние 1 — переключение каналов. Здесь важно, какие именно PPP соединения используются. В примере — ISP1 это l2tp-client, а ISP2 — ppp-client. Если другие, нужно их подправить в строках с default-route-distance.

После включения резервного канала ждем 7 секунд. Это достаточное время для меня, за которое 3G соединение поднимается. За это время текущие соединения и новые висят в таймаутах, пока основной VPN еще не разорвался, и минимизируются ответы роутера типа dest unreachable.

Звуковая индикация на любителя, может и ночью сработать. Если не нужно — убираем.

Далее основной канал отключается, его default-route-distance устанавливается на 1 больше, чем у резервного, и он включается обратно. За счет этого имеем возможность ждать возврата основного канала без помех для работы интернета через резерв.

Забегая вперед, при переходе обратно на основной канал и отключении резерва его default-route-distance снова увеличится на 1. С каждым переключением route distance у PPP соединений последовательно увеличивается. Для того, чтобы они не уходили слишком далеко, здесь проверяется текущее значение и происходит сброс на 1 при превышении 10 (цифра не имеет значения, взято для примера, теоретически максимум около 250).

Состояние 2 — ожидание восстановления основного канала. Стоит отметить, что состояние резерва не интересно. Если он не подключился, ничего не поделать, все условия для него созданы, и фактически нас интересует только основной канал.

Здесь ожидается поднятие VPN основного канала, и после этого через него при активном резерве происходят попытки пинга внешних адресов. Сделано это сложновато, но правильно. Если писать ping xx.xx.xx.xx interface=$ifMain, то по словам разработчиков, это может как работать, так и нет. Тут используется пинг с локального адреса роутера. Допускается, что он всегда есть, иначе зачем роутер нужен. Я не использовал внешний адрес основного канала, потому что провайдер его дает динамическим. Разбираемся, как же сказать роутеру посылать такие пинги через основной канал, даже когда его маршрут неактивен (route distance больше, чем у резервного):

Трафик пингов, используемый тут, является нестандартным. Это output трафик, исходящий от самого роутера на внешний адрес. Обычно, в таких случаях за src-address роутер берет адрес интерфейса, по которому уйдет пакет. Указывая локальный адрес роутера как src-address, мы как бы выносим его за тот же NAT, за которым сидит локалка. Далее, такой трафик метится с routing-mark основного канала, и пакеты идут по основному каналу за счет маршрута с меткой.

Второе правило также необходимо. Без него, если вдруг основной канал снова упадет, то пинги, даже помеченные to_ISP1, пойдут по маршруту без метки резервного канала, что приведет к некорректному возврату на основной канал. Так работает RouterOS, если канал не подключен, то маршруты, даже помеченные, отключаются. Чтобы было немного яснее, представим, что state=2, основной канал поднят, но трафик через него не идет. На пинги в таком случае уйдет 6 секунд. Так вот если в это время основной канал отключится, то пинги начнут проходить по резерву. Второе правило это исключает.

Отмечаем, что пинги в локалку с роутера не метятся и работают как обычно.

Состояние 3 — переход на основной канал. После того, как пинги по основному каналу начали проходить, достаточно выключить резервный VPN, и будет использоваться основной. Далее, меняем default-route-distance у резервного на 1 больше, чем у основного, и подаем звуковой сигнал. Обращаем внимание на тип PPP соединений, и меняем по-необходимости.

На этом цикл замыкается и происходит возврат в состояние 0.

Теперь о том, как при запуске скрипта он узнает текущее состояние:

Здесь логика также сложновата на первый взгляд. Анализируются 3 параметра: запущен ли ISP1, запущен ли ISP2, и соотношение default route distance у них. Начальные состояния 1 и 3 являются нестандартными, и говорят о неправильной настройке, но скрипт в таком случае сам все восстанавливает, пусть иногда и путем ненужных переключений.

У меня есть еще одно состояние, которое я исключил, т.к. скорее всего оно вряд ли нужно большинству. Мой ISP1 подключает VPN по имени, не по IP, для разрешения этого имени нужно использовать DNS этого же провайдера, т.к. оно разрешает в локальный адрес. И если не помочь скрипту с разрешением, указывая конкретный DNS, то даже после доступности сети ISP1 он никогда не подключится, т.к. не разрешит доменное имя, а будет продолжать использовать DNS резерва. Вот это доп. состояние:

Вместо DNSip1, DNSip2 и VPNaddress подставляем нужные данные. Все состояния ниже соответственно смещаются на +1.

Вот в принципе и все, разработано и отлажено на 6.26 и RB951G-2HnD. На других версиях — не обещаю, и простите за отсутствие ‘:’ перед командами.

В моей конфигурации в связке с этим скриптом работает еще один, который запускается по-расписанию раз в минуту. Он проверяет, запущен ли этот скрипт, ну и дополнительно отсылает мне по почте IP адрес, когда тот меняется. Вот небольшой пример, но только первой части:

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

Источник

Резервирование канала в Микротик с lte модемом и переключение провайдера

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

Данная статья является частью единого цикла статьей про Mikrotik.

Введение

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

Распределенная сеть филиалов была настроена очень просто, на базе дефолтной конфигурации микротика. Не было никакого объединения в единую сеть, мониторинга и т.д. Все устройства работали сами по себе, просто обеспечивая доступ в интернет на месте. Задача была сделать резервирование основного канала в интернет максимально быстро и просто, чтобы не требовалось какое-то обслуживание или дополнительная настройка.

2-й провайдер через lte usb модем

В качестве резервного провайдера было принято решение использовать lte модемы. Качество связи через них было приемлемое. Тарифные планы доступные, стоимость модемов невысокая. Mikrotik поддерживает большое количество usb модемов, так что не составляет труда подобрать подходящий вариант. Лично я сами модели 4g модемов не видел, так как настраивал все удаленно. Использовались различные устройства и производители. В рамках задачи по настройке резервирования это не принципиально, так как предложенный мной метод работает одинаково успешно практически с любым резервным провайдером. Не важно, будет ли он через usb модем или по проводу.

Самодельный Mikrotik Wan Failover на 2 провайдера

Рассказываю, как будет работать мой импровизированный wan failover в mikrotik на два провайдера. Я использую скрипт, который выполняет следующие действия:

Обязательным условием работы данного механизма переключения каналов являются статические маршруты по умолчанию для каждого провайдера, так как я их переключаю с помощью скрипта. Даже если у вас приходят настройки по dhcp, это не помеха. Надо просто отключить получение дефолтного маршрута и добавить его вручную.

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

Автоматическое переключение на резервный канал

Давайте теперь настроим автоматическое переключение на резервный канал в случае выхода из строя основного. Для начала убедиться, что оба канала настроены и интернет через них работает. В моем случае я буду использовать 2 интерфейса:

Теперь проверим связь через каждый канал:

Если хотите на 100% убедиться, что пинги идут каждый по своему каналу, можете использовать свои сервера, запустив там tcpdump. Я время от времени делал проверки, когда нужно было наверняка знать внешний ip адрес каждого интерфейса. Иногда не было другой возможности, так как я все настраивал удаленно и информации о конкретных настройках интернета у меня не было.

В целом, понять что соединения идут по разным интерфейсам можно и по отклику. На интерфейсе lte1 задержки будут значительно больше.

Дальше убеждаемся, что для каждого провайдера настроен статический дефолтный маршрут. И обязательно каждый из них помечаем комментарием. Можно пометить их как main и reserver, можно как-то еще. Я лично просто имя интерфейсов писал. Далее они будут использоваться в скрипте. Маршрут для резервного канала сразу отключаем.

Скрипт в процессе эксплуатации (пару месяцев тестов на паре десятков филиалов) претерпевал различные изменения, пока не получился подходящий для моей ситуации вариант. Немного поясню некоторые моменты.

Все остальное вроде бы понятно и так, при обычном осмотре скрипта. Пингуем, смотрим, прошли ли пинги. Если нет, переключаемся, если да, то ничего не делаем. Принцип достаточно простой. Его можно встретить в огромном количестве статей в интернете на тему mikrotik failover. Я только добавил сброс соединений и записи в лог файл.

Сохраните этот скрипт и запустите. Очень рекомендую это делать, имея физический доступ к устройству. Если что-то пойдет не так, доступ к микротику потеряете. У меня один раз такое случилось еще в момент подготовки и тестирования этого решения. Потом уже наловчился, все моменты проработал и настраивал все удаленно. Ни одного фейла не было, чтобы на устройстве совсем пропал интернет. Пару раз пришлось звонить на место и через AnyDesk или TeamViewer подключаться локально к микротику.

Страховал себя следующим образом. Добавлял еще один скрипт:

Запускал его и выполнял все потенциально опасные действия. Если все хорошо и связь не пропадала, то прерывал выполнение скрипта на вкладке Jobs.

Если этого не сделать, то через 240 секунд старая конфигурация, сделанная при запуске скрипта, загрузится и устройство ребутнется. Удаленный доступ к нему восстановится.

Вот и все. Переключение на резервного провайдера настроено. Если интернет через основной wan интерфейс перестанет работать, произойдет переключение на lte интерфейс.

Заключение

Еще раз напоминаю, что это мой опыт и мое решение по резервированию канала. Я не претендую на уникальность или best practice. Данный способ мной использовался не раз. Основные удобства следующие:

В данном проекте я все Mikrotik объединил в единую vpn сеть для удобного управления. Настроил мониторинг микротиков, в том числе и переключение провайдеров. А так же сделал сбор логов с них в единый сервер. Все это существенно упростило обслуживание и управление распределенной филиальной структуры.

Источник