Защо wg-quick презаписва wg0.conf, когато спрете интерфейса

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

Две състояния, един файл и запазване при изключване

Състоянието на WireGuard по време на изпълнение и конфигурационният файл на wg-quick са свързани, но различни. Файлът е вход: wg-quick го чете, създава интерфейса, задава адреси и маршрути и конфигурира партньори. Устройството на ядрото е живият обект и промените на ниско ниво, направени с 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, експорт на рутер или входна точка на контейнер да презаредят редакциите ви, защото тези мениджъри изобщо не четат този файл.

Прилагайте промени по партньорите, без да разкъсвате интерфейса

Не всяка редакция изисква прекъсване. Промените на ниво партньор могат да се приложат към работещ интерфейс чрез превръщане на файла в конфигурация и синхронизирането ѝ, което напълно избягва стъпката на сваляне и следователно избягва запазването:

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

Стъпката strip е важна. Тя отпечатва файла с премахнати ключове, които са само за wg-quick, така че адресите, DNS и директивите за маршрутизация да не се подават на инструмент, който не ги разбира. След това синхронизацията прилага партньорите и ключовете към живото устройство, без да пресъздава интерфейса, така че съществуващите сесии и маршрути оцеляват.

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

Третата команда отпечатва живата конфигурация в същия формат като файла, включително частния ключ, което е полезно за сравнение и опасно в тикет. Редактирайте го преди поставяне; частен ключ в тема за поддръжка е трайно компрометиране, а не печатна грешка.

Ако сервизната единица е неактивна, но интерфейсът съществува, нещо друго го е създало и файлът не е авторитетен. Това единствено наблюдение спестява час редактиране на файл, който никой не чете.

Проверете следващото рестартиране, после запазете възможност за връщане

Тестът, който действително доказва поправката, е второ рестартиране, защото точно тази последователност се провали първия път. Потвърдете, че партньорът оцелява и че живата конфигурация все още съвпада с това, което е на диска:

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