Openhab на русском

В продолжение первой части, поговорим о том, с какими устройствами openHab работает у меня дома, для каких еще устройств существует поддержка, и научимся устанавливать систему на Debian системы (Ubuntu, Raspberry Pi и иже с ними).

Материал довольно объемный, поэтому разделю статью на 4 главы — все в рамках этой конкретной публикации. Те, кто знаком с продукцией Xiaomi для умного дома, в принципе, может пропустить первую главу. Мотайте вниз.

Глава 1 — Почему Xiaomi

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

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

  • Все классические компоненты экосистемы Xiaomi используют протокол ZigBee для связи. С помощью ZigBee компоненты Xiaomi создают самоорганизующуюся и самовосстанавливающуюся ячеистую (mesh) топологию с ретрансляцией и маршрутизацией сообщений.
  • Компоненты, использующие ZigBee, отличаются низким энергопотреблением. Устройства Xiaomi с батарейным питанием живут от миниатюрных батареек по меньшей мере год, и заблаговременно предупреждают о приближающейся смерти батарейки.
  • Настенные выключатели Xiaomi, на данный момент, не умеют диммировать. Только вкл и выкл. В моем случае это никогда не было проблемой, благодаря наличию нескольких источников света разной яркости и теплоты в комнате.
  • Настенные выключатели Xiaomi без нейтрали не совместимы с некоторыми светодиодными лампами, и вызывают периодическое, самопроизвольное вспыхивание оных время от времени. Впрочем, этот недостаток свойствен всем умным выключателям, ставящимся в разрез фазового провода без подключения к нейтрали. Проблема решаема, но о ней стоит знать.
  • Беспроводной настенный выключатель на батарейке, или проводной, будучи подключенным к питанию, но не нагрузке, могут управлять (чем угодно, на самом то деле) другим настенным выключателем, позволяя, к примеру, реализовать проходной выключатель без необходимости прокладки дополнительной электропроводки. У меня это реализовано в нескольких местах, отлично работает. Подробнее поговори об этом, когда станем учиться писать скрипты.
  • Для функционирования всего этого дела, нужен шлюз (gateway). Шлюз выступает в роли моста между устройствами ZigBee и внешним миром, через WiFi. По задумке Xiaomi, взаимодействие со шлюзом будет производиться через фирменную аппликацию MiHome, где к шлюзу можно будет присоединить устройства ZigBee, задать их названия и местоположение. Затем, ими можно управлять индивидуально, через MiHome, пользуясь смартфоном как пультом дистанционного управления, либо графически настроить простые сценарии взаимодействия рода «если А — сделай Б, а иначе сделай В».
  • Все это дело довольно стабильно работает, включая дистанционный контроль через интернет (а не только из локалки), без надобности настраивать домашний раутер, регулярно обновляется и пристойно, хоть и не идеально, выглядит. Что мне не нравится, так это то, что взаимодействие происходит через китайские сервера, что не внушает ни надежности в долгосрочной перспективе, ни ощущения полного контроля над своей собственностью. Кроме того, стандартные возможности задания сценариев взаимодействия, хоть и удовлетворят 80% потребностей, все же напрочь лишены каких-либо продвинутых инструкций, вроде циклов и т.п.
  • К счастью, инженеры Xiaomi решили не выделываться и оставили возможность осуществлять коммуникацию со шлюзом из локальной сети, напрямую, по специальному протоколу связи. Именно этой возможностью пользуются все системы умных домой, поддерживающие интеграцию экосистемы Xiaomi.
  • Следует упомянуть, что описанные способы взаимодействия со шлюзом не взаимоисключающи, и могут использоваться параллельно. Это может иметь определенный смысл во время настройки openHab (или подобных систем), однако делать это на постоянной основе я не вижу смысла. В моей системе шлюз не имеет доступа к интернету и работает совершенно автономно.
  • Помните, что отключая шлюз от интернета, вы теряете возможность связи с ним через MiHome, и не сможете отключить уже настроенные сценарии, если таковые были, и они продолжат отрабатываться.
  • Помимо выключателей, Xiaomi предлагают всевозможные сенсоры, такие как датчики задымления и утечки бытового газа, датчики протечки воды, магнитные датчики открытия дверей (окон), температуры и влажности, движения и т.д. Сенсоры на батарейном питании (кроме сенсора утечки газа — его потребление слишком велико, для питания от батареек), и работают долго и стабильно. Нужно сказать, что датчик движения не может применяться во всех ситуациях, в связи с аппаратными ограничениями, которые нельзя обойти. Речь идет и том, то раз обнаружив движение, датчик засыпает на несколько минут, игнорируя происходящее. Кроме того, он не регистрирует присутствие, а только движение. Так что статичная фигура человека перед ним не детектируется. К примеру, с помощью его одного невозможно точно уловить наличие людей в туалете, для автоматического управления светом и вытяжкой. как было задумано. Ну это весьма условный минус, и продиктован целью обеспечить продолжительное время работы датчика от миниатюрной батарейки, а с таким ограничением невозможно производить постоянный анализ данных инфракрасной обстановки в помещении.
  • С другой стороны, некоторые датчики, вроде датчика открытия двери, будучи по сути лишь контактом (геркон — магнит), легко переделываются под свои нужды. Я расскажу о такой переделке в одной из будущих статей цикла.
  • Кроме того, интересного функционала можно легко и просто добиться с помощью софта. Простейший пример: есть у меня вентиль с мотором на 220, для дистанционного перекрытия главной водяной магистрали, идущей в дом. По идее он управляется специальным включателем, подающим фазу на один из двух управляющих проводов. Я использовал для этой цели обычный двухклавишный выключатель. А для управления оным написан скрипт, который понимает команды «дать воду» и «перекрыть нафиг!», и уже сам разбирается что там делать с фазой. Скрипт, естественно, написан в openHab, и я не уверен, что подобное можно реализоваться средствами MiHome. Выключатель уже полтора года стоит в труднодоступном месте и исправно работает. Это я к тому, что вся система в целом, и в интеграции с openHab чрезвычайно стабильна.
  • Некоторые девайсы Xiaomi, например, светильники, работают сразу через WiFi — будучи всегда запитанными от сети, они могут позволить себе эту роскошь. openHab отлично работает и с ними тоже.

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

