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

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

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

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

Допустим, шлюзом первого провайдера 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-й должен быть выключен.

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

ISP1 будет

ISP2

Следующим создаем статический маршрут до 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-го провайдера и отключить через второго. Код будет следующим

#включем маршрут с комментарием «ISP1» (основной канал) /ip route set disabled=no #отключаем маршрут с комментарием «ISP2″(резервный канал) /ip route set disabled=yes

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

#отключаем маршрут с комментарием «ISP1″(резервный канал) /ip route set disabled=yes #включаем маршрут с комментарием «ISP1» (основной канал) /ip route set disabled=no

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

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

Настроим одновременную работу двух провайдеров, переходим снова в меню 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.

Настройка LAN портов 3-5 и Wi-Fi

LAN порты 3-5 будут объединены с Wi-Fi интерфейсом в единую локальную сеть, к которой будут подключаться компьютеры.

Объединяем LAN порты 3-5 в свитч

  1. Откройте меню Interface;
  2. Сделайте двойной щелчок мыши по интерфейсу ether4;
  3. В списке Master Port выберите ether3 (главный порт нашего свитча);
  4. Нажмите кнопку ОК.

Повторите тоже самое для интерфейса ether5.

Напротив портов ether4 и ether5 появится буква S (Slave — ведомый).

Создаем интерфейс Bridge-local и объединяем в нем LAN порты и Wi-Fi

Чтобы LAN порты 3-5 объединить с Wi-Fi в одну сеть, нужно создать bridge интерфейс, и добавить в него мастер порт свитча ether3 и Wi-Fi интерфейс wlan1.

Создаем интерфейс bridge-local:

  1. Откройте меню Bridge;
  2. Нажмите кнопку Add (синий крестик);
  3. В поле Name пропишите имя интерфейса bridge-local;
  4. Нажмите кнопку OK.

Добавляем главный порт свитча ether3 в bridge-local:

  1. Перейдите на вкладку Ports и нажмите кнопку Add (синий крестик);
  2. В списке Interface выберите главный ethernet порт свитча ether3;
  3. В списке Bridge выберите интерфейс bridge-local;
  4. Нажмите кнопку OK.

Добавляем Wi-Fi интерфейс в bridge-local:

  1. На вкладке Ports нажмите кнопку Add (синий крестик);
  2. В списке Interface выберите беспроводной интерфейс wlan1;
  3. В списке Bridge выберите интерфейс bridge-local;
  4. Нажмите кнопку OK.

Назначаем IP-адрес интерфейсу bridge-local:

  1. Откройте меню IP — Addresses;
  2. Нажмите кнопку Add (синий крестик);
  3. В поле Address введите IP-адрес и маску локальной сети 192.168.88.1/24;
  4. В списке Interface выберите интерфейс локальной сети bridge-local;
  5. Нажмите кнопку OK.

Настраиваем DHCP сервер локальной сети.

Чтобы компьютеры, подключенные к роутеру, получали сетевые настройки автоматически, настроим DHCP сервер:

  1. Откройте меню IP — DHCP Server и нажмите кнопку DHCP Setup;
  2. В списке DHCP Server Interface выберите bridge-local и нажмите Next;
  3. В этом окне выбирается сеть для раздачи DHCP. Оставляем без изменений и нажимаем кнопку Next;
  4. В следующем окне указывается адрес шлюза. Нажмите кнопку Next;
  5. В этом окне прописывается диапазон IP адресов, которые будет раздавать DHCP сервер. Нажмите кнопку Next;
  6. Далее вводятся адреса DNS серверов. Нажмите кнопку Next;
  7. Здесь задается время резервирования IP адресов. Нажмите кнопку Next;
  8. Настройка DHCP сервера успешно завершена. Нажмите кнопку OK.

Настройка Wi-Fi

Сначала включим Wi-Fi:

  1. Откройте меню Wireless;
  2. Нажмите левой кнопкой мыши на интерфейсе wlan1 и нажмите кнопку Enable (синяя галочка).

Создаем пароль для подключения к точке доступа MikroTik:

  1. Откройте вкладку Security Profiles и сделайте двойной щелчок левой кнопкой мыши по default;
  2. В появившемся окне в списке Mode выберите dynamic keys;
  3. Поставьте галочку напротив регистрации по протоколу WPA2 PSK;
  4. В поле WPA2 Pre-Shared Key введите пароль для подключения к Wi-Fi точке;
  5. Нажмите кнопку OK.

Настраиваем параметры Wi-Fi точки MikroTik:

  1. Откройте вкладку Interfaces и сделайте двойной щелчок левой кнопкой мыши на Wi-Fi интерфейсе wlan1, чтобы зайти в его настройки;
  2. Перейдите на вкладку Wireless;
  3. В списке Mode выберите режим работы ap bridge;
  4. В списке Band выберите 2GHz-B/G/N (в каких стандартах будет работать Wi-Fi точка);
  5. В списке Channel Width укажите ширину канала 20/40Mhz HT Above, чтобы беспроводные устройства смогли подключиться на максимальной скорости с шириной канала 40 МГц;
  6. В списке Frequency укажите, на какой частоте будет работать Wi-Fi;
  7. В поле SSID укажите имя Wi-Fi сети;
  8. Нажмите кнопку OK.

