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

Ключевые выводы:

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

Изменение файла с последующим reload подходит для пиров внутри уже маршрутизируемой подсети.

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

Для каких условий подходит управление пирами WireGuard?

Процедура рассчитана на Ubuntu 24.04 LTS, инструменты WireGuard из дистрибутива и нативную службу systemd wg-quick@wg0. Она составлена по официальной документации; полного сквозного авторского тестирования не проводилось. Ниже перечислены ожидаемые признаки, которые проверяете вы, а не фактически полученные автором результаты. Обязанности владельца описывает обзор обслуживания собственной сети.

В примере сервер уже работает по адресу 10.77.0.1/24, существующее устройство использует 10.77.0.2, а 10.77.0.3 свободен. Подставьте собственную непересекающуюся подсеть. Это управление жизненным циклом устройств, а не установка сервера или инструкция для панели. Если различие ключей и пиров пока неясно, прочитайте, как WireGuard распознаёт стороны соединения.［1］

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

Шаг 1: Согласуйте работающий и сохранённый список пиров

Запрашивайте только поля, не выводящие закрытые ключи:

sudo systemctl is-active wg-quick@wg0
sudo wg show wg0 peers
sudo wg show wg0 allowed-ips
sudo wg show wg0 latest-handshakes
sudo wg show wg0 transfer

В приватном локальном редакторе сравните открытые ключи с секциями [Peer] файла /etc/wireguard/wg0.conf. Запишите владельца устройства, ключ, назначенный адрес, дату разрешения и состояние допуска либо отзыва. Открытый ключ служит идентификатором, но сама таблица раскрывает частную инфраструктуру; не публикуйте её. Не прикладывайте к заявке wg showconf, wg show ... dump, полный профиль или QR-код.［4］

Здесь используется управление через файл: SaveConfig должен отсутствовать либо иметь значение false. При true завершение работы сохраняет состояние интерфейса поверх файла и может уничтожить ваши правки. Если параметр включён, сначала согласуйте все намеренные изменения работающего интерфейса с файлом, создайте защищённую копию, затем уберите параметр до любого выключения. Не выполняйте wg-quick save вслепую поверх уже отредактированной конфигурации.［3］

Через независимую консоль создайте уникальную резервную копию, доступную только root, например:

sudo install -d -m 700 /root/wg-peer-backups
sudo test ! -e /root/wg-peer-backups/wg0.before-peer-change.conf
sudo install -m 600 /etc/wireguard/wg0.conf /root/wg-peer-backups/wg0.before-peer-change.conf

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

Шаг 2: Добавьте устройство с отдельным адресом

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

(
  set -eu
  umask 077
  mkdir wg-new-device
  cd wg-new-device
  wg genkey > private.key
  wg pubkey < private.key > public.key
)

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

Передайте администратору только public.key по аутентифицированному каналу. Закрытый ключ оставьте на устройстве; ключ старого ноутбука не копируйте. Перед назначением 10.77.0.3/32 проверьте реестр адресов и работающий список allowed-ips. Повторяющиеся или пересекающиеся диапазоны пиров могут направлять трафик не тому устройству даже при корректном синтаксисе обоих файлов.［1］［4］

Через sudoedit добавьте секцию в существующий серверный файл. Замените прописной заполнитель полным открытым ключом нового устройства; сохраните интерфейс и остальные секции:

[Peer]
# new-device
PublicKey = NEW_DEVICE_PUBLIC_KEY
AllowedIPs = 10.77.0.3/32

В новом клиенте задайте его собственный закрытый ключ, Address = 10.77.0.3/32, прежний открытый ключ сервера, Endpoint и только нужные диапазоны назначения. Не переносите серверный AllowedIPs в клиент без учёта разных ролей. Для раздельной маршрутизации к серверной подсети клиент может использовать 10.77.0.0/24; для существующего полного туннеля сохраните его маршруты, DNS, IPv6 и политику при разрыве. Эта инструкция не расширяет охват трафика.［2］

Шаг 3: Проверьте сохранение пиров WireGuard после применения

Сохраните проверенный файл, оставьте владельца root и режим 0600, затем перезагрузите настройки активной службы:

sudo systemctl reload wg-quick@wg0
sudo wg show wg0 peers
sudo wg show wg0 allowed-ips

Ubuntu описывает reload как способ добавления и удаления пиров без пересоздания существующих туннелей. Он меняет параметры WireGuard, но не адреса интерфейса, системные маршруты, правила межсетевого экрана и DNS-хуки. Новый /32 в примере находится внутри существующей подключённой подсети /24; новая маршрутизируемая подсеть требует отдельной проверки маршрутов и иногда обслуживания с restart. Не используйте reload как универсальное перенастраивание сети.［2］

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

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

Шаг 4: Как выполнить отзыв устройства WireGuard?

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

sudo wg set wg0 peer REVOKED_DEVICE_PUBLIC_KEY remove

Сначала замените заполнитель. Затем удалите соответствующую секцию [Peer] целиком из файла, сохраните его, выполните reload и убедитесь, что ключ отсутствует в wg show wg0 peers. В отдельном журнале отметьте ключ, дату, причину и затронутые копии. Удаление только из работающего состояния временно; удаление только из файла оставляет текущую авторизацию до применения изменений.［4］

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

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

Шаг 5: Какие проверки нужны после перезагрузки и восстановления?

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

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

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

Шаг 6: Безопасно восстановите случайно удалённое устройство

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

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

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

Итоги

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

Часто задаваемые вопросы (FAQ)

Редактирование файла сразу отзывает пир?

Само редактирование не меняет работающий интерфейс. Удалите активный пир или примените проверенный файл через reload, затем отдельно подтвердите отказ и сохранение состояния.

Достаточно ли reload после добавления подсети?

Reload меняет параметры пиров, но не создаёт системные маршруты. Проверьте маршрутизацию новой подсети и запланируйте соответствующее изменение сети отдельно.

Стоит ли устройствам использовать один закрытый ключ?

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

Старое время рукопожатия доказывает отзыв?

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

Можно восстановить копию, сделанную до утечки?

Используйте доверенные настройки только после удаления всех позднее отозванных идентичностей. Старая копия не содержит последующих решений о доступе.

Замена открытого ключа остановит оплату сервера?

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

Что делать при потере административного соединения?

Откройте заранее проверенную независимую консоль и восстановите узкое изменение. Не продолжайте удалённые правки через единственный уже неисправный туннель.

Источники:

WireGuard — Quick Start — https://www.wireguard.com/quickstart/
Ubuntu — Common tasks in WireGuard VPN — https://ubuntu.com/server/docs/how-to/wireguard-vpn/common-tasks/
Ubuntu Noble — wg-quick(8) — https://manpages.ubuntu.com/manpages/noble/man8/wg-quick.8.html
Ubuntu Noble — wg(8) — https://manpages.ubuntu.com/manpages/noble/man8/wg.8.html

Sources checked 11 октября 2026 г.

Рекомендуемые статьи:

Управление пирами WireGuard: добавление и отзыв доступа