NetworkManager eller wg-quick: hvem ejer dine WireGuard-ruter?

Du ændrer AllowedIPs i WireGuard-filen, genstarter tunnelen, og routingtabellen ser præcis ud som før. Den sædvanlige reaktion er at slette den generende rute og komme videre, hvilket virker, indtil den næste genopkobling sætter den tilbage. Den fil, du redigerede, er ikke nødvendigvis det objekt, der frembragte den tilstand, du ser på. To managerprogrammer kan køre samme protokol på én maskine, og kun ét af dem ejer interfacet ad gangen.

Myte: der findes én WireGuard-konfiguration på maskinen

wg-quick læser en fil under /etc/wireguard/ og bygger interfacet, når du tager det op. NetworkManager gemmer en forbindelsesprofil i sit eget keyfile-format og gengiver den ved aktivering, og import af en wg-quick-fil kopierer værdierne ind i den profil i stedet for at linke til den. At redigere originalen bagefter ændrer intet, fordi profilen ikke længere læser den. Den samme liste af peers og nøgler kan derfor findes to gange, med den anden kopi gældende.

Et tegn, der er værd at huske: ændringer, der overlever en genstart, men ikke en genimport, kom fra ét lager, og ændringer, der forsvinder ved genstart, kom fra det andet.

Et praktisk eksempel gør opdelingen tydelig. Sammenlign nmcli connection show med systemctl status wg-quick@wg0, og tjek derefter, hvilket interface ruterne faktisk hænger på. Hvis tjenesten er død, og interfacet er oppe, gør profilen arbejdet, uanset hvad filen siger.

Myte: routingreglerne er en del af WireGuard

WireGuard-enheden i kernen kender peers og nøgler, og den ved intet om policy routing. Hvilke ip rule -poster og ekstra tabeller du end ser, blev installeret af det værktøj, der tog interfacet op. wg-quick kan tilføje et fwmark og en dedikeret tabel plus regler, der peger på den, mens NetworkManager installerer ruter via sine egne ipv4-indstillinger og overlader DNS til den resolver-backend, systemet bruger. Samme tunnel, forskellige bivirkninger.

Læs ip rule og ip route show table all før du ændrer noget, og noter, hvilken tabel hver rute bor i. Et tabelnummer, du ikke har konfigureret, er et stærkt hint om det værktøj, der oprettede den.

Myte: at slette ruten er en løsning

En rute, der slettes under kørsel, er en rute, som ejeren geninstallerer ved næste aktivering, og aktiveringen kan ske uden dig: en laptop, der vågner, et link, der flapper, en tjeneste, der genstarter, eller en NetworkManager-autoforbindelse. Derfor vender den samme rute tilbage, og derfor føles omvejen upålidelig snarere end forkert. Identificér først manageren, og ændr derefter det input, som den manager faktisk læser.

Genopkobling og genstart af den relevante tjeneste er den test, der skiller en rigtig løsning fra en, der blot ser pæn ud.

Vælg én ejer, og fjern den anden

Vælg den manager, din udrulning understøtter, og deaktiver derefter den konkurrerende aktivering via dens dokumenterede kontrol i stedet for at håbe på, at den forbliver passiv. En maskeret wg-quick-tjeneste eller en slettet NetworkManager-profil er eksplicit; at lade begge være aktiveret og lade dem kapløbe er ikke. Bevar fungerende adgang, før du deaktiverer noget, fordi det interface, der bærer din fjernsession, måske er det, du er ved at fjerne.

Efter ændringen skal du kontrollere inkluderet og ekskluderet trafik, derefter DNS, og derefter genstarte én gang. Hvis tilstanden overlever en genstart med én manager, har du en ejer i stedet for et tilfælde.

Den generelle regel er værd at huske ud over WireGuard: når en indstilling bliver ved med at komme tilbage, så stop med at slette resultatet, og find den proces, der bliver ved med at frembringe det.