NetworkManager eller wg-quick: hvem eier WireGuard-rutene dine?

Du endrer AllowedIPs i WireGuard-filen, starter tunnelen på nytt, og rutetabellen ser nøyaktig ut som før. Den vanlige reaksjonen er å slette ruten som er i veien og gå videre, noe som fungerer til neste gjenoppkobling setter den tilbake. Filen du redigerte er ikke nødvendigvis objektet som skapte tilstanden du ser på. To behandlere kan kjøre samme protokoll på én maskin, og bare én av dem eier grensesnittet om gangen.

Myte: det finnes én WireGuard-konfigurasjon på maskinen

wg-quick leser en fil under /etc/wireguard/ og bygger grensesnittet når du tar det opp. NetworkManager lagrer en tilkoblingsprofil i sitt eget keyfile-format og gjengir den ved aktivering, og import av en wg-quick-fil kopierer verdiene inn i den profilen i stedet for å lenke til den. Å redigere originalen etterpå endrer ingenting, fordi profilen ikke lenger leser den. Den samme listen med parter og nøkler kan derfor finnes to ganger, med den andre kopien gjeldende.

Et tegn det er verdt å huske: endringer som overlever en omstart, men ikke en ny import, kom fra ett lager, og endringer som forsvinner ved omstart, kom fra det andre.

Ett praktisk eksempel gjør delingen tydelig. Sammenlign nmcli connection show med systemctl status wg-quick@wg0, og sjekk deretter hvilket grensesnitt rutene faktisk henger på. Hvis tjenesten er død og grensesnittet er oppe, gjør profilen jobben, uansett hva filen sier.

Myte: ruteregler er en del av WireGuard

WireGuard-enheten i kjernen kjenner parter og nøkler, og den vet ingenting om policy-ruting. Hvilke ip rule -oppføringer og ekstra tabeller du enn ser, ble de installert av verktøyet som tok grensesnittet opp. wg-quick kan legge til en fwmark og en egen tabell pluss regler som peker på den, mens NetworkManager installerer ruter via sine egne ipv4-innstillinger og overlater DNS til den resolver-backenden systemet bruker. Samme tunnel, forskjellige bivirkninger.

Les ip rule og ip route show table all før du endrer noe, og noter hvilken tabell hver rute bor i. Et tabellnummer du ikke har konfigurert, er et sterkt hint om verktøyet som opprettet den.

Myte: å slette ruten er en reparasjon

En rute som slettes under kjøring, er en rute eieren vil installere på nytt ved neste aktivering, og aktiveringen kan skje uten deg: en laptop som våkner, et lenkeavbrudd, en tjeneste som starter på nytt eller en automatisk tilkobling fra NetworkManager. Derfor kommer den samme ruten tilbake, og derfor føles midlertidigløsningen upålitelig snarere enn feil. Identifiser først behandleren, og endre deretter inndataene som den behandleren faktisk leser.

Å koble til på nytt og starte den aktuelle tjenesten på nytt er testen som skiller en ekte reparasjon fra en som bare ser ryddig ut.

Velg én eier og fjern den andre

Velg behandleren distribusjonen din støtter, og deaktiver deretter den konkurrerende aktiveringen via dens dokumenterte kontroll i stedet for å håpe at den forblir inaktiv. En maskert wg-quick-tjeneste eller en slettet NetworkManager-profil er eksplisitt; å la begge være aktive og la dem konkurrere er det ikke. Bevar fungerende tilgang før du deaktiverer noe, fordi grensesnittet som bærer fjernøkten din, kan være det du er i ferd med å fjerne.

Etter endringen, verifiser inkludert og ekskludert trafikk, deretter DNS, og start deretter på nytt én gang. Hvis tilstanden overlever en omstart med én behandler, har du en eier i stedet for en tilfeldighet.

Den generelle regelen er verdt å huske utenfor WireGuard også: når en innstilling stadig kommer tilbake, slutt å slette resultatet og finn prosessen som stadig produserer det.