Mikrotik настройка резервного провайдера

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

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

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

  1. Настройка балансировки между шлюзами (разные приоритеты для интерфейсов). Данный метод можно использовать, если у нас оба провайдера предоставляют настройки со статическим адресом шлюза. Настройка выполняется без скриптов через конфигурирование нескольких шлюзов с разным весом.
  2. Проверка доступности основного Интернет-канала и переключение на резервный при наличии проблем. Это универсальный метод настройки отказоустойчивости. Для настройки используется утилита Netwatch, которая выполняет скрипт проверки и, при необходимости, смены основного шлюза для доступа к сети Интернет.

Мы рассмотрим оба варианта. Настройки выполним в программе 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).

Переходим в IPFirewall:

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

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

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

Переходим в ToolsNetwatch:

Создаем новое правило. На вкладке 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 → 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 мин

Читайте также:  Роутер для wi fi hotspot

В качестве примера, для обозначения шлюзов я буду использовать эти, выдуманные мной адреса, вам их необходимо заменить на свои.
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. Тут возникает закономерный вопрос, а почему не проверять доступность шлюза провайдера?!
Бывают ситуации, что сеть провайдера работает нормально, а вот дальше, пакеты уже не летят, тогда не произойдет переключения на резервный канал и все будут сидеть без интернета, по этой причине необходимо проверять доступность адресов именно в глобальной сети!

Читайте также:  Где написан пароль от wifi на роутере асус
3 Настраиваем Netwatch

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

Переходим в раздел Tools -> Netwatch и создаем там новый хост для проверки

Где:
Host: 8.8.8.8 — адрес по доступности которого мы будем проверять работоспособность основного канала
interval: 00:03:00 — в моем примере, проверка будет проводиться каждые 3 мин, интервал проверки вы можете задать по своему усмотрению, данная схема у меня работает уже несколько лет и 3 мин, для меня, вполне приемлемое время, чаще не вижу смысла запускать проверки.
Переходим во вкладку UP в ней будет выполняться команда которая будет выполняться в случае доступности IP адреса, мониторинг которого мы выполняем:


Переходим во вкладку 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 → 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, она и будет проверять, с заданной периодичностью, состояние канала.

Переходим в раздел Tools -> Netwatch и создаем там новый хост для проверки

Где:
Host: 8.8.8.8 — адрес по доступности которого мы будем проверять работоспособность основного канала
interval: 00:03:00 — в моем примере, проверка будет проводиться каждые 3 мин, интервал проверки вы можете задать по своему усмотрению, данная схема у меня работает уже несколько лет и 3 мин, для меня, вполне приемлемое время, чаще не вижу смысла запускать проверки.
Переходим во вкладку UP в ней будет выполняться команда которая будет выполняться в случае доступности IP адреса, мониторинг которого мы выполняем:

Читайте также:  Где написан пароль от wifi на роутере асус


Переходим во вкладку 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

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

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

  1. Настройка балансировки между шлюзами (разные приоритеты для интерфейсов). Данный метод можно использовать, если у нас оба провайдера предоставляют настройки со статическим адресом шлюза. Настройка выполняется без скриптов через конфигурирование нескольких шлюзов с разным весом.
  2. Проверка доступности основного Интернет-канала и переключение на резервный при наличии проблем. Это универсальный метод настройки отказоустойчивости. Для настройки используется утилита Netwatch, которая выполняет скрипт проверки и, при необходимости, смены основного шлюза для доступа к сети Интернет.
Читайте также:  Зайти на роутер tp link archer

Мы рассмотрим оба варианта. Настройки выполним в программе 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).

Переходим в IPFirewall:

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

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

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

Переходим в ToolsNetwatch:

Создаем новое правило. На вкладке 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 настройка резервного провайдера

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

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

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

  1. Настройка балансировки между шлюзами (разные приоритеты для интерфейсов). Данный метод можно использовать, если у нас оба провайдера предоставляют настройки со статическим адресом шлюза. Настройка выполняется без скриптов через конфигурирование нескольких шлюзов с разным весом.
  2. Проверка доступности основного Интернет-канала и переключение на резервный при наличии проблем. Это универсальный метод настройки отказоустойчивости. Для настройки используется утилита Netwatch, которая выполняет скрипт проверки и, при необходимости, смены основного шлюза для доступа к сети Интернет.

