Защо изтрит WireGuard peer се връща след рестарт

Идентичността изчезва от работещия интерфейс и промяната изглежда завършена. След като услугата се рестартира, тя се връща, което изглежда като 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-а, спрете да повтаряте премахването на ниско ниво. Оправете инвентара, който този записващ чете, защото дотогава всеки рестарт е още една покана идентичността да се появи отново.