Настройка переключения интернет каналов между двумя провайдерами

Для настройки переключения интернет каналов между двумя провайдерами будем использовать маршруты (Routes) и встроенную утилиту Netwatch.

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

Если вдруг пропадет связь с 1-ым провайдером, то мы активируем 2-ой маршрут, и весь трафик пойдет через 2-го провайдера.

Как только восстановится связь через 1-го провайдера, мы деактивируем 2-ой маршрут, и весь трафик пойдет через 1-го провайдера.

Утилита Netwatch поможет пинговать ip-адрес в интернете и выполнять скрипты, если ip-адрес перестал пинговаться или снова начал. Она будет выполнять активацию и деактивацию маршрута.

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

  1. Откройте меню IP — Routes;
  2. Кликните левой кнопкой мыши по маршруту первого провайдера со шлюзом 10.10.10.1 unrechable;
  3. Нажмите кнопку удалить (красный минус).

Теперь изменим параметры маршрута второго провайдера:

  1. Сделайте двойной щелчок левой кнопкой мыши по маршруту второго провайдера;
  2. В поле Gateway должен быть указан шлюз второго провайдера 20.20.20.1;
  3. В поле Distance ставим приоритет 2;
  4. Нажмите кнопку Comment;
  5. В поле напишите комментарий ISP2. Комментарий необходим для того, чтобы наши скрипты могли идентифицировать маршрут и активировать или деактивировать его.
  6. Нажмите кнопку OK и в следующем окне еще раз OK.
  7. Выберите маршрут второго провайдера, кликнув по нему левой кнопкой мыши, и деактивируйте, нажав кнопку с красным крестиком. После этого маршрут станет серого цвета.

Дальше нужно добавить маршрут первого провайдера заново, но прежде определим, какой IP-адрес шлюза выдает первый провайдер.

  1. Откройте меню IP — DHCP Client;
  2. Сделайте двойной щелчок левой кнопкой мыши на интерфейсе ether1;
  3. Перейдите на вкладку Status;
  4. Выпишите IP-адрес шлюза из поля Gateway. Он будет нужен при создании маршрута через первого провайдера.

Теперь добавляем маршрут через первого провайдера:

  1. Откройте меню IP — Routes;
  2. Нажмите кнопку добавить (синий плюсик);
  3. В поле Gateway укажите шлюз первого провайдера 10.10.10.1;
  4. В поле Distance ставим приоритет 3;
  5. Нажмите Comment;
  6. В поле напишите комментарий ISP1.
  7. Нажмите кнопку OK и еще раз OK в следующем окне.

3-й маршрут понадобится для того, чтобы сервер Google по умолчанию пинговался только через 1-го провайдера.

  1. Нажмите кнопку добавить (синий плюсик);
  2. В поле Dst. Address укажите IP-адрес сервера Google 8.8.4.4;
  3. В поле Gateway укажите шлюз первого провайдера 10.10.10.1;
  4. В поле Distance ставим приоритет 1;
  5. Нажмите Comment;
  6. Напишите комментарий GOOGLE.
  7. Нажмите кнопку OK и еще раз OK.

Также добавим в Firewall правило, которое запретит пинговать ip-адрес 8.8.4.4 через 2-го провайдера. Иначе утилита Netwatch подумает, что связь с 1-ым провайдером восстановилась, и будет постоянно переключать маршруты по кругу.

  1. Откройте меню IP — Firewall и перейдите на вкладку Filter Rules;
  2. Нажмите кнопку добавить (синий плюсик);
  3. В списке Chain выберите Output;
  4. В поле Dst. Address введите адрес сервера 8.8.4.4;
  5. В списке Out. Interface выберите ether2;
  6. Перейдите на вкладку Action;
  7. В списке Action выберите Drop;
  8. Нажмите кнопку OK.

Netwatch будет проверять связь с интернетом путем пингования сервера Google с IP-адресом 8.8.4.4. Как только сервер перестанет пинговаться, выполнится скрипт, который активирует 2-й маршрут и трафик пойдет через 2-го провайдера. Как только связь через 1-го провайдера восстановится, то выполнится другой скрипт, который деактивирует 2-й маршрут и трафик пойдет через 1-го провайдера.

  1. Откройте меню Tools — Netwatch;
  2. Нажмите кнопку добавить (синий плюсик);
  3. В поле Host укажите сервер Google 8.8.4.4, который утилита будет пинговать;
  4. В поле Interval укажите интервал времени 00:00:05, через который будет пинговаться сервер. Для отладки работы скриптов поставим небольшой интервал 5 секунд. После отладки переключения между двумя провайдерами увеличим интервал до 30 секунд.
  5. Перейдите на вкладку Down;
  6. На вкладке Down вставляем скрипт /ip route enable Этот скрипт будет активировать маршрут через второго провайдера, если перестанет пинговаться сервер Google;
  7. Перейдите на вкладку Up;
  8. На вкладке Up вставляем скрипт /ip route disable Этот скрипт будет деактивировать маршрут через второго провайдера, если восстановится связь через первого провайдера;
  9. Нажмите кнопку OK.

