Hvorfor en slettet WireGuard-peer kommer tilbake etter en omstart

Identiteten forsvinner fra det kjørende grensesnittet, og endringen ser ferdig ut. Når tjenesten starter på nytt, er den tilbake, noe som leses som om WireGuard ignorerer kommandoen. Det som faktisk skjedde, er enklere: oppstartskonfigurasjonen inneholder fortsatt peer-en.

To tilstander holder den listen. Tilbakekalling er bare reell når begge mister den.

Hva wg set faktisk endrer

Kommandoen wg set wg0 peer <public-key> remove redigerer det kjørende grensesnittet i kjernen. Den skriver ingenting til disken. Konfigurasjonsfilen, NetworkManager-profilen eller ruterenes lagrede tilstand er urørt. Det er designet, ikke en feil.

Denne separasjonen er bevisst, fordi verktøyet ikke aner hvem som eier grensesnittet. En kommando under kjøring må være trygg mot et grensesnitt som styres av noe annet. Den kan ikke gjette hvor den varige kopien bor. Konsekvensen er lett å si: en fjerning under kjøring er midlertidig av konstruksjon.

Så peer-en kommer tilbake ved neste omstart, og den kommer tilbake med sine opprinnelige tillatte prefikser. Alt som rutes gjennom den, gjenskapes også. En angivelig tilbakekalt identitet kan derfor nå sine tidligere destinasjoner etter en omlasting. Ingenting i utdataene under kjøring hadde varslet noen.

Finn skriveren før du redigerer en fil

Grensesnittet har en eier. Det kan være wg-quick som leser en fil, NetworkManager som bruker en profil, ruterens egen grensesnittkonfigurasjon, eller et container-entrypoint som gjenskaper grensesnittet ved start. Å redigere en fil som eieren aldri leser, gir ingen varig endring i det hele tatt.

Start fra det kjørende grensesnittet og identifiser de offentlige nøklene, siden navn og adresser er svakere identifikatorer enn nøkkelen selv. Sammenlign deretter listen med den lagrede konfigurasjonen som eieren faktisk leser.

wg show wg0 peers
wg show wg0 allowed-ips
systemctl status wg-quick@wg0 --no-pager
ls -l /etc/wireguard

Et levende grensesnitt der peer-listen og filinnholdet ikke stemmer overens, er hele diagnosen. Den lagrede konfigurasjonen vinner ved oppstart, og tilstanden under kjøring taper. Sammenlign dem før du endrer noen av dem.

SaveConfig-fellen

wg-quick legger til en fold som fanger folk som redigerer filer for hånd. Når SaveConfig er aktivert, skriver dens dokumenterte oppførselsmønster ved nedstenging den gjeldende tilstanden under kjøring over konfigurasjonsfilen.

Det snur den vanlige retningen for persistens. Du fjerner en peer fra filen, og så stopper tjenesten. Den kjørende tilstanden skrives tilbake over redigeringen din og gjenoppretter peer-en du nettopp slettet.

Derfor betyr rekkefølgen noe: rediger filen mens grensesnittet er nede, eller deaktiver SaveConfig før redigeringen, og ta deretter grensesnittet opp igjen og bekreft hva som ble lastet. En håndredigering mens grensesnittet er oppe, er et kappløp med skrivingen ved nedstenging.

Endre begge tilstandene, last deretter på nytt

Under kjøring fjerner du peer-en med nøkkelen. I den lagrede konfigurasjonen fjerner du samme blokk gjennom eierens støttede operasjon, i stedet for å redigere rundt den.

Gå deretter gjennom hva peer-en bar med seg. Et ruttet nettverk som tilhørte den tilbakekalte identiteten, bør tildeles på nytt bevisst eller fjernes, ikke arves stille av den peer-en som redigeres neste gang.

Hold en gjenopprettingsvei åpen hvis gatewayen også bærer din administrative tilgang. En omstart som fjerner feil peer, er et selvpåført avbrudd. Det samme gjelder en omstart som fjerner feil rute.

Hvordan en bestått test ser ut

Last tjenesten på nytt eller start den på nytt, og les deretter peer-listen igjen. Den gamle nøkkelen må mangle, og peer-ene du mente å beholde, må fortsatt være til stede og fungere.

wg show wg0 peers
wg show wg0 allowed-ips
sudo wg-quick down wg0 && sudo wg-quick up wg0
wg show wg0 peers

Der situasjonen tillater det, bekreft at den gamle identiteten ikke lenger når sine tidligere ressurser. En ryddig grensesnittliste før en omstart er halve testen. Den andre halvdelen er hva identiteten fortsatt kan gjøre etterpå.

Hvis en behandler fortsetter å gjenopprette peer-en, slutt å gjenta fjerningen på lavt nivå. Reparer inventaret som den skriveren leser, for inntil da er hver omstart nok en invitasjon til at identiteten dukker opp igjen.