Пір WireGuard зникає після перезавантаження: знайдіть справжню конфігурацію

Пір, доданий через wg set, працює до наступного перезавантаження, бо інтерфейс перестворюється з файлу або профілю, який ви ніколи не редагували. Спершу знайдіть власника.

Пір, який ви додали через 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, лічильник рукостискань зростає після трафіку, і застосунок, що залежить від тунелю, справді відповідає. Пір зі старим рукостисканням — це проблема маршрутизації або ключа, а не збереження, і це розрізнення економить безглузду правку конфігурації.

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

Схожі статті