Pourquoi un serveur domestique perd-il une route statique après une mise à niveau de NetworkManager ?

Une route statique peut disparaître après une mise à niveau de NetworkManager lorsque la route appartenait à un profil ou à un chemin de configuration qui n’est plus la connexion active.

Sur un serveur domestique ZimaSpace ou Linux, une route vers un VLAN IoT, un sous-réseau de sauvegarde ou un routeur secondaire peut avoir été ajoutée manuellement avec ip route, enregistrée dans un ancien profil de connexion ou liée à un profil que NetworkManager remplace après la mise à niveau. Le bon test consiste à comparer la route active avec le profil persistant actif, plutôt que de réexécuter la commande après chaque redémarrage.

Vérifiez si la route était réellement persistante

Comparez une route ajoutée avec ip route au profil de connexion NetworkManager qui devrait la recréer.

Un guide pratique ciblé sur networkmanager concernant les routes statiques persistantes dans le profil de connexion aide à isoler cette piste, car il traite le même problème précis au lieu de se limiter à définir le protocole sous-jacent.

Si la route existe uniquement dans la table du noyau, ajoutez-la au profil géré avant d’accuser la mise à niveau.

Examinez les modifications de profil déclenchées par la mise à niveau

Comparez les noms de profil, les UUID, l’état de la connexion automatique et les entrées de route avant et après la mise à niveau du paquet.

Un article ciblé de dépannage sur le cas où les routes statiques peuvent disparaître lorsque l’état de NetworkManager change aide à isoler cette piste, car il traite le même problème précis au lieu de se limiter à définir le protocole sous-jacent.

Restaurez la route dans le profil persistant actif et conservez une copie de l’ancien profil à des fins de comparaison.

N’oubliez pas que NetworkManager repose sur les profils

Une interface peut disposer de plusieurs profils enregistrés, mais seul le profil activé fournit ses paramètres de route.

Un blog d’ingénierie ciblé sur networkmanager expliquant que la configuration de NetworkManager s’articule autour des profils de connexion aide à isoler cette piste, car il traite le même problème précis au lieu de se limiter à définir le protocole sous-jacent.

Identifiez le profil actif à l’aide de son UUID au lieu de modifier le fichier dont le nom vous semble familier.

Featured

ZimaCube 2 NAS personnel Cloud à domicile

ZimaCube2

$799.00 - $2,499.00

Buy Now

Vérifiez ensemble la table de routage et les règles de stratégie

Une route peut toujours exister dans une table autre que la table principale, tandis que la règle qui sélectionnait cette table a changé.

Une explication ciblée du routage Linux sur le routage par stratégie utilisant à la fois les tables et les règles aide à isoler cette piste, car elle traite le même problème précis au lieu de se limiter à définir le protocole sous-jacent.

Affichez ip rule ainsi que toutes les tables pertinentes avant d’ajouter une route en double à la table principale.

Vérifiez si les métriques de route ont changé le chemin retenu

Lorsque deux routes couvrent la même destination, la métrique effective la plus faible ou la route la plus spécifique peut remplacer le chemin que vous vous attendiez à voir.

Un tutoriel ciblé sur les réseaux Linux expliquant comment les métriques de route déterminent le chemin retenu aide à isoler cette piste, car il traite le même problème précis au lieu de se limiter à définir le protocole sous-jacent.

Comparez le préfixe de destination, la métrique et l’interface après la mise à jour. Ne concluez pas à une suppression simplement parce que le trafic emprunte une autre route.

Centralisez la configuration réseau du serveur dans un seul gestionnaire

Le mélange d’anciens scripts, de commandes manuelles, de Netplan et de profils NetworkManager augmente le risque que les mises à niveau révèlent des conflits de gestion.

Un guide pratique ciblé sur les réseaux Linux concernant un profil NetworkManager unique devant gérer le chemin du serveur aide à isoler cette piste, car il traite le même problème précis au lieu de se limiter à définir le protocole sous-jacent.

Standardisez la route dans un profil géré unique, redémarrez deux fois et confirmez que la même route et la même métrique réapparaissent à chaque fois.

Testez à nouveau le chemin exact vers le serveur domestique

Après avoir modifié une seule variable, répétez le même flux NAS ou auto-hébergé depuis le même client au lieu de passer à un autre test susceptible d’emprunter un chemin différent.

Le guide ZimaSpace associé sur le chemin réseau adjacent d’un serveur domestique aide à maintenir la vérification finale dans le même environnement auto-hébergé.

La correction n’est terminée que lorsque le symptôme initial reste résolu après une reconnexion, un redémarrage du service et un second transfert ou une seconde requête contrôlée.

Foire aux questions

Pourquoi ip route add fonctionne-t-il jusqu’au redémarrage ?

Cette commande modifie la table active du noyau, mais ne crée pas nécessairement une configuration NetworkManager persistante.

La route peut-elle toujours exister tout en utilisant la mauvaise table ?

Oui. Le routage par stratégie peut placer les routes dans d’autres tables qui nécessitent des règles correspondantes.

Dois-je modifier manuellement les fichiers de connexion après une mise à niveau ?

Privilégiez nmcli ou le gestionnaire pris en charge par la plateforme, sauf si vous avez une raison maîtrisée de gérer directement les fichiers keyfile.