Чому wg-quick перезаписує wg0.conf, коли ви зупиняєте інтерфейс

Ви додаєте peer до /etc/wireguard/wg0.conf, запускаєте systemctl restart wg-quick@wg0, і при наступному погляді peer зникає з файлу. Ніщо нічого не пошкодило. Перезапуск — це зупинка, за якою йде запуск, і крок зупинки може записати поточний стан виконання поверх файлу, який ви щойно відредагували. Відповідальне налаштування живе в тому самому файлі, який ви редагували, і саме це робить цикл таким заплутаним першого разу.

Два стани, один файл і збереження під час вимкнення

Стан виконання WireGuard і конфігураційний файл wg-quick пов'язані, але різні. Файл — це вхід: wg-quick читає його, створює інтерфейс, задає адреси й маршрути та налаштовує peer'и. Пристрій ядра — живий об'єкт, і низькорівневі зміни, зроблені за допомогою wg, ніколи не записуються назад самі.

За винятком одного напрямку. Коли SaveConfig = true з'являється в розділі інтерфейсу, wg-quick зберігає живу конфігурацію у файл як частину опускання інтерфейсу. Посібник wg-quick попереджає саме про це: зміни, внесені у файл, поки інтерфейс активний, можуть бути перезаписані, коли його видаляють. Це збереження під час вимкнення, а не фоновий таймер, тому воно спрацьовує лише тоді, коли щось зупиняє інтерфейс.

Читайте таблицю як попередження про порядок. Кожна випадкова втрата в цій області походить від редагування, зробленого до збереження, а не після.

Спочатку зупиніть, потім відредагуйте, в кінці запустіть

Якщо файл — ваше джерело істини, зробіть файл авторитетним побудовою, а не надією. Опустіть інтерфейс, переконайтеся, що він зник, потім відредагуйте і потім підніміть його знову. Правило просте: жодного редагування не існує, поки збереження ще може виконуватися.

sudo cp -a /etc/wireguard/wg0.conf /root/wg0.conf.$(date +%F-%H%M)
sudo wg-quick down wg0
ls /sys/class/net/wg0 2>/dev/null || echo "interface is gone"
sudoedit /etc/wireguard/wg0.conf
sudo wg-quick up wg0

Рядок резервної копії — не церемонія. Якщо тунель — ваш шлях до цієї машини, крок опускання може завершити вашу сесію, і копія на диску плюс консоль або позасмуговий шлях — єдиний робочий відкат. Перевірте цей другий рядок, перш ніж довіряти йому: застаріле ім'я інтерфейсу в скрипті, який мовчки зазнає невдачі, — це спосіб, яким люди редагують файл, що ще живий.

Встановлення SaveConfig = false перед звичайним опусканням — інший прийнятний шлях, і це треба зробити у файлі, який wg-quick справді читає. Це запобігає тому єдиному автоматичному збереженню. Це не змушує окремий профіль NetworkManager, експорт маршрутизатора чи точку входу контейнера перезавантажувати ваші редагування, бо ці менеджери взагалі не читають цей файл.

Застосовуйте зміни peer'ів, не розриваючи інтерфейс

Не кожне редагування потребує простою. Зміни на рівні peer'ів можна застосувати до працюючого інтерфейсу, перетворивши файл на конфігурацію та синхронізувавши її, що повністю уникає кроку опускання і тому уникає збереження:

sudo wg syncconf wg0 <(sudo wg-quick strip wg0)
sudo wg show wg0 peers
sudo wg show wg0 latest-handshakes

Крок strip важливий. Він виводить файл з видаленими ключами, що належать лише wg-quick, щоб адреси, DNS і директиви маршрутизації не потрапляли в інструмент, який їх не розуміє. Потім синхронізація застосовує peer'и й ключі до живого пристрою, не створюючи інтерфейс заново, тож наявні сесії та маршрути виживають.

Будьте точні щодо обмежень. Синхронізація peer'ів не змінює адресу інтерфейсу, маршрути, додані wg-quick, чи конфігурацію резолвера, бо ніщо з цього не належить пристрою WireGuard. Додавання підмережі до AllowedIPs і очікування, що ядро її маршрутизуватиме, — класичне хибне прочитання; маршрут має додати wg-quick під час підняття або ви.

Перевірте, кому належить інтерфейс, перш ніж щось редагувати

На настільному комп'ютері чи сервері, яким керує система конфігурації, файл може бути виходом, а не входом. Підключення NetworkManager, профіль, згенерований маршрутизатором, або скрипт запуску контейнера можуть володіти тим самим ім'ям інтерфейсу, і в такому разі бездоганна послідовність wg-quick усе одно редагує не той артефакт.

systemctl status wg-quick@wg0 --no-pager
nmcli connection show | grep -i wireguard
sudo wg showconf wg0 | head -n 5

Третя команда виводить живу конфігурацію в тому самому форматі, що й файл, включно з приватним ключем, що корисно для порівняння й небезпечно в тікеті. Відредагуйте його перед вставленням; приватний ключ у гілці підтримки — це постійна компрометація, а не одрук.

Якщо сервісний модуль неактивний, але інтерфейс існує, його створило щось інше, і файл не є авторитетним. Це одне спостереження економить годину редагування файлу, який ніхто не читає.

Перевірте наступний перезапуск, потім збережіть відкат

Тест, який справді доводить виправлення, — це другий перезапуск, бо саме ця послідовність не вдалася першого разу. Переконайтеся, що peer його переживає і що жива конфігурація досі збігається з тим, що на диску:

sudo systemctl restart wg-quick@wg0
sudo wg show wg0 latest-handshakes
sudo grep -c '^\[Peer\]' /etc/wireguard/wg0.conf

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

Зберігайте резервну копію від початку процесу, доки не зробите подвійний перезапуск, потім видаліть її або перемістіть з каталогу конфігурації. Заблуканий wg0.conf.bak поруч із справжнім файлом нешкідливий для wg-quick і збиває з пантелику наступну людину, яка зрештою відредагує не той.