Varför en borttagen WireGuard-peer kommer tillbaka efter en omstart

Identiteten försvinner från det körande gränssnittet och ändringen ser klar ut. När tjänsten startar om är den tillbaka, vilket läses som att WireGuard ignorerar kommandot. Vad som faktiskt hände är enklare: startkonfigurationen innehåller fortfarande peer-en.

Två tillstånd håller den listan. Återkallelse är bara verklig när båda tappar den.

Vad wg set faktiskt ändrar

Kommandot wg set wg0 peer <public-key> remove redigerar det körande gränssnittet i kärnan. Det skriver ingenting till disken. Konfigurationsfilen, NetworkManager-profilen eller routerns sparade tillstånd lämnas orörda. Det är designen, inte en bugg.

Den separationen är avsiktlig, eftersom verktyget inte har en aning om vem som äger gränssnittet. Ett kommando under drift måste vara säkert mot ett gränssnitt som något annat hanterar. Det kan inte gissa var den varaktiga kopian bor. Konsekvensen är lätt att uttala: en borttagning under drift är tillfällig av konstruktion.

Alltså kommer peer-en tillbaka vid nästa omstart, och den kommer tillbaka med sina ursprungliga tillåtna prefix. Allt som dirigeras genom den återskapas också. En påstått återkallad identitet kan därför nå sina tidigare destinationer efter en omladdning. Ingenting i utdata under drift hade varnat någon.

Hitta skrivaren innan du redigerar en fil

Gränssnittet har en ägare. Det kan vara wg-quick som läser en fil, NetworkManager som tillämpar en profil, routerns egen gränssnittskonfiguration, eller en container-entrypoint som återskapar gränssnittet vid start. Att redigera en fil som ägaren aldrig läser ger ingen varaktig ändring alls.

Börja från det körande gränssnittet och identifiera de publika nycklarna, eftersom namn och adresser är svagare identifierare än nyckeln själv. Jämför sedan listan med den sparade konfiguration som ägaren faktiskt läser.

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

Ett levande gränssnitt där peer-listan och filinnehållet inte stämmer överens är hela diagnosen. Den sparade konfigurationen vinner vid start, och tillståndet under drift förlorar. Jämför dem innan du ändrar något av dem.

SaveConfig-fällan

wg-quick lägger till en veck som fångar folk som redigerar filer för hand. När SaveConfig är aktiverat skriver dess dokumenterade beteende vid avstängning det aktuella tillståndet under drift över konfigurationsfilen.

Det vänder den vanliga riktningen för beständighet. Du tar bort en peer från filen, sedan stoppar tjänsten. Det körande tillståndet skrivs tillbaka över din redigering och återställer peer-en du just raderade.

Därför spelar ordningen roll: redigera filen medan gränssnittet är nere, eller inaktivera SaveConfig före redigeringen, ta sedan upp gränssnittet igen och bekräfta vad som laddades. En handredigering med gränssnittet uppe är en kapplöpning med skrivningen vid avstängning.

Ändra båda tillstånden och ladda sedan om

Under drift tar du bort peer-en med nyckeln. I den sparade konfigurationen tar du bort samma block genom ägarens stödda operation, i stället för att redigera runt det.

Gå sedan igenom vad peer-en bar. Ett dirigerat nätverk som tillhörde den återkallade identiteten bör omfördelas medvetet eller tas bort, inte tyst ärvas av den peer som redigeras härnäst.

Håll en återställningsväg öppen om gatewayen också bär din administrativa åtkomst. En omstart som tar bort fel peer är ett självförvållat avbrott. Samma sak gäller en omstart som tar bort fel rutt.

Hur ett godkänt test ser ut

Ladda om eller starta om tjänsten och läs sedan peer-listan igen. Den gamla nyckeln måste saknas, och de peers du ville behålla måste fortfarande finnas och fungera.

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

Där situationen tillåter det, bekräfta att den gamla identiteten inte längre når sina tidigare resurser. En prydlig gränssnittslista före en omstart är halva testet. Den andra halvan är vad identiteten fortfarande kan göra efteråt.

Om en hanterare fortsätter att återställa peer-en, sluta upprepa borttagningen på låg nivå. Reparera inventariet som den skrivaren läser, för fram till dess är varje omstart ännu en inbjudan för identiteten att dyka upp igen.