Kvifor wg-quick skriv om wg0.conf når du stoppar grensesnittet

Du legg til ein peer i /etc/wireguard/wg0.conf, køyrer systemctl restart wg-quick@wg0, og peeren er borte frå fila neste gong du ser etter. Ingenting øydela noko. Ein omstart er ein stopp etterfølgd av ein start, og stoppsteget kan skrive den gjeldande køyretidstilstanden tilbake over fila du nettopp redigerte. Innstillinga som er ansvarleg, bur i den same fila du redigerte, og det er derfor løkka er så forvirrande første gong du møter henne.

To tilstandar, éi fil og ei lagring ved nedstenging

WireGuards køyretidstilstand og ei wg-quick-konfigurasjonsfil heng saman, men er ulike. Fila er inndata: wg-quick les henne, opprettar grensesnittet, set adresser og ruter og konfigurerer peers. Kjerneeininga er det levande objektet, og endringar på lågt nivå gjorde med wg skriv seg aldri tilbake.

Bortsett frå i éi retning. Når SaveConfig = true står i grensesnittsdelen, lagrar wg-quick den levande konfigurasjonen til fila som ein del av å ta grensesnittet ned. wg-quick-handboka åtvarar nettopp om dette: endringar i fila medan grensesnittet er oppe kan bli overskrivne når det blir fjerna. Det er ei lagring ved nedstenging, ikkje ein bakgrunnstimer, så ho blir berre utløyst når noko stoppar grensesnittet.

Les tabellen som ei åtvaring om rekkjefølgje. Kvar utilsikta tap i dette området kjem frå ei redigering som skjedde før ei lagring i staden for etter.

Stopp først, rediger deretter, start til slutt

Viss fila er sanningkjelda di, gjer fila autoritativ ved konstruksjon i staden for ved håp. Ta grensesnittet ned, stadfest at det er borte, rediger deretter, og ta det så opp att. Regelen er enkel: inga redigering finst medan ei lagring framleis kan køyre.

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

Sikkerheitskopilinja er ikkje seremoni. Viss tunnelen er måten du når denne maskina på, kan nedtakinga avslutte økta di, og ein kopi på disken pluss ein konsoll eller ein ut-av-band-veg er den einaste tilbakerulleringa som fungerer. Sjekk den andre linja før du stolar på henne: eit utdatert grensesnittnamn i eit skript som feilar stille, er måten folk redigerer ei fil som framleis lever.

Å setje SaveConfig = false før ei normal nedtaking er den andre aksepterte vegen, og det må gjerast i fila wg-quick faktisk les. Det hindrar den eine automatiske lagringa. Det får ikkje ein separat NetworkManager-profil, ein rutareksport eller eit container-inngangspunkt til å laste inn redigeringane dine på nytt, fordi desse administratorane ikkje les denne fila i det heile.

Bruk peer-endringar utan å rive grensesnittet ned

Ikkje kvar redigering treng eit avbrot. Peer-endringar kan brukast på eit køyrande grensesnitt ved å gjere fila om til ein konfigurasjon og synkronisere han, noko som heilt unngår nedtakingsteget og derfor unngår lagringa:

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

strip-steget er viktig. Det skriv ut fila med nøklar som berre høyrer til wg-quick fjerna, slik at adresser, DNS og rutingsdirektiv ikkje blir sende til eit verktøy som ikkje forstår dei. Synkroniseringa brukar deretter peers og nøklar på den levande eininga utan å gjenopprette grensesnittet, så eksisterande økter og ruter overlever.

Ver presis om grensene. Synkronisering av peers endrar ikkje grensesnittadressa, rutene wg-quick la til eller resolver-konfigurasjonen, fordi ingen av desse høyrer til WireGuard-eininga. Å leggje til eit subnett i AllowedIPs og vente at kjernen ruter det, er den klassiske feillesinga; ruta må leggjast til av wg-quick ved oppstart eller av deg.

Sjekk kven som eig grensesnittet før du redigerer noko

På ein stasjonær datamaskin eller ein server administrert av eit konfigurasjonssystem kan fila vere ei utdata i staden for ei inndata. Ei NetworkManager-tilkopling, ein ruter-generert profil eller eit container-oppstartsskript kan alle eige det same grensesnittnamnet, og i så fall redigerer ein feilfri wg-quick-sekvens framleis 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 skriv ut den levande konfigurasjonen i same format som fila, inkludert den private nøkkelen, noko som er nyttig for samanlikning og farleg i ei sak. Rediger han bort før du limer inn; ein privat nøkkel i ein støttetråd er ei permanent kompromittering, ikkje ein skrivefeil.

Viss tenesteeininga er inaktiv, men grensesnittet finst, har noko anna oppretta det, og fila er ikkje autoritativ. Den eine observasjonen sparer ein time med å redigere ei fil som ingenting les.

Verifiser neste omstart og hald deretter ei tilbakerulling

Testen som verkeleg beviser rettinga, er ein andre omstart, fordi det er sekvensen som feila første gong. Stadfest at peeren overlever han, og at den levande konfigurasjonen framleis samsvarer med det som ligg på disken:

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

Køyr omstarten to gonger. Ein einaste rein gjennomkøyring kan vere flaks: den første omstarten kan bruke opp ei køyretidsendring som enno ikkje var lagra, så den andre er den som fortel deg at fila og køyringa var samde ved slutten av den første.

Hald sikkerheitskopien frå starten av prosessen til du har gjort den doble omstarten, og slett han deretter eller flytt han ut av konfigurasjonsmappa. Ein forvilla wg0.conf.bak ved sida av den ekte fila er harmlaus for wg-quick og forvirrande for neste person, som til slutt redigerer den gale.