Микротик два провайдера резервирование

Introduction

In this article, we will look at another advanced method of failover using recursive routing and scopes from the routing section. Recursive routing occurs when a route (either static or dynamically learned) has a next-hop that is not directly connected to the local router. It is necessary to restrict a set of routes that can be used to look up immediate next-hops. Nexthop values of RIP or OSPF routes, for example, are supposed to be directly reachable and should be looked up only using connected routes. This is achieved using a scope and target-scope properties.

Введение

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

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

Продолжаю цикл статей про функциональные и очень доступные роутеры из Латвии. Речь пойдет о том, как получить доступ к Mikrotik через несколько одновременно настроенных провайдеров или внешних IP. Настройка не сложная, плюс в интернете есть информация на эту тему. Я дополню ее тем, что поделюсь своим опытом применения этого функционала.

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

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

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

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

Setup Overview

Before a detailed example overview, in a setup where we have private IP addresses behind the public IP, we should configure source NAT:

Let`s start with marking traffic by configuring routing tables and firewall mangle rules, so we will have everything preconfigured when we go to the routing section:

We will split the routing configuration into three parts. First, we will configure Host1 and Host2 as destination addresses in the routing section:

Now configure routes that will be resolved recursively, so they will only be active when they are reachable with ping:

Configure similar recursive routes for the second gateway:

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

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

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

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

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

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

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

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

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

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

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

Переходим в IP — Firewall:

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

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

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

Переходим в Tools — Netwatch:

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

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

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

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

Маркировка соединений с двух WAN

Первым делом маркируем все соединения. Для этого идем в раздел IP -> Firewall -> Mangle и добавляем новое правило маркировки для пакетов из wan-1.

Следующим этапом назначаем метку маршрутизации для этих соединений. Делается этот тут же в новом правиле.

То же самое делаете для второго соединения, заменяя ip ардес, имя интерфейса и назначая другую метку. Должны получиться следующие 4 правила.

/ip firewall mangle
add action=mark-connection chain=input dst-address=109.68.184.112 in-interface=ether1-wan1 new-connection-mark=wan1-in passthrough=no
add action=mark-routing chain=output connection-mark=wan1-in new-routing-mark=wan1 passthrough=no
add action=mark-connection chain=input dst-address=77.31.15.221 in-interface=ether2-wan2 new-connection-mark=wan2-in passthrough=no
add action=mark-routing chain=output connection-mark=wan2-in new-routing-mark=wan2 passthrough=no

С маркировкой закончили.

Adding Multiple Hosts

In the case where Host1 and Host2 fail, the corresponding link is considered failed too. In this section, we will use two additional hosts for redundancy. In our example, we will use OpenDNS servers Host1B (208.67.222.222) and Host2B (208.67.220.220):

Then, let’s create destinations for «virtual» hops to use in further routes. We will use 10.10.10.1 and 10.20.20.2 as an example, but you can use different ones, be sure they do not override other configured IP addresses in your setup:

Do not forget to add routes with routing marks:

Выпускаем всех остальных и балансируем нагрузку.

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

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

Наверное вы уже догадались, что весь оставшийся трафик от ваших локальных хостов будет попадать в таблицу main.

Давайте сделаем маршрут ECMP с тем учётом, что шлюз 88.88.88.1 это 10Mbps, а 44.44.44.1 5Mbps.

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

Хотя это немного и не правильно, дело в том, что у процесса ECMP есть отдельная таблица кеша, и чтобы каждый раз не выбирать маршрут, маршрутизатор для связки src-address:port dst-address:port создаёт хеш и выберет для данного хеша уже шлюз по схеме Round Robin, тем самым для одного соединения будет выбираться один и тот же шлюз.

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

Проблема в том, что ограничение в 10 минут, это ограничение жёсткое и нам его не убрать и не изменить.

Будем решать штатными средствами RouterOS.

Давайте подумаем вместе, что нам известно о пакете, который попал под ECMP маршрут? Конечно, данный пакет находится в таблице main.

Идея данного способа заключается в следующем. Дать маршрутизатору выбрать маршрут с помощью ECMP, промаркировать такие соединения и все последующие пакеты в этом соединение пускать мимо ECMP, тем самым мы убираем проблему 10 минут.

chain=postrouting — Работаем в цепочке по факту того, что уже выбрал ECMP, можно использовать и цепочку forward, но тогда не попадёт трафик который был сгенерирован самим маршрутизатором.

routing-table=main — Маршрут ECMP находиться в main таблице.

out-interface=ether1 — ECMP выбрал шлюз, который лежит через первый интерфейс

connection-state=new — Мы маркируем соединение, нет смысла работать со всеми пакетами.

action=mark-connection new-connection-mark=ECMP/ether1 — маркируем соединение.

Ещё раз, мы дали возможность ECMP выбрать направление и мы уже по факту промаркировали соединения, основываясь на выборе интерфейса.

А теперь все последующие пакеты в соединениях с такой маркировкой должны быть отправлены в тот же интерфейс, но не в таблицу main, так как там работает ECMP, нам это уже не к чему.

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

Осталось настроить NAT

За сим всё, спасибо за внимание.

Удалённая настройка маршрутизатора, к дальней дороге.

Маркировка соединений от провайдера

Вы наверное помните, а если и нет, то стоит напомнить, что любой пакет, который приходит на маршрутизатор и попадает в цепочку prerouting и не важно куда он дальше попадёт forward или Input.

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

Сначала настроим, а далее разберём что сделали.

Разберём только первое правило, все остальные по аналогии.

Если пакет приходит с интерфейса ether1 и адрес назначения лежит в сети 88.88.88.0/29, и такой пакет создал соединение, то маркируем соединение маркой Next-Hop/88.88.88.1.

88.88.88.0/29 — почему сеть, а не IP? Если вы будете делать правила для каждого IP адреса, количество правил будет расти, а смысл будет тот же самый.

connection-state=new — нет смысла пытаться маркировать соединения, которые уже установлены. Как вы помните new — это пакет, который создал соединение, т.е он только один, а в случае со всеми пакетами routeros будет каждый раз пытаться маркировать соединение. Которое уже и так может иметь маркировку.

Next-Hop/99.99.99.1 — почему именно так? Как вы помните, наша главная задача отправить трафик через тот же самый шлюз, через который трафик пришёл, а мы таким названием себе явно напоминаем, какой шлюз будет использоваться для выхода в сторону провайдера. Мы бы могли использовать что-нибудь вроде ISP1, но так как у нас первый провайдер даёт два префикса в одном и том же интерфейсе, мы должны трафик, который приходит на разные префиксы каким нибудь образом разделить.

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

С этого момента весть трафик, который придёт со стороны провайдера, будет промаркирован, а далее бы будем оперировать данной маркировкой.

Несколько провайдеров на MikroTik v6

Я настоятельно рекомендую сначала прочитать, далее вникнуть, потом понять и только после того, как у вас вся картина будет нарисована в голове, приступить к настройке.

Настройка нескольких провайдеров в RouterOS.

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

Если оператор нам выдал ip адрес 1.1.1.2, то мы должны обеспечить выход через этого провайдера именно с таким ip адресом, а не с каким либо другим.

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

Для начала определим вводные данные.

• Интерфейс ether1
• IP:88.88.88.2/29 Gateway: 88.88.88.1, а также данный провайдер отдаёт ещё один префикс на том же интерфейсе IP:99.99.99.2/24 Gateway: 99.99.99.1
• DSN сервера 2.2.2.2 и 3.3.3.2

• Интерфейс ether2
• IP:44.44.44.2/29 Gateway: 44.44.44.1
• DSN сервера 7.7.7.2 и 6.6.6.2

• Ether3 — IP:172.20.17.1/24 — локальная сеть компьютеров
• Ether4 — IP:172.20.18.1/24 — локальная сеть для серверов

Проверка наличия Интернета

Способ 1 — Netwatch

Каждые 60 секунд отрабатывает Netwatch, который проверяет отклик серверов проверки. Если нет отклика, скрипт находит маршрут по комментарию и включает опцию Check Gateway, которая через 2 проверки с интервалом 10 секунд считает канал «упавшим» и отключает маршрут.

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

Используется в большинстве корпоративных установок.

Онлайн курcы по Mikrotik

Если у вас есть желание научиться работать с роутерами микротик и стать специалистом в этой области, рекомендую пройти курcы по программе, основанной на информации из официального курcа MikroTik Certified Network Associate. Помимо официальной программы, в курcах будут лабораторные работы, в которых вы на практике сможете проверить и закрепить полученные знания. Все подробности на сайте Курcы по ИТ.

Стоимость обучения весьма демократична, хорошая возможность получить новые знания в актуальной на сегодняшний день предметной области. Особенности курcов:

• Знания, ориентированные на практику;
• Реальные ситуации и задачи;
• Лучшее из международных программ.

Помогла статья? Подписывайся на telegram канал автора

Анонсы всех статей, плюс много другой полезной и интересной информации, которая не попадает на сайт.

Выход с маршрутизатора

Хоть и по сути мы сделали уже много, но у нас ещё несколько кейсов впереди. Теперь мы должны сделать таким образом, чтобы пакеты, которые генерирует сам маршрутизатор (не в ответ), уходили через нужного провайдера и шлюза.

Когда вы “пингуете” с маршрутизатора, строите PPP* или IP туннели с самого маршрутизатора или dns запросы отправляете с самого маршрутизатора. Разница с прошлым кейсом в том, что мы отправляли пакет по уже установленному соединению, а здесь пакет улетает с маршрутизатора и соединение не имеет маркировки.

Здесь будет значительно проще.

Весь трафик, уходящий с маршрутизатора, и имеющий IP адрес попадающий под префикс, будет отправлен в именованную таблицу маршрутизации.

Всё, теперь вы можете строить туннели и у вас всё будет работать, но только в том случае если явно указан IP адрес, например в Ipsec или gre, ip туннели и прочее, там где явно можно указать Source адрес. А что делать с сервисами, где нельзя указать явно IP адрес источника? Ответ на этот вопрос кроется в таблице маршрутизации. Параметр pref-src отвечает за то, какой IP адрес будет выбран если он явно не задан.

Если вам необходимо установить соединение из локальной сети с адресом который назначен на интерфейсе провайдера, допустим при использовании Hairpin-NAT, в правилах вы должны исключить BOGON сети из адресов назначения.

В нашем примере если только для одного IP адреса.

Ещё раз для понимания, у нас есть два варианта развитая сюжета, если IP адрес источника явно указан и тогда нам нечего не грозит и всё замечательно работает. Второй вариант, когда IP адрес явно не задан, например вы подминаете l2tp-client у нас нет возможности указать source адрес, но ведь адрес назначения есть в любом случае. Тогда маршрутизатор поступает следующим образом, он находит маршрут в таблице маршрутизации main, смотрит какой указан pref-src и использует данный ip адрес, как адрес источника.

Вы помните что мы создавали фиктивный маршрут.

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

Выбор IP адреса зависит только от вас, выбирайте тот адрес, который считаете менее загруженным.

На этом этапе всё, теперь вы можете строить различные туннели и устанавливать соединения не только указывая явно source адрес.

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

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

1. Пингует 2 разных ip адреса в интернете, каждый через отдельный канал интернета. Для этого создаются статические маршруты.
2. В случае, если пинг через основной канал не проходит, а через резервный идет, выполняется автоматическое переключение на резервный канал путем смены дефолтного маршрута.
3. Далее снова выполняются эти же проверки. Как только пинги через основной канал проходят, выполняется переключение на него.
4. Я одновременно с переключением канала обрываю все tcp и udp подключения, а так же пишу информацию в лог. Это не обязательно делать, но конкретно мне нужно было. Соединения обрывались, чтобы побыстрее переключились sip телефоны и vpn соединение на микротике. А в лог я пишу информацию, так как она уходит на отдельный сервер где анализируется в том числе системой мониторинга.

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

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

2WAN или MultiWAN с резервом

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

Балансировка каналов

Настроим одновременную работу двух провайдеров, переходим снова в меню IP-routes и добавляем следующий маршрут по умолчанию.

В этом примере нагрузка на каналы будет распределяться 50/50, если же нам нужно сделать неравномерное распределение нагрузки, допустим в 1-го отправлять 75 % трафика, а на второго 25%, то это выглядит так.

Т.е три соединения будут идти через шлюз 1.1.1.1 и одно соединение через шлюз 2.2.2.2

Обучающий курс по настройке MikroTik

Нужно разобраться с MikroTik, но не определились с чего начать? В курсе «Настройка оборудования MikroTik» все по порядку. Подойдет и для начала работы с этим оборудованием, и для того, чтобы систематизировать знания. Это видеокурс из 162 уроков и 45 лабораторных работ, построен на официальной программе MTCNA. Проходить можно, когда удобно и пересматривать по необходимости – материалы курса выдаются бессрочно. Также есть 30 дней на личные консультации с автором. На пробу выдают 25 уроков бесплатно, заказать их можно на странице курса.

Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.

Маркировка входящего трафика

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

Доступ за НАТ

172.20.18.2 — это exchange сервер, мы должны обеспечить доступность 25,80,443 портов через каждого провайдера.

НАТ делаем, как обычно, без всяких излишеств.

А теперь давайте вспомним то, что мы делали самым первым правилом в mangle мы промаркировали все соединения, которые приходят через всех провайдеров! Данная маркировка нам опять поможет.

Нам необходимо отфильтровать весь трафик, который идёт из локальной сети и отправить в том направлении к маркировке которого соединение имеет отношение.

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

1. Когда пакет придёт на IP адрес 88.88.88.2 мы промаркировали соединение, которому принадлежит пакет.
2. Далее в NAT мы изменили адрес назначения, и маршрутизатор отправит его до сервера.
3. Естественно сервер в ответ отправит пакет, как минимум syn,ack, так как данный пакет принадлежит уже существующему соединению, мы по имени соединению отправим данный пакет в именованную таблицу маршрутизации.

НАТ уже сделали, дело осталось за малым- найти трафик, который приходит от сервера.

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

Наверное многие спросят, а почему указывается не интерфейс ether1, а не взять и указать явно локальный интерфейс, например ether4.

Мы с вами делаем универсальную конфигурацию, если явно указать какой-либо другой интерфейс, значит в случае если у нас будет ещё один NAT, который пойдёт в другой порт, нам необходимо будет добавлять ещё одно аналогичное правило, но уже с другим интерфейсом. А ведь мы можем даже завернуть трафик с помощью NAT вообще на внешние сервера например 1.1.1.1, и что тогда? Единственный интерфейс откуда в цепочке prerouting мы не должны ожидать данный трафик, это трафик с самого провайдера и причём именно с того, с которого он пришёл.

Всё работает, теперь вы можете подключаться в своему серверу по любому IP адресу. Создайте DNS A запись RR и укажите все три внешних IP адреса и всегда ссылайтесь на данную запись.

А также source NAT?

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

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

Обратное преобразования NAT произойдёт автоматически, давайте взглянем на запись в conntrack.

Давайте уберём из вывода лишнее, чтобы оно нам не мешало.

И так когда пакет попал на маршрутизатор и соединение было “только-только” создано, соединение имело такой вид

После того как произошла процедура dst NAT, маршрутизатор добавил флаги и самое главное на какой адрес изменяется IP адрес во всех пакетах в данном соединении.

Когда пакет уходил с маршрутизатора в цепочки postrouting работает процедура src NAT, но у нас нет правил src NAT, оставили значение исходное.

Обратите внимание, что все данные этапы были сделаны на момент прохождения только первого пакета.

Теперь, если пакет приходит на маршрутизатор и у него в заголовках src-address=5.19.245.3:57839 dst-address=88.88.88.2:80 dst-address изменится на 172.20.18.2:80.

Если пакет приходит на маршрутизатор с адресами в заголовках src-address=172.20.18.2:80 dst-address=5.19.245.3:57839 src адрес изменится на 88.88.88.2:80.

Тем самым src NAT на данном этапе работает автоматически на основании правил dst-NAT.

Онлайн курcы по Mikrotik

Если у вас есть желание научиться работать с роутерами микротик и стать специалистом в этой области, рекомендую пройти курcы по программе, основанной на информации из официального курcа MikroTik Certified Network Associate. Помимо официальной программы, в курcах будут лабораторные работы, в которых вы на практике сможете проверить и закрепить полученные знания. Все подробности на сайте Курcы по ИТ.

Стоимость обучения весьма демократична, хорошая возможность получить новые знания в актуальной на сегодняшний день предметной области. Особенности курcов:

• Знания, ориентированные на практику;
• Реальные ситуации и задачи;
• Лучшее из международных программ.

Помогла статья? Подписывайся на telegram канал автора

Анонсы всех статей, плюс много другой полезной и интересной информации, которая не попадает на сайт.

Failover (WAN Backup)

Do not forget to add routes with routing marks

Проверка

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2 провайдера, резервирование и балансировка

В статье будет рассмотрен способ подключения двух провайдеров к маршрутизатору микротик, использование 2-х провайдеров может быть двумя способами резервирование и балансировка. Резервирования каналов интернета, то есть в постоянной активности будет основной канал, а другой (резервный) будет запускаться в том случае, когда первый будет не активен, используется, если допустим 2-й оператор предоставляет интернет с ограниченным трафиком или через GSM модем. Балансировка, когда одновременно работает 2 провайдера.

Нужно разобраться с MikroTik, но не определились с чего начать? В курсе «Настройка оборудования MikroTik» все по порядку. Подойдет и для начала работы с этим оборудованием, и для того, чтобы систематизировать знания. Это видеокурс из 162 уроков и 45 лабораторных работ, построен на официальной программе MTCNA. Проходить можно, когда удобно и пересматривать по необходимости – материалы курса выдаются бессрочно. Также есть 30 дней на личные консультации с автором. На пробу выдают 25 уроков бесплатно, заказать их можно на странице курса.

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

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

Пример одного из таких модемов, который использую лично я сам, и он отлично работает в Mikrotik. Модель — HUAWEI E3372h или МегаФон M150-2.

А вообще, список гарантированно поддерживаемых usb модемов можно посмотреть в официальной wiki — https://wiki.mikrotik.com/wiki/Manual:Peripherals. Прежде чем настраивать резервирвоание, рекомендую выполнить базовую настройку mikrotik.

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

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

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

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

• ether1 — основной интернет канал
• lte1 — запасной через 4g

Первым делом добавим 2 статических маршрута до каких-то ip адресов в интернете, по которым будем определять наличие интернета на микротике. Я для этого использую dns серверы Яндекса — 77.88.8.1 и 77.88.8.8. Добавляем маршруты:

/ip route add distance=1 dst-address=77.88.8.8/32 gateway=10.0.0.1
/ip route add distance=1 dst-address=77.88.8.1/32 gateway=192.168.100.1

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

ping 77.88.8.1 interface=ether1

ping 77.88.8.8 interface=lte1

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

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

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

В целом, вся подготовка закончена. Теперь идем в System -> Scripts и добавляем скрипт, который будет переключать каналы:

:local PingCount 5;
:local CheckIp1 77.88.8.1;
:local CheckIp8 77.88.8.8;
:local isp1 [/ping $CheckIp1 count=$PingCount interface="ether1"];
:local isp2 [/ping $CheckIp8 count=$PingCount interface="lte1"];
:local BackGw [/ip route get [find comment="lte1"] disable];
:if (($isp1=0) && ($isp2=$PingCount) && ($BackGw=true)) do={
/ip route disable [find comment="ether1"];
/ip route enable [find comment="lte1"];
:delay 2
:log warning "Set routes to lte1";
/ip firewall connection remove [ find protocol~"tcp" ];
/ip firewall connection remove [ find protocol~"udp" ];
:delay 2
:log warning "Set routes to lte1";
}
:local MainGw [/ip route get [find comment="ether1"] disable];
:if (($isp1=$PingCount) && ($MainGw=true)) do={
/ip route enable [find comment="ether1"];
/ip route disable [find comment="lte1"];
:delay 2
:log warning "Set routes to ether1";
/ip firewall connection remove [ find protocol~"tcp" ];
/ip firewall connection remove [ find protocol~"udp" ];
:delay 2
:log warning "Set routes to ether1";
}

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

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

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

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

/system backup save password="secret" name=disconnect
delay 240
/system backup load name=disconnect.backup password="secret"

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

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

В завершении всей настройки проверки и переключения на резервный канал в mikrotik добавляем скрипт в планировщик. Для этого идем в System -> Scheduler и добавляем задание на выполнение каждые 30 или 60 секунд. Интервал подберите сами.

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

Настройка IP адресации

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

Я думаю бессмысленно как-то дополнять данные настройки.

Настройка MikroTik

Закажи настройку MikroTik непосредственно сейчас, поможем в поиске решения по любому кейсу связанному с MikroTik.

Предоставляю гарантию две недели на свою работу, оплата постфактум, работаю как с юридическими, так и физическими лицами.

Настройка шлюза

Провайдер 1

IP адрес 1.1.1.2/30 c шлюзом 1.1.1.2

Провайдер 2

IP адрес 2.2.2.2/32 но с рандомным шлюзом, который можно «прибить» на постоянный обратившись к статье:

Провайдер 3

IP адрес динамический, но если используется USB модем с прошивкой HiLink, то он выполняет роль NAT и IP адрес с шлюзом используется от модема и известен заранее.
Но это не профессиональный подход 🙂

USB модем с безлимитной SIM картой и белым IP можно купить у моего товарища https://4g-inter.net

Для подключения к LTE оператору будет использована антенна MikroTik в режиме проброса IP адреса.

Получаем шлюз 10.177.0.3

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

Одновременный доступ по двум внешним IP

Теперь нам нужно настроить маршрутизацию таким образом, чтобы работали одновременно два wan интерфейса с двумя разными ip адресами. У меня есть очень старая статья, где тоже используются 2 провайдера, но только для резервирования интернета. Одновременно работает только один провайдер, а на второй происходит переключение в случае проблем у первого.

Идем в раздел IP -> Routes и добавляем 2 дефолтных маршрута. Настраиваем их точно так же, как это делали, если бы был только один провайдер. Но при этом указываем для каждого маршрута свою метку маршрутизации (Routing Mark).

То же самое проделываем для второго интерфейса. Должно получиться вот так:

/ip route
add distance=1 gateway=109.68.184.1 routing-mark=wan1
add distance=1 gateway=77.31.15.1 routing-mark=wan2

Все, этого достаточно, чтобы к Mikrotik можно было подключиться извне по любому из предложенных IP адресов обоих WAN интерфейсов. По сути он стал доступен через обоих провайдеров одновременно. Важно понимать, что мы настроили только доступ к самому устройству через оба wan интерфейса, а не работу через обоих провайдеров клиентов локальной сети, если mikrotik выступает в качестве шлюза. Там нужно выполнить дальнейшие настройки, чтобы все корректно работало. Надо промаркировать пакеты и из локальной сети и направить их на тот или иной маршрут в зависимости от меток. В данной статье я это не рассматриваю. Возможно, сделаю отдельно.

Настройка рекурсивных маршрутов

Рекурсивная маршрутизация позволяет проверить наличие интернета за шлюзом через Check Gateway, но включаться он будет через Netwatch
Проверять будет за счет серверов Яндекс.DNS:

• 77.88.8.1 для WAN1
• 77.88.8.2 для WAN2
• 77.88.8.3 для WAN3

Добавим правила маршрутизации:

• 8.8.8.8 для WAN1
• 8.8.4.4 для WAN2
• 4.2.2.1 для WAN3

Чтобы трафик до «проверочных» узлов не убегал через другого провайдера, в Firewall добавим адрес листы:

И настроим запрет пересылки, кроме разрешенного интерфейса:

Я использую данный способ как счетчик и защита от зависших соединений. В отличии от жесткой привязки к маршруту через lookup only table, этот способ никогда не «залипал».

Доступ к маршрутизатору

Первая задача, которую нам необходимо решить, это организовать возможность управления маршрутизатором через разных провайдеров. Мы должны иметь возможность подключаться по любому IP адресу по ssh, winbox, а также если вы будете использовать RouterOS в случае VPN сервера. В общем организовать правильный выход пакетов, которые будет отправлены с маршрутизатора в ответ на входящие соединения.

Для начала нам надо организовать правильные таблицы маршрутизации. В одной таблице маршрутизации не могут быть одновременно два одинаковых активных маршрута, если маршруты одинаковы, то приоритет выбирается из значения distance. Для того чтобы можно было использовать несколько одинаковых маршрутов в RouterOS есть возможность создавать альтернативные (именованные) таблицы маршрутизации.

Создадим данные таблицы.

dst-address=0.0.0.0/0 — обычный маршрут по умолчанию, не более чем.

gateway=88.88.88.1 — шлюз, обратите внимание на то, что нам первый провайдер даёт два префикса с разными шлюзами, и поэтому мы создаём три маршрута, для нас по факту не два провайдера, а три.

routing-mark=Next-Hop/88.88.88.1 — это и есть именованная таблица маршрутизации. Она может иметь любое имя, какое вам удобнее, лично моё мнение, такое именование удобно записывать в названии таблицы шлюз, через который будет отправлен пакет в случае если он будет использовать данный маршрут. Имена маркировок соединений и маршрутов просто совпали и могут быть совершенно разные.

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

Дело в том, что routing-mark это маркировка, когда вы своими руками с помощью mangle назначили на пакет маркировку, а routing-table это то, через какую таблицу маршрутизации вышел пакет.

Если маршрутизатор не найдёт подходящего маршрута в именованной таблице маршрутизации, маршрутизатор продолжит поиск подходящего маршрута в таблице по умолчанию main и такой пакет можно будет отфильтровать например так routing-mark=custommark routing-table=main . Нам же такое поведение не нужно, если по какой-то причине маршрут не будет найден, пакет должен умереть на маршрутизаторе, а отправлять через другого провайдера нет никакого смысла.

Нам необходимо переопределить данное поведение.

Т.е марка и таблица по факту это одно и тоже, пакет, который имеет определённую routing-mark и пытается найти маршрут в таблице с таким же именем.

Осталась самая малость, это отправить в нужную марку необходимый трафик.

Цепочка output, так как мы работаем только с трафиком, который генерирует в ответ на запрос соединения. Выбрали пакеты принадлежащие только определённым соединениям и отправили в именованную таблицу.

Вроде бы всё хорошо и всё должно работать, но это не так, в RouterOS есть один маленький нюанс, который необходимо помнить и учитывать. Дело в том, что маршрутизатор, прежде чем отправить пакет в цепочку output, смотрит в таблицу маршрутизации и ищет для адреса назначения подходящий маршрут в таблице main, есть всего три типа сервисов, которые умеют работать вне данного поведения, это ping, traceroute и ospf — это необходимо для работы в VRF.

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

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

В RouterOS данный интерфейс можно заменить пустым bridge.

Я часто рассказываю на курсах, почему именно такое название, а не просто Loopback, возможно в ближайшем будущем в RouterOS будет добавлено поддержка Loopback интерфейса и если разработчики заложат такое же название, то при обновлении версии RouterOS могут возникнуть проблемы.

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

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

Напоминаю, что дистанция 255 это административная дистанция, которая явно указывает на то, что данный маршрут мёртв и не участвует в маршрутизации.

Всё, на данном этапе вы должны иметь возможность подключаться к маршрутизатору по любому IP адресу через любого провайдера одновременно, можете “пинговать” и делать всякие другие непотребства с внешними IP адресами.

Mikrotik как резервный шлюз

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

В удаленных местах, где нет постоянного технического персонала для обслуживания шлюза, я всегда ставлю 2 устройства, которые могут работать в качестве шлюза для локальной сети. Обычно это полноценный роутер Mikrotik или шлюз в виртуальной машине на базе какого-то линукса. Там могут быть настроены два провайдера, резервирование и т.д. Не суть важно, рассказываю не об этом. В качестве резерва чаще всего выступает свитч микротик с возможностью роутинга. Например, CRS326. Это очень удобно, так как свитч в любом случае какой-то будет установлен, пусть уж сразу с доп. функуионалом.

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

В случае, если у вас только 1 провайдер, но он предоставляет несколько внешних ip адресов, то все настраивается примерно так же. На резервном Микротике настраивается интернет через основной шлюз в локальной сети (в моей статье это wan1), а отдельный внешний ip адрес настраивается как дополнительный (wan2). Отличие будет только в том, что соединения через основной шлюз и локальную сеть не надо маркировать. Будут проблемы с доступом через локальную сеть, vpn и т.д. Достаточно настроить маркировку входящих пакетов только через wan2 — внешний ip адрес провайдера.

При такой схеме вы будете застрахованы от физической поломки основного шлюза. Если она случится, вы подключаетесь через внешний ip адрес к запасному микротику и делаете его временно основным шлюзом. Можно просто назначить ему ip адрес мертвого шлюза или настроить dhcp сервер и выдавать новые сетевые настройки. Это уже будет зависеть от вашей топологии.

Способ 2 — Умный анализ

В связке с 1 способом будем проверять доступность нескольких популярных сервисов с каждого провайдера и сравнивать результат.

1 и 2 способ в связке потому, что скрипт умного анализа читает IP адрес с интерфейса, а если он еще не поднялся или еще не имеет IP, то скрипт не отрабатывает. На этот случай страхует 1 способ проверки.

Нужно добавить дополнительные скрипты «ручного» переключения WAN:

В скрипте задаются названия интерфейсов, с которых берется IP адрес и с которых производится проверка. Параметр Interval в ms используется для оценки качества канала. Если за 100ms канал WAN1 не получил более 1 отклика, то он считается «битым» и сравнивается количество откликов у канала WAN2.
WAN3 всегда читается рабочим, если его не забракует 1 способ проверки.

Не нужно бездумно копировать скрипт умного анализа.

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

Частота запуска «умного» скрипта задаётся индивидуально через System > Sheduler

Microtik два провайдера разделение трафика

Собственно два канала. Витуха Вымпела и 3G мопед
Девайс 2011UAS
Firmware 3.05
Packedge 6.0rc12

Route у шлюза megafon3g прописанный маркер

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

если бы знали, вас бы тут не было.

1. маркируем трафик:

2ое правило нужно чтобы всё остальное роутить, в принципе правило не нужно, но для наглядности оставлю

2. создаём роутинг:

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

3. делаем маскарад:

всё. 2х2=4
добавляем маркеры трафика какой надо куда.

1. Маркируют только нужныйе пакеты
2. Чем роутинг тот что у меня не устраивает? Тоже самое. Резервирование сейчас не принципиально.
3. Маскадинг общий без указания исходящего интерфейса. Тоже самое что и вы указали.

В общем ни чего нового. Ссылки,гугл,готовые маны. плагиат!
Как выяснить где трафик останавливается после маркировки? В логих пробовал включить роутинг но чтото он вообше молчит.

1. вы вообще о чём? хотите маркировать нужный трафик, добавьте в правило параметры нужного трафика.
2. да просто по таким «описаниям» сложно понять, что там у вас за роутинг. проще написать с нуля и объяснить принцип.
3. ну кто как привык работать, я привык задавать конкретику в работе устройства, для меня обобщения губительны.

именнно, вы угадали суть, все о чем вы хотите тут спросить уже давным давно написано. в вашей задаче нет ничего уникального.
что значит «где останавливается трафик»?
запустите трассировку, если остановится на мтике, то значит мтик не смог найти маршрут для пересылки пакета дальше. это значит маршрута нет. дальше можно не продолжать.

Выпустить с правильного адреса

Часто бывают ситуации, что вам необходимо жёстко определить, чтобы какой-то внутренний хост выходил только с определённого IP адреса.

Например, VoIP телефония, ваш провайдер телефонии требует, чтобы вы регистрировались только с определённого IP адреса, или банк клиент на компьютере главного бухгалтера должен подключаться с определённого адреса.

Сначала настроим адрес листы в которые будем добавлять внутренние адреса хостов, которые необходимо отправить через нужного провайдера и с определённого IP адреса.

Адрес 0.0.0.1, для того чтобы создать лист, но не привязывать к реальному адресу.

Название листа явно говорит о том, на какой IP адрес необходимо изменить адрес источника.

Для реализации данного кейса нам необходимо учитывать особенность работы RouterOS.

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

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

Допустим, если мы добавим хост 172.20.17.100 и скажем, что весь трафик направить в первого провайдера, то что будет с трафиком, который идёт на хост 172.20.18.2? Естественно он будет направлен в первый провайдер.

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

Создадим адрес лист с BOGON сетями.

А далее создадим правила для того, чтобы выпустить хосты с определённого IP адреса.

Если пакет в адресе источника находится адрес, который перечислен в адрес листе и при этом адрес назначения не попадает под BOGON листы (т.е трафик в интернет), отправить в именованную таблицу.

И последний нюанс-это настроить NAT.

Обратите внимание, что не весь трафик, а только тот, который находится в определённом маркированном маршруте, это необходимо для того, чтобы трафик между локальными сетями не попадал под NAT правило.

Легенда

• Провайдер 1 дает по IPoE статику
• Провайдер 2 дает по PPPoE статику (динамический шлюз)
• Провайдер 3 дает по 4G (динамика)

Нужно сделать автоматическое переключение с провайдера 1 на провайдера 2 и в крайнем случае на провайдера 3, назовем это все MultiWAN, для двух операторов DualWAN.

Интерфейс-листы WAN

Чтобы было проще настраивать NAT, Firewall и Mangle и был один стиль названий WAN интерфейсов:

1. ether1-WAN1 будет WAN1
2. PPPoE_WAN2 будет WAN2
3. vlan101-LTE-Internet будет WAN3

Резервирование

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

Быстрый способ

Допустим, шлюзом первого провайдера ISP1 является ip 1.1.1.1 он же наш основной канал шлюз второго ISP2 ip 2.2.2.2 резервный провайдер.

Заходим В меню IP-Routes, и добавляем новое правило. Заполняем поля как на рисунке.

Dst.Address – адрес назначения, 0.0.0.0/0 значит любой адрес

Gateway – шлюз провайдера

Check Gateway –Способ проверки доступности шлюза провайдера, будем проверять пингами.

Distance – метрика шлюза, т.е приоритет чем значение меньше тем приоритет выше.т.к ISP1 у нас основной провайдер, то метрику ставим самую высокую 0 или 1

Аналогично настраиваем второго провайдера ISP2? Только метрику Distance ставим больше 1, например 10

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

Комплексный способ

Данный способ основывается на систематической проверке (раз в 1 минуту) доступности какого либо ресурса в интернете, например DNS гугла 8.8.8.8.. Схема такова: если пинг проходит, значит ISP1 канал активен и ISP2 может быть отключен, в противном случае включается второй, а 1-й должен быть выключен.

Следующим создаем статический маршрут до 8.8.8.8 через основной канал. Метрика по умолчанию равна 0, поэтому ее можем не указывать. Этот маршрут нужен для проверки доступности интернета через основной канал, если он пропадает то происходит переключение

Обратите внимание, что в качестве ресурса для мониторинга нужно выбирать ip который не будет использоваться для работы. Например если вы в сети используете DNS гугла 8.8.8.8, то не нужно мониторить его доступность, в противном случае при отключении основного канала, DNS 8.8.8.8 работать не будут, т.к запросы на этот адрес будут идти через не работающего провайдера

Переключение будем делать с помощью встроенной утилиты Netwatch. Эта утилита может следить за состоянием хоста в сети и основываясь на доступности или недоступности хоста выполнять действия.

Идем в меню Tools-Netwatch и добавляем правило.

Host – ресурс который будем проверять на доступность

Interval – c какой периодичностью проверять, оставим 1 раз в минуту. Далее переходим на вкладку «UP». Здесь нам нужно прописать действие которое будет выполняться при доступности хоста. Если хост доступен, то нам нужно включить маршрут через 1-го провайдера и отключить через второго. Код будет следующим

На вкладке «Down». Прописываем правила что если хост не доступен, то отключаем ISP1 и включаем ISP2.

Нажимаем «OK». Теперь при недоступности ip адреса 8.8.8.8, произойдет отключение маршрута 1.1.1.1 и включение маршрута 2.2.2.2. А когда хост 8.8.8.8 снова станет доступен, резервный канал выключится и включится основной.

Заключение

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

Заключение

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

1. Настраивается просто и понятно.
2. Умеет сбрасывать все соединения после переключения.
3. Пишет информацию в лог для дальнейшего анализа.

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