Глава 2 — Что я использую c openHab кроме девайсов Xiaomi

Мой умный дом все еще в процессе активной, хоть и не быстротечной эволюции. На данный момент, из покупных устройств, в openHab интегрирован AV ресивер и драйвер для светодиодной подсветки в гостиной. Такие устройства как датчики свежести воздуха (CO2), Wi-Fi адаптеры для систем кондиционирования, адаптер для считывания показаний умного электросчетчика и т.п. — самодельные и работают по протоколу MQTT. Подробно про эти устройства я также расскажу с будущих статьях цикла. Устройства просты в изготовлении, дешевы, легки в программировании и необычайно гибки в конфигурации и использовании.

Глава 3 — А какие еще устройства поддерживает openHab

На сегодняшний день в той или иной мере openHab поддерживает более полутора тысяч умных устройств от КУЧИ разных производителей. Я просто дам ссылку на официальный список — ВОТ ОН! Там можно покопаться, поискать и подробнее прочитать про поддерживаемый функционал конкретного устройства. Как видите, там и телевизоры, и светильники, и пылесосы и тд и тп. Пожалуй, непросто будет назвать устройство, которое совсем не поддерживается и никак нельзя подключить.

Глава 4 — Устанавливаем openHab (Ubuntu)

Как я уже упоминал, openHab оптимизирован под маломощные системы вроде Raspberry Pi, и действительно неплохо бегает — я сам, ради интереса, проверял, с год назад. Но поскольку у меня есть полноценный сервер на Ubuntu, я буду использовать его в качестве примера. Я предполагаю, что у читателя есть минимальные знания о работе с командной строкой Ubuntu, а также, что компьютер, на который производится установка подключен к интернету.

По сути установка очень проста и сводится к рутинному запуску последовательности команд, расписанных в официальной документации (и ).

Поскольку openHab написан на Java, именно с этого и начнем установку. Разумеется, если у вас уже установлены пакеты Java, этот этап можно пропустить.

Разработчики openHab рекомендуют 8 версию платформы Zulu Java, поэтому будем ставить ее. Кроме того, обратите внимание, что для процессоров ARM нужно в любом случает ставить 32-битную версию Java.

Начать установку, я бы рекомендовал с конфигурирования статичного IP адреса для вашего сервера, если это не было сделано раньше. В последних версиях Ubuntu это делается путем редактирования файла /etc/netplan/01-netcfg.yaml:

sudo nano /etc/netplan/01-netcfg.yaml

Итоговый вид примерно такой:

network: version: 2 renderer: networkd ethernets: ens3: dhcp4: no addresses: — 192.168.121.199/24 gateway4: 192.168.121.1 nameservers: addresses:

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

sudo netplan apply

Теперь ставим Java. Выполняем следующие команды от супер-пользователя, для того чтобы добавить репозиторий Zulu Java:

sudo apt-key adv —keyserver hkp://keyserver.ubuntu.com:80 —recv-keys 0xB1998361219BD9C9 sudo apt-add-repository ‘deb http://repos.azulsystems.com/ubuntu stable main’ sudo apt-get update

Теперь можно установить Java:

sudo apt-get install zulu-8

Далее, добавляем репозитории openHab:

wget -qO — ‘https://bintray.com/user/downloadSubjectPublicKey?username=openhab’ | sudo apt-key add — sudo apt-get install apt-transport-https echo ‘deb https://dl.bintray.com/openhab/apt-repo2 stable main’ | sudo tee /etc/apt/sources.list.d/openhab2.list sudo apt-get update

Устанавливаем openHab и дополнения:

sudo apt-get install openhab2 sudo apt-get install openhab2-addons

Запускаем openHab и добавляем его в системные службы, запускающиеся автоматом при старте операционной системы:

sudo /etc/init.d/openhab2 start sudo /etc/init.d/openhab2 status sudo update-rc.d openhab2 defaults

Комманда «sudo /etc/init.d/openhab2 status» выводит статус работы сервиса openHab и в случае проблем, искать источник бед следует отсюда:

Первый запуск openHab на слабом компьютере может занять до 15ти минут. В это время происходит первоначальная конфигурация и генерация сертификатов безопасности. Это нормально и последующие старты будут быстрыми. На моем сервере первый запуск занял буквально несколько секунд. Когда система полностью загрузится, станет доступным веб-интерфейс по адресу http://IP-адрес-сервера:8080:

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

Глупый умный дом. Часть 4, установка и настройка

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

Выбор системы

Создание системы УД из устройств одного производителя – наиболее простое и очевидное решение. Плохая новость в том, что большинство систем домашней автоматизации плохо совместимы друг с другом «из коробки». Хорошая новость в том, что заставить работать вместе устройства из разных экосистем все-таки можно, но об этом позже.

В плане гибкости построения системы, бесспорно, выигрывает система от Samsung. Кратко опишу суть дела тем, кто не читал материал о ней: фирменный хаб Smartthings работает не только со своими устройствами, но и с немалым количеством сторонних решений. Например, Philips Hue, Ikea Tradfri и даже некоторые устройства от Xiaomi. Последнее связано с вероятными «танцами с бубном», но, по крайней мере, такая возможность есть. Но в данном случае речь идет исключительно об устройствах, связывающихся по протоколу Zigbee и Z-Wave. Все, что работает посредством Wi-Fi или Bluetooth, этому хабу недоступно. Благодаря поддержке универсальных протоколов, владелец может покупать самые недорогие «умные» устройства на китайских онлайн-площадках, благодаря чему стоимость хаба окупится довольно быстро.

