Hvorfor wg-quick overskriver wg0.conf, når du stopper grænsefladen

Du tilføjer en peer til /etc/wireguard/wg0.conf, kører systemctl restart wg-quick@wg0, og peeren er væk fra filen, næste gang du ser efter. Intet har ødelagt noget. En genstart er et stop efterfulgt af en start, og stoppet kan skrive den aktuelle kørselstilstand tilbage oven på den fil, du netop har redigeret. Den indstilling, der er ansvarlig, bor i den samme fil, du redigerede, og det er netop derfor, løkken er så forvirrende første gang, du støder på den.

To tilstande, én fil og en gemning ved nedlukning

WireGuards kørselstilstand og en wg-quick-konfigurationsfil hænger sammen, men er forskellige. Filen er input: wg-quick læser den, opretter grænsefladen, sætter adresser og ruter og konfigurerer peers. Kernel-enheden er det levende objekt, og ændringer på lavt niveau foretaget med wg skriver sig aldrig tilbage.

Bortset fra i én retning. Når SaveConfig = true står i grænsefladeafsnittet, gemmer wg-quick den levende konfiguration til filen som en del af at tage grænsefladen ned. wg-quick-manualen advarer netop om dette: ændringer i filen, mens grænsefladen er oppe, kan blive overskrevet, når den fjernes. Det er en gemning ved nedlukning, ikke en baggrundstimer, så den udløses kun, når noget stopper grænsefladen.

Læs tabellen som en advarsel om rækkefølge. Hvert utilsigtet tab i dette område kommer fra en redigering, der skete før en gemning i stedet for efter.

Stop først, rediger derefter, start sidst

Hvis filen er din sandhedskilde, så gør filen autoritativ ved konstruktion i stedet for ved håb. Tag grænsefladen ned, bekræft, at den er væk, rediger derefter, og bring den så op igen. Reglen er enkel: ingen redigering findes, mens en gemning stadig kan kø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

Backup-linjen er ikke ceremoni. Hvis tunnelen er den måde, du når denne maskine på, kan nedtagningen afslutte din session, og en kopi på disken plus en konsol eller en out-of-band-vej er den eneste tilbagerulning, der virker. Tjek den anden linje, før du stoler på den: et forældet grænsefladenavn i et script, der fejler lydløst, er måden, folk redigerer en fil, der stadig er levende.

At sætte SaveConfig = false før en normal nedtagning er den anden accepterede vej, og det skal gøres i den fil, wg-quick faktisk læser. Det forhindrer den ene automatiske gemning. Det får ikke en separat NetworkManager-profil, et router-eksport eller et container-entrypoint til at genindlæse dine ændringer, fordi disse administratorer slet ikke læser denne fil.

Anvend peer-ændringer uden at rive grænsefladen ned

Ikke enhver redigering kræver et afbrud. Peer-ændringer kan anvendes på en kørende grænseflade ved at omdanne filen til en konfiguration og synkronisere den, hvilket helt undgår nedtagningen og derfor undgår gemningen:

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

strip-trinnet er vigtigt. Det udskriver filen med nøgler, der kun hører til wg-quick, fjernet, så adresser, DNS og rutningsdirektiver ikke bliver sendt til et værktøj, der ikke forstår dem. Synkroniseringen anvender derefter peers og nøgler på den levende enhed uden at genskabe grænsefladen, så eksisterende sessioner og ruter overlever.

Vær præcis om grænserne. Synkronisering af peers ændrer ikke grænsefladens adresse, de ruter wg-quick tilføjede, eller resolver-konfigurationen, fordi ingen af disse tilhører WireGuard-enheden. At tilføje et subnet til AllowedIPs og forvente, at kernen ruter det, er den klassiske fejllæsning; ruten skal tilføjes af wg-quick ved opstart eller af dig.

Tjek, hvem der ejer grænsefladen, før du redigerer noget

På en stationær computer eller en server, der styres af et konfigurationssystem, kan filen være et output i stedet for et input. En NetworkManager-forbindelse, en router-genereret profil eller et container-startscript kan alle eje det samme grænsefladenavn, og i så fald redigerer en fejlfri wg-quick-sekvens stadig det forkerte artefakt.

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

Den tredje kommando udskriver den levende konfiguration i samme format som filen, inklusive den private nøgle, hvilket er nyttigt til sammenligning og farligt i en ticket. Rediger den væk, før du indsætter; en privat nøgle i en supporttråd er et permanent kompromis, ikke en tastefejl.

Hvis serviceenheden er inaktiv, men grænsefladen findes, har noget andet oprettet den, og filen er ikke autoritativ. Den ene observation sparer en time med at redigere en fil, som intet læser.

Verificér den næste genstart, og behold så en tilbagerulning

Den test, der faktisk beviser rettelsen, er en anden genstart, fordi det er den sekvens, der fejlede første gang. Bekræft, at peeren overlever den, og at den levende konfiguration stadig svarer til det, der 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 genstarten to gange. En enkelt ren gennemkørsel kan være held: den første genstart kan forbruge en kørselstidsændring, der endnu ikke var gemt, så den anden er den, der fortæller dig, at filen og kørslen var enige ved slutningen af den første.

Behold backuppen fra processens start, indtil du har udført den dobbelte genstart, og slet den derefter eller flyt den ud af konfigurationsmappen. En forvildet wg0.conf.bak ved siden af den rigtige fil er harmløs for wg-quick og forvirrende for den næste person, som til sidst redigerer den forkerte.