WireGuard-peer försvinner efter omstart: hitta den riktiga konfigurationen

Peeren du la till med wg set svarar på ping hela eftermiddagen och är borta efter omstarten. Inget skadades: kärnan lagrade aldrig den peeren någon annanstans än i det levande gränssnittet, och allt som återskapar gränssnittet vid start byggde det från en fil som du inte har rört. Reparationen är inte ännu en wg set. Det handlar om att ta reda på vilken komponent som äger gränssnittet, redigera den komponentens tillstånd och sedan bevisa att peeren överlever exakt den livscykelhändelse som tog bort den.

Återskapa det en gång, med avsikt

Åtgärda inte ett omstartsproblem förrän du kan se det hända. Med konsol- eller out-of-band-åtkomst tillgänglig, anteckna peerlistan, starta om via tjänsten som äger gränssnittet och jämför. Om peeren fortfarande finns där har din ändring redan nått det beständiga tillståndet och du felsöker fel händelse.

Skriv ner tre fakta medan du gör detta: gränssnittets namn, enheten eller profilen som startade det, och om handskakningsräknaren på den överlevande peeren nollställdes. En nollställd räknare betyder att gränssnittet förstördes och återskapades; en oförändrad räknare med en saknad peer betyder att något redigerade konfigurationen under fötterna på dig.

Vem äger gränssnittet?

WireGuard självt har ingen daemon och ingen konfigurationsfil. Något ovanför det anropar wg vid start, och det något är sanningens källa. De vanliga kandidaterna är [email protected], en NetworkManager-anslutningsprofil, en distributionsspecifik nätverksenhet eller en administrationspanel som skriver sin egen databas.

Fråga systemet, inte dokumentationen för din distribution. systemctl status wg-quick@wg0 och nmcli connection show avgör det vanligtvis med en kommandorad var. Om båda gör anspråk på gränssnittet har du hittat felet innan du redigerade något: två ägare skriver om samma enhet vid varje start, och den som körs sist vinner.

systemctl status wg-quick@wg0 --no-pager
grep -R "Address\|SaveConfig\|PostUp" /etc/wireguard/wg0.conf
nmcli -g NAME,TYPE connection show
wg show wg0 peers

Körtidstillstånd och starttillstånd är inte samma fil

wg set manipulerar den levande enheten via netlink. Det skriver inte /etc/wireguard/wg0.conf, en NetworkManager-profil eller en panels databas. En lyckad wg show efteråt bevisar att kärnan accepterade peeren, inte att något kommer att återställa den.

Det finns en andra fälla i motsatt riktning. Inställningen SaveConfig i wg-quick skriver det aktuella gränssnittstillståndet tillbaka till konfigurationsfilen när gränssnittet tas ner. Med den aktiverad kan en ändring i filen medan gränssnittet är uppe skrivas över av nedstängningen som följer, och du kommer att svära på att raden fanns där. Om peeren ständigt kommer tillbaka, läs filen efter ett stopp, inte före.

NetworkManager beter sig annorlunda igen: den äger profilen och tillämpar den vid aktivering, så en handredigerad .conf bredvid en aktiv NetworkManager-anslutning är bara dekoration. Välj en ägare för gränssnittet och låt den andra hanteraren lämna det ifred.

Se till att ändringen landar på båda ställena

Redigera det beständiga tillståndet först, låt sedan ägaren tillämpa det och verifiera till sist det levande tillståndet. Den ordningen innebär att ett fel i vilket steg som helst pekar på en sak i stället för tre.

# 1. persistent state (wg-quick owner)
sudo vi /etc/wireguard/wg0.conf

# 2. apply through the owner, not by hand
sudo systemctl restart wg-quick@wg0

# 3. verify runtime matches the file
sudo wg show wg0
sudo wg showconf wg0

wg showconf skriver ut den levande konfigurationen i samma syntax som filen använder, vilket gör de två direkt jämförbara. Behandla den utskriften som en hemlighet: den innehåller privata nycklar, så klistra inte in den i ett ärende eller en chattkanal. Jämför peerarnas publika nycklar och de tillåtna IP-adresserna, och kontrollera att peeren du tog bort med avsikt inte är tillbaka.

Bevisa att den överlever livscykelhändelsen

Starta om via ägaren en andra gång och bekräfta sedan tre separata saker: peeren visas i wg show, handskakningsräknaren ökar efter trafik, och applikationen som är beroende av tunneln svarar faktiskt. En peer som listas med en gammal handskakning är ett routing- eller nyckelproblem, inte ett beständighetsproblem, och den distinktionen sparar en meningslös konfigurationsändring.

Kontrollera slutligen vad omstarten återställde. En omstart som återuppväcker en peer som du tog bort med avsikt är samma bugg med omvänt tecken, och det betyder vanligtvis att en gammal kopia av konfigurationen fortfarande laddas från någonstans. Anteckna ägaren, filsökvägen, peerens publika nyckel och verifieringskommandona bredvid konfigurationen, så att nästa person inte återupptäcker detta genom att starta om en produktionsvärd.