К слову, Apple Homekit (в котором вообще нет собственных устройств) поддерживает многие девайсы из «чужих» экосистем. Например, один из вариантов шлюзов Xiaomi под названием Aqara Hub без проблем можно добавить в Homekit. Все датчики, кнопки и лампочки, поддерживаемые им, автоматически появятся в интерфейсе этой системы. Проблема в том, что он поддерживает чуть меньшее количество этих самых датчиков и ламп, чем основной шлюз. А самая главная проблема – он не может использоваться для сторонних систем управления «умным» домом, так как не имеет «режима разработчика». Если вам надо без заморочек наполнить систему Homekit недорогими устройствами, то это самая лучшая возможная комбинация. Если же вы планируете совмещать несколько систем или внедрять более мощную систему управления, то лучше выбрать оригинальный шлюз Mijia Hub.

К тому же для Apple Homekit существует сторонний софт под названием Homebridge, позволяющий добавить многие устройства и Xiaomi, и других производителей. По умолчанию такой возможности в Homekit нет. Для Homebridge потребуется запуск отдельного сервера (на ПК/Mac или на Raspberry Pi), но зато и возможности системы УД от Apple очень расширятся.

В отличие от предыдущих вариантов, шлюзу компании Xiaomi поддержка сторонних устройств не так уж и нужна, потому что в экосистеме Mi Home их и так хватает. Здесь есть все, начиная от простых лампочек и кнопок и заканчивая холодильниками и водонагревателями. Правда, не все они работают через Zigbee, и это создает немалую путаницу в беспроводных протоколах одной системы. Но даже несмотря на огромное количество «своих» устройств, шлюз Xiaomi Mijia поддерживает добавление лампочек Ikea. На общем фоне это не так уж и влияет на что-то, но все-таки некое движение в сторону мультиплатформенности есть, и это уже приятно.

К шлюзу от Ikea подключить сторонние устройства не получится, а вот добавить устройства Tradfri можно в тот же Homekit. Если от УД вам нужно только управление светом и некоторыми электроприборами – смело выбирайте этот вариант, особенно если магазин сети есть в вашем городе. Лампочки относительно недорогие (по сравнению с теми же Hue), но при этом у них отличное качество сборки и качественные светодиодные платы. Если же планируется большое количество устройств и глубокие сценарии автоматизации, то эта платформа – пока не лучшая опция.

Сторонние системы управления

Несмотря на то, что у каждой из рассмотренных систем есть свое фирменное приложение (а у некоторых – даже два), ни одно из них не подходит на роль единственной и главной системы управления УД. Важная ремарка – это мое личное мнение, многим людям достаточно и решения «из коробки». Например, если ваша автоматизация заканчивается на том, что свет включается по датчику движения, то любой из этих систем будет достаточно. Но если хочется комплексных сценариев с несколькими задействованными устройствами, тонкой подстройки параметров и триггеров, офлайнового взаимодействия и много другого, то стоит обратиться к внешним системам управления УД. Они бывают как коммерческие, с закрытым исходным кодом, так и открытые, поддерживаемые сообществом. Первые (Savant, Crestron, Control4) используются нечасто – как правило, в проектах с высоким бюджетом, и конфигурируют их профессиональные установщики.

Для широкого использования лучше подойдут open-source системы, коих существует огромное множество. Со временем в конкурентной борьбе остались два основных участника – OpenHAB и Home Assistant, причем второй успешно наращивает отрыв в популярности. В рамках этой статьи мы не будем изучать все нюансы конфигурации, здесь не будет инструкций по установке и настройке – это слишком большой объем информации. Вместо этого мы лучше сравним их основные недостатки и преимущества.

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

Еще одна большая проблема этой системы в том, что она очень сильно сегментирована. Здесь нет единого внешнего интерфейса, существует несколько различных вариантов. При этом ни один из них не позволяет обойтись вообще без программирования. Вся платформа работает на языке Java, на нем же пишутся и связи между компонентами. Это не так уж и сложно – подавляющую их часть можно найти в готовом виде в сети, но все-таки это способно отпугнуть многих. К слову, здесь очень большое и развитое сообщество – найти ответ на свой вопрос получится в большинстве случаев, а в остальных можно найти человека, который что-то подскажет.

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

Home Assistant – такой же проект, разрабатываемый энтузиастами, но возрастом помоложе – ему всего три года. Занятно, что он даже еще не вышел в версии 1.0 – текущий релиз имеет нумерацию 0.104. Получается, что система еще находится в бета-тестировании, но при этом по популярности и количеству пользователей уже догоняет «старичка». Причин тому много.

Во-первых, новые компоненты внедряются здесь просто молниеносно. В 99% случаев можно быть уверенным, что если вы купили какую-то новую «умную» технику, то ее поддержка скоро здесь появится. Если, конечно, производитель не оказался «бякой» и не заблокировал доступ разработчиков к API. Да и даже в таких случаях можно рассчитывать на удачный исход, чайник Redmond – тому пример. Занятно, что не только электроника имеет свои плагины для Home Assistant, но и различные онлайн-сервисы и другие платформы. Например для стриминга музыки здесь предусмотрен плагин Spotify и Google Play Music, для просмотра фильмов – Kodi и VLC, а плагин Yandex Transport автоматически подгружает расписание транспорта на ближайших остановках.

