Определение интернет-соединения

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

Проблема с Netwatch: у Netwatch есть ограничения при тестировании отдельных интерфейсов, в отличие от ping. Хотя можно использовать Netwatch вместе с правилами IP-маршрутизации, чтобы добиться похожего результата, мне этот способ показался слишком запутанным. Принудительное направление трафика к конкретному IP через определённый шлюз лишь усложняет настройку без необходимости.

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

Благодаря команде, упомянутой в одном из предыдущих постов, мне удалось написать простой скрипт, который использует /interface detect-internet state для мониторинга состояния интерфейсов и соответствующей реакции.

Сценарий использования: в моей конфигурации я хочу, чтобы вторичный роутер включался только тогда, когда основной WAN/интернет-ссылка не работает. Как только основной канал восстанавливается, вторичный роутер должен отключаться. Такой подход помогает экономить трафик и электроэнергию, так как резервный роутер имеет ограниченные ресурсы. Это скорее актив-ожидание (active-cold/standby), что идеально подходит под мои задачи. Хотя на подключение вторичного канала уходит несколько минут, выигрыш в эффективности того стоит.

Вот скрипт, который я использую:

:local primaryState [/interface detect-internet state get [find name="pppoe0"] state]
:local backupState [/interface detect-internet state get [find name="ether2"] state]
:local powerState [/interface ethernet poe get ether2 poe-out]

# Когда основной WAN недоступен  
:if ($primaryState != "internet") do={  
   # Проверяем, что ether2 не включён по питанию  
   :if ($powerState != "auto-on") do={  
       /interface ethernet poe set ether2 poe-out=auto-on  
       /log info "IntelliFailover: PPPoE интерфейс (pppoe0) ОТКЛЮЧЁН"  
       /log info "IntelliFailover: Переключение на резервное соединение (ether2)"  
   }  
} else={  
   # Когда основной WAN восстановлен, проверяем наличие интернета на обоих интерфейсах  
   :if ($primaryState = "internet" && $backupState = "internet") do={  
       # Проверяем, что ether2 включён  
       :if ($powerState != "off") do={  
           /interface ethernet poe set ether2 poe-out=off  
           /log info "IntelliFailover: PPPoE интерфейс (pppoe0) ВОССТАНОВЛЕН"  
           /log info "IntelliFailover: Восстановление основного соединения (pppoe0)"  
       }  
   }  
}

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

Я не уверен, что стоит автоматически добавлять интерфейс в список WAN или LAN. Чтобы использовать detect-internet, у вас уже должны быть определены интерфейсы как WAN. А поскольку detect-interface-list=WAN, он всё равно никогда не найдёт LAN. Добавление чего-то в стандартный список LAN или WAN может привести к разным побочным эффектам, которые нужно учитывать, так как firewall использует эти списки в качестве критериев. Поэтому, если вы не используете состояние detect-internet в правилах файрвола, вообще не нужно ничего задавать (оставьте пустым), кроме detect-interface-list=WAN для вашего скрипта.

Если хотите использовать функцию «добавления интерфейса в список» для новых правил файрвола, лучше сделать это через отдельные списки, например internet-interface-list=DETECTED_WAN, lan-interface-list=DETECTED_LAN, wan-interface-list=DETECTED_WAN — а не через все переменные сразу. К тому же их лучше делать локальными (:local), а не глобальными (:global), если скрипт запускается из /system/scheduler и вы не используете переменные в других скриптах (там нужны бы были :global).

На самом деле, не нужен даже «value name=» — просто используйте [/interface/detect-internet/state get $id name], это работает так же, но короче.

:global> :local ms [:pick $ifaceRTT 9 12];
:set ifaceRTT ($ms . “ms”);

Наверно, это работает нормально. Но RTT может быть равен 0 или чему-то другому, так что использовать [:pick] без «защиты» не лучшая идея… Но для письма — если показывается только «ms», это уже сигнал о проблеме.

Не уверен, что многие решались использовать, тем более писать скрипты с /interface/detect-internet. Но для уведомлений на почту — это простой и удобный способ проверить интернет.

Отказ от ответственности: не рекомендую использовать /internet/detect-internet для принятия маршрутизационных решений или переключения на резервный канал — для этого есть более надёжные методы. И detect-internet может вызывать побочные эффекты — об этом и в документации MT предупреждают, хотя многие из них довольно тонкие и порой неожиданные.

