что такое резервный канал

Резервирование канала в Микротик с lte модемом и переключение провайдера

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

Данная статья является частью единого цикла статьей про Mikrotik.

Введение

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

Распределенная сеть филиалов была настроена очень просто, на базе дефолтной конфигурации микротика. Не было никакого объединения в единую сеть, мониторинга и т.д. Все устройства работали сами по себе, просто обеспечивая доступ в интернет на месте. Задача была сделать резервирование основного канала в интернет максимально быстро и просто, чтобы не требовалось какое-то обслуживание или дополнительная настройка.

2-й провайдер через lte usb модем

В качестве резервного провайдера было принято решение использовать lte модемы. Качество связи через них было приемлемое. Тарифные планы доступные, стоимость модемов невысокая. Mikrotik поддерживает большое количество usb модемов, так что не составляет труда подобрать подходящий вариант. Лично я сами модели 4g модемов не видел, так как настраивал все удаленно. Использовались различные устройства и производители. В рамках задачи по настройке резервирования это не принципиально, так как предложенный мной метод работает одинаково успешно практически с любым резервным провайдером. Не важно, будет ли он через usb модем или по проводу.

Самодельный Mikrotik Wan Failover на 2 провайдера

Рассказываю, как будет работать мой импровизированный wan failover в mikrotik на два провайдера. Я использую скрипт, который выполняет следующие действия:

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

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

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

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

Теперь проверим связь через каждый канал:

Если хотите на 100% убедиться, что пинги идут каждый по своему каналу, можете использовать свои сервера, запустив там tcpdump. Я время от времени делал проверки, когда нужно было наверняка знать внешний ip адрес каждого интерфейса. Иногда не было другой возможности, так как я все настраивал удаленно и информации о конкретных настройках интернета у меня не было.

В целом, понять что соединения идут по разным интерфейсам можно и по отклику. На интерфейсе lte1 задержки будут значительно больше.

Дальше убеждаемся, что для каждого провайдера настроен статический дефолтный маршрут. И обязательно каждый из них помечаем комментарием. Можно пометить их как main и reserver, можно как-то еще. Я лично просто имя интерфейсов писал. Далее они будут использоваться в скрипте. Маршрут для резервного канала сразу отключаем.

Скрипт в процессе эксплуатации (пару месяцев тестов на паре десятков филиалов) претерпевал различные изменения, пока не получился подходящий для моей ситуации вариант. Немного поясню некоторые моменты.

Все остальное вроде бы понятно и так, при обычном осмотре скрипта. Пингуем, смотрим, прошли ли пинги. Если нет, переключаемся, если да, то ничего не делаем. Принцип достаточно простой. Его можно встретить в огромном количестве статей в интернете на тему mikrotik failover. Я только добавил сброс соединений и записи в лог файл.

Сохраните этот скрипт и запустите. Очень рекомендую это делать, имея физический доступ к устройству. Если что-то пойдет не так, доступ к микротику потеряете. У меня один раз такое случилось еще в момент подготовки и тестирования этого решения. Потом уже наловчился, все моменты проработал и настраивал все удаленно. Ни одного фейла не было, чтобы на устройстве совсем пропал интернет. Пару раз пришлось звонить на место и через AnyDesk или TeamViewer подключаться локально к микротику.

Страховал себя следующим образом. Добавлял еще один скрипт:

Запускал его и выполнял все потенциально опасные действия. Если все хорошо и связь не пропадала, то прерывал выполнение скрипта на вкладке Jobs.

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

Вот и все. Переключение на резервного провайдера настроено. Если интернет через основной wan интерфейс перестанет работать, произойдет переключение на lte интерфейс.

Заключение

Еще раз напоминаю, что это мой опыт и мое решение по резервированию канала. Я не претендую на уникальность или best practice. Данный способ мной использовался не раз. Основные удобства следующие:

