Netmaker: веб-панель управления mesh-сетью на WireGuard

MAATRIX

Netmaker уже установлен, панель открывается по адресу вида https://netmaker.example.com, а первый узел, возможно, даже подключён — и тут начинается вопрос, с которым сталкивается почти каждый администратор: как быть с новой сетью для второго проекта, где посмотреть, почему узел не в статусе online, и что делать, если один из ноутбуков потерян и его ключ WireGuard нужно немедленно аннулировать. Разберём интерфейс панели по разделам — что где находится и какие действия закрывают эти задачи без единой правки конфига руками.

Разделы веб-панели: что где искать

Если Netmaker ещё не установлен, сначала пройдите установку — она разобрана в статье про установку Netmaker через Docker. Здесь предполагается, что стек уже поднят и вход в панель по MASTER_KEY или учётной записи администратора пройден.

Навигация в актуальных версиях панели построена вокруг нескольких разделов в боковом меню:

• Hosts — все физические машины (или контейнеры/VM) с установленным netclient, независимо от того, в какую сеть они входят. Один host может состоять сразу в нескольких сетях.
• Networks — список сетей (адресных пространств); внутри каждой сети — свой список узлов-участников, ACL-матрица и настройки DNS.
• Enrollment Keys — ключи регистрации для присоединения новых хостов без ручной генерации токена в CLI.
• Users — учётные записи, которые имеют доступ к панели, и их роли.
• Metrics / Graph — топология сети в виде графа и базовые метрики соединений.

Названия пунктов меню и их порядок отличаются между релизами — в версиях до 0.20 разделение на «Hosts» и «Nodes» было не таким явным, узел и хост были синонимами. Смысл раздела ищите по функции, а не только по точному названию: если пункта «Hosts» нет, аналогичные действия обычно лежат в разделе Nodes.

Создаём и настраиваем сеть через панель

Раздел Networks → Create Network уже был показан в статье про установку — здесь стоит остановиться на настройках, которые обычно упускают при первом создании сети:

• Address Range (IPv4) и опционально Address Range (IPv6) — задаются один раз при создании и на практике не меняются задним числом без пересоздания сети, так что закладывайте диапазон с запасом (/24 вместо /28, даже если узлов пока пять);
• Default ACL — переключатель, разрешены ли узлы друг другу по умолчанию сразу после присоединения; для сети, где заранее известен ограниченный круг ролей (например, только продакшен-серверы), логичнее выключить и открывать доступ парами вручную;
• DNS — Netmaker может вести собственную зону для сети и резолвить имена узлов (node-name.network-name) внутри mesh; включается в настройках сети, но требует, чтобы клиенты использовали DNS-сервер Netmaker или ресолвили через /etc/hosts, который генерирует netclient — на практике DNS-режим Netmaker менее надёжен, чем прямая адресация по IP, и многие администраторы держат его выключенным.

Открыв уже созданную сеть, вы попадаете на её страницу с несколькими вкладками: список узлов сети, ACL-матрица (кто с кем может соединяться внутри этой конкретной сети), и настройки — диапазон адресов, DNS, список egress/relay-узлов. Изменить адресный диапазон существующей сети через UI обычно нельзя — единственный надёжный путь при необходимости расширить пространство адресов — создать новую сеть и перевести узлы.

ACL-матрица — это таблица «узел × узел» с переключателями allow/deny для каждой пары. Открывается на странице сети: Networks → название сети → Access Control. Изменения применяются сразу, без перезапуска — панель рассылает обновлённые правила netclient-агентам при следующей синхронизации, обычно это занимает несколько секунд.

Управляем узлами: статусы, детали, действия

Список узлов — самая используемая страница в повседневной работе. У каждой записи видно:

• имя хоста и внутренний IP в подсети сети;
• статус — online/offline, обычно с временем последней синхронизации;
• публичный эндпоинт — внешний адрес и порт, через который узел доступен для WireGuard-соединений;
• версию netclient — полезно при диагностике, если после обновления сервера старые агенты ведут себя иначе.

Клик по узлу открывает карточку с деталями и меню действий. Типичный набор:

Настройка egress- и ingress-шлюзов подробно разобрана в статье про установку — здесь важно только знать, что это делается прямо со страницы узла, без правки iptables руками: Netmaker сам добавляет и убирает правила форвардинга при включении и отключении шлюза.

Статус offline дольше пары минут при живом сервере почти всегда означает проблему на стороне самого узла, а не панели — процесс netclient, смена публичного IP или закрытый исходящий трафик к MQTT-брокеру. Общие причины обрывов и их диагностика разобраны в статье про частые ошибки WireGuard на сервере — большая часть подходит и для узлов Netmaker, поскольку под капотом это тот же WireGuard.

Ключи регистрации: выдаём доступ новым узлам без ручных токенов

Раздел Enrollment Keys заменяет ручную генерацию токена через CLI, которая была показана в статье про установку. Создание ключа в панели — Enrollment Keys → Create Key — даёт больше контроля, чем разовая команда:

