NetworkManager o wg-quick: qui posseeix les teves rutes WireGuard?
Dos gestors poden reclamar el mateix enllaç WireGuard, i la configuració que has editat potser no és la que està en vigor. Troba el propietari a partir de les rutes, les regles i l’estat de la interfície.
Canvies AllowedIPs al fitxer de WireGuard, reinicies el túnel i la taula d’encaminament queda exactament com abans. La reacció habitual és esborrar la ruta conflictiva i continuar, cosa que funciona fins que la propera reconnexió la torna a posar. El fitxer que has editat no és necessàriament l’objecte que ha produït l’estat que estàs veient. Dos gestors poden executar el mateix protocol en una màquina, i només un d’ells posseeix la interfície en cada moment.
Mite: hi ha una sola configuració de WireGuard a la màquina
wg-quick llegeix un fitxer sota /etc/wireguard/ i construeix la interfície quan la puges. NetworkManager desa un perfil de connexió en el seu propi format keyfile i el presenta en l’activació, i importar un fitxer wg-quick copia els valors en aquest perfil en lloc d’enllaçar-hi. Editar l’original després no canvia res, perquè el perfil ja no el llegeix. La mateixa llista de parells i claus pot existir, doncs, dues vegades, amb la segona còpia en vigor.
Una pista que val la pena recordar: els canvis que sobreviuen a un reinici però no a una reimportació vénen d’un magatzem, i els canvis que desapareixen en reiniciar vénen de l’altre.
Un exemple pràctic fa evident la divisió. Compareu nmcli connection show amb systemctl status wg-quick@wg0, després comproveu a quina interfície pengen realment les rutes. Si el servei és mort i la interfície està aixecada, el perfil fa la feina, digui el que digui el fitxer.
Mite: les regles d’encaminament formen part de WireGuard
El dispositiu WireGuard del nucli coneix els parells i les claus, i no sap res d’encaminament per política. Les entrades de ip rule i les taules addicionals que vegis les ha instal·lat l’eina que ha aixecat la interfície. wg-quick pot afegir un fwmark i una taula dedicada més regles que hi apunten, mentre que NetworkManager instal·la rutes a través de la seva pròpia configuració ipv4 i deixa el DNS al backend de resolució que faci servir el sistema. El mateix túnel, efectes secundaris diferents.
Llegeix ip rule i ip route show table all abans de canviar res, i anota en quina taula viu cada ruta. Un número de taula que no has configurat és una pista forta sobre l’eina que la va crear.
Mite: esborrar la ruta és una solució
Una ruta esborrada en temps d’execució és una ruta que el propietari tornarà a instal·lar en la propera activació, i l’activació pot passar sense tu: represa d’un portàtil, un flapeig de l’enllaç, un reinici del servei o una autoconnexió de NetworkManager. Per això torna la mateixa ruta i per això la solució temporal sembla poc fiable en lloc d’incorrecta. Identifica primer el gestor i després canvia l’entrada que aquell gestor llegeix de veritat.
Reconnectar i reiniciar el servei pertinent és la prova que separa una solució real d’una que només fa bona aparença.
Tria un sol propietari i elimina l’altre
Tria el gestor que admet el teu desplegament i després desactiva l’activació rival mitjançant el seu control documentat, en lloc d’esperar que es quedi inactiva. Un servei wg-quick emmascarat o un perfil de NetworkManager esborrat és explícit; deixar tots dos activats i fer-los competir no ho és. Preserva l’accés funcional abans de desactivar res, perquè la interfície que porta la teva sessió remota pot ser la que estàs a punt d’eliminar.
Després del canvi, verifica el trànsit inclòs i l’exclòs, després el DNS i després reinicia un cop. Si l’estat sobreviu a un reinici amb un sol gestor, tens un propietari en lloc d’una coincidència.
La regla general val la pena conservar-la més enllà de WireGuard: quan una configuració torna una vegada i una altra, deixa d’esborrar el resultat i troba el procés que el continua produint.