В данном проекте я все Mikrotik объединил в единую vpn сеть для удобного управления. Настроил мониторинг микротиков, в том числе и переключение провайдеров. А так же сделал сбор логов с них в единый сервер. Все это существенно упростило обслуживание и управление распределенной филиальной структуры.

Источник

Записки IT специалиста

Технический блог специалистов ООО»Интерфейс»

Резервирование каналов в Mikrotik при помощи рекурсивной маршрутизации

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

Как показывает читательский отклик, маршрутизация для многих администраторов является достаточно сложной темой. Тем не менее если вы внимательно выполните все инструкции данной статьи, то всё будет работать. Однако слепое выполнение инструкций не добавляет понимания происходящих процессов и, если что-то пойдет не так вы окажетесь в весьма затруднительном положении, поэтому перед тем, как перейти к практике мы выполним небольшой теоретический ликбез.

Теория

Действительно, маршрутизация достаточно сложная тема, поэтому мы сознательно упростили многие моменты для того, чтобы обеспечить понимание процессов начинающими в объеме необходимом для решения поставленной задачи.

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

Для каждого узла маршрута, а наш роутер является одним из них, решение о маршрутизации принимается на основании таблицы маршрутизации. Рассмотрим ее простейший вариант, за основу мы взяли стандартный вывод в терминале Mikrotik и добавили дополнительные данные, сейчас они могут быть непонятны, но ниже мы будем к ним обращаться.

Прежде всего разберемся как заполняется таблица маршрутизации. Это может происходить несколькими способами:

К одной цели могут вести несколько маршрутов, приоритетом их выбора является значение административной дистанции, чем ниже это значение, тем выше приоритет у маршрута. Если вернуться к нашей аналогии с навигатором, то он может проложить нам несколько маршрутов, но приоритет получит самый короткий. Но если на этом маршруте возникнут серьезные затруднения, скажем, пробка или авария, то мы можем выбрать более длинный маршрут. Также и здесь, если маршрут с наименьшей административной дистанцией недоступен, то выбирается маршрут с более высокой дистанцией.

Теперь разберемся как все это работает. Допустим мы хотим обратиться к узлу 8.8.8.8, роутер берет таблицу маршрутизации и осуществляет в ней поиск наилучшего маршрута к запрашиваемому узлу. В нашем случае искать особо нечего и это будет «нулевой» маршрут со шлюзом 192.168.3.1. Но маршрутизаторы крупных сетевых узлов могут содержать тысячи и десятки тысяч маршрутов и поэтому поиск может оказаться совсем не простым и дешевым действием.

Коротко напомним о том, что такое «нулевой» маршрут или шлюз по умолчанию, он используется в том случае, если в таблице для узла назначения не было найдено ни одного подходящего маршрута. Проще говоря, если роутер не знает куда отправить данные, он отправляет их шлюзу по умолчанию. Особой записи для узла 8.8.8.8 в нашей таблице нет, поэтому будет использоваться «нулевой» маршрут.

В нашем случае основной задачей маршрутизатора будет определить интерфейс выхода, т.е. куда именно физически нужно направить данные, чтобы они добрались до требуемого места назначения. Поэтому роутер снова начинает поиск в таблице маршрутизации чтобы определить каким образом следует добраться до искомого адреса шлюза 192.168.3.1, согласно таблице, будет найден маршрут к сети 192.168.3.0/24 через интерфейс ether5. Так как интерфейс выхода определен, то поиск прекращается и роутер формирует необходимый тип данных для передачи на канальном уровне.

Здесь тоже следует дать краткие пояснения, если интерфейс выхода является сетью Ethernet, то роутер выполнит ARP-запрос для адреса шлюза и сформирует Ethernet-кадр, а если это туннельный интерфейс точка-точка (VPN, PPPoE), то выполнит инкапсуляцию IP-пакета и отправит его на другую сторону туннеля.

