На удалённом объекте стоит контроллер. Он управляет насосами, вентиляцией или чем-то столь же полезным и столь же неприятным в ремонте. В объект заведён мобильный интернет: проводного канала нет, роутер с SIM-картой висит под потолком щитовой. Вы звоните оператору и просите открыть входящий порт, а в ответ слышите вежливое: такой услуги нет, адрес общий, порты не пробрасываются. Контроллер работает, телеметрия, возможно, уходит куда надо, но зайти на него изнутри вашей сервисной группы нельзя. Любая диагностика превращается в поездку за сотни километров ради одной перезагрузки.
Эта статья про то, как построить дорогу, которой не нужна дверь снаружи. Идея простая: если нельзя позвонить на объект, пусть объект сам позвонит вам. Точкой встречи станет ваш VPS с постоянным публичным адресом. А вот как сделать эту дорогу узкой, чтобы она вела к одному устройству, а не к целой сети объекта, мы разберём отдельно: это не менее важная часть задачи, чем сам туннель.
Два адреса, которые не стоит путать
У контроллера есть адрес в локальной сети объекта: допустим, из частного диапазона вроде 192.168.x.x. Он понятен только тем, кто находится в этой же сети. Для интернета у объекта есть другой адрес, внешний, и он принадлежит не вам, а оператору. При обычном проводном подключении этот внешний адрес выдаётся одному клиенту, и на роутере можно настроить проброс: пакеты, пришедшие на такой-то порт, отправляются на такой-то внутренний хост.
В мобильных сетях часто работает иначе: один внешний адрес оператора делят между многими абонентами, а трансляцию адресов выполняет оборудование оператора. Это и называют CGNAT. Ваш роутер получает адрес из внутреннего пространства оператора, оператор подменяет его на общий внешний, и всё, что вы настроили на своём роутере, оказывается лишь первой ступенью двухступенчатой лестницы. Вторая ступень вам не принадлежит. Проброс порта на вашем роутере бесполезен: входящий пакет из интернета до него просто не дойдёт, потому что оператор не знает, кому из тысяч абонентов он адресован.
Отсюда неочевидное следствие. Внешний адрес объекта, который показывает любой сервис «узнать свой IP», — это адрес выхода оператора, а не адрес контроллера и даже не адрес вашего роутера. Записывать его в инструкции для техников бессмысленно. Он может быть общим для многих и менять привязку, когда соединение переустановится.
Важная оговорка: речь идёт о ситуации, когда оператор не даёт входящие подключения. Мы не пытаемся обойти его ограничения силой и не обещаем, что схема заработает при любых настройках сети. Мы используем то, что почти всегда разрешено: клиент может сам открыть исходящее соединение к серверу в интернете.
Объект звонит первым
Исходящее соединение — единственный вид трафика, для которого CGNAT устроен без сюрпризов. Когда роутер или устройство на объекте отправляет пакет на ваш VPS, оборудование оператора запоминает: эта внутренняя пара «адрес и порт» связана с таким-то внешним портом, и ответы с VPS нужно вернуть обратно. Пока запись жива, по ней идёт трафик в обе стороны. Туннель между объектом и VPS пользуется именно этим: объект делает первый шаг, а VPS отвечает.
Тут пригодится документация по NetBird про порты и межсетевые экраны. Там описано, что участники сети, которые называются peers, сами инициируют исходящие соединения и используют NAT traversal, а когда прямой путь невозможен, предусмотрен relay — ретрансляция через промежуточный узел (NetBird: порты и межсетевые экраны). Для сервисной команды это практический вывод: схему можно проектировать так, чтобы ей не требовалось ни одного входящего правила на стороне объекта. В обычной жизни прямой путь между объектом и инженером за ноутбуком иногда не получается, и тогда трафик идёт кружным путём через ретранслятор. Это медленнее, зато работает.
Есть и тонкость, которую легко упустить. Внешний порт, который оператор присвоил соединению, не вечен. В той же документации сказано, что наблюдаемый внешний NAT-порт другого peer может измениться, поэтому правило, составленное по однажды увиденному значению, не гарантирует постоянный доступ. Для нас это аргумент против любых схем вида «посмотрим, какой порт сейчас у объекта, и пропишем его у себя». Адрес и порт на стороне объекта — величины переменные. Постоянной должна быть другая точка: VPS с известным адресом, к которому объект будет возвращаться снова и снова.
Что на самом деле делает VPS
Роль у сервера скромнее, чем может показаться. Он не хранит данные объекта и не управляет контроллером. Он только даёт два свойства: постоянный публичный адрес, потому что у вас, в отличие от мобильного абонента, он есть, и место, где встречаются два исходящих соединения — от объекта и от рабочего места инженера. Если ваша команда использует WireGuard, сервер становится peer с известной конечной точкой, а объект подключается к нему как клиент. Если вы выбрали платформу вроде NetBird, сервер может стать узлом управления или местом, где живут ретрансляторы. Принципы одни, различается только упаковка.
Для WireGuard полезно помнить две вещи из краткого руководства. У каждого peer есть пара закрытого и открытого ключей, и именно по ним участники узнают друг друга, а не по IP-адресам. Команда wg show выводит состояние интерфейса и показывает, видел ли peer рукопожатие (WireGuard Quick Start). Для техники на объекте это важная привычка: проверять не «пингуется ли что-то», а когда последний раз был обмен с этим конкретным peer.
Вторая вещь — параметр PersistentKeepalive. В документации он описан как способ поддерживать состояние NAT; по умолчанию он выключен, и нужен не каждой конфигурации. Для объекта за CGNAT он обычно нужен: если устройство молчит, оператор в какой-то момент забывает запись о соединении, и VPS уже не сможет первым достучаться до объекта. Периодическое «я здесь» с объекта держит запись живой. Конкретный интервал стоит подбирать испытанием на вашей SIM-карте и у вашего оператора, а не брать из чужих примеров: слишком редкий пакет не удержит запись, слишком частый зря расходует трафик на тарифе с лимитом.
Теперь про сам сервер. Для роли точки встречи не нужна мощная машина: туннелям и управляющему плоскому трафику хватает скромных ресурсов, а вот предсказуемый публичный адрес и root-доступ нужны всегда. Из тарифной линейки MAATRIX для первого теста разумно взять самый компактный план Ba — 1 vCPU, 2 ГБ RAM, 40 ГБ NVMe. Но это отправная точка для проверки, а не обещание ёмкости: сколько объектов и сколько одновременных сессий она выдержит, покажет ваш замер. Если вы собираетесь держать на том же сервере панель управления сетью и журналы, ресурсов понадобится больше, и тогда имеет смысл перейти к Uab (2 vCPU, 4 ГБ, 80 ГБ) или выше. Локацию сервера выбирают по задержке до инженеров и по тому, где допустимо хранить служебные данные: доступны Россия, США, Франция и Великобритания, но точный набор образов и наличие в конкретной локации уточняйте в форме заказа.
Туннель не равен допуску к объекту
Самая частая ошибка при подобных схемах — построить дорогу и забыть спросить, куда она ведёт. Туннель поднят, объект подключён, сервисная группа в той же сети. И вот уже инженер, который хотел перезапустить один контроллер, видит всю подсеть объекта: камеры, кассу, принтеры, чьи-то ноутбуки. Технически это удобно, организационно — повод для будущих разбирательств. Если один из ноутбуков команды окажется скомпрометирован, злоумышленник получит такой же доступ.
Разумнее с самого начала разделить два вопроса. Первый: кто может подключиться к вашей сети, то есть получить туннель. Второй: что именно разрешено делать внутри нее. Для второго в NetBird есть понятие Network: оно объединяет ресурсы, routing peers и политики доступа, а ресурсом может быть один IP, диапазон CIDR или домен. Доступ к ресурсу за routing peer требует разрешающей политики, и его можно ограничить одним хостом вместо всей подсети (NetBird Networks).
На нашем примере это выглядит так. На объекте есть маленькое устройство, например миниатюрный компьютер или сам роутер, который умеет быть routing peer: он выходит в туннель и знает, как добраться до внутренней сети. Контроллер находится за ним по адресу из локального диапазона. Вместо того чтобы публиковать весь диапазон объекта, вы описываете как ресурс единственный адрес контроллера и создаёте политику: группе «сервисная команда» разрешён доступ к этому ресурсу и только к нему. Остальные устройства объекта для сервисной группы не существуют: до них нет маршрута и нет правила.
Даже если вы выбрали не NetBird, а чистый WireGuard, принцип тот же. Список разрешённых адресов для каждого peer и правила межсетевого экрана на VPS и на объекте должны описывать конкретный адрес и конкретный порт, а не «всё». Если контроллер отвечает по веб-интерфейсу, разрешайте порт веб-интерфейса, а не весь хост. Если нужен SSH, то пусть он идёт отдельным правилом, которое можно выдавать на время и отзывать. Это самая прозаическая часть работы, но именно она отличает аккуратный сервисный канал от лазейки.
Заодно полезно помнить, что у любой точки входа есть судьба. Такие маршруты легко забывают, когда проект закончился, а доступ остался. О похожей проблеме для тестовых окружений мы писали в материале про тестовый сервер с копией боевой базы: забытая точка входа опасна не потому, что она сложная, а потому, что про неё перестали помнить. Для сервисного канала действует то же правило: у каждого ключа и каждой политики должен быть владелец и дата пересмотра.
Нужен сервер под эту задачу?
Разверните VPS MAATRIX за пару минут: NVMe, AMD EPYC, root-доступ, локации Россия, США, Франция и Великобритания. Оплата картой РФ и по СБП.
Условный пример: один контроллер и одна SIM-карта
Возьмём пример без привязки к реальной модели, чисто для иллюстрации. Допустим, на объекте стоит промышленный контроллер с сетевым портом и веб-интерфейсом. Рядом — мобильный роутер с SIM-картой, за которым проложена маленькая локальная сеть: контроллер и пара вспомогательных устройств. Оператор выдаёт адрес за CGNAT.
- На VPS поднимается точка встречи: либо WireGuard с известным публичным адресом, либо компонент выбранной платформы. Сервер получает постоянный адрес и открытый порт под сам туннель, остальное закрыто.
- Объект получает собственную пару ключей или собственную идентичность peer. В нашем примере устройством-посредником служит небольшой компьютер рядом с роутером, а не сам контроллер: на контроллере нельзя поставить стороннее ПО, и это нормально.
- Посредник сам подключается к VPS. Входящих правил на роутере нет, проброса нет. Для поддержания записи о соединении у оператора включён keepalive, интервал выбран по результатам пробы на этой SIM-карте.
- Контроллер описывается как единственный ресурс, а сервисной группе выдаётся политика на него. Для остальных устройств на объекте маршрута нет.
- Инженер подключается со своего ноутбука к той же сети через VPS, открывает адрес контроллера и видит страницу диагностики так, будто сидит на объекте.
Что здесь важно: ни одно звено цепочки не требует от оператора связи ничего необычного. Объект звонит наружу, сервер отвечает, а граница доступа проходит по одной записи в политике, а не по настройкам чужого оборудования.
Когда связь пропала и как объекту вернуться
Мобильный интернет капризен: сигнал на объекте может исчезать, питание может мигнуть, SIM-карта может оказаться на лимите. Хорошая схема не должна зависеть от того, что всё всегда стабильно. Она должна уметь возвращаться сама.
Начнём с того, что именно происходит при обрыве. Пока объект недоступен, запись о соединении у оператора со временем исчезает. Когда связь восстанавливается, объект получает, скорее всего, другой внутренний адрес у оператора и новое внешнее сопоставление. С точки зрения VPS peer теперь приходит с другого адреса и порта. И здесь снова работает та самая мысль о непостоянстве внешнего порта: сервер не должен ждать объект по старым данным, а должен принять новое рукопожатие, как только объект его инициирует. В WireGuard это естественно: peer узнаётся по ключу, а не по адресу, и сервер обновляет конечную точку, когда приходит корректный пакет от известного ключа. Поэтому ваша задача на стороне объекта — чтобы туннель поднимался автоматически после старта и после потери связи, а не вручную.
Проверить это нужно честно, пока техник ещё на объекте или пока вы можете вызвать кого-то на месте. Минимальный набор проверок такой:
- перезагрузить посредника и убедиться, что туннель поднялся без участия человека;
- отключить питание роутера, дождаться возвращения мобильной сети и снова проверить туннель;
- посмотреть на VPS через wg show (или в панели платформы), когда было последнее рукопожатие с этим peer;
- открыть сервис контроллера уже после перезапуска, а не ограничиваться пингом;
- записать, сколько времени объект возвращался в сеть, — это пригодится как ориентир, но не как обещание.
Если связь не возвращается, диагностику разумно вести от внешнего к внутреннему. Сначала вопрос к самому объекту: есть ли у роутера мобильная сеть вообще, не закончился ли пакет трафика, не заблокировал ли оператор какой-либо вид трафика. Затем вопрос к туннелю: приходят ли хоть какие-то пакеты на VPS, видит ли сервер попытки подключения. Затем вопрос к политике: не отозван ли ключ, не истёк ли срок разрешения. И только в конце — к самому контроллеру. Такой порядок экономит время: большинство «пропавших» объектов оказываются просто без интернета.
Отдельно о случаях, когда прямое соединение между инженером и объектом не получается. В платформах, которые умеют NAT traversal, при неудаче трафик пойдёт через relay — и это отражено в упомянутой выше документации NetBird. Для техподдержки это значит, что скорость и задержка могут меняться в зависимости от пути: страница веб-интерфейса контроллера, которая на прямом соединении открывается мгновенно, через ретранслятор может открываться заметно дольше. Это не авария, но стоит заранее предупредить сервисную группу, чтобы она не принимала медленную загрузку за поломку.
Если же оператор блокирует тот тип трафика, на котором работает ваш туннель, схему придётся менять: другой порт, другой транспорт или другой канал связи. Мы не обещаем, что исходящее соединение разрешено всегда и везде; но проверить его до выезда техника на объект гораздо дешевле, чем после.
Что нужно технику до выезда и во время диагностики
Хорошо построенный канал бесполезен, если инженер не знает, как им пользоваться. Поэтому сведения для сервисной группы лучше собрать в короткую карточку объекта — один абзац или одна таблица на устройство. Вот что в ней стоит держать.
| Сведение | Зачем оно технику |
|---|---|
| Название объекта и роль устройства | Чтобы не искать нужный адрес среди похожих имён |
| Адрес контроллера в локальной сети объекта | Это единственный ресурс, доступный по политике |
| Что именно разрешено: веб-интерфейс, SSH, другой порт | Чтобы не тратить время на попытки там, где правила нет |
| Устройство-посредник и способ его перезапуска | Если пропала связь, нужен понятный первый шаг для человека на месте |
| Оператор, тип SIM и условия тарифа | Лимит трафика и ограничения влияют на интервал keepalive и на диагностику |
| Время последнего успешного рукопожатия или контакта | Отличает «объект выключен» от «объект есть, но не отвечает» |
| Владелец доступа и срок пересмотра политики | Чтобы канал не пережил проект, ради которого его открыли |
Отдельно подготовьте то, что нужно, если выезд всё-таки неизбежен: что взять с собой, какой кабель, какая запасная SIM-карта, к кому обратиться на объекте. Удалённая диагностика редко отменяет поездки целиком, но она позволяет ехать с точным диагнозом: не «что-то не отвечает», а «питание контроллера в порядке, сетевой порт молчит, нужен новый патч-корд».
Хорошая практика — хранить ключи peer отдельно для каждого объекта. Тогда потерянное устройство или уволенный подрядчик не требуют перенастройки всей сети: достаточно отозвать один ключ или одну политику. Для сервисных инженеров стоит завести отдельные учётные записи или отдельные ключи, а не один общий на всех: так в журнале видно, кто и когда подключался к контроллеру.
Где живёт всё это хозяйство
Теперь, когда ясно, что делает сервер в этой схеме, можно честно оценить, что от него нужно. Постоянный публичный адрес, root-доступ для установки нужных компонентов и предсказуемая сеть. VPS MAATRIX на NVMe с процессорами AMD EPYC подходит для такой роли, а оплата картой РФ или по СБП и создание сервера в течение пары минут после оплаты позволяют быстро поднять стенд для пробы. Практичный порядок действий такой: взять небольшой план, подключить к нему один тестовый объект или один имитирующий его роутер, пройти проверки перезапуска, а уже потом масштабировать. Нагрузку на сервер от пары десятков туннелей лучше измерить на ваших данных, чем угадать по характеристикам.
Если вы планируете держать на этом же сервере что-то ещё, например хранилище документов по объектам, то в каталоге предложены варианты с установкой Nextcloud, а для автоматизации уведомлений — n8n. Но наличие конкретного образа и операционной системы проверяйте в форме заказа, а не предполагайте заранее. И помните, что смешивать служебный канал к оборудованию с другими сервисами на одном сервере — решение, которое нужно обдумать отдельно: чем больше на сервере разных сервисов, тем тщательнее придётся описывать, кто к чему имеет доступ.
Граница, которая делает канал надёжным
Вернёмся к контроллеру в щитовой. Он по-прежнему сидит за мобильным интернетом, у оператора по-прежнему нет услуги входящих портов, а адрес объекта по-прежнему принадлежит тысячам абонентов сразу. Но теперь это перестало быть препятствием. Маленький посредник на объекте сам выходит к вашему VPS, держит запись о соединении живой, возвращается в сеть после каждого обрыва и открывает инженеру ровно одну дверь: страницу диагностики и, если нужно, один порт одного устройства.
Когда в следующий раз что-то пойдёт не так, техник откроет карточку объекта, подключится к сети и посмотрит, жив ли контроллер, когда было последнее рукопожатие и что показывает его журнал. Иногда это закончится удалённой перезагрузкой в три клика. Иногда диагностика покажет, что на объект всё-таки нужно ехать, но с нужной деталью в сумке. А остальные устройства объекта останутся именно там, где им положено быть, — за границей, которую вы провели сами и можете в любой момент проверить, сузить или закрыть.