Bakit muling isinusulat ng wg-quick ang wg0.conf kapag hininto mo ang interface

Nagdaragdag ka ng peer sa /etc/wireguard/wg0.conf, pinapatakbo mo ang systemctl restart wg-quick@wg0, at wala na ang peer sa file sa susunod mong tingin. Walang sumira sa anuman. Ang restart ay isang paghinto na sinusundan ng pagsisimula, at ang hakbang ng paghinto ay maaaring magsulat ng kasalukuyang runtime state sa ibabaw ng file na kaaayos mo lang. Ang setting na may pananagutan ay nasa parehong file na ineedit mo, at iyon ang dahilan kung bakit napakalito ng loop sa unang pagkakataong makatagpo mo ito.

Dalawang estado, isang file, at isang save sa oras ng pag-off

Ang runtime state ng WireGuard at isang wg-quick configuration file ay magkaugnay ngunit magkaiba. Ang file ay input: binabasa ito ng wg-quick, gumagawa ng interface, nagtatakda ng mga address at ruta at nagko-configure ng mga peer. Ang kernel device ang buhay na object, at ang mga low-level na pagbabagong ginawa gamit ang wg ay hindi kailanman nagsusulat pabalik sa sarili nito.

Maliban sa isang direksyon. Kapag lumitaw ang SaveConfig = true sa seksyon ng interface, sine-save ng wg-quick ang buhay na configuration sa file bilang bahagi ng pagbaba ng interface. Ang manual ng wg-quick ay nagbababala tungkol dito mismo: ang mga pagbabagong ginawa sa file habang aktibo ang interface ay maaaring ma-overwrite kapag ito ay inalis. Ito ay save sa oras ng pag-off, hindi background timer, kaya gumagana lamang ito kapag may huminto sa interface.

Basahin ang talahanayan bilang babala tungkol sa pagkakasunod-sunod. Bawat aksidenteng pagkawala sa lugar na ito ay nagmumula sa isang edit na nangyari bago ang isang save sa halip na pagkatapos.

Hinto muna, i-edit pangalawa, simulan sa huli

Kung ang file ang iyong pinagmumulan ng katotohanan, gawing awtoridad ang file sa pamamagitan ng konstruksyon sa halip na pag-asa. Ibaba ang interface, kumpirmahing wala na ito, pagkatapos ay i-edit, pagkatapos ay iangat muli. Simple ang tuntunin: walang edit na umiiral habang ang isang save ay maaari pang tumakbo.

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

Ang backup na linya ay hindi seremonya. Kung ang tunnel ang paraan mo upang maabot ang makinang ito, maaaring tapusin ng hakbang ng pagbaba ang iyong session, at ang kopya sa disk kasama ang isang console o isang out-of-band na landas ang tanging rollback na gumagana. Suriin ang ikalawang linyang iyon bago mo ito pagkatiwalaan: ang lumang pangalan ng interface sa isang script na tahimik na nabibigo ang paraan ng pag-edit ng mga tao sa isang file na buhay pa.

Ang pagtatakda ng SaveConfig = false bago ang isang normal na pagbaba ay ang isa pang tinatanggap na landas, at dapat itong gawin sa file na talagang binabasa ng wg-quick. Pinipigilan nito ang isang awtomatikong save na iyon. Hindi nito pinapapag-load muli ng isang hiwalay na NetworkManager profile, isang router export o isang container entrypoint ang iyong mga edit, dahil ang mga manager na iyon ay hindi binabasa ang file na ito.

Ilapat ang mga pagbabago sa peer nang hindi pinupunit ang interface

Hindi bawat edit ay nangangailangan ng downtime. Ang mga pagbabago sa antas ng peer ay maaaring ilapat sa isang tumatakbong interface sa pamamagitan ng pag-convert ng file sa isang configuration at pag-sync nito, na ganap na umiiwas sa hakbang ng pagbaba at kaya umiiwas sa save:

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

Mahalaga ang hakbang na strip. Ini-print nito ang file na inalis ang mga key na para lamang sa wg-quick, upang ang mga address, DNS at mga routing directive ay hindi mapunta sa isang tool na hindi naiintindihan ang mga ito. Pagkatapos ay inilalapat ng sync ang mga peer at key sa buhay na device nang hindi muling ginagawa ang interface, kaya nabubuhay ang mga umiiral na session at ruta.

Maging tumpak tungkol sa mga limitasyon. Ang pag-sync ng mga peer ay hindi binabago ang address ng interface, ang mga rutang idinagdag ng wg-quick o ang configuration ng resolver, dahil wala sa mga iyon ang pag-aari ng WireGuard device. Ang pagdaragdag ng subnet sa AllowedIPs at pag-asang iruruta ito ng kernel ay ang klasikong maling pagbasa; ang ruta ay dapat idagdag ng wg-quick sa pag-angat o ikaw mismo.

Suriin kung kanino ang interface bago ka mag-edit ng kahit ano

Sa isang desktop o server na pinamamahalaan ng isang configuration system, ang file ay maaaring output sa halip na input. Ang isang koneksyon ng NetworkManager, isang profile na nabuo ng router o isang startup script ng container ay maaaring pagmamay-ari ng parehong pangalan ng interface, at sa kasong iyon ang isang walang kamaliang wg-quick sequence ay nag-e-edit pa rin ng maling artifact.

systemctl status wg-quick@wg0 --no-pager
nmcli connection show | grep -i wireguard
sudo wg showconf wg0 | head -n 5

Ini-print ng ikatlong command ang buhay na configuration sa parehong format ng file, kasama ang private key, na kapaki-pakinabang para sa paghahambing at mapanganib sa isang ticket. I-redact ito bago i-paste; ang private key sa isang support thread ay isang permanenteng kompromiso, hindi isang typo.

Kung ang service unit ay hindi aktibo ngunit umiiral ang interface, may ibang gumawa nito at ang file ay hindi awtoridad. Ang isang obserbasyong iyon ay nakakatipid ng isang oras sa pag-edit ng isang file na walang binabasa.

I-verify ang susunod na restart, pagkatapos ay panatilihin ang isang rollback

Ang test na talagang nagpapatunay ng pag-aayos ay ang ikalawang restart, dahil iyon ang sequence na nabigo sa unang pagkakataon. Kumpirmahing nakakaligtas ang peer at ang buhay na configuration ay tumutugma pa rin sa nasa disk:

sudo systemctl restart wg-quick@wg0
sudo wg show wg0 latest-handshakes
sudo grep -c '^\[Peer\]' /etc/wireguard/wg0.conf

Patakbuhin ang restart nang dalawang beses. Ang isang malinis na pagpasa ay maaaring swerte: ang unang restart ay maaaring kumonsumo ng isang runtime change na hindi pa na-save, kaya ang pangalawa ang nagsasabi sa iyo na ang file at ang runtime ay sumang-ayon sa dulo ng una.

Panatilihin ang backup mula sa simula ng proseso hanggang matapos mo ang dobleng restart, pagkatapos ay burahin ito o ilipat ito sa labas ng configuration directory. Ang isang naligaw na wg0.conf.bak sa tabi ng tunay na file ay hindi mapanganib sa wg-quick at nakakalito sa susunod na tao, na sa huli ay mag-e-edit ng mali.