Чому видалений peer WireGuard повертається після перезавантаження
Список peer зберігають два стани: робочий інтерфейс і те, що записує його під час завантаження. Видаліть його з обох і перевірте SaveConfig, перш ніж щось змінювати.
Ідентичність зникає з робочого інтерфейсу, і зміна виглядає завершеною. Після перезапуску служби вона повертається, що читається як ігнорування команди з боку 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, припиніть повторювати видалення на низькому рівні. Виправте перелік, який читає цей записувач, бо доти кожне перезавантаження — це чергове запрошення ідентичності з'явитися знову.