NetworkManager ou wg-quick : qui possède vos routes WireGuard ?

Vous modifiez AllowedIPs dans le fichier WireGuard, redémarrez le tunnel, et la table de routage est exactement comme avant. La réaction habituelle est de supprimer la route gênante et de continuer, ce qui marche jusqu’à ce que la reconnexion suivante la remette. Le fichier que vous avez modifié n’est pas forcément l’objet qui a produit l’état que vous observez. Deux gestionnaires peuvent faire tourner le même protocole sur une machine, et un seul d’entre eux possède l’interface à un instant donné.

Mythe : il n’y a qu’une configuration WireGuard sur la machine

wg-quick lit un fichier sous /etc/wireguard/ et construit l’interface quand vous la montez. NetworkManager stocke un profil de connexion dans son propre format keyfile et le rend à l’activation, et importer un fichier wg-quick copie les valeurs dans ce profil au lieu de pointer vers lui. Modifier l’original ensuite ne change rien, car le profil ne le lit plus. La même liste de pairs et de clés peut donc exister deux fois, la seconde copie étant en vigueur.

Un indice à retenir : les modifications qui survivent à un redémarrage mais pas à une réimportation viennent d’un magasin, et celles qui disparaissent au redémarrage viennent de l’autre.

Un exemple concret rend la séparation évidente. Comparez nmcli connection show avec systemctl status wg-quick@wg0, puis vérifiez sur quelle interface les routes sont réellement accrochées. Si le service est mort et l’interface montée, c’est le profil qui fait le travail, quoi qu’en dise le fichier.

Mythe : les règles de routage font partie de WireGuard

L’appareil WireGuard du noyau connaît les pairs et les clés, et il ne sait rien du routage par politique. Les entrées ip rule et les tables supplémentaires que vous voyez ont été installées par l’outil qui a monté l’interface. wg-quick peut ajouter un fwmark et une table dédiée plus des règles qui pointent vers elle, tandis que NetworkManager installe des routes via ses propres réglages ipv4 et laisse le DNS au backend de résolution qu’utilise le système. Même tunnel, effets secondaires différents.

Lisez ip rule et ip route show table all avant de changer quoi que ce soit, et notez dans quelle table vit chaque route. Un numéro de table que vous n’avez pas configuré est un indice fort sur l’outil qui l’a créée.

Mythe : supprimer la route est une solution

Une route supprimée à chaud est une route que le propriétaire réinstallera à la prochaine activation, et l’activation peut se produire sans vous : reprise d’un portable, flottement de la liaison, redémarrage d’un service ou autoconnexion de NetworkManager. C’est pourquoi la même route revient et pourquoi le contournement semble peu fiable plutôt que faux. Identifiez d’abord le gestionnaire, puis modifiez l’entrée que ce gestionnaire lit réellement.

Se reconnecter et redémarrer le service concerné est le test qui sépare un vrai correctif d’un correctif qui fait seulement propre.

Choisissez un propriétaire et retirez l’autre

Choisissez le gestionnaire que votre déploiement prend en charge, puis désactivez l’activation concurrente via son contrôle documenté au lieu d’espérer qu’elle reste inactive. Un service wg-quick masqué ou un profil NetworkManager supprimé est explicite ; laisser les deux activés et les faire courir l’un contre l’autre ne l’est pas. Préservez l’accès fonctionnel avant de désactiver quoi que ce soit, car l’interface qui porte votre session distante peut être celle que vous êtes sur le point de retirer.

Après le changement, vérifiez le trafic inclus et exclu, puis le DNS, puis redémarrez une fois. Si l’état survit à un redémarrage avec un seul gestionnaire, vous avez un propriétaire au lieu d’une coïncidence.

La règle générale vaut au-delà de WireGuard : quand un réglage revient sans cesse, arrêtez de supprimer le résultat et trouvez le processus qui ne cesse de le produire.