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

Резервирование Интернет-канала на 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.

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

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

Источник

Универсальный скрипт переключения 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 2 провайдера с автоматическим переключением на резервный канал( MikroTik Failover 2 ISP )

Всех приветствую, решил написать статью, описывающую способ реализации отказоустойчивости на оборудовании Mikrotik.
В одной маленькой конторе, где я подрабатываю, из-за регулярных проблем у провайдера, задумались о подключении второго интернет канала, основного провайдера (не стабильного в последнее время) отключать не хотят, за много лет его использования тариф для фирмы не изменимся, да и скорость отличная, за те деньги + есть внешний IP и сотрудники офиса могут подключаться по VPN к офису, руководство о смене провайдера ничего слышать не хочет, это почти самый центр Москвы и с провайдерами там не очень весело.

Идея была в том что офис будет протянут новый канал и необходимо было реализовать следующую схему,
первый провайдер назовем его ISP1 (Глючный) и ISP2 (не имеет внешнего адреса только серый 10.57.ХХ.ХХ), опишу схему подробнее
ISP1 предоставляет сеть с белым IP который прилетает по DHCP, скорость 100 Мбит/с
ISP2 предоставляет сеть с серым IP адресом находящимся за NAT скорость 30 Мбит/с
Провайдер ISP2 нужен чтобы пересидеть, время недоступности основного канала, а офис мог функционировать с небольшими ограничениями.
Я пробежался по готовым статьям и не нашел того решения что меня устраивало на 100%, вот я и решил поделиться
своей наработкой с общественностью.
Я опишу свой способ, который без проблем работает как у 2х провайдеров которые выдают IP адреса по DHCP, так и у 2х провайдеров которые раздают статические адреса, как вы просчитали выше, у меня 2 сети- одна сеть конфигурируируется по DHCP, а вторая — статические адреса.
Данная схема, отработала уже более 2х лет, статистика сипользования
переключений в неделю — в среднем 3
среднее время использование резервного канала 12 мин

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

В качестве подготовки

Я не буду останавливаться на настройке маршрутизатора, пример настройки можно посмотреть в статье: Настройка MikroTik RouterBoard RB951G-2HnD, а перейдем сразу к делу.

Для начала переходим в меню настройки сетевых интерфейсов, интерфейс ether1 подключенный к провайдеру ISP1, мы переименуем в ether1-ISP1, чтобы было понятно за что он отвечает

Сетевой интерфейс ether2 подключен у нас к провайдеру ISP2, назовем его ether2-ISP2
Поступим с ним аналогичным образом.

Кратко опишу процесс работы по проверке работы канала и алгоритма переключения на резервный канал и обратно.
Выбираем IP адрес в интернете, с высокой степенью доступности, в качестве примера, буду использовать IP 8.8.8.8
Создаем правило фаерволла, которое разрешает прохождение пакетов только через основной канал с интерфейсом подключенным в ISP 1, в случае переключения на резервный канал, пакеты будут пытаться отправляться через новый маршрут по умолчанию, вот тут вступает правило фаерволла, которое прямо запрещает прохождение пакетов от маршрутизатора через интерфейс подключенный к ISP 2.

1 Настраиваем Firewall

Переходим в IP->Firewall и создаем правило, запрещающее отправку пакетов через ISP2

Где
Chain: output — указываем правило, которое применяется для исходящих пакетов от маршрутизатора.
Dest address: 8.8.8.8 — IP адрес, пакеты адресованные которому, будут подпадать под это правило.
ether2-ISP2 — Интерфейс, для которого применяется это правило.

Теперь нам надо перейти в во кладку Action, тут мы указываем что делать с пакетом, в нашей ситуации мы его выбрасываем
Action: Drop

Жмем OK и сохраняем изменения.

2 Настраиваем маршрутизацию

Переходим в IP-> Routers и видим примерно такую таблицу маршрутизации, IP основного канала ISP1 я закрасил, серыйе адреса второго провайдера я оставил.

Из скриншота мы видим что маршрутом по умолчанию 0.0.0.0/0 у нас является интерфейс подключенный к провайдеру ISP1, вот этим параметром мы и будем управлять, перенося его с одного интерфейса на другой.
Нам необходимо создать маршрут к IP 8.8.8.8 пакеты к которому, от маршрутизатора, будут идти только через ISP1

Жмем + и добавляем новый маршрут как на скришшоте

Для чего это все нужно?
Система будет проверять доступность этого IP адреса, через провайдера ISP1, если этот адрес не доступен, выполняется переключение на резервный канал, при этом система будут продолжать, с определенной периодичностью, пытаться достучаться до адреса 8.8.8.8, через провайдера ISP1. Тут возникает закономерный вопрос, а почему не проверять доступность шлюза провайдера?!
Бывают ситуации, что сеть провайдера работает нормально, а вот дальше, пакеты уже не летят, тогда не произойдет переключения на резервный канал и все будут сидеть без интернета, по этой причине необходимо проверять доступность адресов именно в глобальной сети!

3 Настраиваем Netwatch

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