В общем, просто использовать «detect-interface-list=WAN» относительно безопасно, но если detect-interface МОЖЕТ МЕНЯТЬ ваши списки интерфейсов WAN или LAN (или добавлять DHCP клиентов), вот тут начинаются проблемы. Если интерфейс объявлен как WAN в /interface/list, он должен иметь IP-адрес или DHCP клиента, если вы явно назначаете интерфейс WAN, тогда «автоматический DHCP клиент» проблем не создаст.

Нет, я думаю, это вполне разумный подход. Я использую /interface/detect-internet в стандартной конфигурации с detect-interface-list=WAN, так как мобильное приложение Mikrotik показывает статус интернета прямо на главном экране... И да, это «безопасно», если не устанавливать «три нижних атрибута» в detect-internet, потому что они записывают обнаруженный интерфейс в список адресов — насколько я понимаю, ты это уже исправил. detect-interface-list= просто ЧИТАЕТ список интерфейсов, один атрибут отвечает за то, что «проверяется на наличие интернета», но не меняет никакие списки интерфейсов. Поэтому типичная ошибка — когда кто-то ставит все четыре параметра, а на самом деле нужен только detect-interface-list=WAN (или твой собственный список интерфейсов для проверки). Вторая распространённая ошибка — включать в detect-interface-list известные LAN (или другие внутренние) сети, чего делать не стоит, и с этим у тебя всё в порядке.

Что касается скрипта, если хочешь именно миллисекунды... RTT — это тип «время», так что можно конвертировать напрямую в наносекунды (а потом в миллисекунды), что, вероятно, точнее, чем разбирать строку (или, по крайней мере, устойчивее к будущим изменениям в выводе скриптов). Но я почти уверен, что твой существующий код работает нормально. Просто для информации:

:local ms [:pick $ifaceRTT 9 12];
:if ([:len $ms] = 0) do={ :set ms “No RTT”; }
:set ifaceRTT ($ms . “ms”);

можно заменить на

:set ifaceRTT "$[([:tonsec $ifaceRTT]/(1000*1000))]ms"

Думаю, можно добавить ещё одно письмо, когда detect-internet переключается в состояние “WAN”. Это происходит, если пингуется DNS от Google 8.8.8.8, но недоступны серверы Mikrotik (через UDP). Приложение в таком случае показывает что-то вроде “Интернет (Ограничен)”, когда в состоянии WAN, а если “Internet state”, то просто “Интернет: Хорошо” (или что-то в этом духе). Так что можно обработать и состояние “WAN” (например, в тексте):

:if ($ifaceState = “wan”) do={/tool e-mail send to=“mail@gmail.com” subject=("Ограниченный интернет на " . $ifaceName) body=$emailBody;} else={/tool e-mail send to=“mail@gmail.com” subject=("Ограниченное соединение на " . $ifaceName . " Семья начнёт жаловаться — беги прочь!") body=$emailBody;}}

Да, это был мой единственный момент — обычно «wan» означает, что интернет есть. Например, раньше в /ip/cloud иногда случались кратковременные сбои, из-за чего что-то, что обычно в состоянии «internet», переходило в состояние «wan». Как уведомлять — это уже на ваше усмотрение, я просто хотел привести конкретный пример, подкорректируйте под свои нужды.

Еще на что стоит обратить внимание: например, в состоянии «WAN» пинг до 8.8.8.8 работает, тогда как в состоянии «Internet» можно передавать данные через UDP на Mikrotik. В detect-internet не хватает функции определения типа NAT, а это полезно, чтобы понимать, CGNAT это или другая схема NAT, потому что состояние «WAN» может появляться при работающем интернете в зависимости от того, что делает провайдер.

Игровые консоли часто показывают какой-то «тип NAT» — это было бы полезно в RouterOS, но пока нет. Всё правда.

Еще есть узкополосный LTE, который поддерживает KNOT, и такие SIM-карты довольно дешевые в месяц, так как трафик ограничен.

Также есть LoRaWAN для таких уведомлений, который поддерживают KNOT/LtAP и подобные. Конечно, нужно больше настроек, оборудования, конфигураций, скриптов… В общем, всегда можно найти решение, если что-то действительно важно.