Hvorfor wg-quick skriver om wg0.conf når du stopper grensesnittet

Du legger til en peer i /etc/wireguard/wg0.conf, kjører systemctl restart wg-quick@wg0, og peeren er borte fra filen neste gang du ser etter. Ingenting ødela noe. En omstart er en stopp etterfulgt av en start, og stoppsteget kan skrive den gjeldende kjøretidstilstanden tilbake over filen du nettopp redigerte. Innstillingen som er ansvarlig, bor i den samme filen du redigerte, og det er derfor løkken er så forvirrende første gang du møter den.

To tilstander, én fil og en lagring ved nedstenging

WireGuards kjøretidstilstand og en wg-quick-konfigurasjonsfil henger sammen, men er forskjellige. Filen er input: wg-quick leser den, oppretter grensesnittet, setter adresser og ruter og konfigurerer peers. Kjerneenheten er det levende objektet, og endringer på lavt nivå gjort med wg skriver seg aldri tilbake.

Bortsett fra i én retning. Når SaveConfig = true står i grensesnittsdelen, lagrer wg-quick den levende konfigurasjonen til filen som en del av å ta grensesnittet ned. wg-quick-manualen advarer nettopp om dette: endringer i filen mens grensesnittet er oppe kan bli overskrevet når det fjernes. Det er en lagring ved nedstenging, ikke en bakgrunnstimer, så den utløses bare når noe stopper grensesnittet.

Les tabellen som en advarsel om rekkefølge. Hvert utilsiktet tap i dette området kommer fra en redigering som skjedde før en lagring i stedet for etter.

Stopp først, rediger deretter, start til slutt

Hvis filen er sannhetskilden din, gjør filen autoritativ ved konstruksjon i stedet for ved håp. Ta grensesnittet ned, bekreft at det er borte, rediger deretter, og ta det så opp igjen. Regelen er enkel: ingen redigering finnes mens en lagring fortsatt kan kjøre.

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

Sikkerhetskopilinjen er ikke seremoni. Hvis tunnelen er måten du når denne maskinen på, kan nedtakingen avslutte økten din, og en kopi på disken pluss en konsoll eller en out-of-band-vei er den eneste tilbakerullingen som fungerer. Sjekk den andre linjen før du stoler på den: et utdatert grensesnittnavn i et skript som feiler stille, er måten folk redigerer en fil som fortsatt lever.

Å sette SaveConfig = false før en normal nedtaking er den andre aksepterte veien, og det må gjøres i filen wg-quick faktisk leser. Det forhindrer den ene automatiske lagringen. Det får ikke en separat NetworkManager-profil, en rutereksport eller et container-inngangspunkt til å laste inn redigeringene dine på nytt, fordi disse administratorene ikke leser denne filen i det hele tatt.

Bruk peer-endringer uten å rive grensesnittet ned

Ikke hver redigering trenger et avbrudd. Peer-endringer kan brukes på et kjørende grensesnitt ved å gjøre filen om til en konfigurasjon og synkronisere den, noe som helt unngår nedtakingstrinnet og derfor unngår lagringen:

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

strip-trinnet er viktig. Det skriver ut filen med nøkler som bare hører til wg-quick fjernet, slik at adresser, DNS og rutingsdirektiver ikke sendes til et verktøy som ikke forstår dem. Synkroniseringen bruker deretter peers og nøkler på den levende enheten uten å gjenopprette grensesnittet, så eksisterende økter og ruter overlever.

Vær presis om grensene. Synkronisering av peers endrer ikke grensesnittadressen, rutene wg-quick la til eller resolver-konfigurasjonen, fordi ingen av disse tilhører WireGuard-enheten. Å legge til et subnett i AllowedIPs og forvente at kjernen ruter det, er den klassiske feillesningen; ruten må legges til av wg-quick ved oppstart eller av deg.

Sjekk hvem som eier grensesnittet før du redigerer noe

På en stasjonær datamaskin eller en server administrert av et konfigurasjonssystem kan filen være en utdata i stedet for en inndata. En NetworkManager-tilkobling, en ruter-generert profil eller et container-oppstartsskript kan alle eie det samme grensesnittnavnet, og i så fall redigerer en feilfri wg-quick-sekvens fortsatt det gale artefaktet.

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

Den tredje kommandoen skriver ut den levende konfigurasjonen i samme format som filen, inkludert den private nøkkelen, noe som er nyttig for sammenligning og farlig i en sak. Rediger den bort før du limer inn; en privat nøkkel i en støttetråd er en permanent kompromittering, ikke en skrivefeil.

Hvis tjenesteenheten er inaktiv, men grensesnittet finnes, har noe annet opprettet det, og filen er ikke autoritativ. Den ene observasjonen sparer en time med å redigere en fil som ingenting leser.

Verifiser neste omstart og behold deretter en tilbakerulling

Testen som virkelig beviser rettelsen, er en andre omstart, fordi det er sekvensen som feilet første gang. Bekreft at peeren overlever den, og at den levende konfigurasjonen fortsatt samsvarer med det som ligger på disken:

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

Kjør omstarten to ganger. En enkelt ren gjennomkjøring kan være flaks: den første omstarten kan bruke opp en kjøretidsendring som ennå ikke var lagret, så den andre er den som forteller deg at filen og kjøringen var enige ved slutten av den første.

Behold sikkerhetskopien fra starten av prosessen til du har gjort den doble omstarten, og slett den deretter eller flytt den ut av konfigurasjonsmappen. En forvillet wg0.conf.bak ved siden av den ekte filen er harmløs for wg-quick og forvirrende for neste person, som til slutt redigerer den gale.