NetworkManager eller wg-quick: vem äger dina WireGuard-rutter?

Du ändrar AllowedIPs i WireGuard-filen, startar om tunneln, och routingtabellen ser exakt ut som tidigare. Den vanliga reaktionen är att radera den störande rutten och gå vidare, vilket fungerar tills nästa återanslutning sätter tillbaka den. Filen du redigerade är inte nödvändigtvis det objekt som skapade det tillstånd du tittar på. Två hanterare kan köra samma protokoll på en maskin, och bara en av dem äger gränssnittet i taget.

Myt: det finns en WireGuard-konfiguration på maskinen

wg-quick läser en fil under /etc/wireguard/ och bygger gränssnittet när du tar upp det. NetworkManager lagrar en anslutningsprofil i sitt eget keyfile-format och renderar den vid aktivering, och import av en wg-quick-fil kopierar värdena till den profilen i stället för att länka till den. Att redigera originalet efteråt ändrar ingenting, eftersom profilen inte längre läser det. Samma lista med parter och nycklar kan därför finnas två gånger, där den andra kopian gäller.

Ett tecken som är värt att komma ihåg: ändringar som överlever en omstart men inte en ny import kom från ett lager, och ändringar som försvinner vid omstart kom från det andra.

Ett praktiskt exempel gör uppdelningen tydlig. Jämför nmcli connection show med systemctl status wg-quick@wg0, och kontrollera sedan vilket gränssnitt rutterna faktiskt hänger på. Om tjänsten är död och gränssnittet är uppe gör profilen jobbet, vad filen än säger.

Myt: routingreglerna är en del av WireGuard

WireGuard-enheten i kärnan känner till parter och nycklar, och den vet ingenting om policy-routing. Vilka ip rule -poster och extra tabeller du än ser installerades de av verktyget som tog upp gränssnittet. wg-quick kan lägga till en fwmark och en egen tabell plus regler som pekar på den, medan NetworkManager installerar rutter via sina egna ipv4-inställningar och lämnar DNS till den resolver-backend som systemet använder. Samma tunnel, olika bieffekter.

Läs ip rule och ip route show table all innan du ändrar något, och notera vilken tabell varje rutt bor i. Ett tabellnummer du inte har konfigurerat är en stark ledtråd om verktyget som skapade den.

Myt: att radera rutten är en lagning

En rutt som raderas under drift är en rutt som ägaren installerar igen vid nästa aktivering, och aktiveringen kan ske utan dig: en laptop som vaknar, ett länkflap, en tjänst som startar om eller en automatisk anslutning från NetworkManager. Det är därför samma rutt kommer tillbaka och därför känns tillfälliga lösningen opålitlig snarare än fel. Identifiera först hanteraren och ändra sedan den indata som hanteraren faktiskt läser.

Att ansluta igen och starta om den berörda tjänsten är testet som skiljer en riktig lagning från en som bara ser städad ut.

Välj en ägare och ta bort den andra

Välj den hanterare som din utrullning stöder och inaktivera sedan den konkurrerande aktiveringen via dess dokumenterade kontroll i stället för att hoppas att den förblir inaktiv. En maskerad wg-quick-tjänst eller en raderad NetworkManager-profil är explicit; att lämna båda aktiverade och låta dem tävla är det inte. Behåll fungerande åtkomst innan du inaktiverar något, eftersom gränssnittet som bär din fjärrsession kan vara det du är på väg att ta bort.

Efter ändringen, verifiera inkluderad och exkluderad trafik, sedan DNS och starta sedan om en gång. Om tillståndet överlever en omstart med en enda hanterare har du en ägare i stället för en slump.

Den allmänna regeln är värd att komma ihåg utanför WireGuard också: när en inställning ständigt kommer tillbaka, sluta radera resultatet och hitta processen som ständigt producerar det.