И даже протокол связи не преграда – Home Assistant (как и OpenHAB, кстати) поддерживает Zigbee/Z-Wave, Bluetooth и Wi-Fi. Вот только для этого надо приобретать необходимые устройства – шлюзы с соответствующей технологией, потому что все сторонние системы управления, как правило, устанавливаются на одноплатные компьютеры вроде Raspberry Pi. Можно использовать и решения от крупных производителей (те же Xiaomi Gateway и Smartthings Hub, например), но если уж вас понесло в сторону мощной домашней автоматизации, то стоит заморочиться на универсальные модули, не привязанные лишь к одному бренду. Например, эта плата может подключить сразу все ваши устройства Zigbee и Z-Wave – IKEA, Fibaro, Honeywell, Samsung, Xiaomi, да хоть просто безымянное поделие из стран Азии.

Возвращаясь к особенностям Home Assistant, можно заметить, что быстрый выход релизов (раз в две недели) является и недостатком этой платформы – они часто бывают «сырыми», а устройства иногда выдают ошибки. Все это, конечно, быстро исправляется, но не всем хочется быть испытателем недоделанного продукта.

Еще одна приятная особенность Home Assistant в том, что здесь есть возможность использовать один из лучших способов «визуального» программирования компонентов – Node RED. Эта оболочка, разработанная когда-то компанией IBM, является посредником между пользователем и настраиваемой системой УД. Здесь используются связи неких блоков на экране вместо текстового программирования. Таким образом, хоть Home Assistant и работает на языке Python, знать его практически не нужно. Но даже если в каких-то случаях приходится писать код обычными «словами», то и тогда понимание языка необязательно – в интернете вполне достаточно готовых решений для самых распространенных сценариев.

В целом, структура Home Assistant гораздо более гибкая, чем у OpenHAB. Здесь больше возможностей настройки каждого компонента и сценария. А если подключить к нему сервисы наподобие IFTTT и Tasker, то возможности становятся и вовсе безграничными – лишь бы было желание и время их воплощать.

Возможно, в комментариях вы вспомните и другие системы управления УД: Domoticz, Majordomo, ioBroker и прочее. Но по факту первый уже умирает (хотя и был когда-то на вершине), а второй и третий толком и взлететь не успели. Чтобы не попасть в ситуацию «я купил что-то, оно не работает с моей системой, и я не знаю, как это исправить» – просто не связывайтесь с нишевыми решениями.

Голосовые ассистенты

Если вам нужен функционал управления голосом, то выбор не особо-то и велик. В случае с УД от Apple единственным полноценно работающим голосовым сервисом будет Siri. Он хорошо распознает голос, имеет неплохой базовый функционал и, что особенно приятно, понимает русский язык. Из минусов: ограниченное количество устройств, которые можно установить дома стационарно и на которых можно запустить Сири голосом. По сути, это только HomePod, но он не поддерживает русский язык. Зато его поддерживает планшет iPad Air (и более новые модели) – с небольшой натяжкой его можно назвать стационарным.

Голосовой ассистент от Google – более универсальная опция. Его можно подключить ко многим системам УД (в т.ч. Xiaomi, IKEA и Samsung) и ко всем альтернативным системам управления. Он неплохо распознает русский язык, но почему-то даже базовые команды вроде «Включи свет в спальне» иногда в нем не срабатывают.

У Google есть и свое приложение для контроля УД под названием Google Home, но пока что оно выглядит как простенькая оболочка для того же ассистента. До уровня Homekit ей еще далеко.

А вот до кого им обоим далеко, так это до амазоновской «Алексы». Она сейчас на слуху у всех благодаря хорошей оптимизации голосовой модели и грамотному маркетинговому продвижению. В начале 2020 года Дэйв Лимп, старший вице-президент в Amazon, заявил, что всего в мире продано более 100 миллионов устройств с предустановленным ассистентом Alexa. Это немалое число для нового формата взаимодействия, и до таких показателей ни Google, ни Apple пока не дотягивают. Колонки действительно неплохи, особенно за свою цену, но для жителей нашей страны присутствует один большой минус – русский язык здесь не поддерживается (и не будет в ближайшем времени). Если английский (или другой поддерживаемый язык) вам совсем не чужд, эту систему можно смело рекомендовать.

Единственной адекватной альтернативой для русскоязычного пользователя остается «Алиса» от «Яндекса». Она отлично понимает естественную речь и, что немаловажно, умеет управлять некоторыми устройства УД, например, экосистемы Mijia. Благо, колонки с поддержкой этого ассистента есть в разных размерах и ценовых сегментах, какой-никакой выбор.

Выводы

Этой статьей я завершаю обзорный цикл материалов об «умном» доме. На эту тему можно еще много сказать, многих производителей вспомнить, но основные нюансы были затронуты. Если вы считаете, что чего-то не хватает, обязательно расскажите об этом в комментариях – возможно, что другим читателям это будет полезно.

Не все наши читатели разделяют ажиотаж вокруг этого сегмента. Проблема рынка УД в том, что его пытаются натянуть на аудиторию, как «сову на глобус». Вместо того, чтобы сконцентрироваться на создании действительно полезных товаров, производители занимаются выпуском всего, что придет им в голову, но с приставкой «умный». А «умом»-то там и не пахнет. Но так работает рынок, ничего не поделаешь. А нам как потребителям остается фильтровать поток этого «горя от ума» и приобретать то, что действительно может принести пользу. Поделитесь в комментариях, была ли у вас какая-то «умная» техника или электроника, которая оправдала свое название. Что бы вы хотели увидеть в ближайшей перспективе, а что, наоборот, является исключительной блажью?

К содержанию >>>

Ссылки по теме

Алексей Подболотов (a.podbolotov@yahoo.com)

Опубликовано — 20 января 2020 г.

Настройка нескольких провайдеров

Я настоятельно рекомендую сначала прочитать, далее вникнуть, потом понять и только после того, как у вас вся картина будет нарисована в голове, приступить к настройке.

