Connecter un petit contrôleur à un VPN NetworkManager

Un petit programme qui connecte un VPN existant a besoin d'un contrôleur, pas d'une nouvelle implémentation de VPN. Le moteur pris en charge doit gérer la négociation et le trafic du tunnel ; votre programme doit exprimer la demande de l'utilisateur et expliquer le résultat honnêtement. Sous Linux, l'interface D-Bus de NetworkManager donne à ce contrôleur un modèle concret à suivre.

Quatre vérifications empêchent le contrôleur de confondre un profil enregistré, une demande d'activation et une session en fonctionnement.

Vérification un : quelle identité est sélectionnée

Gardez l'UUID du profil comme identité persistante et résolvez-le via le gestionnaire lorsque vous avez besoin du chemin d'objet. Un nom d'affichage peut être partagé par deux profils, et un chemin de bus à l'exécution n'est pas une préférence utilisateur raisonnable à stocker. Écrivez la sélection dans votre propre configuration, pas dans un commentaire sur l'entrée qui était la deuxième de la liste.

Vérifiez ce que le gestionnaire renvoie avant de parler de correspondance. Un UUID qui n'existe plus produit un échec de recherche, ce qui est un chemin de code différent de celui d'un profil qui existe et refuse de s'activer.

Vérification deux : ce que renvoie l'appel d'activation

L'appel d'activation documenté prend le chemin d'objet d'une connexion existante, un chemin de périphérique et un objet spécifique. Il renvoie un chemin de connexion active, et cette réponse est un descripteur, pas un résultat de disponibilité. Ne fixez pas l'indicateur de disponibilité de votre application à partir de la valeur de retour ; abonnez-vous plutôt à l'état et à la raison de la connexion active.

Pour un VPN, l'objet spécifique sélectionne la connexion de base active. Passer le chemin racine laisse le choix du périphérique à NetworkManager, qui prend celui qui est actuellement par défaut. C'est une décision de contexte de routage et non un champ de mot de passe, et elle change le périphérique sur lequel le tunnel est superposé.

Ne reprenez pas un exemple générique d'ajout et d'activation en espérant qu'il crée un profil VPN. L'assistant documenté exclut les connexions VPN, donc le provisionnement ou l'import du profil est une étape distincte et revue. Cela compte parce que le provisionnement exige une autorisation et une revue qu'un bouton de connexion n'apporte pas. Traitez l'import comme une action administrative avec sa propre ligne de journal et son propre approbateur.

Vérification trois : comment l'état est représenté

Une connexion active passe par activation, active, désactivation et désactivée, et le champ de raison dit pourquoi. Réduire tout cela à un booléen nommé loggedIn perd l'information dont l'utilisateur a besoin et celle que le support demandera. Affichez au moins si la connexion est en attente, établie ou disparue, et conservez la chaîne de raison pour le cas d'échec.

Associez les réponses asynchrones à la demande qui les a produites. Une fin tardive d'une tentative plus ancienne ne doit pas écraser une action plus récente de l'utilisateur, et un appui répété sur Connect doit être ignoré ou traité comme une annulation et une nouvelle tentative avec une politique visible.

Vérification quatre : ce qui se passe après un redémarrage

Lorsque le gestionnaire redémarre ou que votre contrôleur se reconnecte au bus, reconstruisez l'état observé auprès du propriétaire. Ne continuez pas à afficher une session mise en cache comme active parce qu'un ancien chemin d'objet est encore en mémoire. Les signaux de changement d'état existent précisément pour qu'un contrôleur puisse se resynchroniser au lieu de deviner.

Choisissez ce que signifie fermer le contrôleur. Laisser une connexion existante appartenant à la machine active peut être correct, et démonter une session délibérément éphémère peut aussi être correct. Laisser une connexion existante appartenant à la machine active peut être correct ; démonter une session délibérément éphémère peut aussi être correct. Écrivez ce contrat de propriété dans l'interface au lieu de supposer que la sortie du processus effectue l'action réseau. Les utilisateurs ne devraient pas avoir à deviner si fermer la fenêtre fera tomber leur tunnel. Mettez la réponse dans le texte de l'interface, pas seulement dans un commentaire de code.

Gardez l'autorité et les secrets chez leurs propriétaires

Les permissions reviennent sous la forme oui, auth ou non, et l'interface doit refléter la différence entre autorisé, autorisé après authentification et refusé. Exécuter le contrôleur en root n'implémente pas une politique de permissions ; cela supprime la question.

Les identifiants appartiennent à l'agent de secrets pris en charge ou à l'intégration client pour la méthode d'authentification configurée. Un mot de passe dans le code source, dans un argument ou dans un journal est une constatation, et une autorisation administrative locale n'est pas le même événement que l'authentification auprès de la passerelle.

Enfin, rapportez l'état de la connexion séparément de la tâche que l'utilisateur veut accomplir. Un tunnel peut être actif tandis qu'un nom privé ou une application reste indisponible, et ce second échec mérite son propre message et son propre statut. Un contrôleur qui dit exactement quelle couche a échoué est plus utile qu'un autre qui dit que le VPN est en panne.