Контакты
Аккаунт
Избранное
Корзина
Стабильный интернет становится все более важным, особенно во время COVID19, когда большая часть населения вынуждена работать удаленно. Одним из действий, обеспечивающих доступ к Интернету, является приобретение подключения у второго оператора, многие здесь решают выбрать доступ в виде LTE-соединения.
Уже было много идей, как управлять вторым звеном, которое в принципе должно быть только резервным. К сожалению, ни одно решение не оправдало моих ожиданий, хотя все они "работали".
В поисках вдохновения я наткнулся на статью Тимо Пуистай, опубликованную в 2017 году на сайте Server Management. Описанный способ обнаружения связи путем расширения и манипулирования маршрутизацией оказался достаточно эффективным, но он не смог обнаружить сбои связи, когда происходят потери пакетов или резкое увеличение времени передачи пакетов по основному каналу. Я решил расширить эту идею для всех своих нужд.
Нажмите, чтобы увеличить!
Принцип работы основан на использовании инструмента Netwatch, реализованного в MikroTik RouterOS с поддержкой скриптов и дополнительной проверки путем расширения маршрута маршрутизации и проверки доступности шлюза по умолчанию.
/системный скрипт
add dont-require-permissions=no name=NetWatch-check owner=admin policy=\
reboot,read,write,policy,test source="#Здесь вы можете изменить значение.\r\
\n#количество времени в минутах, в течение которого ссылка BACKUP является предпочтительной.\r\
\n# позже мы проверим, работает ли основная ссылка должным образом.\r\
\n#\r\
\n:global nwwait 15;\r\
\n# Оставить без изменений.\r\
\n:global nwgw2;\r\
\n:tonum nwgw2;\r\
\n:local nwstatus;\r\
\n:local nwgwstatus;\r\
\nset nwgwstatus ([/tool netwatch get value-name=status [find comment=\
\"NetWatch\"]]);\r\
\nset nwstatus ([/ip route get value-name=distance number=[/ip route f\
ind comment=\"BACKUP\"]]);\r\
\n:if (\$nwstatus = \"6\") do={\r\
\nset nwgw2 (nwgw2 + 1)\r\
\n}\r\
\n:if ((\$nwgw2 > \$nwwait) and (\$nwgwstatus = \"up\")) do={ :log err\
or \"Master GW: OK\"\r\
\n/ip route set [find comment=\"BACKUP\"] distance=66;\r\
\nset nwgw2 (0)\r\
\n}\r\
\n"
add dont-require-permissions=no name=NetWatch owner=admin policy=\
reboot,read,write,test source="/log error \"Master GW: PROBLEM\"\r\
\n/ip route set [find comment=\"BACKUP\"] distance=6\r\
\n\r\
\n"
add dont-require-permissions=no name=NetWatch-init owner=admin policy=\
ftp,reboot,read,write,policy,test,password,sniff,sensitive,romon \
source="#количество проверок перед переключением соединения\r\
\n:global nwwait 20;\r\
\n"
NetWatch - сценарий, который будет выполняться в случае отказа основного канала связи
NetWatch-check - скрипт, временно проверяющий переключение обратно на основную ссылку, в этом скрипте мы можем определить, как долго ссылка BACKUP с момента переключения будет оставаться ведущей ссылкой, прежде чем мы проверим, работает ли уже основная ссылка должным образом. В ситуации по умолчанию это 15 минут.
Следующим шагом является определение времени выполнения сценариев.
/system scheduler
add interval=1m name=NetWatch on-event=\
"/system script run NetWatch-check\r\
\n" policy=\
ftp,reboot,read,write,policy,test,password,sniff,sensitive,romon \
start-date=apr/11/2020 start-time=17:31:44
Пришло время настроить инструмент Netwatch от Mikrotik. вместо A.B.C.D введите адрес шлюза по умолчанию основного канала. Мы можем указать значение тайм-аута, насколько чувствительным будет обнаружение отказа основного канала.
/tool netwatch
add comment=NetWatch down-script="/system script run NetWatch\r\
\n" host=A.B.C.D interval=5s timeout=100ms
Наконец, необходимо настроить маршрутизацию, здесь мы используем трюк с расширенным маршрутом и проверкой доступности шлюза по умолчанию. Введите адрес шлюза по умолчанию основного канала вместо A.B.C.D и адрес шлюза по умолчанию резервного канала вместо E.F.G.H. BACKUP.
/ip-маршрут
add comment=MASTER distance=10 gateway=10.255.66.1
add comment=BACKUP distance=66 gateway=10.255.67.1
add check-gateway=ping distance=1 dst-address=10.255.66.1/32 gateway=
208.67.220.220 scope=10
add check-gateway=ping distance=1 dst-address=10.255.66.1/32 gateway=10
8.8.8.8 scope=10
add check-gateway=ping distance=1 dst-address=10.255.67.1/32 gateway=
208.67.222.222 scope=10
add check-gateway=ping distance=1 dst-address=10.255.67.1/32 gateway=
8.8.4.4 scope=10
add distance=1 dst-address=8.8.4.4/32 gateway=E.F.G.H scope=10
add distance=1 dst-address=8.8.8.8/32 gateway=A.B.C.D scope=10
add distance=1 dst-address=208.67.220.220/32 gateway=A.B.C.D scope=10
add distance=1 dst-address=208.67.222.222/32 gateway=E.F.G.H scope=10
Мы используем популярные ip-адреса dns-сервисов Google (8.8.8.8, 8.8.4.4) и OpenDNS (208.67.220.220, 208.67.222.222), которые мы проверяем на достижимость данным оператором. Если доступно, активируется шлюз по умолчанию для данного соединения.
В приведенном выше решении мы использовали двойную проверку правильности работы интернет-канала, один раз проверяя шлюз по умолчанию основного канала и дополнительно проверяя доступность хостов "далеко в интернете", достигаемых с определенных каналов.
Это решение имеет некоторое ограничение, в случае, когда один из операторов меняет параметр шлюза по умолчанию во время перезаключения соединения, мы не можем настроить его напрямую.
В этом случае для данного подключения необходимо использовать отдельный маршрутизатор, как показано на рисунках ниже, и указать его в качестве шлюза подключения.
Нажмите, чтобы увеличить!
Нажмите, чтобы увеличить!
Я убежден, что решение может быть улучшено и доработано, подготовленные мной скрипты могут быть написаны по-другому, сохраняя основной принцип решения.
Для дальнейшего обсуждения этой темы, пожалуйста, посетите наш ФОРУМ, где вы можете поделиться своими настройками и комментариями по этой теме со всем сообществом.