Настройка нескольких провайдеров в RouterOS.

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

Если оператор нам выдал ip адрес 1.1.1.2, то мы должны обеспечить выход через этого провайдера именно с таким ip адресом, а не с каким либо другим.

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

Для начала определим вводные данные.

Первый провайдер:

Второй провайдер:

  • Интерфейс ether2
  • IP:44.44.44.2/29 Gateway: 44.44.44.1
  • DSN сервера 7.7.7.2 и 6.6.6.2

Локальная сеть:

  • Ether3 — IP:172.20.17.1/24 — локальная сеть компьютеров
  • Ether4 — IP:172.20.18.1/24 — локальная сеть для серверов

Настройка IP адресации

Настроим IP адреса, согласно выданным настройкам от провайдеров.

/ip address add interface=ether1 address=88.88.88.2/29 comment=ISP1 add interface=ether1 address=99.99.99.2/24 comment=ISP1 add interface=ether2 address=44.44.44.2/24 comment=ISP2 add interface=ether3 address=172.20.17.1/24 comment=LocalNetworkComputers add interface=ether4 address=172.20.18.1/24 comment=LocalNetworkServers

Я думаю бессмысленно как-то дополнять данные настройки.

Маркировка соединений от провайдера

Вы наверное помните, а если и нет, то стоит напомнить, что любой пакет, который приходит на маршрутизатор попадает в цепочку prerouting и не важно куда он дальше попадёт forward или Input.

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

Сначала настроим, а далее разберём что сделали.

/ip firewall mangle add chain=prerouting in-interface=ether1 dst-address=88.88.88.0/29 connection-state=new action=mark-connection new-connection-mark=Next-Hop/88.88.88.1 passthrough=no add chain=prerouting in-interface=ether1 dst-address=99.99.99.0/24 connection-state=new action=mark-connection new-connection-mark=Next-Hop/99.99.99.1 passthrough=no add chain=prerouting in-interface=ether2 dst-address=44.44.44.0/24 connection-state=new action=mark-connection new-connection-mark=Next-Hop/44.44.44.1 passthrough=no

Разберём только первое правило, все остальные по аналогии.

Если пакет приходит с интерфейса ether1 и адрес назначения лежит в сети 88.88.88.0/29, и такой пакет создал соединение, то маркируем соединение маркой Next-Hop/88.88.88.1.

Небольшие пояснения:

88.88.88.0/29 — почему сеть, а не IP? Если вы будете делать правила для каждого IP адреса, количество правил будет расти, а смысл будет тот же самый.

connection-state=new — нет смысла пытаться маркировать соединения, которые уже установлены, как вы помните new — это пакет, который создал соединение, т.е он только один, а в случае со всеми пакетами routeros будет каждый раз пытаться маркировать соединение, которое уже и так может иметь маркировку.

Next-Hop/99.99.99.1 — почему именно так? Как вы помните, наша главная задача отправить трафик через тот же самый шлюз, через который трафик пришёл, а мы таким названием себе явно напоминаем, какой шлюз будет использоваться для выхода в сторону провайдера. Мы бы могли использовать что-нибудь вроде ISP1, но так как у нас первый провайдер даёт два префикса в одном и том же интерфейсе, мы должны трафик, который приходит на разные префиксы каким нибудь образом разделить.

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

С этого момента весть трафик, который придёт со стороны провайдера, будет промаркирован, а далее бы будем оперировать данной маркировкой.

Доступ к маршрутизатору

Первая задача, которую нам необходимо решить, это организовать возможность управления маршрутизатором через разных провайдеров. Мы должны иметь возможность подключится по любому IP адресу по ssh, winbox, а также если вы будете использовать RouterOS в случае VPN сервера. В общем организовать правильный выход пакетов, которые будет отправлены с маршрутизатора в ответ на входящие соединения.

Для начала нам надо организовать правильные таблицы маршрутизации. В одной таблице маршрутизации не могут быть одновременно два одинаковых активных маршрута, если маршруты одинаковы, то приоритет выбирается из значения distance. Для того чтобы можно было использовать несколько одинаковых маршрутов в RouterOS есть возможность создавать альтернативные (именованные) таблицы маршрутизации.

Создадим данные таблицы.

/ip route add dst-address=0.0.0.0/0 gateway=88.88.88.1 routing-mark=Next-Hop/88.88.88.1 add dst-address=0.0.0.0/0 gateway=99.99.99.1 routing-mark=Next-Hop/99.99.99.1 add dst-address=0.0.0.0/0 gateway=44.44.44.1 routing-mark=Next-Hop/44.44.44.1

Разберём:

dst-address=0.0.0.0/0 — обычный маршрут по умолчанию, не более чем.

gateway=88.88.88.1 — шлюз, обратите внимание на то, что нам первый провайдер даёт два префикса с разными шлюзами, и поэтому мы создаём три маршрута, для нас по факту не два провайдера, а три.

routing-mark=Next-Hop/88.88.88.1 — это и есть именованная таблица маршрутизации. Она может иметь любое имя, какое вам удобнее, лично моё мнение, такое именование удобно записывать в названии таблицы шлюз, через который будет отправлен пакет в случае если он будет использовать данный маршрут. Имена маркировок соединений и маршрутов просто совпали и могут быть совершенно разные.

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

/ip firewall mangle add routing- tab tab routing-mark routing-table

Дело в том, что routing-mark это маркировка, когда вы своими руками с помощью mangle назначили на пакет маркировку, а routing-table это то, через какую таблицу маршрутизации вышел пакет.

Если маршрутизатор не найдёт подходящего маршрута в именованной таблице маршрутизации, маршрутизатор продолжит поиск подходящего маршрута в таблице по умолчанию main и такой пакет можно будет отфильтровать например так routing-mark=custommark routing-table=main. Нам же такое поведение не нужно, если по какой-то причине маршрут не будет найден, пакет должен умереть на маршрутизаторе, а отправлять через другого провайдера нет никакого смысла.

