Nawawala ang peer ng WireGuard pagkatapos ng restart: hanapin ang tunay na configuration

Ang peer na idinagdag mo gamit ang wg set ay sumasagot sa ping buong hapon at nawawala pagkatapos ng reboot. Walang nasira: hindi kailanman iniimbak ng kernel ang peer na iyon sa ibang lugar maliban sa live na interface, at ang anumang muling gumagawa ng interface sa boot ay itinayo ito mula sa file na hindi mo hinawakan. Ang pag-aayos ay hindi isa pang wg set. Ito ay ang alamin kung aling bahagi ang nagmamay-ari ng interface, i-edit ang estado ng bahaging iyon, at pagkatapos ay patunayan na ang peer ay nakakaligtas sa eksaktong pangyayari sa lifecycle na nagtanggal dito.

Ulitin ito nang isang beses, nang sadya

Huwag ayusin ang problema sa restart hanggang makita mo itong nangyayari. Kung may access sa console o out-of-band, itala ang listahan ng peer, i-restart sa pamamagitan ng serbisyo na nagmamay-ari ng interface, at ihambing. Kung naroon pa rin ang peer, naabot na ng iyong pagbabago ang permanenteng estado at mali ang dine-debug mong pangyayari.

Itala ang tatlong katotohanan habang ginagawa ito: ang pangalan ng interface, ang unit o profile na nagpasimula nito, at kung na-reset ang handshake counter ng natirang peer. Ang na-reset na counter ay nangangahulugang sinira at muling ginawa ang interface; ang hindi nagbago na counter na may nawawalang peer ay nangangahulugang may nag-edit ng configuration sa ilalim ng iyong paa.

Sino ang nagmamay-ari ng interface?

Ang WireGuard mismo ay walang daemon at walang configuration file. May isang bagay sa itaas nito na tumatawag sa wg sa boot, at ang bagay na iyon ang pinagmumulan ng katotohanan. Ang karaniwang kandidato ay [email protected], isang profile ng koneksyon ng NetworkManager, isang unit ng network na partikular sa distribusyon, o isang panel ng pamamahala na nagsusulat ng sarili nitong database.

Tanungin ang system, hindi ang dokumentasyon ng iyong distribusyon. Ang systemctl status wg-quick@wg0 at nmcli connection show ay karaniwang nilulutas ito sa tig-isang utos. Kung pareho nilang inaangkin ang interface, natagpuan mo na ang bug bago ka pa mag-edit ng kahit ano: dalawang may-ari ang nagsusulat muli ng parehong device sa bawat simula, at ang huling tumatakbo ang nananalo.

systemctl status wg-quick@wg0 --no-pager
grep -R "Address\|SaveConfig\|PostUp" /etc/wireguard/wg0.conf
nmcli -g NAME,TYPE connection show
wg show wg0 peers

Ang estado sa pagtakbo at ang estado sa pagsisimula ay hindi parehong file

wg set ay nagmamanipula ng live na device sa pamamagitan ng netlink. Hindi nito isinusulat ang /etc/wireguard/wg0.conf, isang profile ng NetworkManager, o ang database ng isang panel. Ang matagumpay na wg show pagkatapos ay nagpapatunay na tinanggap ng kernel ang peer, hindi na may magbabalik nito.

May pangalawang bitag sa kabaligtaran ng direksyon. Ang opsyong SaveConfig ng wg-quick ay nagsusulat ng kasalukuyang estado ng interface pabalik sa configuration file kapag ibinababa ang interface. Kapag naka-enable ito, ang edit na ginawa sa file habang nakaupo ang interface ay maaaring ma-overwrite ng pagsasara na sumusunod, at isusumpa mong naroon ang linyang iyon. Kung paulit-ulit na bumabalik ang peer, basahin ang file pagkatapos ng paghinto, hindi bago.

Iba na naman ang pag-uugali ng NetworkManager: pagmamay-ari nito ang profile at inilalapat ito sa activation, kaya ang manu-manong na-edit na .conf sa tabi ng aktibong koneksyon ng NetworkManager ay dekorasyon lamang. Pumili ng isang may-ari para sa interface at hayaan ang kabilang manager na huwag itong galawin.

Siguraduhing makarating ang pagbabago sa dalawang lugar

I-edit muna ang permanenteng estado, hayaang ilapat ito ng may-ari, pagkatapos ay i-verify ang live na estado. Ang pagkakasunod-sunod na iyon ay nangangahulugang ang kabiguan sa anumang hakbang ay tumuturo sa isang bagay sa halip na tatlo.

# 1. persistent state (wg-quick owner)
sudo vi /etc/wireguard/wg0.conf

# 2. apply through the owner, not by hand
sudo systemctl restart wg-quick@wg0

# 3. verify runtime matches the file
sudo wg show wg0
sudo wg showconf wg0

wg showconf ay nagpi-print ng live na configuration sa parehong syntax na ginagamit ng file, kaya direktang maihahambing ang dalawa. Ituring na lihim ang output na iyon: may mga pribadong key ito, kaya huwag itong i-paste sa ticket o chat channel. Ihambing ang mga pampublikong key ng peer at ang mga pinapayagang IP, at tingnan na hindi bumalik ang peer na sadyang tinanggal mo.

Patunayan na nakakaligtas ito sa pangyayari sa lifecycle

I-restart sa pamamagitan ng may-ari sa pangalawang pagkakataon, pagkatapos ay kumpirmahin ang tatlong hiwalay na bagay: lumalabas ang peer sa wg show, tumataas ang handshake counter pagkatapos ng trapiko, at talagang sumasagot ang application na umaasa sa tunnel. Ang peer na nakalista na may lumang handshake ay problema sa routing o key, hindi problema sa pagpapatuloy, at ang pagkakaibang iyon ay nagtitipid ng walang saysay na edit sa configuration.

Sa huli, tingnan kung ano ang naibalik ng restart. Ang restart na bumabuhay sa peer na sadyang tinanggal mo ay ang parehong bug na kabaligtaran ang senyales, at karaniwang nangangahulugang may lumang kopya pa ng configuration na naglo-load mula sa kung saan. Itala ang may-ari, ang path ng file, ang pampublikong key ng peer at ang mga utos ng verification sa tabi ng configuration, para hindi ito muling matuklasan ng susunod na tao sa pamamagitan ng pag-restart ng production host.