NetworkManager ou wg-quick: quen posúe as túas rutas de WireGuard?

Cambias AllowedIPs no ficheiro de WireGuard, reinicias o túnel e a táboa de rutas queda exactamente como antes. A reacción habitual é borrar a ruta conflitiva e seguir adiante, o que funciona ata que a seguinte reconexión a volve poñer. O ficheiro que editaches non é necesariamente o obxecto que produciu o estado que estás a mirar. Dous xestores poden executar o mesmo protocolo nunha máquina, e só un deles posúe a interface en cada momento.

Mito: hai unha soa configuración de WireGuard na máquina

wg-quick le un ficheiro en /etc/wireguard/ e constrúe a interface cando a levantas. NetworkManager garda un perfil de conexión no seu propio formato keyfile e represéntao na activación, e importar un ficheiro de wg-quick copia os valores nese perfil en lugar de ligalo. Editar o orixinal despois non cambia nada, porque o perfil xa non o le. A mesma lista de pares e claves pode existir, por tanto, dúas veces, coa segunda copia en vigor.

Unha pista que paga a pena recordar: os cambios que sobreviven a un reinicio pero non a unha reimportación veñen dun almacén, e os cambios que desaparecen ao reiniciar veñen do outro.

Un exemplo práctico deixa clara a división. Compara nmcli connection show con systemctl status wg-quick@wg0, e despois comproba de que interface colgan realmente as rutas. Se o servizo está morto e a interface está levantada, o perfil fai o traballo, diga o que diga o ficheiro.

Mito: as regras de encamiñamento forman parte de WireGuard

O dispositivo WireGuard do núcleo coñece os pares e as claves, e non sabe nada do encamiñamento por políticas. As entradas ip rule e as táboas adicionais que vexas instalounas a ferramenta que levantou a interface. wg-quick pode engadir un fwmark e unha táboa dedicada máis regras que apuntan a ela, mentres que NetworkManager instala rutas mediante a súa propia configuración de ipv4 e deixa o DNS ao backend de resolución que use o sistema. O mesmo túnel, efectos secundarios distintos.

Le ip rule e ip route show table all antes de cambiar nada, e anota en que táboa vive cada ruta. Un número de táboa que non configuraches é unha pista forte sobre a ferramenta que a creou.

Mito: borrar a ruta é unha solución

Unha ruta borrada en tempo de execución é unha ruta que o propietario reinstalará na seguinte activación, e a activación pode ocorrer sen ti: reanudación dun portátil, un parpadeo da ligazón, un reinicio do servizo ou unha autonexión de NetworkManager. Por iso volve a mesma ruta e por iso o apaño parece pouco fiable en lugar de incorrecto. Identifica primeiro o xestor e logo cambia a entrada que ese xestor le de verdade.

Reconectar e reiniciar o servizo correspondente é a proba que separa unha solución real dunha que só fai boa aparencia.

Escolle un único propietario e elimina o outro

Escolle o xestor que admite o teu despregamento e logo desactiva a activación rival mediante o seu control documentado, en lugar de esperar que quede inactiva. Un servizo wg-quick enmascarado ou un perfil de NetworkManager borrado é explícito; deixar os dous activados e facelos competir non o é. Preserva o acceso funcional antes de desactivar nada, porque a interface que leva a túa sesión remota pode ser a que estás a piques de eliminar.

Despois do cambio, verifica o tráfico incluído e o excluído, logo o DNS e logo reinicia unha vez. Se o estado sobrevive a un reinicio cun só xestor, tes un propietario en lugar dunha coincidencia.

A regra xeral paga a pena conservala máis alá de WireGuard: cando un axuste volve unha e outra vez, deixa de borrar o resultado e atopa o proceso que o segue producindo.