NetworkManager o wg-quick: ¿quién posee tus rutas de WireGuard?

Cambias AllowedIPs en el archivo de WireGuard, reinicias el túnel y la tabla de rutas queda exactamente como antes. La reacción habitual es borrar la ruta conflictiva y seguir adelante, lo que funciona hasta que la siguiente reconexión la vuelve a poner. El archivo que editaste no es necesariamente el objeto que produjo el estado que estás viendo. Dos gestores pueden ejecutar el mismo protocolo en una máquina, y solo uno de ellos posee la interfaz en cada momento.

Mito: hay una sola configuración de WireGuard en la máquina

wg-quick lee un archivo en /etc/wireguard/ y construye la interfaz cuando la levantas. NetworkManager guarda un perfil de conexión en su propio formato keyfile y lo representa al activarse, y importar un archivo de wg-quick copia los valores en ese perfil en lugar de enlazarlo. Editar el original después no cambia nada, porque el perfil ya no lo lee. La misma lista de pares y claves puede existir, por tanto, dos veces, con la segunda copia en vigor.

Una señal que merece recordarse: los cambios que sobreviven a un reinicio pero no a una reimportación vienen de un almacén, y los cambios que desaparecen al reiniciar vienen del otro.

Un ejemplo práctico deja clara la división. Compara nmcli connection show con systemctl status wg-quick@wg0, y luego comprueba de qué interfaz cuelgan realmente las rutas. Si el servicio está muerto y la interfaz está levantada, el perfil hace el trabajo, diga lo que diga el archivo.

Mito: las reglas de enrutamiento son parte de WireGuard

El dispositivo WireGuard del núcleo conoce los pares y las claves, y no sabe nada de enrutamiento por políticas. Las entradas ip rule y las tablas adicionales que veas las instaló la herramienta que levantó la interfaz. wg-quick puede añadir un fwmark y una tabla dedicada más reglas que apuntan a ella, mientras que NetworkManager instala rutas mediante su propia configuración de ipv4 y deja el DNS al backend de resolución que use el sistema. El mismo túnel, efectos secundarios distintos.

Lee ip rule y ip route show table all antes de cambiar nada, y anota en qué tabla vive cada ruta. Un número de tabla que no configuraste es una pista fuerte sobre la herramienta que la creó.

Mito: borrar la ruta es un arreglo

Una ruta borrada en tiempo de ejecución es una ruta que el propietario reinstalará en la siguiente activación, y la activación puede ocurrir sin ti: reanudación de un portátil, un parpadeo del enlace, un reinicio del servicio o una autonexión de NetworkManager. Por eso vuelve la misma ruta y por eso el apaño parece poco fiable en lugar de incorrecto. Identifica primero al gestor y luego cambia la entrada que ese gestor lee de verdad.

Reconectar y reiniciar el servicio correspondiente es la prueba que separa un arreglo real de uno que solo parece ordenado.

Elige un solo propietario y elimina el otro

Elige el gestor que admite tu despliegue y luego desactiva la activación rival mediante su control documentado, en lugar de confiar en que se quede inactiva. Un servicio wg-quick enmascarado o un perfil de NetworkManager eliminado es explícito; dejar ambos activados y hacerlos competir no lo es. Conserva el acceso funcional antes de desactivar nada, porque la interfaz que lleva tu sesión remota puede ser la que estás a punto de eliminar.

Después del cambio, verifica el tráfico incluido y el excluido, luego el DNS y luego reinicia una vez. Si el estado sobrevive a un reinicio con un solo gestor, tienes un propietario en lugar de una coincidencia.

La regla general merece conservarse más allá de WireGuard: cuando un ajuste vuelve una y otra vez, deja de borrar el resultado y encuentra el proceso que lo sigue produciendo.