Miksi wg-quick kirjoittaa wg0.conf-tiedoston uudelleen, kun pysäytät liitännän

Lisäät peerin tiedostoon /etc/wireguard/wg0.conf, suoritat systemctl restart wg-quick@wg0, ja peer on kadonnut tiedostosta, kun katsot seuraavan kerran. Mikään ei korruptoinut mitään. Uudelleenkäynnistys on pysäytys, jota seuraa käynnistys, ja pysäytysvaihe voi kirjoittaa nykyisen ajonaikaisen tilan juuri muokkaamasi tiedoston päälle. Vastuussa oleva asetus sijaitsee samassa tiedostossa, jota muokkasit, ja juuri se tekee silmukasta niin hämmentävän, kun kohtaat sen ensimmäisen kerran.

Kaksi tilaa, yksi tiedosto ja tallennus sammutuksen aikana

WireGuardin ajonaikainen tila ja wg-quickin määritystiedosto liittyvät toisiinsa mutta ovat erilaisia. Tiedosto on syöte: wg-quick lukee sen, luo liitännän, asettaa osoitteet ja reitit ja määrittää peerit. Ytimen laite on elävä objekti, eivätkä wg:lla tehdyt matalan tason muutokset koskaan kirjoita itseään takaisin.

Paitsi yhteen suuntaan. Kun liitännän osiossa on SaveConfig = true, wg-quick tallentaa elävän määrityksen tiedostoon osana liitännän alasajoa. wg-quickin käsikirja varoittaa juuri tästä: liitännän ollessa käynnissä tiedostoon tehdyt muutokset voidaan korvata, kun se poistetaan. Se on sammutuksen aikainen tallennus, ei taustalla toimiva ajastin, joten se laukeaa vain, kun jokin pysäyttää liitännän.

Lue taulukko varoituksena järjestyksestä. Jokainen tahaton menetys tällä alueella johtuu muokkauksesta, joka tapahtui ennen tallennusta eikä sen jälkeen.

Pysäytä ensin, muokkaa toiseksi, käynnistä viimeiseksi

Jos tiedosto on totuutesi lähde, tee tiedostosta valtuutettu rakenteella etkä toivolla. Aja liitäntä alas, varmista että se on poissa, muokkaa sitten ja nosta se sitten takaisin. Sääntö on yksinkertainen: yhtään muokkausta ei ole olemassa, kun tallennus voi vielä käynnistyä.

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

Varmuuskopiorivi ei ole seremoniallinen. Jos tunneli on tapasi päästä tähän koneeseen, alasajovaihe voi lopettaa istuntosi, ja kopio levyllä sekä konsoli tai kaistan ulkopuolinen reitti on ainoa toimiva palautus. Tarkista se toinen rivi ennen kuin luotat siihen: vanhentunut liitännän nimi skriptissä, joka epäonnistuu hiljaa, on tapa, jolla ihmiset muokkaavat tiedostoa, joka on vielä elossa.

SaveConfig = false:n asettaminen ennen normaalia alasajoa on toinen hyväksytty tapa, ja se on tehtävä tiedostossa, jota wg-quick todella lukee. Se estää tuon yhden automaattisen tallennuksen. Se ei saa erillistä NetworkManager-profiilia, reitittimen vientiä tai kontin käynnistyspistettä lataamaan muokkauksiasi uudelleen, koska ne hallitsijat eivät lue tätä tiedostoa lainkaan.

Käytä peer-muutoksia repimättä liitäntää alas

Jokainen muokkaus ei vaadi katkosta. Peer-tason muutokset voidaan kohdistaa käynnissä olevaan liitäntään muuntamalla tiedosto määritykseksi ja synkronoimalla se, mikä välttää alasajovaiheen kokonaan ja siten välttää tallennuksen:

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

strip-vaihe on tärkeä. Se tulostaa tiedoston ilman vain wg-quickille kuuluvia avaimia, jotta osoitteet, DNS ja reititysohjeet eivät mene työkaluun, joka ei ymmärrä niitä. Synkronointi kohdistaa sitten peerit ja avaimet elävään laitteeseen luomatta liitäntää uudelleen, joten olemassa olevat istunnot ja reitit säilyvät.

Ole täsmällinen rajoista. Peerien synkronointi ei muuta liitännän osoitetta, wg-quickin lisäämiä reittejä tai resolverin määritystä, koska mikään niistä ei kuulu WireGuard-laitteeseen. Aliverkon lisääminen AllowedIPs:ään ja odottaminen, että ydin reitittää sen, on klassinen väärinluku; reitti on lisättävä wg-quickin toimesta ylösnoston yhteydessä tai sinun itsesi.

Tarkista, kuka omistaa liitännän, ennen kuin muokkaat mitään

Määritysjärjestelmän hallitsemalla työpöydällä tai palvelimella tiedosto voi olla tuloste eikä syöte. NetworkManager-yhteys, reitittimen luoma profiili tai kontin käynnistysskripti voivat kaikki omistaa saman liitännän nimen, ja siinä tapauksessa virheetön wg-quick-jakso muokkaa silti väärää artefaktia.

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

Kolmas komento tulostaa elävän määrityksen samassa muodossa kuin tiedosto, yksityinen avain mukaan lukien, mikä on hyödyllistä vertailuun ja vaarallista tikettissä. Peitä se ennen liittämistä; yksityinen avain tukiketjussa on pysyvä vaarantuminen, ei kirjoitusvirhe.

Jos palveluyksikkö on passiivinen mutta liitäntä on olemassa, jokin muu loi sen eikä tiedosto ole valtuutettu. Se yksi havainto säästää tunnin tiedoston muokkaamista, jota mikään ei lue.

Varmista seuraava uudelleenkäynnistys ja pidä sitten palautus

Testi, joka todella todistaa korjauksen, on toinen uudelleenkäynnistys, koska juuri se jakso epäonnistui ensimmäisellä kerralla. Varmista, että peer selviää siitä ja että elävä määritys vastaa edelleen sitä, mikä on levyllä:

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

Suorita uudelleenkäynnistys kahdesti. Yksi puhdas läpikäynti voi olla onnea: ensimmäinen uudelleenkäynnistys voi kuluttaa ajonaikaisen muutoksen, jota ei ollut vielä tallennettu, joten toinen on se, joka kertoo sinulle, että tiedosto ja ajo olivat samaa mieltä ensimmäisen lopussa.

Pidä varmuuskopio prosessin alusta, kunnes olet tehnyt kaksinkertaisen uudelleenkäynnistyksen, poista se sitten tai siirrä se määrityshakemiston ulkopuolelle. Eksynyt wg0.conf.bak oikean tiedoston vieressä on wg-quickille harmiton ja seuraavalle henkilölle hämmentävä, joka lopulta muokkaa väärää.