Varför wg-quick skriver om wg0.conf när du stoppar gränssnittet

Du lägger till en peer i /etc/wireguard/wg0.conf, kör systemctl restart wg-quick@wg0, och peeren är borta från filen nästa gång du tittar. Inget förstörde något. En omstart är ett stopp följt av en start, och stoppsteget kan skriva det aktuella körtidstillståndet tillbaka över filen du just redigerade. Inställningen som ansvarar för det bor i samma fil som du redigerade, och det är därför loopen är så förvirrande första gången du stöter på den.

Två tillstånd, en fil och en sparning vid avstängning

WireGuards körtidstillstånd och en wg-quick-konfigurationsfil hänger ihop men är olika. Filen är indata: wg-quick läser den, skapar gränssnittet, ställer in adresser och rutter och konfigurerar peers. Kärnenheten är det levande objektet, och ändringar på låg nivå som görs med wg skriver aldrig tillbaka sig själva.

Förutom i en riktning. När SaveConfig = true står i gränssnittsavsnittet sparar wg-quick den levande konfigurationen till filen som en del av att ta ned gränssnittet. wg-quick-manualen varnar just för detta: ändringar i filen medan gränssnittet är uppe kan skrivas över när det tas bort. Det är en sparning vid avstängning, inte en bakgrundstimer, så den utlöses bara när något stoppar gränssnittet.

Läs tabellen som en varning om ordningen. Varje oavsiktlig förlust i detta område kommer från en redigering som skedde före en sparning i stället för efter.

Stoppa först, redigera sedan, starta sist

Om filen är din sanningskälla, gör filen auktoritativ genom konstruktion i stället för genom hopp. Ta ned gränssnittet, bekräfta att det är borta, redigera sedan och ta sedan upp det igen. Regeln är enkel: ingen redigering finns medan en sparning fortfarande kan köra.

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

Säkerhetskopieringsraden är ingen ceremoni. Om tunneln är ditt sätt att nå den här maskinen kan nedtagningen avsluta din session, och en kopia på disken plus en konsol eller en out-of-band-väg är den enda återställning som fungerar. Kontrollera den andra raden innan du litar på den: ett inaktuellt gränssnittsnamn i ett skript som misslyckas tyst är sättet folk redigerar en fil som fortfarande lever.

Att sätta SaveConfig = false före en normal nedtagning är den andra accepterade vägen, och det måste göras i filen som wg-quick faktiskt läser. Det förhindrar den enda automatiska sparningen. Det får inte en separat NetworkManager-profil, en routerexport eller en container-entrypoint att ladda om dina redigeringar, eftersom de hanterarna inte läser den här filen alls.

Tillämpa peer-ändringar utan att slita ned gränssnittet

Inte varje redigering kräver ett avbrott. Peer-ändringar kan tillämpas på ett körande gränssnitt genom att göra om filen till en konfiguration och synkronisera den, vilket helt undviker nedtagningssteget och därför undviker sparningen:

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

Steget strip spelar roll. Det skriver ut filen med nycklar som bara hör till wg-quick borttagna, så att adresser, DNS och routningsdirektiv inte hamnar i ett verktyg som inte förstår dem. Synkroniseringen tillämpar sedan peers och nycklar på den levande enheten utan att återskapa gränssnittet, så befintliga sessioner och rutter överlever.

Var precis om gränserna. Synkronisering av peers ändrar inte gränssnittets adress, rutterna som wg-quick lade till eller resolverkonfigurationen, eftersom ingen av dem tillhör WireGuard-enheten. Att lägga till ett subnät i AllowedIPs och förvänta sig att kärnan routar det är den klassiska felläsningen; rutten måste läggas till av wg-quick vid uppstart eller av dig.

Kontrollera vem som äger gränssnittet innan du redigerar något

På en stationär dator eller en server som hanteras av ett konfigurationssystem kan filen vara en utdata i stället för en indata. En NetworkManager-anslutning, en routergenererad profil eller ett containerstartskript kan alla äga samma gränssnittsnamn, och i så fall redigerar en felfri wg-quick-sekvens fortfarande fel artefakt.

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

Det tredje kommandot skriver ut den levande konfigurationen i samma format som filen, inklusive den privata nyckeln, vilket är användbart för jämförelse och farligt i en biljett. Redigera bort den innan du klistrar in; en privat nyckel i en supporttråd är en permanent kompromiss, inte ett skrivfel.

Om tjänsteenheten är inaktiv men gränssnittet finns, har något annat skapat det och filen är inte auktoritativ. Den enda observationen sparar en timme av att redigera en fil som ingenting läser.

Verifiera nästa omstart och behåll sedan en återställning

Testet som verkligen bevisar rättelsen är en andra omstart, eftersom det är sekvensen som misslyckades första gången. Bekräfta att peeren överlever den och att den levande konfigurationen fortfarande stämmer 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

Kör omstarten två gånger. En enda ren genomgång kan vara tur: den första omstarten kan förbruka en körtidsändring som ännu inte hade sparats, så den andra är den som säger att filen och körningen var överens i slutet av den första.

Behåll säkerhetskopian från början av processen tills du har gjort den dubbla omstarten, radera den sedan eller flytta den utanför konfigurationskatalogen. En förirrad wg0.conf.bak bredvid den riktiga filen är ofarlig för wg-quick och förvirrande för nästa person, som till slut redigerar fel.