Мы рассмотрим оба варианта. Настройки выполним в программе 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).

Переходим в IPFirewall:

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

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

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

Переходим в ToolsNetwatch:

Создаем новое правило. На вкладке 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.

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

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

Источник

Записки IT специалиста

Технический блог специалистов ООО»Интерфейс»

  • Главная
  • Резервирование каналов в Mikrotik при помощи рекурсивной маршрутизации

Резервирование каналов в Mikrotik при помощи рекурсивной маршрутизации

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

Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на углубленном курсе по администрированию MikroTik. Автор курса, сертифицированный тренер MikroTik Дмитрий Скоромнов, лично проверяет лабораторные работы и контролирует прогресс каждого своего студента. В три раза больше информации, чем в вендорской программе MTCNA, более 20 часов практики и доступ навсегда.

Читайте также:  Подключить оптику без роутера

Как показывает читательский отклик, маршрутизация для многих администраторов является достаточно сложной темой. Тем не менее если вы внимательно выполните все инструкции данной статьи, то всё будет работать. Однако слепое выполнение инструкций не добавляет понимания происходящих процессов и, если что-то пойдет не так вы окажетесь в весьма затруднительном положении, поэтому перед тем, как перейти к практике мы выполним небольшой теоретический ликбез.

Теория

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

Что такое маршрутизация? Это процесс определения пути следования данных в сетях связи. Его можно сравнить с прокладкой маршрута с использованием навигатора, вы задаете начальную и конечную точку и получаете несколько вариантов проезда с указанием всех промежуточных точек. В некоторых точках маршрут может разделяться на несколько вариантов, из которых вы можете выбрать наиболее оптимальный, исходя из оценки текущей дорожной обстановки.

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

Прежде всего разберемся как заполняется таблица маршрутизации. Это может происходить несколькими способами:

  • Непосредственно присоединенные сети — в данном случае они имеют флаг С — connect — это сети к которым физически подключен маршрутизатор, они добавляются при подключении интерфейса и удаляются при его отключении.
  • Статические маршруты — добавляются системным администратором, либо динамически, при подключении коммутируемого соединения или получения сетевых параметров по DHCP. В этом случае к флагу S -static, добавляется флаг D — dynamic.
  • Динамические маршруты — маршруты добавляемые при помощи протоколов динамической маршрутизации, таких как OSPF, RIP и т.д. Не следует путать их с динамически добавляемыми статическими маршрутами и маршрутами непосредственно присоединенных сетей. Флаг D — dynamic в Mikroitk обозначает только то, что маршрут добавлен автоматически, без участия пользователя. А динамические маршруты обозначаются флагами r — rip, b — bgp, o — ospf, m — mme, однако их рассмотрение выходит за рамки данной статьи.

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

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

Коротко напомним о том, что такое «нулевой» маршрут или шлюз по умолчанию, он используется в том случае, если в таблице для узла назначения не было найдено ни одного подходящего маршрута. Проще говоря, если роутер не знает куда отправить данные, он отправляет их шлюзу по умолчанию. Особой записи для узла 8.8.8.8 в нашей таблице нет, поэтому будет использоваться «нулевой» маршрут.

Хорошо, адрес шлюза мы определили, но это не решило основной задачи — куда отправить данные. Почему? Вернемся к нашей аналогии, вы решили поехать из Белгорода в Москву, карта показывает, что сначала вам нужно приехать в Курск. Отлично, но как именно в него попасть? Навигатор услужливо подскажет нам, что требуется ехать на север по федеральной трассе М2 «Крым».

В нашем случае основной задачей маршрутизатора будет определить интерфейс выхода, т.е. куда именно физически нужно направить данные, чтобы они добрались до требуемого места назначения. Поэтому роутер снова начинает поиск в таблице маршрутизации чтобы определить каким образом следует добраться до искомого адреса шлюза 192.168.3.1, согласно таблице, будет найден маршрут к сети 192.168.3.0/24 через интерфейс ether5. Так как интерфейс выхода определен, то поиск прекращается и роутер формирует необходимый тип данных для передачи на канальном уровне.