И здесь мы приходим к следующим соображениям: таблица маршрутизации может быть большая и поиск по ней может быть затратным, в тоже время шлюз будет располагаться в одной из непосредственно присоединенных сетей, возможно следует ограничить поиск только по ним?

По умолчанию данные опции имеют следующее значение:

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

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

Давайте рассмотрим следующую таблицу маршрутизации:

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

Теперь разберемся как это работает. Когда мы хотим связаться с каким-либо узлом в сети интернет маршрутизатор выполнит поиск по таблице маршрутизации и, если не указано иных маршрутов, выберет «нулевой» в котором указан шлюзом 1.1.1.1, так как найден адрес, то поиск будет продолжен, чтобы определить интерфейс выхода. Так как указанный нами шлюз не находится ни в одной из непосредственно присоединенных сетей, то сделать это не удастся и такой маршрут работать не будет.

Практика

Будем считать что на вашем роутере уже настроен доступ к двум провайдерам и мы не будем останавливаться на этапе базовой настройки, если вы испытываете затруднения с этим, то обратитесь к нашей статье: Базовая настройка роутера MikroTik.

Перед тем, как переходить к дальнейшим настройкам нам нужно выяснить и запомнить адреса шлюзов провайдеров, для этого можно заглянуть на закладку Nexthops, для коммутируемых подключений (VPN, PPPoE) следует проверить свойства соответствующего соединения.

Внимание! Дальнейшие действия следует производить имея физический доступ к устройству!

После этого доступ в интернет по обоим каналам пропадет. Имейте это ввиду при планировании работ.

Эти же действия через терминал:

Затем добавим два рекурсивных «нулевых» маршрута. Для первого провайдера:

Для второго провайдера:

То же самое быстро в терминале:

Теперь таблица маршрутизации будет выглядеть следующим образом:

Наши маршруты добавились как рекурсивные и активным является маршрут через основного провайдера. Теперь имитируем аварию у первого провайдера, буквально через 10-20 секунд таблица маршрутизации изменится и рабочим станет маршрут через резервный канал:

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

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

Рекурсивная маршрутизация и PPPoE

При использовании PPPoE подключения вы рано или поздно столкнетесь с проблемой изменения адреса шлюза провайдера, это может произойти даже при наличии выделенного IP адреса. После чего маршрут к высокодоступному узлу перестает работать, что приводит к полной неработоспособности этого провайдера. Диагностика такой неисправности может оказаться весьма затруднительной если вы не сталкивались с данной проблемой ранее и недостаточно четко представляете себе принципы работы рекурсивных маршрутов.

Чтобы этого избежать используем одну небольшую хитрость. Вспомним, о чем мы говорили в теоретической части. При использовании PPPoE соединения адрес шлюза провайдера роутеру как таковой не нужен. Он используется только для определения интерфейса выхода. Для работы протокола PPP, который лежит в основе PPPoE, IP-адреса не требуются. Это дает возможность самостоятельно присвоить произвольный адрес для удаленного конца туннеля и использовать его в качестве шлюза.

В терминале это можно сделать так:

После чего назначим этот профиль вашему PPPoE соединению:

И после его перезапуска убедимся, что удаленный адрес соединения теперь соответствует назначенному нами:

Теперь можно использовать данный адрес как шлюз для этого провайдера, не беспокоясь о возможных изменениях.

Рекурсивная маршрутизация и DHCP

Описанная выше проблема актуальна и для провайдеров, выдающих настройки по DHCР, в том случае если у клиента нет выделенного IP-адреса, текущий адрес может быть назначен из нескольких диапазонов, а следовательно, будет изменен и адрес шлюза. В отличие от PPPoE здесь мы не сможем задать произвольный адрес, поэтому нам на выручку придут скрипты.

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

Теперь при каждом новом получении адреса по DHCP скрипт будет находить наш маршрут и изменять в нем значение шлюза на реально полученный адрес. Попробуем смоделировать данную ситуацию и выдадим нашему роутеру адрес первого провайдера из другого диапазона. Как видим, все автоматически изменилось согласно вновь полученных настроек:

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