Проверка переключения интернета между двумя провайдерами

Проверим, как работает переключение между двумя провайдерами.

  1. Откройте меню IP — Routes. Маршрут второго провайдера должен быть серого цвета, т.е. не активен;
  2. Отсоедините от роутера кабель 1-го провайдера;
  3. В Routes маршрут второго провайдера должен активироваться.
  4. Проверьте, что на компьютерах есть интернет.
  5. Теперь подключаем кабель первого провайдера обратно.
  6. В Routes маршрут второго провайдера должен деактивироваться.
  7. Проверьте, что на компьютерах есть интернет.

Настройка роутера MikroTik на два провайдера работает правильно. Теперь можно увеличить интервал пингования сервера Google.

  1. Откройте меню Tools — Netwatch;
  2. Сделайте двойной щелчок левой кнопкой мыши по 8.8.4.4;
  3. На вкладке Host в поле Interval укажите интервал времени 00:00:30 — 30 секунд.
  4. Нажмите кнопку OK.

На этом настройка маршрутизатора Микротик на два провайдера завершена.

Как видно на иллюстрации, шейпер режет всё, что не влезло, а шедулер просто притормаживает.

Соответственно, именно шедулер нам и нужен.

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

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

Итак, план таков:

prio_1: DNS, ICMP, ACK — в первую очередь идёт служебный трафик. Установка и разрыв соединений, резолвинг имён и т.п.

prio_2: SIP — VoIP очень любит минимальные задержки.

prio_3: SSH и игры — удалённый доступ важен для работы. Игры — для отдыха.

prio_4: RDP и HTTP/HTTPS — веб, видео и т.п.

prio_5: всё, что не опознано выше — в принципе, можно принудительно загнать сюда торренты. Благо дома порты с которых работают клиенты вполне известны.

Маленькое лирическое отступление:

Если мы поищем информацию о QoS в Mikrotik, то найдём несколько вариантов скриптов, начиная от монструозного QOS script by Greg Sowell или явно основанного на нём The Mother of all QoS Trees, заканчивая Traffic Prioritization Script (кстати, советую отнестись к нему с большой осторожностью, автор явно довольно смутно понимает, что делает и поэтому скрипт делает явно не то, что было задумано). У всех этих скриптов есть одна общая проблема — они написаны довольно давно и в значительной степени устарели по одной простой причине — мир изменился.

Сегодня, благодаря всеобщему шифрованию трафика, мы не можем так запросто взять и с помощью L7-regexp отловить трафик youtube, например, или Skype. Поэтому, используя такие скрипты, внимательно отнеситесь к вопросу определения трафика. Это, на мой взгляд, единственная сложность в этом вопросе.

Теперь разметим трафик согласно плана выше. В коде я использую interfaceBandwidth, т.е. ширину канала. У меня он симметричный и равен 100М. Если у вас отличается ширина канала, то необходимо изменить значение interfaceBandwidth на необходимое. Если канал асинхронный, то скрипт будет сложнее за счёт необходимости отдельно маркировать пакеты для входящего и исходящего трафика. Это несложно, но значительно увеличит скрипт, ухудшив его читаемость и, в целом, выходит за рамки статьи.

В address-list я демонстрирую возможность массовой вставки адресов из FQDN (для примера взяты адреса кластеров из wiki Мира Танков). Разумеется, можно просто прописать необходимые IP вручную.

#Set bandwidth of the interface

:local interfaceBandwidth 100M

# address-lists

:for i from=1 to=10 do={/ip firewall address-list add list=WoT address=(«login.p».»$i».».worldoftanks.net»)}

/ip firewall mangle

# prio_1

add chain=prerouting action=mark-packet new-packet-mark=prio_1 protocol=icmp

add chain=prerouting action=mark-packet new-packet-mark=prio_1 protocol=tcp port=53

add chain=prerouting action=mark-packet new-packet-mark=prio_1 protocol=udp port=53

add chain=prerouting action=mark-packet new-packet-mark=prio_1 protocol=tcp tcp-flags=ack packet-size=0-123

# prio_2

add chain=prerouting action=mark-packet new-packet-mark=prio_2 dscp=40

add chain=prerouting action=mark-packet new-packet-mark=prio_2 dscp=46

# prio_3

add chain=prerouting action=mark-packet new-packet-mark=prio_3 protocol=tcp port=22

add chain=prerouting action=mark-packet new-packet-mark=prio_3 address-list=WoT

# prio_4

add chain=prerouting action=mark-packet new-packet-mark=prio_4 protocol=tcp port=3389

add chain=prerouting action=mark-packet new-packet-mark=prio_4 protocol=tcp port=80,443

# prio_5

add chain=prerouting action=mark-packet new-packet-mark=prio_5

Аккуратно уложим размеченный трафик в очередь:

queue tree add max-limit=$interfaceBandwidth name=QoS_global parent=global priority=1

:for indexA from=1 to=5 do={

/queue tree add \

name=( «prio_» . «$indexA» ) \

parent=QoS_global \

priority=($indexA) \

queue=ethernet-default \

packet-mark=(«prio_» . $indexA) \

comment=(«Priority » . $indexA . » traffic»)

}