Нам необходимо переопределить данное поведение.

/ip route rule add routing-mark=Next-Hop/88.88.88.1 action=lookup-only-in-table table=Next-Hop/88.88.88.1 add routing-mark=Next-Hop/99.99.99.1 action=lookup-only-in-table table=Next-Hop/99.99.99.1 add routing-mark=Next-Hop/44.44.44.1 action=lookup-only-in-table table=Next-Hop/44.44.44.1

Т.е марка и таблица по факту это одно и тоже, пакет который имеет определённую routing-mark пытается найти маршрут в таблице с таким же именем.

Осталась самая малость, это отправить в нужную марку необходимый трафик.

/ip firewall mangle add chain=output connection-mark=Next-Hop/88.88.88.1 action=mark-routing new-routing-mark=Next-Hop/88.88.88.1 passthrough=no add chain=output connection-mark=Next-Hop/99.99.99.1 action=mark-routing new-routing-mark=Next-Hop/99.99.99.1 passthrough=no add chain=output connection-mark=Next-Hop/44.44.44.1 action=mark-routing new-routing-mark=Next-Hop/44.44.44.1 passthrough=no

Цепочка output, так как мы работаем только с трафиком, который генерирует в ответ на запрос соединения. Выбрали пакеты принадлежащие только определённым соединениям и отправили в именованную таблицу.

Вроде бы всё хорошо и всё должно работать, но это не так, в RouterOS есть один маленький нюанс, который необходимо помнить и учитывать. Дело в том, что маршрутизатор, прежде чем отправить пакет в цепочку output, смотрит в таблицу маршрутизации и ищет для адреса назначения подходящий маршрут в таблице main, есть всего три типа сервисов, которые умеют работать вне данного поведения, это ping, traceroute и ospf — это необходимо для работы в VRF.

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

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

В RouterOS данный интерфейс можно заменить пустым bridge.

/interface bridge add name=Br-Loopback

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

А теперь создадим маршрут в таблице main, который необходим для преодоления выбора маршрута и попадания пакета в цепочку output.

/ip route add dst-address=0.0.0.0/0 gateway=Br-Loopback distance=254

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

Напоминаю, что дистанция 255 это административная дистанция, которая явно указывает на то, что данный маршрут мёртв и не участвует в маршрутизации.

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

Выход с маршрутизатора

Хоть и по сути мы сделали уже много, но у нас ещё несколько кейсов впереди. Теперь мы должны сделать таким образом, чтобы пакеты, которые генерирует сам маршрутизатор (не в ответ), уходили через нужного провайдера и шлюза.

Когда вы пингуете с маршрутизатора, строите PPP* или IP туннели с самого маршрутизатора или dns запросы отправляете с самого маршрутизатора. Разница с прошлым кейсом в том, что мы отправляли пакет по уже установленному соединению, а здесь пакет улетает с маршрутизатора и соединение не имеет маркировки.

Здесь будет значительно проще.

/ip firewall mangle add chain=output src-address=88.88.88.0/29 action=mark-routing new-routing-mark=Next-Hop/88.88.88.1 passthrough=no add chain=output src-address=99.99.99.0/24 action=mark-routing new-routing-mark=Next-Hop/99.99.99.1 passthrough=no add chain=output src-address=44.44.44.0/24 action=mark-routing new-routing-mark=Next-Hop/44.44.44.1 passthrough=no

Весь трафик, который уходит с маршрутизатора, и имеет IP адрес, который попадает под префикс, будет отправлен в именованную таблицу маршрутизации.

Всё, теперь вы можете строить туннели и у вас всё будет работать, но только в том случае если явно указан IP адрес, например в Ipsec или gre, ip туннели и прочее, там где явно можно указать Source адрес. А что делать с сервисами, где нельзя указать явно IP адрес источника? Ответ на этот вопрос кроется в таблице маршрутизации. Параметр pref-src отвечает за то, какой IP адрес будет выбран если он явно не задан.

Ещё раз для понимания, у нас есть два варианта развитая сюжета, если IP адрес источника явно указан и тогда нам нечего не грозит и всё замечательно работает. Второй вариант, когда IP адрес явно не задан, например вы подминаете l2tp-client у нас нет возможности указать source адрес, но ведь адрес назначения есть в любом случае. Тогда маршрутизатор поступает следующим образом, он находит маршрут в таблице маршрутизации main, смотрит какой указан pref-src и использует данный ip адрес, как адрес источника.

Вы помните что мы создавали фиктивный маршрут.

/ip route add dst-address=0.0.0.0/0 gateway=Br-Loopback distance=254

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

/ip route set pref-src=88.88.88.2

Выбор IP адреса зависит только от вас, выбирайте тот адрес, который считаете менее загруженным.

На этом этапе всё, теперь вы можете строить различные туннели и устанавливать соединения не только указывая явно source адрес.

Доступ за НАТ

172.20.18.2 — это exchange сервер, мы должны обеспечить доступность 25,80,443 портов через каждого провайдера.

НАТ делаем как обычно, без всяких излишеств.

/ip firewall nat add chain=dstnat in-interface=ether1 dst-address=88.88.88.2 protocol=tcp dst-port=25,80,443 action=dst-nat to-addresses=172.20.18.2 add chain=dstnat in-interface=ether1 dst-address=99.99.99.2 protocol=tcp dst-port=25,80,443 action=dst-nat to-addresses=172.20.18.2 add chain=dstnat in-interface=ether2 dst-address=44.44.44.2 protocol=tcp dst-port=25,80,443 action=dst-nat to-addresses=172.20.18.2

