NetworkManager eller wg-quick: kven eig WireGuard-rutene dine?

Du endrar AllowedIPs i WireGuard-fila, startar tunnelen på nytt, og rutetabellen ser nøyaktig ut som før. Den vanlege reaksjonen er å sletta ruta som er i vegen og gå vidare, noko som fungerer til neste gjenoppkopling set henne tilbake. Fila du redigerte er ikkje nødvendigvis objektet som skapte tilstanden du ser på. To behandlarar kan køyra same protokoll på éin maskin, og berre éin av dei eig grensesnittet om gongen.

Myte: det finst éin WireGuard-konfigurasjon på maskinen

wg-quick les ei fil under /etc/wireguard/ og byggjer grensesnittet når du tek det opp. NetworkManager lagrar ein tilkoplingsprofil i sitt eige keyfile-format og gjev han att ved aktivering, og import av ei wg-quick-fil kopierer verdiane inn i den profilen i staden for å lenkja til han. Å redigera originalen etterpå endrar ingenting, fordi profilen ikkje lenger les han. Den same lista med partar og nøklar kan difor finnast to gonger, med den andre kopien gjeldande.

Eit teikn det er verdt å hugsa: endringar som overlever ein omstart, men ikkje ein ny import, kom frå eitt lager, og endringar som forsvinn ved omstart, kom frå det andre.

Eitt praktisk døme gjer delinga tydeleg. Samanlikn nmcli connection show med systemctl status wg-quick@wg0, og sjekk deretter kva grensesnitt rutene faktisk heng på. Viss tenesta er daud og grensesnittet er oppe, gjer profilen jobben, uansett kva fila seier.

Myte: rutereglar er ein del av WireGuard

WireGuard-eininga i kjernen kjenner partar og nøklar, og ho veit ingenting om policy-ruting. Kva ip rule -oppføringar og ekstra tabellar du enn ser, vart dei installerte av verktøyet som tok grensesnittet opp. wg-quick kan leggja til ein fwmark og ein eigen tabell pluss reglar som peikar på han, medan NetworkManager installerer ruter via sine eigne ipv4-innstillingar og overlèt DNS til den resolver-backenden systemet brukar. Same tunnel, ulike biverknader.

Les ip rule og ip route show table all før du endrar noko, og noter kva tabell kvar rute bur i. Eit tabellnummer du ikkje har konfigurert, er eit sterkt hint om verktøyet som oppretta han.

Myte: å sletta ruta er ein reparasjon

Ei rute som vert sletta under køyring, er ei rute eigaren vil installera på nytt ved neste aktivering, og aktiveringa kan skje utan deg: ein laptop som vaknar, eit lenkebrot, ei teneste som startar på nytt eller ei automatisk tilkopling frå NetworkManager. Difor kjem den same ruta tilbake, og difor kjennest mellomboyløysinga upåliteleg snarare enn feil. Identifiser først behandlaren, og endra deretter inndataa som den behandlaren faktisk les.

Å kopla til på nytt og starta den aktuelle tenesta på nytt er testen som skil ein ekte reparasjon frå ein som berre ser ryddig ut.

Vel éin eigar og fjern den andre

Vel behandlaren distribusjonen din støttar, og deaktiver deretter den konkurrerande aktiveringa via den dokumenterte kontrollen hans i staden for å håpa at han blir inaktiv. Ei maskert wg-quick-teneste eller ein sletta NetworkManager-profil er eksplisitt; å la begge vera aktive og la dei konkurrera er det ikkje. Ta vare på fungerande tilgang før du deaktiverer noko, fordi grensesnittet som ber fjernøkta di, kan vera det du er i ferd med å fjerna.

Etter endringa, verifiser inkludert og ekskludert trafikk, deretter DNS, og start deretter på nytt éin gong. Viss tilstanden overlever ein omstart med éin behandlar, har du ein eigar i staden for ei tilfeldigheit.

Den generelle regelen er verdt å hugsa utanfor WireGuard òg: når ei innstilling stadig kjem tilbake, slutt å sletta resultatet og finn prosessen som stadig produserer det.