И последнее, коль скоро Mikrotik поддерживает WMM, было бы логично разметить трафик и для него.

Делается это тем же mangle-ом с помощью команды set_priority. Согласно wiki Mikrotik’а, таблица приоритетов WMM выглядит довольно причудливо:

1,2 — background

0,3 — best effort

4,5 — video

6,7 — voice.

Разметим приоритеты, используя те же правила, что и для маркировки пакетов:

/ip firewall mangle

# prio_1

add chain=prerouting action=set-priority new-priority=7 protocol=icmp

add chain=prerouting action=set-priority new-priority=7 protocol=tcp port=53

add chain=prerouting action=set-priority new-priority=7 protocol=udp port=53

add chain=prerouting action=set-priority new-priority=7 protocol=tcp tcp-flags=ack packet-size=0-123

# prio_2

add chain=prerouting action=set-priority new-priority=6 dscp=40

add chain=prerouting action=set-priority new-priority=6 dscp=46

# prio_3

add chain=prerouting action=set-priority new-priority=5 protocol=tcp port=22

add chain=prerouting action=set-priority new-priority=4 address-list=WoT

# prio_4

add chain=prerouting action=set-priority new-priority=3 protocol=tcp port=3389

В принципе, на этом всё.

В будущем, при необходимости, можно подумать о формировании динамических адресных листов, периодически формируемых из кэша DNS скриптами типа:

:foreach i in=

do={:put }

для отбора онлайнового видео.

Или детектить Skype с помощью поиска upnp-правил:

:foreach i in=

do={:put }

Но пока у меня такой необходимости нет.

На днях надо было срочно сделать резервный канал на Микротике с помощью 3G модема с автоматическим переключением резервный/основной.

Данная статья построена на конфигурации описанной в статье Настройка MikroTik RB951G-2HnD

Надеюсь кому-то пригодится.

  1. Втыкаем USB 3G модем в Микротик. Со списком поддерживаемого оборудования можно ознакомится на официальном сайте.
  2. Заходим на Микротик через Winbox в Терминал или по ssh и вводим:

    /interface ppp-client
    print

  3. Если модем появился то увидите что-то вроде этого:

    /interface ppp-client> print
    Flags: X — disabled, R — running
    0 X name=»ppp-out1″ max-mtu=1500 max-mru=1500 mrru=disabled port=usb1 data-channel=0
    info-channel=0 apn=»internet» pin=»» user=»» password=»» profile=default phone=»»
    dial-command=»ATDT» modem-init=»» null-modem=no dial-on-demand=yes add-default-route=yes
    use-peer-dns=yes keepalive-timeout=30 allow=pap,chap,mschap1,mschap2
    /interface ppp-client>

    Из списка видно что у нас один интерфейс с номером 0. Если у вас несколько или, к примеру, интернет провайдер через pptp то находим нужный.

  4. Переименовываем модем и снимаем dial-on-demand и use-peer-dns:

    set 0 name=ppp-3G dial-on-demand=no use-peer-dns=no

  5. Создаем список адресов inet2 с адресами которым будет разрешен выход в интернет через 3G модем.

    /ip firewall address-list
    add address=192.168.0.1 disabled=no list=inet2
    add address=192.168.0.100 disabled=no list=inet2

    В нашем примере выход в интернет будет разрешен только адресам 192.168.0.1 & 192.168.0.100.
    Если надо разрешить доступ всем из локальной сети, то используйте команду:
    /ip firewall address-list add address=192.168.0.0/24 disabled=no list=inet2

  6. Смотрим существующие правила файервола (нас интересует forward)

    /ip firewall filter
    print

    7 ;;; Allow related connections
    chain=forward action=accept connection-state=related

    8 ;;; Allow acess to internet
    chain=forward action=accept src-address-list=inet in-interface=bridge-local
    out-interface=wan

    9 ;;; All other drop
    chain=forward action=drop

    /ip firewall filter>

  7. Нам надо перед последним запрещающим правилом forward (в данном случае оно №9) вставить свое:

    add place-before=9 action=accept chain=forward comment=»acess to internet via 3G» disabled=no in-interface=bridge-local out-interface=ppp-3G src-address-list=inet2

  8. Проверяем что у нас получилось командой print:

    8 ;;; Allow acess to internet
    chain=forward action=accept src-address-list=inet in-interface=bridge-local
    out-interface=wan

    9 I ;;; acess to internet via 3G
    chain=forward action=accept src-address-list=inet2 in-interface=bridge-local
    out-interface=ppp-3G

    10 ;;; All other drop
    chain=forward action=drop

    /ip firewall filter>

  9. Не забываем добавить правило для маскарадинга через 3G модем:

    /ip firewall nat add action=masquerade chain=srcnat out-interface=ppp-3G

  10. Ну, а теперь самое интересное — механизм который будет переключать на резервный канал и обратно. Я предлагаю вариант с Netwatch. Маршрутизатор регулярно будет проверять адрес 8.8.4.4 и в случае его недоступности переключатся на резервный канал 3G модема.
    ВНИМАНИЕ: использование Netwatch имеет существенный недостаток. Лучше использовать скрипт из статьи: Автоматическое переключение на резервный 3G модем
    Первым делом делаем так чтобы пакеты на 8.8.4.4 всегда шли через основного провайдера:

    /ip route add comment=»always via ISP1″ disabled=no dst-address=8.8.4.4/32 gateway=1.2.3.254
    Теперь создаем netwatch правило:

    /tool netwatch
    add disabled=no down-script=»/interface enable ;\r\
    \n:log warning \»Switch to 3G modem\»;\r\
    \n/ip route disable ;\r\
    \n» host=8.8.4.4 interval=10s timeout=100ms up-script=»/interface disable \
    ;\r\
    \n:log warning \»Switch to main internet\»;\r\
    \n/ip route enable ;\r\
    \n»

    Немного пояснений как это работает: netwatch каждые 10 секунд проверяет адрес 8.8.4.4, если он недоступен (down), то отключает маршрут по умолчанию (с комментом isp) и включает 3G модем. При этом проверка адреса 8.8.4.4 у нас по прежнему будет идти через основного провайдера. Модем у нас настроен так что сразу подключается и получает от провайдера новый маршрут по умолчанию и адреса DNS серверов. В случае получения ответов от 8.8.4.4 (up) 3G модем отключается, тем самым отключая маршрут и DNS сервера оператора связи, и активируется маршрутизация через основного провайдера.

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

