Почему удалённый peer WireGuard возвращается после перезагрузки

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

Этот список хранят два состояния. Отзыв реален только тогда, когда его теряют оба.

Что на самом деле меняет wg set

Команда wg set wg0 peer <public-key> remove правит работающий интерфейс в ядре. Она ничего не пишет на диск. Файл конфигурации, профиль NetworkManager или сохранённое состояние маршрутизатора остаются нетронутыми. Это замысел, а не ошибка.

Такое разделение намеренно, ведь инструмент не знает, кому принадлежит интерфейс. Команда времени выполнения должна быть безопасной для интерфейса, которым управляет что-то другое. Она не может угадать, где живёт долговечная копия. Следствие легко сформулировать: удаление во время работы по своей конструкции временное.

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

Найдите того, кто пишет, прежде чем править файл

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

Начните с работающего интерфейса и определите открытые ключи, поскольку имена и адреса — более слабые идентификаторы, чем сам ключ. Затем сравните этот список с сохранённой конфигурацией, которую владелец действительно читает.

wg show wg0 peers
wg show wg0 allowed-ips
systemctl status wg-quick@wg0 --no-pager
ls -l /etc/wireguard

Живой интерфейс, у которого список peer и содержимое файла не совпадают, — это весь диагноз. Сохранённая конфигурация побеждает при загрузке, а состояние времени выполнения проигрывает. Сравните их, прежде чем менять любое из двух.

Ловушка SaveConfig

wg-quick добавляет складку, которая ловит тех, кто правит файлы вручную. Когда SaveConfig включён, его документированное поведение при остановке записывает текущее состояние времени выполнения поверх файла конфигурации.

Это переворачивает обычное направление сохранности. Вы удаляете peer из файла, затем служба останавливается. Работающее состояние записывается поверх вашей правки и восстанавливает только что удалённый peer.

Поэтому порядок важен: правьте файл, пока интерфейс опущен, или отключите SaveConfig перед правкой, затем поднимите интерфейс снова и убедитесь, что загрузилось. Правка вручную при поднятом интерфейсе — это гонка с записью при остановке.

Измените оба состояния, затем перезагрузите

Во время работы удалите peer по ключу. В сохранённой конфигурации удалите тот же блок поддерживаемой операцией владельца, а не правкой вокруг него.

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

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

Как выглядит пройденный тест

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

wg show wg0 peers
wg show wg0 allowed-ips
sudo wg-quick down wg0 && sudo wg-quick up wg0
wg show wg0 peers

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

Если какой-то менеджер продолжает восстанавливать peer, прекратите повторять удаление на низком уровне. Исправьте перечень, который читает этот писатель, потому что до тех пор каждая перезагрузка — очередное приглашение идентичности появиться снова.