Маршрутизатор за NAT: подключение, одобрение и восстановление связи в Fleetd

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

В знакомстве с Fleetd я упоминал исходящие подключения агентов. Здесь разберём их направление, одобрение устройства и восстановление связи по реализации v0.3.0.

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

Изменить направление подключения

Вместо поиска домашнего маршрутизатора сервером агент сам обращается к серверу. Он устанавливает WebSocket к доступному адресу и использует соединение для метрик и последующих запросов.

И Linux-агенты, и агенты за NAT подключаются к fleetd-server. Сервер хранит данные в PostgreSQL, администратор работает через веб-интерфейс.

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

Условие остаётся: агент должен иметь доступ к серверу. DNS, исходящие правила, прокси и качество сети влияют на результат. Можно использовать публичный домен или доступную частную сеть, в том числе существующий WireGuard.

Работа за NAT означает смену инициатора соединения. Она не обходит запреты исходящего трафика и не делает недоступный сервер доступным сама по себе.

Доступная панель проверяет только один маршрут

Браузер может входить в панель, пока агент не соединяется. Страницы и API — один путь; агенту нужен настроенный WebSocket endpoint, например:

wss://fleetd.example.com/agent/ws

Это пример, домен нужно заменить своим. Обратный прокси должен поддерживать WebSocket Upgrade и не закрывать длительные соединения слишком рано.

Если главная страница открывается, но проксирование WebSocket отсутствует, переустановка агента вряд ли поможет. Сначала проверяются адрес, журналы прокси и ошибка handshake.

Внутри WebSocket Fleetd создаёт зашифрованную Noise-сессию между агентом и сервером. Агент закрепляет публичный ключ сервера: доступность адреса не означает доверия любому ответившему процессу.

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

Сначала подготовить агенты

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

Для постоянного использования создайте собственный ключ выпуска, соберите и загрузите подходящий пакет, затем используйте установочную команду панели. Бинарники v0.3.0 предназначены для Linux amd64 и arm64; архитектуру маршрутизатора нужно проверять.

Первую машину рекомендую подключить с monitor: сначала сеть и метрики, потом решение о командах. Пример формы команды:

curl -fsSL https://fleetd.example.com/install.sh | sh -s -- --permission monitor

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

Скрипт настраивает systemd либо procd, записывает конфигурацию и регистрирует службу. Ключи в настройках имеют разные назначения:

Данные	Проверяемый вопрос
Публичный ключ сервера	Это ожидаемый сервер Fleetd?
Ключ идентичности и отпечаток агента	Кто запрашивает регистрацию?
Публичный ключ подписи команд	Разрешил ли действие доверенный подписант?
Публичный ключ выпусков	Подписал ли обновление доверенный издатель?

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

Ожидание одобрения — предусмотренный этап

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

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

Прочитайте отпечаток в контролируемом терминале установки или через уже доверенное соединение и сравните с панелью. Для установленного агента с правильным путём конфигурации:

fleetd-agent -config /etc/fleetd/agent.yaml fingerprint

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

Одобрение не выдаёт произвольные команды. Агент monitor остаётся наблюдателем; действия требуют подписи и локальных прав. Кнопка одобрения не открывает root-терминал на всех устройствах.

Почему результат одобрения не мгновенный

В v0.3.0 ожидающий агент повторяет подключение примерно раз в минуту. После одобрения он обычно ждёт следующей попытки, затем устанавливает обычную сессию и начинает отчёты. Старая ожидающая сессия не превращается мгновенно в рабочую.

Если спустя несколько секунд данных нет, сначала изучите журнал. Удалять и переустанавливать рано. Минута не является гарантией доступности: DNS, сеть или ключи могут мешать и следующей попытке. Различайте ожидание попытки и уже случившуюся ошибку.

Обычные разрывы имеют другую политику

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

База ожидания начинается с секунды и растёт до 60 секунд. Фактическая задержка включает случайную часть, поэтому обещать восстановление максимум за минуту нельзя. Если прошлая сессия длилась больше минуты, база после её завершения сбрасывается к короткому ожиданию.

Сервер отправляет keepalive. Длительное отсутствие входящего прогресса завершает сеанс и ведёт к переподключению. Эти механизмы восстанавливают связь, но не гарантируют продолжение операций.

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

Жизненный цикл задач разберём в статье о командах; сейчас важно разделить восстановление сети и восстановление работы.

Переименование, новый адрес и переустановка различаются

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

Если переустановка уничтожила ключ, тот же hostname может появиться новым агентом и потребовать проверки. Обратная проблема — клонирование уже зарегистрированной системы вместе с её ключом.

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

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

Удаление не запрещает возвращаться

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

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

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

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

Проверять по этапам

Симптом	Начать с проверки
Служба после установки не работает	Архитектура, скачивание, установка, systemd/procd
Нет ожидающей записи	Endpoint, DNS, исходящая сеть, WebSocket, ключ сервера
Ожидание есть, метрик нет	Отпечаток, одобрение, время следующей попытки
После одобрения всё ещё офлайн	Последний handshake и переход к одобренной сессии
Онлайн, но команды отклоняются	Права, ключи подписантов, адресат и срок действия
После удаления появляется снова	Работает ли агент, нужно ли остановить или отклонить

Для systemd:

systemctl status fleetd-agent
journalctl -u fleetd-agent -n 80 --no-pager

Для OpenWrt / iStoreOS:

/etc/init.d/fleetd-agent status
logread | grep fleetd

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

Небольшая первая проверка

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

Так разобраться проще, чем сразу выдать full всему парку и запускать массовые команды. Доступность, идентичность сервера, идентичность агента и локальные полномочия — отдельные решения. Это делает диагностику и авторизацию понятнее.

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