Переходим во вкладку DOWN
Эта команда будет выполнена в случае недоступности IP адреса

Жмем OK, в списке у нас появится правило:

Где будет указывать интервал проверки, который мы задали, 3 мин, таймаут проверки 1000 мс или 1 сек и состояние UP, также дата и время последнего изменения состояния.

4 Тестирование

Это важный этап проверки работоспособности данной схемы!
Нам необходимо проверить работу системы переключения на резервный канал и возвращение на основной.
Нужно зайти в настройки сетевых интерфейсов Interfaces и выключить сетевой интерфейс ether1-ISP1 подключенный к ISP1
Открыв окно, netwatch, где можно наблюдать, как система запустит проверку и обнаружит что канал провайдера ISP1 не доступен, статус изменится на down и шлюзом по умолчанию, станет шлюз провайдера ISP2 888.888.888.888
На перестройку таблицы маршрутизации уходит примерно 30 сек, после этого интернет опять начинает работать. Можно зайти например на сайт 2ip.ru и увидеть что у вас IP адрес резервного провайдера.
Чтобы все вернуть обратно, просто включаем интерфейс ether1-ISP1, через 3 мин система обнаружит что доступ к IP 8.8.8.8 восстановлен и можно переключать на основной канал, сделав шлюзом, по умолчанию, шлюз провайдера ISP1 777.777.777.777
Снова заходим на 2ip.ru и видим что теперь у нас IP выданный провайдером ISP1

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

Источник

Mikrotik, 3 провайдера, переключение и разделение трафика

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

Собственно на этом всё. Наш MikroTik готов для дальнейшей тонкой настройке.

На следующем этапе мы настроем отзывчивость MikroTik со всех провайдеров.

Для начала настроем маскарад для все трёх интерфейсов.

Теперь наверное самое интересное Mangle

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

Картинка для закрепления. И понимания.

Отлично теперь мы можем заходить на MikroTik через любого провайдера.

Настало время каждого офиса займёмся трафиком с четвёртого порта. Но прежде предусмотрительно подготовим один маленький но тонкий нюанс, так как мы будет использовать prerouting то трафик перед «Попаданием» в таблицу маршрутизации, необходимо отфильтровать.
Необходимо создать адрес листы с сетями которые не должны маркироватся.
Я обычно называю его LocalNet и в этот раз поступим также.

И так мы создали листы локальных сетей, теперь приступим к маршрутизации трафика.

Перед тем как пакет покинет маршрутизатор: если адрес отправителя состоит в сети 192.168.101.0/24 и адрес назначения не числится в листах, то маркируем маршрут именем office 1
Совсем просто, это весь трафик который принадлежит офису 1 и не идёт до наших других локальных подсетей.

Далее нам необходимо создать три маршрута для трафика office 1

Немного разъяснения check-gateway это процедура автоматической проверки доступности шлюза, так как у меня это соединение L2 то в моём случае arp лучше чем ping, если у вас L3 (pptp etc) то ставите ping.
Также необходимо обратить внимание distance как раз по ней маршрутизатор определяет при одинаковом адресе назначения какой приоритет маршрутов.

Ну а теперь финальная часть нашего «марлезонского балета».
Так как cheсk-gateway проверяет доступность только шлюза, нас это категорически не устраивает.
Наша задача определить живой ли канал в интернет через каждого провайдера и в зависимости от живности включать и отключать маршруты.
В данном случае у нас две сети
office1 ISP1->ISP2->ISP3
office2 ISP2->ISP1-ISP3
Как видно что конченым результатом у нас в любом случае будет ISP3, естественно канал ISP3 нам нет необходимости проверять.
И так прежде нам необходимо настроить дату и время на MikroTik. Я надеюсь вы сделаете это без моей помощи.

Отступление: в интернете много различных скриптов, но большинство из них выполняют скрипт в заданный промежуток времени которые меняет значения дистанции в маршрутах. Нас такой вариант не устраивает так как в MikroTik стоит NAND память и у неё есть свой предел записи. Мы будем его экономить. Кончено же можно было отредактировать скрипт и делать проверку, но это не наш метод. )

Будем использовать функционал MikroTik. NetWatch
Создадим два правила.

Netwacth работает как тригер.
Если состояние изменилось то выполняется скрипт указанный в текущем значении тригера.
В нашем случае если пинг до 8.8.8.8 не пройдёт то, смениться статус на down и исполниться скрипт ISP1-DOWN, как только значение станет up, то исполниться скрипт ISP1-UP

Напишем скрипты для наших событий.
ISP1-UP

В моё случае я ищу так, кто то определяет по комментариям к маршрутам.
Но я пока встречал только один раз где реально использовалась дистанция больше 10.
ISP1-DOWN

Для того чтобы весь наш netwatch полноценно работал нам необходимо добавить два маршрута, который будут отправлять трафик на 8.8.8.8 через ISP1, а трафик до 8.8.4.4 через ISP2

Источник

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. Также, за счет расписания, при непредвиденных перезагрузках роутера скрипт будет автоматически запущен снова.

Источник