А теперь давайте вспомним то, что мы делали самым первым правилом в mangle мы промаркировали все соединения, которые приходят через всех провайдеров! Данная маркировка нам опять поможет.

Нам необходимо отфильтровать весь трафик, который идёт из локальной сети и отправить в том направлении к маркировки которого соединение имеет отношение.

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

  1. Когда пакет придёт на IP адрес 88.88.88.2 мы промаркировали соединение которому принадлежит пакет.
  2. Далее в NAT мы изменили адрес назначения и маршрутизатор отправит его до сервера.
  3. Естественно сервер в ответ отправит пакет, как минимум syn,ack, так как данный пакет принадлежит уже существующему соединению, мы по имени соединению отправим данный пакет в именованную таблицу маршрутизации.

НАТ уже сделали, дело осталось за малым- найти трафик, который приходит от сервера.

/ip firewall mangle add chain=prerouting connection-mark=Next-Hop/88.88.88.1 in-interface=!ether1 action=mark-routing new-routing-mark=Next-Hop/88.88.88.1 passthrough=no add chain=prerouting connection-mark=Next-Hop/99.99.99.1 in-interface=!ether1 action=mark-routing new-routing-mark=Next-Hop/99.99.99.1 passthrough=no add chain=prerouting connection-mark=Next-Hop/44.44.44.1 in-interface=!ether2 action=mark-routing new-routing-mark=Next-Hop/44.44.44.1 passthrough=no

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

Наверное многие спросят, а почему указывается не интерфейс ether1, а не взять и указать явно локальный интерфейс, например ether4.

Мы с вами делаем универсальную конфигурацию, если явно указать какой-либо другой интерфейс, значит в случае если у нас будет ещё один NAT, который пойдёт в другой порт, нам необходимо будет добавлять ещё одно аналогичное правило, но уже с другим интерфейсом. А ведь мы можем даже завернуть трафик с помощью NAT вообще на внешние сервера например 1.1.1.1, и что тогда? Единственный интерфейс откуда в цепочке prerouting мы не должны ожидать данный трафик, это трафик с самого провайдера и причём именно с того, с которого он пришёл.

Всё работает, теперь вы можете подключаться в своему серверу по любому IP адресу. Создайте DNS A запись RR и укажите все три внешних IP адреса и всегда ссылайтесь на данную запись.

Например: mail.mycompany.ru

mail.mycompany.ru A 88.88.88.2 mail.mycompany.ru A 99.99.99.2 mail.mycompany.ru A 44.44.44.2

Ещё каких-то лет 7 назад, DNS RR работал не очень хорошо, в плане того, что приложения зачастую использовали только первый IP адрес, сейчас все изменилось и многие приложения в случае, если не смогут подключиться по одному адресу, будут пытаться подключаться по другому и так далее…

А также source NAT?

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

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

Обратное преобразования NAT произойдёт автоматически, давайте взглянем на запись в conntrack.

/ip firewall connection print detail where dstnat Flags: E — expected, S — seen-reply, A — assured, C — confirmed, D — dying, F — fasttrack, s — srcnat, d — dstnat 0 SAC d protocol=tcp src-address=5.19.245.3:57839 dst-address=88.88.88.2:80 reply-src-address=172.20.18.2:80 reply-dst-address=5.19.245.3:57839 tcp-state=established timeout=23h56m33s orig-packets=191 orig-bytes=19 352 orig-fasttrack-packets=0 orig-fasttrack-bytes=0 repl-packets=200 repl-bytes=32 631 repl-fasttrack-packets=0 repl-fasttrack-bytes=0 orig-rate=0bps repl-rate=0bps

Давайте уберём из вывода лишнее, чтобы оно нам не мешало.

0 SAC protocol=tcp src-address=5.19.245.3:57839 dst-address=88.88.88.2:80 reply-src-address=172.20.18.2:80 reply-dst-address=5.19.245.3:57839

И так когда пакет попал на маршрутизатор и соединение было «только только» создано, соединение имело такой вид

0 SAC src-address=5.19.245.3:57839 dst-address=88.88.88.2:80

После того, как произошла процедура dst NAT, маршрутизатор добавил флаги и самое главное на какой адрес изменяется IP адрес во всех пакетах в данном соединении.

0 SAC d src-address=5.19.245.3:57839 dst-address=88.88.88.2:80 reply-src-address=172.20.18.2:80

Когда пакет уходил с маршрутизатора в цепочки postrouting работает процедура src NAT, но у нас нет правил src NAT, оставили значение исходное.

0 SAC d src-address=5.19.245.3:57839 dst-address=88.88.88.2:80 reply-src-address=172.20.18.2:80 reply-dst-address=5.19.245.3:57839

Обратите внимание, что все данные этапы были сделаны на момент прохождения только первого пакета.

Тем самым src NAT на данном этапе работает автоматически на основании правил dst-NAT.

Выпустить с правильного адреса

Часто бывают ситуации, что вам необходимо жёстко определить, чтобы какой-то внутренний хост выходил только с определённого IP адреса.

Например, VoIP телефония, ваш провайдер телефонии требует, чтобы вы регистрировались только с определённого IP адреса, или банк клиент на компьютере главного бухгалтера должен подключаться с определённого адреса.

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

/ip firewall address-list add list=via/88.88.88.2 address=0.0.0.1 add list=via/99.99.99.2 address=0.0.0.1 add list=via/44.44.44.2 address=0.0.0.1

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

Название листа явно говорит о том, на какой IP адрес необходимо изменить адрес источника.

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

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

И мы не можем просто взять и завернуть весь трафик от внутренного хоста в определённого провайдера, так как у нас есть ещё и локальная сеть.

Допустим, если мы добавим хост 172.20.17.100 и скажем, что весь трафик направить в первого провайдера, то что будет с трафиком, который идёт на хост 172.20.18.2? Естественно он будет направлен в первый провайдер.

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