Написать данный пост меня сподвигла ситуация с отключением одного из каналов Интернета.
В самом же Интернете ответов по данному вопросу много, но не каждый является рабочим.
Что я хотел сделать, если отключается основной канал Интернета:
1. Переключиться на резервный канал (после «появления», разумеется, вернуться на основной);
2. Отправить уведомление по email о факте изменения состояния.
Кому интересно, прошу под кат.
Нам дано:
— Mikrotik RB450G с прошивкой 5.19 версии;
— 2 порта с Интернетом, один из которых для подключения использует PPPoE соединение.
Сперва добавим 2 скрипта, один из которых будет переключать на резервный канал, а второй вернет подключение к первому.

Составим первый скрипт, который будет активировать резервный канал и назовем его «change-to-reserv» и содержать в себе код:

/ip route set gateway=1.1.1.1 ;
(Примечание: IP-адрес 1.1.1.1 выбран как пример и символизирует резервный канал)
То есть, при обнаружении отсутствия пинга на сервер (об этом чуть позже) мы будем выключать маршрут с шлюзом, указывающим на «pppoe-main».
P.S.: После комментария erazel данная схема была улучшена, а именно раннее скрипт переключался между двумя маршрутами, которые давали сбой, а именно, если запустить с компа, например, команду ping google.ru -t, то при изменении маршрута пинг будет уходить на старый интерфейс, так как трансляция не обновилась. В предложенном же методе изменения только шлюза очистка трансляции не требуется.
Следующей строкой в этом же скрипте укажем:
/tool e-mail send server=192.168.1.1 port=25 user=robot@mysite.ru password=1PaSsW0rD1 tls=no to=admin@mysite.ru from=»ROBOT<robot@mysite.ru>» \ subject=»MikroTik: $, $» \ body=»Переключение на резервный канал\nДата: $\nAВремя: $»;
где:
/tool e-mail send — отправляем уведомление на email администратора о факте изменения статуса
server=192.168.1.1 — SMTP-сервер. Так как у нас используется свой, указываю его;
port=25 — в версии RouterOS 5.x порт указывается отдельно. В нашем случае он по-умолчанию 25;
user=robot@mysite.ru — логин пользователя для авторизации на SMTP-сервере (если требуется);
password=1PaSsW0rD1 — указываем пароль (если требуется);
tls=no — TLS-шифрование трафика. У нас нет, ставлю «no», а если и будет — «yes»;
to=admin@mysite.ru — на какой email-адрес будет приходить уведомление;
from=»ROBOT<robot@mysite.ru>» — от кого будет приходить уведомление (в моем случае совпадает с логином авторизации. В скобках указывается адрес отправителя, а перед ним имя, отображаемое во входящей почте);
subject=»MikroTik: $, $» — указываем заголовок письма. В данном случае он будет иметь вид «MikroTik: jul/30/2014, 10:52:13» (дата и время отправки сообщения);
body=»Переключение на резервный канал\nДата: $\nAВремя: $»; — соответственно, само тело сообщения, которое будет иметь вид:
Переключение линии на резервный канал
Дата: jul/30/2014
Время: 10:52:13
В итоге, наш скрипт будет иметь вид (RouterOS 5.19):
/ip route set gateway=1.1.1.1 ; /tool e-mail send server=192.168.1.1 port=25 user=robot@mysite.ru password=1PaSsW0rD1 tls=no to=admin@mysite.ru from=»ROBOT<robot@mysite.ru>» \ subject=»MikroTik: $, $» \ body=»Переключение на резервный канал\nДата: $\nAВремя: $»;
И для RouterOS 6.17:
/ip route set gateway=1.1.1.1 ; /tool e-mail send server=192.168.1.1 port=25 user=robot@mysite.ru password=1PaSsW0rD1 to=admin@mysite.ru from=»ROBOT<robot@mysite.ru>» \ subject=»MikroTik: $, $» \ body=»Переключение на резервный канал\nДата: $\nAВремя: $»;
Как уже писал выше, сохраним его под именем «change-to-reserv» и приступим к написанию второго скрипта:
/ip route set gateway=pppoe-main ; /tool e-mail send server=192.168.1.1 port=25 user=robot@mysite.ru password=1PaSsW0rD1 tls=no to=admin@mysite.ru from=»ROBOT<robot@mysite.ru>» \ subject=»MikroTik: $, $» \ body=»Переключение на основной канал\nДата: $\nAВремя: $»;
В отличие от первого скрипта, в теле отправляемого email-сообщения мы укажем «Переключение на основной канал» и включим раннее отключенный маршрут.
Сохраним наш скрипт под именем «change-to-main».
Так как память у Mikrotik не резиновая, мы оптимизируем наш скрипт для выполнения поставленной задачи.
Для этого нам необходимо использование утилиты Netwatch, которая работает как тригер. То есть, если состояние подключение изменится, то сменится и статус с выполнением нужных нам скриптов.