• тип ограничения — по числу использований (ключ работает N раз и становится недействителен) или по времени действия (ключ жив до конкретной даты);
• сети — один ключ можно привязать сразу к нескольким сетям, тогда новый узел при регистрации присоединяется ко всем указанным одновременно;
• теги — метки, которые автоматически проставляются узлам, зарегистрированным по этому ключу; удобно для последующей фильтрации в ACL или отчётах.

Практический сценарий: для подрядчика, которому нужен временный доступ к одной сети на неделю, создаётся ключ с ограничением по времени и по числу использований (например, 1 использование, срок действия 7 дней). После истечения срока или использования ключ автоматически становится недействующим, и его не нужно отдельно отзывать — в отличие от ручных токенов, которые оставались рабочими, пока их явно не удаляли.

Сгенерированный ключ панель показывает в двух видах: как строку токена для команды netclient join -t <TOKEN>, и как готовый one-liner для копипаста на новый узел — это тот же принцип, что показан в статье об установке, только без захода в CLI сервера за токеном.

Ротация ключей WireGuard через панель

Ключи WireGuard в Netmaker не статичны: у каждого узла есть пара приватный/публичный ключ, которую панель может перегенерировать по требованию, не трогая физический доступ к машине. Это и есть то, что в CLI-подходе к WireGuard требует ручной пересборки конфига на каждой стороне.

Перегенерация запускается со страницы узла — кнопка Refresh Keys (в некоторых версиях подписана как Regenerate Keys или спрятана в выпадающем меню действий узла). После нажатия происходит следующее:

1. Панель генерирует новую пару ключей и сохраняет её как ожидающую для этого узла.
2. При следующей синхронизации netclient на самом узле получает команду обновить локальный ключ и пересоздать интерфейс WireGuard.
3. Панель автоматически рассылает новый публичный ключ всем узлам, которые должны видеть этот узел как пира — вручную обновлять [Peer]-блоки на других машинах не нужно.

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

Важный нюанс: перегенерация ключа не меняет внутренний IP узла в mesh-сети и не требует создания нового ключа регистрации — это разные сущности. Enrollment Key нужен один раз, чтобы узел вступил в сеть; ключ WireGuard — это то, чем шифруется сам туннель, и его ротация не затрагивает членство узла в сети или его ACL-настройки.

Если узел временно недоступен (например, выключен), перегенерация всё равно применится на панели сразу, но реально произойдёт только когда netclient снова выйдет на связь и подхватит отложенную команду — узел не потеряет доступ мгновенно, разрыв случится в момент, когда агент применит новый ключ.

Пользователи и роли доступа

Раздел Users управляет тем, кто может входить в саму панель — это отдельный уровень доступа от того, кто состоит в mesh-сети как узел. По умолчанию есть один суперпользователь-администратор, созданный при первом входе по MASTER_KEY.

В базовой (community) редакции модель ролей простая: платформенный администратор с полным доступом и обычный пользователь с более узкими правами на выбранные сети. Более гранулярный RBAC — кастомные роли с точечными правами (например, «может видеть узлы, но не может их удалять», или доступ только на чтение для конкретной сети) — относится к платным уровням Netmaker (Pro/Enterprise) и в открытой версии панели может быть недоступен или ограничен.

Практическая рекомендация для команды из нескольких человек: заводите отдельную учётную запись на каждого, кто работает с панелью, а не делитесь одним MASTER_KEY — так действия в аудит-логе (если он включён) привязаны к конкретному человеку, и при уходе сотрудника достаточно отозвать одну учётную запись, не меняя мастер-ключ для всех.

Диагностика и граф сети из панели

Каждая сеть на странице Networks → название сети показывает граф топологии: узлы — точки, активные WireGuard-туннели между ними — линии. Цвет узла обычно кодирует статус (зелёный — на связи, красный или серый — offline или не синхронизировался долгое время). Это быстрый способ увидеть проблему визуально, не читая логи каждого узла по отдельности: если один узел красный, а соседние с ним линии исчезли — проблема локализована именно на нём, а не в сети целиком.

Клик по узлу в графе открывает ту же карточку деталей, что и из списка Nodes — время последней синхронизации, эндпоинт, версия агента. Базовая метрика трафика через интерфейс (байты отправлено/получено) обычно доступна прямо в карточке узла; более детальная историческая аналитика с графиками во времени в открытой версии панели ограничена и полноценно раскрывается в платных редакциях с интеграцией Prometheus.

Если граф показывает узел как offline, а сам узел уверяет, что жив, порядок диагностики стандартный: проверить процесс netclient на машине, проверить исходящую связность до MQTT-брокера (порт 8883/tcp из требований установки) и посмотреть журнал агента. Отдельные симптомы вроде «хендшейк проходит, а трафика нет» — это уже не про панель, а про сам WireGuard-туннель под ней, и разбираются так же, как в статье про проблему с хендшейком без трафика.

Частые вопросы