Мосты Mosquitto: связываем два брокера

Дача дышала в домашний брокер на малине исправно: теплица публиковала температуру, реле подчинялось командам. Захотелось смотреть это из города — и первая мысль была правильной по направлению и неправильной по исполнению: пробросить порт 1883 на роутере. Через два дня я заглянул в лог брокера и похолодел: сотни попыток подключения в час от клиентов с именами admin, test, backup — интернет сканирует открывшийся 1883 постоянно, не спрашивая, чей это дом.

Вторая попытка кончилась раньше первой: на дачном тарифе оказался серый адрес от провайдера (CGNAT), и пробрасывать было вообще нечего — у дома нет внешнего порта. Выручило перевёрнутое мышление: не пускать город к дому, а дать дому самому дойти до города. Мост, bridge — режим, в котором ваш локальный mosquitto сам подключается наружу к облачному брокеру как обычный клиент и держит линию.

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

Механика проста: mosquitto с настроенным мостом становится MQTT-клиентом удалённого брокера. Он открывает соединение, подписывается на заданные ветки в заданных направлениях и пересылает сообщения через границу двух брокеров. Со стороны облака это выглядит как ещё один клиент с паспортом и подписками — ничего особенного; ровно та модель издателей и подписчиков, что разобрана в уроке про основы pub-sub: мост публикует свои ветки наружу и подписывается на чужие. Вся конфигурация живёт на вашей стороне, в файле conf.d рядом с настройками из урока про установку брокера.

В конфиге три главных слова. connection — имя моста: оно всплывает в логах и в служебных топиках состояния. address — куда подключаться: хост и порт удалённого брокера. topic — правило пересылки: какая ветка, в каком направлении и с каким качеством обслуживания. Направлений ровно три: out — из дома наружу, in — изнаружи в дом, both — в обе стороны.

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

Разбор направлений с моими границами. dacha/# наружу — телеметрия уезжает в облако, откуда её читает дашборд. cmd/dacha/# внутрь — команды с облачного брокера приезжают в домашний, а дальше всё как обычно: подписка, callback — конвейер приёма разобран в уроке про subscribe и callback, и финальный щелчок реле тот же, что в уроке про модуль реле 220 В: команда до пина, с проверкой payload. both я ставлю осознанно и только на отдельные ветки: двусторонняя пересылка одного и того же топика двумя разными мостами — прямой путь к дублям, об этом ниже.

Тонкость с адресами: в облаке ваша ветка может столкнуться с чужой — не все владельцы брокеров аккуратны с именами. У слова topic есть необязательные суффиксы local-prefix и remote-prefix: приставка подставляется к имени с каждой стороны. Я предпочитаю решать вопрос уникальным префиксом ещё на этапе имён — привычка из урока про публичные брокеры — но если имена уже заняты, приставки спасают без переименования всего дома.

Пара cleansession false — моя любимая строка в конфиге моста. Пока мост отключён — интернет у малины моргнул, провайдер рестартнул оборудование — облачный брокер копит входящие для моста и отдаёт их при восстановлении, если сообщения поедут с QoS 1. С чистой сессией команда, отправленная в момент обрыва, просто исчезнет: насос не включится, а вы будете гадать, кто виноват. restart_timeout 30 задаёт паузу между попытками reconnect — брокер поднимает мост сам, без скриптов и костылей.

Почему мост проходит там, где проброс порта не прошёл. Соединение устанавливает тот, кто за NAT: малина звонит в облако, роутер пропускает исходящий поток, и дальше обе стороны общаются по уже открытому каналу. Облачному брокеру не нужен адрес вашего дома — ему нужен clientId моста. Пусть провайдер меняет внешний адрес хоть каждые сутки: после обрыва мост сам переподключится через restart_timeout, и все подписки восстановятся — та же дисциплина reconnect, что у плат, разобранная в уроке про автопереподключение Wi-Fi, только на стороне брокера. Пока мост жив, линию держит сам протокол: раз в несколько секунд идут пинги туда-обратно, и NAT не рвёт канал, потому что трафик по нему идёт постоянно.

Фраза возврат в дом из моей записки объясняется этой механикой. Город не может дозвониться до дачи — и не пытается: дача стоит на линии, и город говорит по ней. Дашборд шлёт команду на облачный брокер, тот раздаёт её подписчикам, мост — один из подписчиков — забирает команду в локальный брокер, и дальше она едет по домашним веткам как родная. Для дома всё выглядит так, будто команда пришла из соседней комнаты.

Граница применимости, чтобы не ждать от моста лишнего. Он пересылает сообщения и не умеет ничего кроме: не трансформирует payload, не хранит историю, не агрегирует показания. Если нужна логика вида среднее за час или перекладка данных из формата в формат — это задача скетча или серверного скрипта, а не конфига брокера. Мост — труба с фильтром веток, и это ровно та роль, в которой он непобедим.

Петли. Один мост между двумя брокерами не зациклится: мост подписывается на удалённые ветки с флагом no_local, поэтому собственные сообщения, которые он сам же туда доставил, обратно не возвращаются. Ломается это на конфигурациях сложнее пары: три брокера, соединённые мостами в кольцо A-B, B-C, C-A, уже могут гонять одно сообщение по кругу — каждый проход добавляет дубль, а счёт подписчиков у сообщения не ведётся. Моё правило без исключений: топология — звезда или иерархия, кольца не строить.

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

Ограничение, о котором узнают поздно: мост настраивается только на стороне Mosquitto. Облачный брокер — просто брокер: приём подключений, логин, пароль, возможно TLS-сертификат. Никакой панели настроить мост у чужого брокера нет — многие облака предлагают собственные агенты и SDK, но это другие механизмы с другими словами и другой логикой. Если вторая сторона тоже mosquitto, мост можно строить с любого конца — и это вся имеющаяся свобода.