В Netwatch мы добавим новое правило, где укажем хост 8.8.8.8 и имена скриптов во вкладках «Up» — «change-to-main» и «change-to-reserv» во вкладке «Down» соответственно.
Также следует указать период проверки состояния. У нас указана 1 минута.

Дальше следует завершающий шаг — проброс маршрута. Если этого не сделать, то скрипт сработает на переключение к резервному каналу и останется в данном положении. Обратный переход будет возможен если резервный канал «упадет».
В общем, добавляем маршрут с указанием следующих данных:
Dst. Address = 8.8.8.8 // Указываем, что будем пинговать DNS-сервер Гугла (для меня не критично, указываю его);
Gateway = pppoe-main // То самое PPPoE-соединение на основной канал
Distance = 1
Остальные параметры оставляем как есть.

Всё!
Отныне принцип работы следующий:
Netwatch через основной канал будет проверять пинг до DNS-сервера Google. Как только пинг пропадет, выполнится скрипт «change-to-reserv», указанный на вкладке «Down». Данный скрипт отключит основной маршрут (PPPoE) и все пакеты будут идти по резервному каналу. Как только пинг по основному каналу возобновится, скрипт вновь активирует маршрут основного канала (параметр Distance которого, разумеется, «1», а резервного — «2»). Вместе с этим будут приходить уведомления на email-адрес о фактах изменения состояния.
Profit!
ВНИМАНИЕ!!! Для работы скриптов под управлением RouterOS 6.17 необходимо внести изменения в скрипт отправки email-адреса, а именно убрать параметр «tls=».
То есть, наш код (например, для переключения на резервный канал) будет иметь вид:
/ip route set gateway=1.1.1.1 ; /tool e-mail send server=192.168.1.1 port=25 user=robot@mysite.ru password=1PaSsW0rD1 to=admin@mysite.ru from=»ROBOT<robot@mysite.ru>» \ subject=»MikroTik: $, $» \ body=»Переключение на резервный канал\nДата: $\nAВремя: $»;
UPDATED: Изменены маршруты в скриптах

Полезна ли Вам эта статья?

Вопрос о балансировке нагрузки на WAN-линках встает довольно часто, и, к сожалению, в отличие от некоторых других вещей, которые можно настроить на оборудовании MikroTik быстро и безболезненно — в случае настройки Load Balancing придется немного постараться. Тема относительно сложная, наличие нескольких WAN-линков и задача по настройке балансировки нагрузки включает в себя настройку нескольких шлюзов и маршрутов по умолчанию, множество правил трансляции NAT и так далее.

Настройка маршрутизатора

Итак, в наличие у нас имеется один маршрутизатор MikroTik, который подключен к двум провайдерам — Тарс Телеком и Милайн на портах ether1 и ether2 соответственно, и локальной сетью на порту ether3. Трафик из локальной сети будет NATирован из обоих WAN портов и будет сбалансирован по нагрузке. Топология ниже:

Настраиваем локальные IP-адреса:

/ip address add address=1.1.1.199/24 interface=ether1 comment=»Tars» add address=2.2.2.199/24 interface=ether2 comment=»Meeline» add address=192.168.1.1/24 interface=ether3 comment=»LAN Gateway»

Настраиваем шлюзы по умолчанию:

/ip route add dst-address=0.0.0.0/0 check-gateway=ping gateway=1.1.1.1,2.2.2.1

Настраиваем NAT на WAN портах для исходящего направления:

/ip firewall nat add action=masquerade chain=srcnat comment=»Tars» out-interface=ether1 add action=masquerade chain=srcnat comment=»Meeline» out-interface=ether2

Если на данном этапе перестать настраивать роутер, то это будет являть собой пример настройки отказоустойчивости. Если один из линков “отвалится”, то вместо него будет использоваться второй. Однако, никакой балансировки нагрузки здесь нет и в помине, и, с экономической точки зрения, это является плохой идеей — вряд ли найдется компания, которая захочет платить абонентскую плату за второй канал и использовать его только в случае аварии.

Исходящая и входящая Mangle маркировка