Здесь тоже следует дать краткие пояснения, если интерфейс выхода является сетью Ethernet, то роутер выполнит ARP-запрос для адреса шлюза и сформирует Ethernet-кадр, а если это туннельный интерфейс точка-точка (VPN, PPPoE), то выполнит инкапсуляцию IP-пакета и отправит его на другую сторону туннеля.

И здесь мы приходим к следующим соображениям: таблица маршрутизации может быть большая и поиск по ней может быть затратным, в тоже время шлюз будет располагаться в одной из непосредственно присоединенных сетей, возможно следует ограничить поиск только по ним?

Читайте также:  Роутер вай фай для ноутбука самсунг

Для решения этой проблемы в Linux, а следовательно, и в RouterOS, введены понятия области маршрута — Scope, и области поиска — Target-scope. Теперь вернемся к нашей таблице маршрутизации, «нулевой» маршрут имеет область — 30 и область поиска — 10. Следовательно дальнейший поиск будет вестись только среди маршрутов с областью 10.

По умолчанию данные опции имеют следующее значение:

  • Непосредственно присоединенные сети: Scope — 10, Target Scope не имеет смысла, так как данный маршрут указывает на интерфейс выхода
  • Динамические маршруты — OSPF, RIP, MME: Scope — 20, Target Scope — 10
  • Статические маршруты: Scope — 30, Target Scope — 10

Таким образом область поиска существенно снижается и маршрут к шлюзу ищется только среди непосредственно присоединенных сетей. Теперь самое время перейти к рекурсивной маршрутизации.

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

Давайте рассмотрим следующую таблицу маршрутизации:

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

Теперь разберемся как это работает. Когда мы хотим связаться с каким-либо узлом в сети интернет маршрутизатор выполнит поиск по таблице маршрутизации и, если не указано иных маршрутов, выберет «нулевой» в котором указан шлюзом 1.1.1.1, так как найден адрес, то поиск будет продолжен, чтобы определить интерфейс выхода. Так как указанный нами шлюз не находится ни в одной из непосредственно присоединенных сетей, то сделать это не удастся и такой маршрут работать не будет.

Поэтому мы «подскажем» маршрутизатору как достичь указанного нами узла и добавим маршрут к 1.1.1.1 через сеть провайдера, а чтобы он участвовал в поиске его область должна быть меньше или равна области поиска «нулевого» маршрута, т.е. 10. Это очень важный момент, если вы неправильно укажете область второго маршрута — рекурсивная маршрутизация работать не будет.

Итак, роутер находит адрес первого шлюза — 1.1.1.1 и начинает искать маршрут к нему с среди маршрутов с областью 10, там он находит второй маршрут и получает из него новое значение шлюза — 192.168.3.1 — который является шлюзом нашего провайдера, затем еще раз выполняет поиск и находит связанный с ним интерфейс выхода — ether5. После чего пакет отправляется провайдеру, а удаленный узел 1.1.1.1 используется нами только как способ проверки наличия интернета через данный канал. Это и есть рекурсивная маршрутизация.

Практика

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

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

У нас есть два нулевых маршрута с разными административными дистанциями (1 для основного провайдера, 2 для резервного) и три маршрута для непосредственно присоединенных сетей, где 192.168.3.0/24 — сеть основного провайдера, а 192.168.16.0/24 — резервного.

Перед тем, как переходить к дальнейшим настройкам нам нужно выяснить и запомнить адреса шлюзов провайдеров, для этого можно заглянуть на закладку Nexthops, для коммутируемых подключений (VPN, PPPoE) следует проверить свойства соответствующего соединения.

Внимание! Дальнейшие действия следует производить имея физический доступ к устройству!

Прежде всего отключим автоматическое создание нулевых маршрутов для сетей провайдеров, для этого следует снять флаг Add Default Route в свойствах подключения, либо установить одноименную опцию в значение — no.