Создадим адрес лист с BOGON сетями.

/ip firewall address-list add list=BOGONS address=0.0.0.0/8 add list=BOGONS address=10.0.0.0/8 add list=BOGONS address=100.64.0.0/10 add list=BOGONS address=127.0.0.0/8 add list=BOGONS address=169.254.0.0/16 add list=BOGONS address=172.16.0.0/12 add list=BOGONS address=192.0.0.0/24 add list=BOGONS address=192.0.2.0/24 add list=BOGONS address=192.168.0.0/16 add list=BOGONS address=198.18.0.0/15 add list=BOGONS address=198.51.100.0/24 add list=BOGONS address=203.0.113.0/24 add list=BOGONS address=224.0.0.0/3

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

/ip firewall mangle add chain=prerouting src-address-list=via/88.88.88.2 dst-address-list=!BOGONS action=mark-routing new-routing-mark=Next-Hop/88.88.88.1 passthrough=no add chain=prerouting src-address-list=via/99.99.99.2 dst-address-list=!BOGONS action=mark-routing new-routing-mark=Next-Hop/99.99.99.1 passthrough=no add chain=prerouting src-address-list=via/44.44.44.2 dst-address-list=!BOGONS action=mark-routing new-routing-mark=Next-Hop/44.44.44.1 passthrough=no

Если пакет в адресе источника находится адрес, который перечислен в адрес листе и при этом адрес назначения не попадает под BOGON листы (т.е трафик в интернет), отправить в именованную таблицу.

И последний нюанс- это настроить NAT.

/ip firewall nat add chain=srcnat routing-mark=Next-Hop/88.88.88.1 src-address-list=via/88.88.88.2 action=src-nat to-addresses=88.88.88.2 add chain=srcnat routing-mark=Next-Hop/99.99.99.1 src-address-list=via/99.99.99.2 action=src-nat to-addresses=99.99.99.2 add chain=srcnat routing-mark=Next-Hop/44.44.44.1 src-address-list=via/44.44.44.2 action=src-nat to-addresses=44.44.44.2

Обратите внимание, что не весь трафик, а только тот, который находится в определённом маркированном маршруте, это необходимо для того, чтобы трафик между локальными сетями не попадал под NAT правило.

Выпускаем всех остальных и балансируем нагрузку.

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

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

Наверное вы уже догадались, что весь оставшийся трафик от ваших локальных хостов будет попадать в таблицу main.

Давайте сделаем маршрут ECMP с тем учётом, что шлюз 88.88.88.1 это 10Mbps, а 44.44.44.1 5Mbps.

/ip route add dst-address=0.0.0.0/0 gateway=88.88.88.1,88.88.88.1,44.44.44.1 pref-src=88.88.88.2

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

Хотя это немного и не правильно, дело в том, что у процесса ECMP есть отдельная таблица кеша, и чтобы каждый раз не выбирать маршрут, маршрутизатор для связки src-address:port dst-address:port создаёт хеш и выберет для данного хеша уже шлюз по схеме Round Robin, тем самым для одного соединения будет выбираться один и тот же шлюз.

Но не все так однозначно, каждый раз, когда вы изменили маршрут, например добавили шлюз или шлюз умер то кеш ECMP чистится, а также каждые 10 минут всё также чистится кеш, отсюда появляется проблема, что каждые 10 минут может выбраться другой шлюз. И снова для каждого уникального хеша будет выбираться маршрут.

На ресурсах, которые используют привязку сессии авторизации к IP адресу, вы получите проблему в виде запроса логина и пароля, например mail.ru будет у вас запрашивать пароль при смене ip адреса.

Проблема в том, что ограничение в 10 минут, это ограничение жёсткое и нам его не убрать и не изменить.

Будем решать штатными средствами RouterOS.

Давайте подумаем вместе, что нам известно о пакете, который попал под ECMP маршрут? Конечно, данный пакет находится в таблице main.

Идея данного способа заключается в следующем. Дать маршрутизатору выбрать маршрут с помощью ECMP, промаркировать такие соединения и все последующие пакеты в этом соединение пускать мимо ECMP, тем самым мы убираем проблему 10 минут.

Делаем.

/ip firewall mangle add chain=postrouting routing-table=main out-interface=ether1 connection-state=new action=mark-connection new-connection-mark=ECMP/ether1 passthrough=no add chain=postrouting routing-table=main out-interface=ether2 connection-state=new action=mark-connection new-connection-mark=ECMP/ether2 passthrough=no

Давайте разберём.

chain=postrouting — Работаем в цепочке по факту того, что уже выбрал ECMP, можно использовать и цепочку forward, но тогда не попадёт трафик который был сгенерирован самим маршрутизатором.

routing-table=main — Маршрут ECMP находиться в main таблице.

out-interface=ether1 — ECMP выбрал шлюз, который лежит через первый интерфейс

connection-state=new — Мы маркируем соединение, нет смысла работать со всеми пакетами.

action=mark-connection new-connection-mark=ECMP/ether1 — маркируем соединение.

Ещё раз, мы дали возможность ECMP выбрать направление и мы уже по факту промаркировали соединения, основываясь на выборе интерфейса.

А теперь все последующие пакеты в соединениях с такой маркировкой должны быть отправлены в тот же интерфейс, но не в таблицу main, так как там работает ECMP, нам это уже не к чему.

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

/ip firewall mangle add chain=prerouting connection-mark=ECMP/ether1 action=mark-routing new-routing-mark=Next-Hop/88.88.88.1 passthrough=no in-interface=!ether1 add chain=prerouting connection-mark=ECMP/ether2 action=mark-routing new-routing-mark=Next-Hop/44.44.44.1 passthrough=no in-interface=!ether2

Почти всё.

Осталось настроить NAT