RouterSCRIPTS — коллекция скриптов для устройств RouterBOARD

Я сталкиваюсь с той же проблемой, что и @paulavalencia. Кто-нибудь может помочь?

Привет, помогите, пожалуйста. Независимо от используемых значений я получаю сообщение: "Provision][Error]: Конфигурация шлюзов для XXXXXXXXX не имеет соответствующего маршрута по умолчанию. [Provision][Error]: Конфигурация шлюзов для XXXXXXXX не имеет соответствующего маршрута по умолчанию. [Provision][Error]: Конфигурация шлюзов некорректна, пожалуйста, проверьте файл конфигурации и попробуйте снова. ****** Вывод скрипта ******** [admin@MikroTik] > /import RouterSCRIPTS_Installer.rsc [RouterSCRIPTS][Info]: Установка завершена. Предполагая, что вы прочитали прилагаемый файл readme, теперь можете удалить ненужные модули, а затем запустить: $provision auto Скрипт загружен и успешно выполнен [admin@MikroTik] > $provision auto [Provision][Info]: Настройка всех доступных модулей. [Provision][Info]: Настройка шлюзов. [Provision][Error]: Конфигурация шлюзов для Vodafone не имеет соответствующего маршрута по умолчанию. [Provision][Error]: Конфигурация шлюзов для Verizon не имеет соответствующего маршрута по умолчанию. [Provision][Error]: Конфигурация шлюзов некорректна, проверьте файл конфигурации и попробуйте снова. [Provision][Info]: Настройка failover. [Provision][Error]: Модуль failover зависит от модуля выбора шлюза, пожалуйста, настройте его и попробуйте снова. [Provision][Info]: Настройка dyndns. [Provision][Info]: Настройка resolver. [Provision][Info]: Настройка livestream. [Provision][Error]: Завершено с ошибками. [admin@MikroTik] >

Привет, Frostbyte, спасибо за скрипт! Очень интересно. Я провожу кое-какие эксперименты, но столкнулся с проблемой — не могу заставить его работать. Как скрипт Failover может проверить доступность WAN-цели через разные вторичные шлюзы, если текущий маршрут по умолчанию на Mikrotik настроен на активный шлюз? То есть, если я пытаюсь пинговать WAN-цель (например, 8.8.8.8) с интерфейса второго шлюза, ответ — таймаут ICMP, хотя у второго шлюза есть полноценное интернет-соединение. ICMP-запрос не выходит через интерфейс второго шлюза, поэтому скрипт считает, что у второго шлюза нет подключения к WAN. Нужно ли с NAT что-то делать? Сейчас я использую src NAT (маскарадинг) на обоих интерфейсах шлюзов. У меня RouterBOARD с двумя интернет-подключениями от разных провайдеров. Можешь помочь? Большое спасибо, с наилучшими пожеланиями!

Дорогой Frostbyte, спасибо за ответ. Я не до конца уверен в назначении опции «interface=» команды ping. По моему мнению, эта опция используется для рекурсивного определения IP-адреса, связанного с указанным интерфейсом, и затем создаёт ICMP-пакет с исходящим IP-адресом этого интерфейса. Однако это не значит, что пинг действительно пойдёт с этого интерфейса, потому что если адрес назначения не в локальной сети, роутер всё равно смотрит на текущий основной шлюз, чтобы решить, куда отправлять пакет и через какой интерфейс. Но я не эксперт по Mikrotik, так что могу ошибаться. Всё это к тому, что в моей небольшой лабораторной сети ваш скрипт, похоже, не способен пинговать целевой хост по второму пути, чтобы проверить связность, и поэтому не переключается на второго провайдера при сбое первого. Не могли бы вы помочь? Большое спасибо! Прикладываю вывод ваших команд, а также команды ping. [admin@MikroTik] > /ip address print detail Флаги: X - отключён, I - некорректный, D - динамический 0 ;;; defconf address=192.168.80.1/24 сеть=192.168.80.0 интерфейс=bridge actual-interface=bridge 1 address=192.168.10.71/24 сеть=192.168.10.0 интерфейс=ether1 actual-interface=ether1 2 address=192.168.88.2/24 сеть=192.168.88.0 интерфейс=ether5 actual-interface=ether5 [admin@MikroTik] > /ip route print detail Флаги: X - отключён, A - активен, D - динамический, C - подключён, S - статический, r - rip, b - bgp, o - ospf, m - mme, B - blackhole, U - недоступен, P - запрещён 0 A S ;;; основная маршрутизация dst-address=0.0.0.0/0 шлюз=192.168.10.1 статус-шлюза=192.168.10.1 доступен через ether1 distance=1 scope=30 target-scope=10 1 S ;;; основная маршрутизация dst-address=0.0.0.0/0 шлюз=192.168.88.1 статус-шлюза=192.168.88.1 доступен через ether5 check-gateway=ping distance=4 scope=30 target-scope=10 2 ADC dst-address=192.168.10.0/24 pref-src=192.168.10.71 шлюз=ether1 статус-шлюза=ether1 доступен distance=0 scope=10 3 ADC dst-address=192.168.80.0/24 pref-src=192.168.80.1 шлюз=bridge статус-шлюза=bridge доступен distance=0 scope=10 4 ADC dst-address=192.168.88.0/24 pref-src=192.168.88.2 шлюз=ether5 статус-шлюза=ether5 доступен distance=0 scope=10 [admin@MikroTik] > $provision auto [Provision][Info]: Выполняется Provisioning для всех доступных модулей. [Provision][Info]: Выполняется Provisioning шлюзов. [Provision][Info]: Выполняется Provisioning отказоустойчивости. [admin@MikroTik] > $failover check SEQ HOST SIZE TTL TIME STATUS 0 8.8.8.8 56 57 12ms отправлено=1 получено=1 потеря пакетов=0% min-rtt=12ms avg-rtt=12ms max-rtt=12ms SEQ HOST SIZE TTL TIME STATUS 0 8.8.8.8 таймаут отправлено=1 получено=0 потеря пакетов=100% [admin@MikroTik] > ping 8.8.8.8 interface=ether5 SEQ HOST SIZE TTL TIME STATUS 0 8.8.8.8 таймаут 2 8.8.8.8 таймаут 3 8.8.8.8 таймаут 4 8.8.8.8 таймаут 5 8.8.8.8 таймаут

