Route VPN manquante dans NetworkManager : politique du profil ou script ?

Vous vous connectez, l'interface du tunnel apparaît, et un préfixe dont vous avez besoin n'est tout simplement pas dans la table. L'étape suivante consiste généralement à chercher un script qui l'ajoute. Cette recherche mène à des réponses qui collent un assistant OpenVPN dans un profil, et la moitié de ces réponses aggravent la situation au lieu de l'améliorer, car une route manquante a trois propriétaires possibles et un seul d'entre eux est un script manquant.

Décidez quel propriétaire est responsable avant d'écrire quoi que ce soit.

Trois propriétaires, un préfixe manquant

Le préfixe peut être absent parce que personne ne l'a fourni, parce que le profil l'a refusé, ou parce qu'il a été installé quelque part que vous ne regardez pas. Ce sont des défauts différents et ils ont des corrections différentes.

Le premier est le plus facile à vérifier : le serveur ou le greffon a-t-il jamais proposé la route ? Un backend qui n'a jamais reçu le préfixe ne peut pas l'installer, et un script auxiliaire ne peut pas inventer une joignabilité que le pair n'a jamais décrite. Le deuxième est la politique du profil, qui peut supprimer des routes que la connexion prendrait autrement. Le troisième est une table ou une règle, qui peut conserver la route dans un endroit que la recherche par défaut ne consulte jamais.

Un quatrième propriétaire, c'est vous, plus tard : un script qui ajoute la route à la connexion mais ne la retire pas à la déconnexion. Cela produit un préfixe qui survit au tunnel, pointe vers une interface morte et déroute la personne suivante qui débogue la machine.

Lisez le profil avant d'ajouter quoi que ce soit

Commencez par les propriétés de la connexion enregistrée. Lisez-les sans déverser de secrets, et utilisez l'UUID si le nom du profil est ambigu.

nmcli -f vpn.service-type,ipv4.never-default,ipv4.ignore-auto-routes,ipv4.route-table,ipv4.routes connection show office

vpn.service-type vous dit quel backend possède la connexion, et cela compte parce que les données du greffon sont propres au backend. Une clé acceptée par un greffon n'est pas une instruction prise en charge par un autre, donc un extrait copié de la documentation d'un autre client ne prouve rien.

ipv4.ignore-auto-routes et ipv4.never-default répondent à des questions différentes. Le premier peut rejeter des routes que la connexion prendrait autrement automatiquement, et le second contrôle si le profil peut devenir la route par défaut. Un profil qui ignore les routes automatiques et ne s'appuie sur rien d'autre se connectera proprement et n'installera presque rien.

ip -4 rule show
ip -4 route show table all

Ces deux commandes tranchent la troisième possibilité. Cherchez votre préfixe dans chaque table, pas seulement dans main, et vérifiez si une règle de politique envoie la recherche pertinente ailleurs. Si le préfixe est présent dans une autre table et que rien ne la consulte, vous n'avez pas une route manquante ; vous avez une recherche qui ne l'atteint jamais.

Ce qu'un script ne peut pas corriger

Ajouter un script auxiliaire donne à vpn.data de NetworkManager un programme à exécuter. C'est un mécanisme réel, et c'est le mauvais pour la plupart de ces cas, car le script prend le contrôle après que la politique du profil a déjà décidé ce qu'il faut accepter.

Le script-security d'OpenVPN est l'autre confusion récurrente. C'est un réglage d'OpenVPN qui régit quels scripts le client peut exécuter et ce qu'il peut mettre dans leur environnement ; le niveau 3 permet de transmettre des identifiants via l'environnement, ce qui est une décision de gestion de secrets et non une correction de routage. Le coller dans un profil dont le backend n'est pas OpenVPN, ou l'élever alors qu'aucun script n'en a besoin, ajoute de l'exposition sans ajouter de route.

Vient ensuite le réflexe de redémarrage. Redémarrer le service NetworkManager démonte et reconstruit chaque lien géré, y compris celui par lequel vous êtes connecté si vous travaillez à distance. C'est une action perturbatrice, pas un diagnostic inoffensif, et sur un serveur, cela peut faire la différence entre une session qui survit et une qui ne survit pas.

La décision, dans l'ordre

Posez trois questions dans l'ordre. Le pair a-t-il fourni le préfixe, ce que montreront le journal du backend ou sa propre sortie d'état ? Si oui, le profil est-il configuré pour accepter et installer des routes, ou les supprime-t-il ? Si la route existe quelque part, le chemin de recherche est-il correct pour le trafic que vous testez ?

Ce n'est que lorsque la première réponse est oui, la deuxième oui et la troisième correcte qu'un script supplémentaire devient défendable, et même alors vous devriez demander si le backend prend en charge la route nativement. La référence des paramètres VPN documente service-type et le dictionnaire de données propre au greffon, et c'est là qu'il faut commencer avant de supposer qu'une clé existe.

Après une correction approuvée, reconnectez-vous et testez la destination par adresse puis par nom, puis déconnectez-vous et reconnectez-vous pour confirmer que l'état est reproductible. Un propriétaire, une table et une route qui disparaît avec le tunnel, voilà le résultat qui vaut la peine.