Waarom wg-quick wg0.conf herskryf wanneer jy die koppelvlak stop

Jy voeg ’n peer by /etc/wireguard/wg0.conf, hardloop systemctl restart wg-quick@wg0, en die peer is weg uit die lêer wanneer jy weer kyk. Niks het enigiets beskadig nie. ’n Herbegin is ’n stop gevolg deur ’n begin, en die stopstap kan die huidige looptydtoestand terugskryf oor die lêer wat jy pas gewysig het. Die instelling wat daarvoor verantwoordelik is, woon in dieselfde lêer wat jy gewysig het, en dit is wat die lus so verwarrend maak die eerste keer dat jy dit teëkom.

Twee toestande, een lêer en ’n stoor by afskakeling

WireGuard se looptydtoestand en ’n wg-quick-konfigurasielêer hou verband maar is tog verskillend. Die lêer is invoer: wg-quick lees dit, skep die koppelvlak, stel adresse en roetes in en konfigureer peers. Die kerntoestel is die lewende objek, en laevlakveranderinge wat met wg gemaak word, skryf nooit hulself terug nie.

Behalwe in een rigting. Wanneer SaveConfig = true in die koppelvlakafdeling verskyn, stoor wg-quick die lewende konfigurasie in die lêer as deel van die afbring van die koppelvlak. Die wg-quick-handleiding waarsku presies hieroor: veranderinge wat aan die lêer gemaak word terwyl die koppelvlak op is, kan oorskryf word wanneer dit verwyder word. Dit is ’n stoor by afskakeling, nie ’n agtergrondtydhouer nie, so dit werk net wanneer iets die koppelvlak stop.

Lees die tabel as ’n waarskuwing oor volgorde. Elke toevallige verlies in hierdie area kom van ’n wysiging wat voor ’n stoor plaasgevind het in plaas van daarna.

Stop eerste, wysig tweede, begin laaste

As die lêer jou bron van waarheid is, maak die lêer gesaghebbend deur konstruksie eerder as deur hoop. Bring die koppelvlak af, bevestig dat dit weg is, wysig dan, en bring dit dan weer op. Die reël is eenvoudig: geen wysiging bestaan terwyl ’n stoor nog kan loop nie.

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

Die rugsteunreël is nie seremonie nie. As die tonnel jou manier is om hierdie masjien te bereik, kan die afstap jou sessie beëindig, en ’n kopie op skyf plus ’n konsole of buitebandroete is die enigste terugrol wat werk. Kontroleer daardie tweede reël voordat jy dit vertrou: ’n verouderde koppelvlaknaam in ’n skrip wat stilweg misluk, is hoe mense ’n lêer wysig wat nog lewendig is.

Om SaveConfig = false voor ’n normale afstap te stel, is die ander aanvaarde roete, en dit moet in die lêer gedoen word wat wg-quick werklik lees. Dit verhoed daardie een outomatiese stoor. Dit maak nie dat ’n aparte NetworkManager-profiel, ’n router-uitvoer of ’n houer-intreepunt jou wysigings herlaai nie, want daardie bestuurders lees glad nie hierdie lêer nie.

Pas peer-veranderinge toe sonder om die koppelvlak af te breek

Nie elke wysiging benodig ’n onderbreking nie. Peer-vlakveranderinge kan op ’n lopende koppelvlak toegepas word deur die lêer in ’n konfigurasie te omskep en dit te sinchroniseer, wat die afstap heeltemal vermy en dus die stoor vermy:

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

Die strip-stap maak saak. Dit druk die lêer met slegs-wg-quick-sleutels verwyder, sodat adresse, DNS en roeteringsopdragte nie aan ’n gereedskap gevoer word wat hulle nie verstaan nie. Die sinchronisasie pas dan peers en sleutels op die lewende toestel toe sonder om die koppelvlak te herskep, sodat bestaande sessies en roetes oorleef.

Wees presies oor die grense. Die sinchronisering van peers verander nie die koppelvlakadres, die roetes wat wg-quick bygevoeg het, of die oplosserkonfigurasie nie, want nie een van daardie dinge behoort aan die WireGuard-toestel nie. Om ’n subnet by AllowedIPs te voeg en te verwag dat die kern dit sal roeteer, is die klassieke verkeerde lees; die roete moet deur wg-quick by opstaptyd of deur jou bygevoeg word.

Kontroleer wie die koppelvlak besit voordat jy enigiets wysig

Op ’n lessenaar of ’n bediener wat deur ’n konfigurasiestelsel bestuur word, kan die lêer ’n uitset eerder as ’n invoer wees. ’n NetworkManager-verbinding, ’n router se gegenereerde profiel of ’n houer se beginskrip kan almal dieselfde koppelvlaknaam besit, en in daardie geval wysig ’n foutlose wg-quick-reeks steeds die verkeerde artefak.

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

Die derde opdrag druk die lewende konfigurasie in dieselfde formaat as die lêer, privaatsleutel ingesluit, wat nuttig is vir vergelyking en gevaarlik in ’n kaartjie. Verwyder dit voordat jy dit plak; ’n privaatsleutel in ’n ondersteuningsdraad is ’n permanente kompromie, nie ’n tikfout nie.

As die dienseenheid onaktief is maar die koppelvlak bestaan, het iets anders dit geskep en die lêer is nie gesaghebbend nie. Daardie enkele waarneming spaar ’n uur se wysig van ’n lêer wat niks lees nie.

Verifieer die volgende herbegin en hou dan ’n terugrol

Die toets wat die regstelling werklik bewys, is ’n tweede herbegin, want dit is die reeks wat die eerste keer misluk het. Bevestig dat die peer dit oorleef en dat die lewende konfigurasie steeds ooreenstem met wat op skyf is:

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

Voer die herbegin twee keer uit. ’n Enkele skoon slaag kan geluk wees: die eerste herbegin kan ’n looptydverandering verbruik wat nog nie gestoor is nie, so die tweede is die een wat jou vertel dat die lêer en die looptyd aan die einde van die eerste ooreengestem het.

Hou die rugsteun van die begin van die proses totdat jy die dubbele herbegin gedoen het, en verwyder dit dan of skuif dit uit die konfigurasiegids. ’n Verdwaalde wg0.conf.bak langs die regte lêer is onskadelik vir wg-quick en verwarrend vir die volgende persoon, wat uiteindelik die verkeerde een sal wysig.