Дополнительные материалы:

Mikrotik

The Dude

Помогла статья? Поддержи автора и новые статьи будут выходить чаще:

Или подпишись на наш Телеграм-канал:

Источник

Автоматическое резервирование канала в интернет для маленького офиса

Что есть

Офис, сеть, 15 компьютеров ну файловый сервер еще. Роутер ASUS RT-AC56U, 4G/3G USB модем Huawei E392. Провайдер проводного интернета, скорость 100 Мб/с. В качестве резервного канала — Йота. Еще есть в здании пара других проводных провайдеров, можно как резервный канал рассмотреть другого провайдера.

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

Что нужно

1. Чтобы в случае, если у основного провайдера падает соединение с интернетом, автоматически поднималось резервное соединение.
2. Хорошо, чтоб когда у основного провайдера восстанавливается соединение с интернетом — происходило переключение обратно на основное соединение.
3. И в идеале, чтоб каким-то образом происходило оповещение о переходе на резервный канал (хотя и не обязательно)
4. Чтобы все это стабильно работало и не отваливалось в самый неподходящий момент. И хорошо, чтоб не надо было объяснять секретарше, что ей делать, если пропал интернет (и составлять инструкцию из 10 пунктов 🙂

Что не так сейчас

1. Судя по всему, для ASUS RT-AC56U событие перехода на резервный канал — пропадание линка. А если линк есть, а интернета нет, то резервный канал вообще не поднимется. А линк у нас всегда есть, так как перед роутером стоит Voicegateway для IP телефонии. И даже есть его убарть — бывает так, что линк до провайдера есть, но интернета-то нет.
2. При пропадании линка на основном канале, он поднимает резервный, но обратно не возвращается на основной канал до принудительной перезагрузки.

Желательно, чтоб решение было типовым. Вариант типа «Поднять гейтвей на линуксах, и написать для него скрипты» нежелателен, т.к. не понятно, что делать в случае проблем с этой нестандартной штукой. Хорошо, чтоб любой приходящий сисадмин в случае необходимости легко разобрался «с чем это едят».
Я знаю, что все что мне нужно умеет делать KWF, но лицензия на него стоит порядка 20тр/год, это не считая того, что для него нужно либо физическую машину либо какую-то виртуалку поднимать. Мне кажется не очень целесообразно для такой вроде простой задачи использовать подобное недешевое решение.

Может есть железо, которое «из коробки» умеет делать то, что мне нужно?

[UPD] Добавлено — если говорить о роутере, который в т.ч. поднимает Wi-Fi сеть, то желательно:
А. Поднять две сети — рабочую (для ноутбуков, с доступом в локалку) и гостевую (для смартфонов, напрямую в интернет)
Б. Поставить дополнительную точку и сделать вай-фай роуминг (или как это правильно называется, когда устройство автоматически переключается на другую точку доступа если сигнал лучше), т.к. одна точка доступа плохо покрывает все пространство в офисе.

Источник

Любой бизнес, так или иначе, связан с риском. Владельцы бизнеса пытаются всячески избегать рискованных сделок и ситуаций. Использование современных средств связи в бизнесе это тоже определенный риск. Каналы связи являются неотъемлемым инструментом современной работы компании. Технические неисправности каналов передачи данных могут поставить на кон судьбу самой компании.

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

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

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

Резервирование каналов связи осуществляется с помощью технологии VSAT. Контроль над работой канала связи осуществляется сотрудниками провайдера, управление централизовано, ведется круглосуточный мониторинг состояния оборудования. Благодаря высокой надёжности данной технологии ее используют как основной способ передачи данных в тех местах, где построение наземной сети невозможно.

Компания провайдер обеспечивает настройку и сервисное обслуживание станции приема, которая находится у абонента. Также сотрудниками производятся периодические профилактические проверки клиентских станций.

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

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

Источник