WireGuard-peer ferdwynt nei werstart: fyn de echte konfiguraasje

De peer dy't jo mei wg set tafoege hawwe, antwurdet de hiele middei op ping en is nei de werstart fuort. Der is neat skansearre: de kernel hat dy peer nea earne oars beware as yn 'e libbene ynterface, en alles wat de ynterface by it opstarten opnij makket, hat it boud út in bestân dat jo net oanrekke hawwe. De reparaasje is net noch in wg set. It is útfine hokker komponint de ynterface besit, de steat fan dat komponint bewurkje en dan bewize dat de peer krekt dy libbenssyklusbarrens oerlibbet dy't him fuorthelle hat.

Reprodusearje it ien kear, mei opset

Reparaasje gjin werstartprobleem foardat jo it sjen kinne. Mei tagong ta de console of bûten de bân, skriuw de peerlist op, werstart fia de tsjinst dy't de ynterface besit, en fergelykje. As de peer der noch is, hat jo wiziging de persistinte steat al berikt en debugge jo de ferkearde barrens.

Skriuw trije feiten op wylst jo dit dogge: de namme fan 'e ynterface, de ienheid of it profyl dat him starte, en oft de hânskodde-teller op 'e oerlibjende peer weromset is. In weromsette teller betsjut dat de ynterface ferneatige en opnij makke is; in ûnferoare teller mei in ûntbrekkende peer betsjut dat eat de konfiguraasje ûnder jo fuotten bewurke hat.

Wa besit de ynterface?

WireGuard sels hat gjin daemon en gjin konfiguraasjebestân. Eat boppe him ropt wg op by it opstarten, en dat eat is de boarne fan wierheid. De gewoane kandidaten binne [email protected], in NetworkManager-ferbiningsprofyl, in netwurk-ienheid spesifyk foar de distribúsje, of in behearspaneel dat syn eigen databank skriuwt.

Freegje it systeem, net de dokumintaasje fan jo distribúsje. systemctl status wg-quick@wg0 en nmcli connection show meitsje it meastentiids út mei ien opdracht elk. As beide de ynterface opeaskje, hawwe jo de bug fûn foardat jo eat bewurke: twa eigners skriuwe by elke start itselde apparaat oer, en de lêste dy't rint wint.

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

Rintiidsteat en startsteat binne net itselde bestân

wg set manipulearret it libbene apparaat fia netlink. It skriuwt gjin /etc/wireguard/wg0.conf, NetworkManager-profyl of databank fan in paneel. In suksesfolle wg show dêrnei bewist dat de kernel de peer akseptearre hat, net dat eat him werombringe sil.

Der is in twadde falstrik yn 'e oare rjochting. De opsje SaveConfig fan wg-quick skriuwt de hjoeddeistige steat fan 'e ynterface werom yn it konfiguraasjebestân as de ynterface delhellet. Mei dat oan kin in bewurking fan it bestân wylst de ynterface omheech is, oerskreaun wurde troch it útsetten dat folget, en jo sille swarde dat de rigel der wie. As de peer hieltyd weromkomt, lês it bestân nei in stop, net earder.

NetworkManager hâldt him wer oars: hy besit it profyl en past it ta by aktivearring, dus in mei de hân bewurke .conf njonken in aktive NetworkManager-ferbining is allinnich dekoraasje. Kies ien eigner foar de ynterface en lit de oare behearder him gewurde litte.

Soargje dat de bewurking op beide plakken lânet

Bewurkje earst de persistinte steat, lit de eigner it dan tapasse en kontrolearje dan de libbene steat. Dy folchoarder betsjut dat in mislearring by elke stap nei ien ding wiist ynstee fan trije.

# 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 prints de libbene konfiguraasje yn deselde syntaksis as it bestân, wat de twa direkt fergelykber makket. Behandel dy útfier as geheim: hy befettet privee kaaien, plak him dus net yn in ticket of in petearkanaal. Fergelykje de iepenbiere kaaien fan 'e peers en de tastiene IP-adressen, en kontrolearje dat de peer dy't jo mei opset fuorthellen net werom is.

Bewiis dat er de libbenssyklusbarrens oerlibbet

Werstart fia de eigner in twadde kear, befêstigje dan trije aparte dingen: de peer ferskynt yn wg show, de hânskodde-teller groeit nei ferkear, en de applikaasje dy't fan de tunnel ôfhinklik is antwurdet echt. In peer mei in ferâldere hânskodde is in probleem mei routing of kaai, net in probleem mei persistinsje, en dat ûnderskie sparret in nutteloaze konfiguraasjebewurking.

Kontrolearje ta beslút wat de werstart werombrocht hat. In werstart dy't in peer wer libben makket dy't jo mei opset fuorthellen, is deselde bug mei it tsjinoerstelde teken, en it betsjut meastentiids dat in âlde kopy fan 'e konfiguraasje noch earne wei laden wurdt. Skriuw de eigner, it bestânspaad, de iepenbiere kaai fan 'e peer en de kontrôle-opdrachten njonken de konfiguraasje, sadat de folgjende persoan dit net wer ûntdekt troch in produksjeserver te werstarten.