Привет, Frostbyte, спасибо ещё раз за твою помощь и объяснения. Как только смогу, сделаю несколько тестов и дам тебе знать.

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

Ответ №1: Если у вас только один интернет-шлюз/подключение, то нет. Если только вы не собираетесь провести тест "proof of concept", который можно сделать, используя/настраивая несколько устройств/виртуальных машин MikroTik. Технически вам нужно как минимум два разных интернет-шлюза/подключения, чтобы обеспечить нормальный отказоустойчивый режим. Иного смысла в этом нет, уверен, вы понимаете почему. Кроме того, алгоритм настройки явно запрещает дублирование значений в WANNames и WANGateways, так что обойти это, введя одинаковую информацию дважды в конфигурационном файле, не получится.

Ответ №2: Если у вас два или больше разных интернет-шлюза/подключения, но доступных через один и тот же интерфейс или в одной подсети, вам всё равно придётся разделить их на разные подсети и интерфейсы (мосты и VLAN тоже допустимы). Такое ограничение связано с тем, что иначе нечётко различать доступные шлюзы при проверке каждого из них на доступ в интернет – скрипты будут путаться. Согласно документации на github: можно иметь только один шлюз на подсеть. Несколько шлюзов через один мост или основной интерфейс не поддерживаются.

Отказ от ответственности: Если вы хотите использовать функцию балансировки модуля шлюза, предположим, что помимо наличия двух разных интернет-шлюзов/подключений вы хорошо разбираетесь в настройке PCC Load Balancing, чтобы достичь желаемого результата. Потому что вся эта опция всего лишь включает или выключает (с учётом сбоев в интернете) правила mangle с соответствующим префиксом комментария (заданным в конфигурационном файле).

В такой ситуации, если использование скриптов — это желаемая цель, есть два варианта на рассмотрение:  
Подключить GW1 и GW2 к двум разным физическим портам устройства RouterBoard.  
Пропускать GW1 и GW2 как тегированные VLAN через один физический порт устройства RouterBoard.  

На данный момент я совершенно не в курсе вашей точной физической схемы и почему вы просто не подключаете CPE1 к одному физическому порту RouterBoard, а CPE2 — к другому. Это, кажется, самый простой способ как с физической, так и с конфигурационной точки зрения (просто не забывайте: разные подсети, разные интерфейсы).  

Теперь, если есть какая-то сложность или особенность, о которой я не знаю (а скорее всего, не знаю), давайте исходить из схемы, которую вы нарисовали выше. Я бы не считал вариант №2 избыточным (потому что в этом случае у вас будет один кабель, и занятый один физический порт RouterBoard, а не два). Правда, нужно будет убедиться, что суммарная пропускная способность GW1 и GW2 не превышает скорость порта RouterBoard, к которому вы подключаетесь (чтобы избежать потенциального узкого места).  

Если вы решите подключать GW1 и GW2 как тегированные VLAN через один и тот же физический порт RouterBoard, то дальше всё просто:  
Вы создаёте два VLAN, каждый со своим VLAN ID (тем самым, с которым вы тегировали их на другой стороне), и указываете физический порт, через который они проходят, в качестве интерфейса (в вашем случае RouterBoardETH1).  
Далее заходите в IP > Address и назначаете соответствующие адреса и маски подсетей для каждого созданного VLAN (не забывайте, что подсети должны быть разными).  
В конце заходите в IP > Route и создаёте два маршрута (обязательно внимательно посмотрите документацию на github, так как параметры distance и содержимое комментариев в этом шаге важны).