Пир WireGuard исчезает после перезагрузки: найдите настоящую конфигурацию

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

Воспроизведите это один раз намеренно

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

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

Кто владеет интерфейсом?

У самого WireGuard нет ни демона, ни файла конфигурации. Что-то над ним вызывает wg при загрузке, и это что-то — источник истины. Обычные кандидаты — [email protected], профиль соединения NetworkManager, сетевой юнит конкретного дистрибутива или панель управления, которая пишет собственную базу данных.

Спросите систему, а не документацию вашего дистрибутива. systemctl status wg-quick@wg0 и nmcli connection show обычно решают вопрос одной командой каждый. Если оба претендуют на интерфейс, вы нашли ошибку ещё до любых правок: два владельца переписывают одно и то же устройство при каждом старте, и побеждает тот, кто выполнится последним.

systemctl status wg-quick@wg0 --no-pager
grep -R "Address\|SaveConfig\|PostUp" /etc/wireguard/wg0.conf
nmcli -g NAME,TYPE connection show
wg show wg0 peers

Состояние во время работы и состояние при запуске — не один и тот же файл

wg set управляет живым устройством через netlink. Он не записывает /etc/wireguard/wg0.conf, профиль NetworkManager или базу данных панели. Успешный wg show после этого доказывает, что ядро приняло пир, а не что что-то его восстановит.

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

NetworkManager ведёт себя иначе: он владеет профилем и применяет его при активации, поэтому отредактированный вручную .conf рядом с активным соединением NetworkManager — просто украшение. Выберите одного владельца интерфейса и попросите второго менеджера его не трогать.

Добейтесь, чтобы правка попала в оба места

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

# 1. persistent state (wg-quick owner)
sudo vi /etc/wireguard/wg0.conf

# 2. apply through the owner, not by hand
sudo systemctl restart wg-quick@wg0

# 3. verify runtime matches the file
sudo wg show wg0
sudo wg showconf wg0

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

Докажите, что он переживает событие жизненного цикла

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

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