Одной из типичных проблем при использовании более одного WAN-соединения является то, что пакеты принятые на одном WAN интерфейсе, могут тут же быть отправлены через другой WAN-интерфейс, что может, к примеру, сломать VPN-based сеть. Нам нужно чтобы пакеты “принадлежащие” одному и тому же соединению принимались и отправлялись через один и тот же WAN порт. В случае аварии у одного из провайдеров, все подключения на порту “умрут” и затем будут переподключены на другом WAN порту. Для этого необходимо промаркировать соединения:

/ip firewall mangle add action=mark-connection chain=input comment=»Tars Input» in-interface=ether1 new-connection-mark=»Tars Input» add action=mark-connection chain=input comment=»Meeline Input» in-interface=ether2 new-connection-mark=»Meeline Input»

Это поможет маршрутизатору отслеживать порт для каждого входящего подключения.

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

add action=mark-routing chain=output comment=»Tars Output» connection-mark=»Tars Input» new-routing-mark=»Out Tars» add action=mark-routing chain=output comment=»Meeline Output» connection-mark=»Meeline Input» new-routing-mark=»Meeline Telecom»

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

Маркировка LAN маршрута

Понадобится также настроить несколько Mangle правил — они необходимы, чтобы сообщить роутеру о необходимости балансировки пакетов, которые отправляются из локальной сети. Сам механизм балансировки в этой статье не описывается, можно только сказать что происходить много операций хеширования — если же интересно копнуть глубже, то вы можете обратиться к официальной документации MikroTik. В соответствии с этими правилами маршрутизатор будет балансировать трафик приходящий на порт ether3 (LAN-порт), который направлен на любой нелокальный адрес в Интернете. Мы захватываем трафик в цепочке предварительной маршрутизации для перенаправления его на необходимый нам WAN-порт в соответствии с меткой маршрутизации.

Следующие команды балансируют трафик на LAN-интерфейсе через две группы:

add action=mark-routing chain=prerouting comment=»LAN load balancing 2-0″ \ dst-address-type=!local in-interface=ether3 new-routing-mark=\ «Out Tars» passthrough=yes per-connection-classifier=\ both-addresses-and-ports:2/0 add action=mark-routing chain=prerouting comment=»LAN load balancing 2-1″ \ dst-address-type=!local in-interface=ether3 new-routing-mark=\ «Out Meeline» passthrough=yes per-connection-classifier=\ both-addresses-and-ports:2/1 Настройка меток маршрутизации выше была выполнена точно такие же как и в предыдущем шаге и соответствуют тем маршрутам, которые будут созданы в следующем шаге.

Особые маршруты по умолчанию.

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

/ip route add distance=1 gateway=1.1.1.1 routing-mark=»Out Tars» add distance=1 gateway=2.2.2.1 routing-mark=»Out Meeline» Данные маршруты используются только при наличии необходимой метки маршрутизации. Непомеченные пакеты используют обычный маршрут по умолчанию.

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

Заключение

Итого, какие шаги по настройке роутера были выполнены:

  1. Маркировка новых подключений в WAN
  2. Соединения с этой маркировкой получают метку маршрутизации
  3. Исходящий из локальной сети трафик балансируется с теми же метками маршрутизации
  4. Метки маршрутизации соответствуют маршрутам по умолчанию и отправляются из соответствующего интерфейса
  5. Если количество WAN-линков более 2 — необходимо проделать такие же действия для остальных подключений.

Итого, теперь у вас настроена балансировка трафика для двух WAN-соединений.

Пожалуйста, расскажите почему?

Нам жаль, что статья не была полезна для вас 🙁 Пожалуйста, если не затруднит, укажите по какой причине? Мы будем очень благодарны за подробный ответ. Спасибо, что помогаете нам стать лучше!

Подпишитесь на нашу еженедельную рассылку, и мы будем присылать самые интересные публикации 🙂 Просто оставьте свои данные в форме ниже.

P.S. Если укажите свою дату рождения, то мы обязательно Вас поздравим и подарим небольшой подарок 🙂

Эти статьи могут быть вам интересны:

Балансировка трафика в Mikrotik между двумя WAN-интерфейсами с учетом входящего трафика

Недавно решил попробовать реализовать простую балансировку трафика между несколькими WAN. Почему именно простую? Я слишком тяжело разбираюсь в больших массивах информации, и подозреваю не один я. Поэтому решил попробовать разработать схему в которой разберется даже новичок, так как мало использовать чужие наработки, нужно знать что и для чего ты делаешь.
Сразу предупреждаю – система имеет много недостатков, например возможны обращения к одному и тому же ресурсу с разных IP, что чревато слетом авторизации. Так что использовать ее лучше всего для подключений которые не чувствительны к source address, тем же торентам например.
И еще, я не буду описывать настройку Микротика с нуля, предполагается что у вас уже есть роутер с двумя ВАНами, на котором заведены уже IP-адреса, локальные порты так же настроенные. И что пользователь боле-менее ориентируется в микротике, хотя бы на уровне того что знает где-какой пункт меню находится.
Для совсем новичков и людей слабо разбирающихся в сетях(можно быть мастером в одном и новичком в другом, ничего необычного в таком не вижу) я разместил пару спойлеров
Итак. Условно примем что:
— локальные адреса у нас лежат в диапазоне 192.168.0.0/16 и подключены к бриджу Localca
— Провайдер1 сидит у нас на интерфейсе WAN1, с шлюзом 10.0.0.1
— Провайдер2 сидит у нас на интерфейсе WAN2, с шлюзом 172.16.25.1
Итак приступим.
Первым делом создадим новые маршруты:

