WireGuard-peer forsvinder efter genstart: find den rigtige konfiguration

Den peer, du tilføjede med wg set, svarer på ping hele eftermiddagen og er væk efter genstarten. Intet blev beskadiget: kernen gemte aldrig den peer andre steder end i den levende grænseflade, og alt, hvad der genskaber grænsefladen ved opstart, byggede den ud fra en fil, du ikke har rørt. Rettelsen er ikke endnu en wg set. Det handler om at finde ud af, hvilken komponent der ejer grænsefladen, redigere den komponents tilstand og derefter bevise, at peeren overlever netop den livscyklushændelse, der fjernede den.

Genskab det én gang, med vilje

Ret ikke et genstartsproblem, før du kan se det ske. Med adgang via konsol eller out-of-band til rådighed, noter peerlisten, genstart gennem den tjeneste, der ejer grænsefladen, og sammenlign. Hvis peeren stadig er der, har din ændring allerede nået den vedvarende tilstand, og du fejlfinder den forkerte hændelse.

Skriv tre fakta ned, mens du gør det: grænsefladens navn, den unit eller profil, der startede den, og om håndtryks-tælleren på den overlevende peer blev nulstillet. En nulstillet tæller betyder, at grænsefladen blev ødelagt og genskabt; en uændret tæller med en manglende peer betyder, at noget redigerede konfigurationen under dig.

Hvem ejer grænsefladen?

WireGuard selv har ingen daemon og ingen konfigurationsfil. Noget oven over det kalder wg ved opstart, og det noget er sandhedens kilde. De sædvanlige kandidater er [email protected], en NetworkManager-forbindelsesprofil, en distributionsspecifik netværksenhed eller et administrationspanel, der skriver sin egen database.

Spørg systemet i stedet for dokumentationen til din distribution. systemctl status wg-quick@wg0 og nmcli connection show afgør det normalt med én kommando hver. Hvis begge gør krav på grænsefladen, har du fundet fejlen, før du redigerede noget: to ejere omskriver den samme enhed ved hver opstart, og den sidste, der kører, vinder.

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ørselstilstand og opstartstilstand er ikke den samme fil

wg set manipulerer den levende enhed via netlink. Det skriver ikke /etc/wireguard/wg0.conf, en NetworkManager-profil eller et panels database. En vellykket wg show bagefter beviser, at kernen accepterede peeren, ikke at noget vil gendanne den.

Der er en anden fælde i den modsatte retning. wg-quicks indstilling SaveConfig skriver grænsefladens aktuelle tilstand tilbage til konfigurationsfilen, når grænsefladen tages ned. Med den aktiveret kan en redigering af filen, mens grænsefladen er oppe, blive overskrevet af den efterfølgende nedlukning, og du vil sværge på, at linjen var der. Hvis peeren bliver ved med at vende tilbage, så læs filen efter et stop, ikke før.

NetworkManager opfører sig igen anderledes: den ejer profilen og anvender den ved aktivering, så en håndredigeret .conf ved siden af en aktiv NetworkManager-forbindelse er ren dekoration. Vælg én ejer til grænsefladen, og lad den anden manager lade den være.

Sørg for, at ændringen lander begge steder

Rediger først den vedvarende tilstand, lad derefter ejeren anvende den, og verificér så den levende tilstand. Den rækkefølge betyder, at en fejl på ethvert trin peger på én ting i stedet for 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 udskriver den levende konfiguration i samme syntaks, som filen bruger, hvilket gør de to direkte sammenlignelige. Behandl det output som hemmeligt: det indeholder private nøgler, så indsæt det ikke i en ticket eller en chatkanal. Sammenlign peerenes offentlige nøgler og de tilladte IP-adresser, og kontrollér, at den peer, du fjernede med vilje, ikke er tilbage.

Bevis, at den overlever livscyklushændelsen

Genstart gennem ejeren en anden gang, og bekræft så tre separate ting: peeren optræder i wg show, håndtryks-tælleren stiger efter trafik, og den applikation, der afhænger af tunnelen, svarer faktisk. En peer, der er listet med et gammelt håndtryk, er et routing- eller nøgleproblem, ikke et vedholdenhedsproblem, og den skelnen sparer en meningsløs konfigurationsredigering.

Kontrollér til sidst, hvad genstarten gendannede. En genstart, der genopliver en peer, du med vilje fjernede, er den samme fejl med modsat fortegn, og det betyder normalt, at en gammel kopi af konfigurationen stadig indlæses et eller andet sted fra. Notér ejeren, filstien, peerens offentlige nøgle og verifikationskommandoerne ved siden af konfigurationen, så den næste person ikke genopdager dette ved at genstarte en produktionsvært.