После этого доступ в интернет по обоим каналам пропадет. Имейте это ввиду при планировании работ.

Теперь начнем добавлять собственные маршруты, но сначала выберем два высокодоступных узла для первого и второго провайдера. Допустим это будут 1.1.1.1 (Cloudflare DNS) и 9.9.9.9 (Quad9 DNS). Каких-либо ограничений по их выбору нет, это могут быть как ваши собственные, так и публичные узлы, единственное условие — они не должны использоваться в вашей сети, потому как при отказе одного из провайдеров окажутся недоступными.

Читайте также:  Роутер кнопка отключения wi fi

В первую очередь создадим маршруты к этим узлам. Для этого снова перейдем в IP — Routes и создадим новый маршрут:

Где Dst. Address — 1.1.1.1 — узел для проверки первого провайдера, Gateway — 192.168.3.1 — шлюз первого провайдера, Distance — 1, Scope — 10. Обратите внимание на значение области (Scope), если вы оставите там значение по умолчанию — 30, то рекурсивная маршрутизация работать не будет! Затем добавим второй аналогичный маршрут, но уже к узлу 9.9.9.9 через шлюз второго провайдера.

Эти же действия через терминал:

Затем добавим два рекурсивных «нулевых» маршрута. Для первого провайдера:

Dst. Address оставляем по умолчанию — 0.0.0.0/0, Gateway — 1.1.1.1 — высокодоступный узел для первого провайдера, Check Gateway — ping — указываем проверку доступности шлюза, Distance — 1.

Для второго провайдера:

Dst. Address0.0.0.0/0, Gateway — 9.9.9.9, Check Gateway — ping , Distance — 2. Обратите внимание на значение административной дистанции второго маршрута, она должна быть больше, чем у основного провайдера, в нашем случае — 2.

То же самое быстро в терминале:

Теперь таблица маршрутизации будет выглядеть следующим образом:

Наши маршруты добавились как рекурсивные и активным является маршрут через основного провайдера. Теперь имитируем аварию у первого провайдера, буквально через 10-20 секунд таблица маршрутизации изменится и рабочим станет маршрут через резервный канал:

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

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

Рекурсивная маршрутизация и PPPoE

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

Чтобы этого избежать используем одну небольшую хитрость. Вспомним, о чем мы говорили в теоретической части. При использовании PPPoE соединения адрес шлюза провайдера роутеру как таковой не нужен. Он используется только для определения интерфейса выхода. Для работы протокола PPP, который лежит в основе PPPoE, IP-адреса не требуются. Это дает возможность самостоятельно присвоить произвольный адрес для удаленного конца туннеля и использовать его в качестве шлюза.

Для этого перейдем в PPP — Profiles и создадим новый профиль, укажем для него понятное имя и зададим параметр — Remote Address, адрес можно указать любой, единственное условие — он не должен пересекаться с вашими внутренними сетями, в нашем случае это 10.253.252.251. Также установите переключатель Change TCP MSS в положение yes.

В терминале это можно сделать так:

После чего назначим этот профиль вашему PPPoE соединению:

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

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

Рекурсивная маршрутизация и DHCP

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

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

Затем перейдем в настройки DHCP-клиента — IP — DHCP Client — и на закладке Advanced внесем в соответствующее поле короткий скрипт:

Теперь при каждом новом получении адреса по DHCP скрипт будет находить наш маршрут и изменять в нем значение шлюза на реально полученный адрес. Попробуем смоделировать данную ситуацию и выдадим нашему роутеру адрес первого провайдера из другого диапазона. Как видим, все автоматически изменилось согласно вновь полученных настроек:

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

Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на углубленном курсе по администрированию MikroTik. Автор курса, сертифицированный тренер MikroTik Дмитрий Скоромнов, лично проверяет лабораторные работы и контролирует прогресс каждого своего студента. В три раза больше информации, чем в вендорской программе MTCNA, более 20 часов практики и доступ навсегда.

Дополнительные материалы:

Mikrotik

The Dude

Помогла статья? Поддержи автора и новые статьи будут выходить чаще:

Или подпишись на наш Телеграм-канал:

Источник

Adblock
detector