Сегодня хочу поговорить о резервирование WAN-канала на Mikrotik.
Содержание
Вводная часть
Рассказываю о том, как я настраиваю резервирование у клиентов.
Нам потребуется два провайдера. В нашем примере будет вот так:
- Провайдер#1 (ISP1) по кабелю вставлен в Eth 1, даёт статические настройки;
Условные настройки провайдера для нашего примера:
IP: 68.16.108.224
Maska: 255.255.255.0
Gate: 68.16.108.221 - Провайдер#2 (ISP2) это обычный USB-LTE модем;
Условные настройки провайдера для нашего примера:
Настройки прилетают по DHCP
Немного теории
Проверять будем через инструмент Netwatch. Данные инструмент проверяет доступность заданных IP-адресов. Проверка происходит в заданном интервале. Далее выполняются два скрипта один в случае доступности IP-адреса (UP), второй в случае доступности (Down).
Нам потребуется ресурс с высокой доступностью.
Я видел, что некоторые специалисты рекомендуют использовать шлюз провайдера, но мне такой способ не нравится. Может быть такая ситуация, что шлюз доступен, а интернета нет.
В примере я буду использовать IP-адрес 1.1.1.1;
Нам потребуется:
- Статичные маршруты 0.0.0.0/24 до провайдерских шлюзов;
Что будет, если это не сделать: нам необходимо подписать через комментарии наши маршруты. Если не сделать статический маршрут, то может потеряться комментарий и Netwatch просто не отработает. - Статичный маршрут для провайдера#1 до 1.1.1.1;
Что будет, если это не сделать: наш Netwatch отработает ровно 1 раз. Далее он не сможет перейти в режим UP из-за того, что пинги не проходят от провайдера до 1.1.1.1. Маршрута то нет… :) - Правило FireWall, которое запрещает нашему LTE-модему пинговать 1.1.1.1;
Что будет, если это не сделать: в случае обрыва связи у провайдера#1 Netwatch сработает и переведёт в режим Down, но из-за того, что адрес доступен (по интерфейсу LTE), то он опять перейдёт в режим UP. Таким образом мы будем всё время переключаться с рабочего интернета по LTE на нерабочий от нашего основного провайдера.
Звучит несложно. Делается тоже просто. От слов к практике.
Настройка резервирования на MikroTik
Предоположительно, что у Вас настроены оба провайдера на выход в интернет.
Но я хочу уточнить, что при настройке Dhcp-клиента на lte должна быть отключена Add Default Route.
Что будет, если это не сделать: маршрут, который создается автоматически при переподключение LTE теряется комментарий и Netwatch не срабатывает. Если пока не понимаете про что речь, то не переживайте. Ещё чуть-чуть и поймете зачем нужен этот комментарий.
Поэтому смело отключаем дефолтный маршрут и идём дальше.
Статичные маршруты до провайдерских шлюзов
Маршрут провайдера#1
Из нашего примера у провайдера#1 шлюз 68.16.108.221, поэтому создаём маршрут 0.0.0.0/0 до 68.16.108.221. По идеи, у Вас он уже есть и чаще всего этот шаг можно пропустить. Если данный маршрут есть, то нужно только поставить комментарий «ISP1«.
Переходим в IP->Routes. Добавляем обычный маршрут. Вешаем комментарий ISP1.
Маршрут провайдера#2
Для того, что создать маршрут надо сначала определить шлюз. Для этого переходим IP->DHCP Client->lte1->Status.
Возвращаемся в IP->Routes и создаём маршрут для нашего lte. Я его создаю обычно по кнопке Disable, чтобы маршрут был по умолчанию выключен.
Статичный маршрут для проверки
Всё в том же IP->Routes создаём маршрут от провайдера#1 до 1.1.1.1. Зачем это нужно я писал в самом начале.
Запрет пинга через LTE
Переходим в IP->FireWall и создаём правило, которое запрещает пинги до 1.1.1.1 с нашего USB-модема.
Создаём правило.
Chain: Output; Мы работаем с запросами наружу;
Dst. Address: 1.1.1.1; то, наша цель;
Ptotocol: 1 (icmp); мы запращеаем только пинги;
Out. Inteface: lte1;
В Actions прописываем возврат и выбираем с чем будет возвращаться.
Настройка Netwatch
Переходим Tools->Netwatch и создаём зачем будем следить.
Host: наша цель, что мы проверяем доступность (следовательно и интернет);
Interval: периодичность выполнения проверки;
TimeOut: время, которое мы ждём, чтобы признать ресурс недоступным;
Status: тут у нас будет вывод состояния Up или Down;
Since: будет написано, когда создано правило;
На вкладке Up пишем скрипт, который будет выполняться в случае доступности. В данном примере мы включаем маршрут основго провайдера, а маршрут LTE-выключаем. И удаляет все имеющиеся подключения.
1 2 3 |
/ip route set [find comment="ISP1"] disabled=no /ip route set [find comment="ISP2"] disabled=yes foreach i in=[/ip firewall connection find] do={/ip firewall connection remove $i} |
На вкладке Down прописываем обратный скрипт. Который выключает маршрут основного провайдера и включаем маршрут LTE. И удаляет все имеющиеся подключения.
1 2 3 |
/ip route set [find comment="ISP1"] disabled=yes /ip route set [find comment="ISP2"] disabled=no foreach i in=[/ip firewall connection find] do={/ip firewall connection remove $i} |
Итог
Вот и вся настройка. Кто как будет проверять работоспособность этого решения каждый будет решать сам за себя.
Данный способ можно протюнить. Например, в скрипты добавить отправку об инциденте по email, telegram или записывать в log. Или включить пищалку. В общем, фантазия тут безграничная.
Субъективно — скриптами рулить такой функционал есть зло. Я бы использовал для резервного маршрута метрику с бОльшим весом