Зошто 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 и збунувачко за следниот човек, кој на крајот ќе ја уреди погрешната.