L'état de NEVPNManager est invalide tant que les préférences ne sont pas chargées

Relancez l'application, demandez au gestionnaire l'état de la connexion, et il répond « déconnecté » alors que le menu système montre clairement un tunnel actif. Ou bien un appel d'enregistrement renvoie une erreur qui n'explique rien, ou bien un secret partagé est déclaré manquant quelques secondes après avoir été attribué. Trois symptômes, un seul mécanisme : le gestionnaire est une vue sur un magasin système, et une vue se lit vide tant que personne ne la charge.

Avant de déboguer quoi que ce soit de tout cela, déterminez quelle API vous devez utiliser. Un tunnel IPsec ou IKEv2 du système convient au gestionnaire intégré ; un protocole que le système n'implémente pas exige un fournisseur de tunnel avec votre propre gestion des paquets, et aucune combinaison de champs n'y change rien.

Le gestionnaire est une vue sur un magasin

Créez ou récupérez le gestionnaire, demandez-lui de charger ses préférences et laissez le gestionnaire de complétion se terminer avant de lire l'état ou de modifier les réglages du protocole. Quand la tâche consiste à énumérer les configurations enregistrées, utilisez l'appel de toutes les variantes plutôt que de réutiliser une seule instance à deux fins. Avant l'arrivée du chargement, l'état est généralement invalide, et convertir invalide en éteint est précisément le bug qui fait qu'une application paraît fausse seulement après un relancement.

L'écriture suit le même ordre. Un enregistrement tenté sur un gestionnaire qui n'a jamais rien chargé peut échouer sans message utile, car il n'existe aucune identité stockée à laquelle appliquer la modification. Chargez, modifiez, enregistrez, puis relisez l'état. L'objet auquel le système se connecte est le profil enregistré, pas celui que vous éditiez en mémoire.

Les changements d'état n'arrivent que pendant que vous regardez

Une fois les préférences chargées, l'état passe par déconnecté, connexion, connecté, réaffirmation et déconnexion. Initialisez l'interface à partir d'une seule lecture, puis écoutez la notification de changement au lieu d'interroger avec un minuteur. L'interrogation fonctionne au premier plan et ment en arrière-plan, et c'est ainsi que les applications finissent avec un indicateur qui ne se résout jamais.

Les notifications n'arrivent que tant que l'application est au premier plan. Tout ce qui maintient un état en arrière-plan paraîtra obsolète après un relancement, alors rafraîchissez au lancement et de nouveau quand l'application revient au premier plan. Si un fournisseur possède le tunnel, pilotez-le via l'objet de session correspondant ; la propriété de connexion simple ne modélise pas le cycle de vie d'un fournisseur.

Les secrets sont des références, pas des chaînes

Une erreur signalant un secret partagé manquant signifie rarement que personne n'en a attribué un. L'objet de protocole veut une référence : une pour le mot de passe utilisateur et une pour la clé prépartagée IPsec. Passer nil, ou une référence dérivée de la mauvaise entrée du trousseau, produit la même plainte qu'un emplacement vide. L'erreur nomme le symptôme et cache la cause, c'est pourquoi les gens ressaisissent le même secret plusieurs fois.

Écrivez d'abord le secret comme élément de mot de passe générique, puis relisez une référence persistante vers celui-ci. Une référence persistante survit à un relancement, contrairement à un pointeur gardé en mémoire, et c'est la représentation que le profil sérialise. Choisissez une classe d'accessibilité qui autorise encore l'accès une fois l'appareil déverrouillé, sinon un tunnel qui doit se reconnecter sur un écran verrouillé échouera l'authentification avec un secret parfaitement valide.

L'extension a sa propre vue du trousseau

Une extension réseau est un processus séparé, donc l'accès par défaut de l'application au trousseau ne l'atteint pas. Donnez aux deux cibles le même groupe d'accès au trousseau dans leurs droits, stockez l'élément une fois dans ce groupe et laissez chaque processus le lire. Sans le groupe, l'extension ne trouve rien et signale un échec d'identifiants que l'application ne peut pas reproduire.

Si le fournisseur est configuré via son objet de configuration de fournisseur, n'intégrez pas aussi le secret dans l'application. Deux copies divergent, et la divergence se présente comme de mauvais identifiants plutôt que comme une duplication. Un widget ou un second processus signalant un autre état a la même explication : chacun a besoin du groupe, et chacun doit charger les préférences avant de lire.

Faites correspondre l'API au protocole

Le gestionnaire intégré porte des objets de protocole IPsec et IKEv2. Il ne devient pas un client SSL VPN générique grâce à des champs supplémentaires, et un profil inadapté peut s'enregistrer proprement et pourtant ne jamais se connecter. Décidez à quelle catégorie vous appartenez avant d'enquêter sur l'état, car un bug d'état et un protocole non pris en charge se ressemblent vus de l'extérieur.

Pour le prochain relancement, la liste de contrôle est courte : chargez les préférences, lisez l'état, gardez les abonnements aux changements au premier plan, reconstruisez les références depuis le groupe partagé et confirmez que l'objet de protocole correspond à l'API que vous avez implémentée. Parcourir cette liste prend une minute ; la deviner prend tout un après-midi.