/ip route add disabled=no distance=1 dst-address=192.168.0.0/16 gateway=Localca routing-mark=isp2 scope=30 target-scope=10 add disabled=no distance=1 dst-address=0.0.0.0/0 gateway=172.16.25.1 routing-mark=isp2 scope=30 target-scope=10 add disabled=no distance=1 dst-address=192.168.0.0/16 gateway=Localca routing-mark=isp1 scope=30 target-scope=10 add disabled=no distance=1 dst-address=0.0.0.0/0 gateway=10.0.0.1 routing-mark=isp1 scope=30 target-scope=10
Что такое роуты, они же маршрутыМаршруты это указание роутеру на каком порту или за каким IP-адресом искать нужную подсеть. Без этого роутер не будет знать куда отсылать пакеты. Вот поэтому мы и указали не только шлюзы для интернета но и порт на котором находятся наши локальные адреса
Не переживайте если оно продублирует уже существующие динамические(или же созданые вами) маршруты. Вся соль в роутинг-марках. Все маршруты с роутинг марком это отдельная таблица роутинга, и пакеты ходящие через нее другие таблицы использовать не могут, так что нужно прописать и путь к локальным адресам тоже. В теории когда нет адреса в нужной таблице пакеты могут смотреть дефолтную (не маркированную) таблицу роутинга. Но у меня бывали случаи когда этот принцип не работал, так что лучше перестраховаться
Cоздадим мангл который будет все новые коннекты отправлять на нужный шлюз:
/ip firewall mangle add action=mark-connection chain=prerouting connection-mark=no-mark disabled=no dst-address=!192.168.0.0/16 new-connection-mark=inet_con passthrough=yes add action=mark-routing chain=prerouting comment=multiwan connection-mark=inet_con disabled=no new-routing-mark=isp2 passthrough=no
Первое правило ловит все не промаркированные (а значит новые) коннекты которые идут не в нашу локалку, а следовательно пойдут через WAN интерфейс, и маркирует их нужной меткой. Я выбрал такой подход, так как ВАН интерфейсов у нас несколько, и для каждого пришлось бы создавать отдельное правило с нужным Out. Interface, а так мы ограничились одним правилом. Второе правило коннектам с нужной меткой назначает марк роутинга. Comment служит нам для того что бы мы могли найти это правило скриптом.
mark-routing, для чего онМарк роутинга служит для указания таблицы маршрутизации выбранным пакетам/соединениям. Они будут использовать только те роуты которые несут соответствующий Routing Mark. Таким методом мы можем разный трафик отправлять на разные шлюзы/порты по нужных нам условиях. Все что левее закладки Action в манглах(да и в фильтре и NAT) это фильтр. Так что чем меньше мы критериев укажем тем шире будет охват подпадающего под это правило трафика. Соответственно комбинируя разные условия мы очень точно может отделить нужный нам трафик.
Следующим пунктом мы идем в System-Scripts и создаем новый скрипт вот такого вот содержания:
:global rx1 «0» :global rx2 «0» /interface monitor WAN1 once do={ :global rx1 $(«rx-bits-per-second»); } /interface monitor WAN2 once do={ :global rx2 $(«rx-bits-per-second»); } :local one 20000000 :local two 8000000 :global wan1 ($one / $rx1) :global wan2 ($two / $rx2) if ($wan1>$wan2) do={/ip firewall mangle set new-routing-mark=isp1} else={/ip firewall mangle set new-routing-mark=isp2}
Сначала мы обнуляем переменные, потом получаем в эти переменные данные о загруженности интерфейсов(а конкретно то количество получаемых бит в секунду, за что отвечает параметр rx-bits-per-second). Дальше в переменные one и two вписываем ширину каждого интернет-канала в битах, и получаем обратную(так как микротик не показывает дробную часто то при делении количества бит на ширину мы бы получили 0) относительную загруженность(делим ширину на загруженность в битах). А потом их сравниваем, и если число больше у первого ВАНа то в наш мангл(здесь и пригодился комментарий, по нему мы и обратились к нужному манглу) вписываем роутмарк для ВАН1, иначе к ВАН2.
Теперь дело за малым – задать периодичность исполнения скрипта. Идем в System-Sheduler и добавляем новую задачу с нужным интервалом исполнения, в поле on Event: вписываем
/system script run erazel_balancing
Где erazel_balancing – это имя скрипта в котором мы меняем мангл. Не забудьте поменять на имя вашего скрипта.
Вот теперь мы имеем полностью автоматическую систему балансировки нагрузки на внешние интерфейсы в зависимости от их относительной загруженности.
Ну и остается еще вопрос обращения к серверу с разных внешних адресов. Так что я бы советовал данный подход применять для торентов и других не критично-важных приложений. Просто в первом мангле(который маркирует конекшны ) сделать еще условие по протоколу и порту, ну и продублировать его для разных протоколов/портов. Например: