WireGuard-peer forsvinn etter omstart: finn den eigenlege konfigurasjonen

Peeren du la til med wg set svarar på ping heile ettermiddagen og er borte etter omstarten. Ingenting vart skadd: kjernen lagra aldri den peeren nokon annan stad enn i det levande grensesnittet, og alt som byggjer grensesnittet opp att ved oppstart, bygde det frå ei fil du ikkje har rørt. Reparasjonen er ikkje nok ein wg set. Det gjeld å finne ut kva komponent som eig grensesnittet, redigere tilstanden til den komponenten og deretter prove at peeren overlever nøyaktig den livssyklushendinga som fjerna han.

Gjenskap det éin gong, med vilje

Ikkje fiks eit omstartsproblem før du kan sjå det skje. Med konsoll- eller out-of-band-tilgang tilgjengeleg, noter peerlista, start på nytt gjennom tenesta som eig grensesnittet, og samanlikn. Viss peeren framleis er der, har endringa di alt nådd den vedvarande tilstanden, og du feilsøkjer feil hending.

Skriv ned tre fakta medan du gjer dette: namnet på grensesnittet, eininga eller profilen som starta det, og om handtrykk-teljaren på peeren som overlevde vart nullstilt. Ein nullstilt teljar tyder at grensesnittet vart øydelagt og bygd opp att; ein uendra teljar med ein manglande peer tyder at noko redigerte konfigurasjonen under føtene dine.

Kven eig grensesnittet?

WireGuard sjølv har ingen daemon og inga konfigurasjonsfil. Noko over det kallar wg ved oppstart, og det noko er sanningas kjelde. Dei vanlege kandidatane er [email protected], ein NetworkManager-tilkoplingsprofil, ei distribusjonsspesifikk nettverksening eller eit administrasjonspanel som skriv si eiga database.

Spør systemet, ikkje dokumentasjonen til distribusjonen din. systemctl status wg-quick@wg0 og nmcli connection show avgjer det vanlegvis med éin kommando kvar. Viss begge gjer krav på grensesnittet, har du funne feilen før du redigerte noko: to eigarar skriv om den same eininga ved kvar oppstart, og den siste som køyrer vinn.

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øyretidstilstand og oppstartstilstand er ikkje same fil

wg set manipulerer den levande eininga via netlink. Det skriv ikkje /etc/wireguard/wg0.conf, ein NetworkManager-profil eller databasen til eit panel. Ein vellukka wg show etterpå provar at kjernen godtok peeren, ikkje at noko vil gjenopprette han.

Det finst ei andre felle i motsett retning. Innstillinga SaveConfig i wg-quick skriv den gjeldande tilstanden til grensesnittet tilbake til konfigurasjonsfila når grensesnittet blir teke ned. Med ho aktivert kan ei endring i fila medan grensesnittet er oppe bli overstyrt av nedstenginga som følgjer, og du vil sverje på at linja var der. Viss peeren stadig kjem tilbake, les fila etter ein stopp, ikkje før.

NetworkManager oppfører seg annleis igjen: han eig profilen og brukar han ved aktivering, så ein handredigert .conf ved sida av ein aktiv NetworkManager-tilkopling er berre dekorasjon. Vel éin eigar for grensesnittet og lat den andre administratoren la det vere i fred.

Syt for at endringa landar begge stader

Rediger den vedvarande tilstanden først, lat deretter eigaren bruke han, og verifiser til slutt den levande tilstanden. Den rekkjefølgja tyder at ein feil på eit kva som helst steg peikar på éin ting i staden 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 skriv ut den levande konfigurasjonen i same syntaks som fila brukar, noko som gjer dei to direkte samanliknbare. Handsame den utskrifta som ein hemmelegheit: ho inneheld private nøklar, så ikkje lim henne inn i ein sak eller ein chatkanal. Samanlikn dei offentlege nøklane til peerane og dei tillatne IP-adressene, og kontroller at peeren du fjerna med vilje ikkje er tilbake.

Prov at han overlever livssyklushendinga

Start på nytt gjennom eigaren ein gong til, og stadfest deretter tre separate ting: peeren viser seg i wg show, handtrykk-teljaren aukar etter trafikk, og applikasjonen som er avhengig av tunnelen svarar faktisk. Ein peer som er lista med eit gammalt handtrykk, er eit rutings- eller nøkkelproblem, ikkje eit vedvaringsproblem, og den skilnaden sparer ei meiningslaus konfigurasjonsendring.

Til slutt, kontroller kva omstarten gjenoppretta. Ein omstart som vekkjer til live ein peer du fjerna med vilje, er den same feilen med motsett forteikn, og det tyder vanlegvis at ein gammal kopi av konfigurasjonen framleis blir lasta frå ein stad. Noter eigaren, filstien, den offentlege nøkkelen til peeren og verifiseringskommandoane ved sida av konfigurasjonen, slik at neste person ikkje gjenoppdagar dette ved å starte ein produksjonsvert på nytt.