Portabilité du profil OpenVPN : clés portables ou options de plateforme

Le même fichier .ovpn ouvre un tunnel dans un client et refuse de démarrer dans un autre, et le certificat est généralement le premier suspect. Le plus souvent, le fichier contient une directive qu’un seul moteur implémente. Un profil est un contrat avec un client précis, pas un script portable.

Séparez ce qui voyage avec l’identité de ce qui appartient à une plateforme. L’échec se nomme alors souvent de lui-même.

Un fichier, deux contrats

Un profil regroupe trois types de contenu : le matériel d’identité, comme les certificats CA et client et la clé privée, les faits de transport, comme le point de terminaison distant et le protocole, et les directives de comportement, comme la gestion du DNS ou les options d’appareil. Les deux premiers sont largement portables entre moteurs qui prennent en charge le même protocole. Le troisième est là où les implémentations divergent. Traiter le fichier entier comme une seule unité portable est ce qui produit les échecs déroutants.

Un fichier qui fonctionne dans une interface graphique sur une plateforme n’est pas automatiquement valable pour le client en ligne de commande d’une autre. Même lorsque les deux sont OpenVPN, les analyseurs et les jeux d’options diffèrent. C’est pourquoi un import réussi n’est pas la preuve d’un profil portable.

Matériel portable contre directives de plateforme

Les sections d’identité et de transport sont la partie à conserver. ca, cert, key et remote décrivent qui se connecte et où, et ils signifient la même chose pour tout client conforme.

Les directives de comportement sont la partie à comparer. block-outside-dns, par exemple, existe pour modifier le comportement du DNS sous Windows. Un client Unix peut ne pas le reconnaître du tout.

Lisez la liste d’options du client récepteur plutôt que celle de l’émetteur. Le manuel de référence OpenVPN 2.6 documente les options du moteur, et la boîte d’import d’une interface graphique n’est pas cette liste.

Lisez l’erreur de l’analyseur avant le certificat

Une erreur qui nomme une option non reconnue est un échec de l’analyseur, pas un échec d’authentification. La connexion n’a jamais atteint TLS, donc changer les certificats ne peut pas aider. Lisez la première erreur du client et de la version réels, puis retirez ou remplacez uniquement la directive que ce client ne peut pas implémenter. Supprimer les sections de certificat ou de routes pour que le fichier se charge est la façon dont un profil fonctionnel devient non sécurisé.

Si l’erreur mentionne la poignée de main, un certificat ou un chiffrement, le profil a été analysé et le problème est ailleurs.

Gardez le fichier d’origine à côté de celui qui a été adapté. Lorsque le fichier adapté échoue plus tard, l’original est le témoin qui indique si c’est la modification ou l’environnement qui a bougé.

Les privilèges sont une seconde frontière

Les privilèges sont l’autre frontière : créer un périphérique tunnel, installer des routes et lire une clé privée dépendent tous des autorisations locales. Un fichier de clé lisible uniquement par root est un déploiement normal, pas un défaut du profil. Le correctif relève de la propriété ou des capacités, pas du fichier.

Exécuter le client avec sudo peut résoudre un refus d’autorisation local, et cela ne peut pas ajouter une directive que le binaire n’implémente pas. Cela change aussi le trousseau, les chemins de configuration et le contexte du gestionnaire de réseau qui s’appliquent, donc le résultat n’est pas le même test.

Adaptez délibérément

Lorsqu’un fournisseur publie des profils séparés, prenez celui destiné au client récepteur. Adapter le fichier d’une autre plateforme est un dernier recours. Cela exige un relevé de chaque option modifiée et une copie de l’original.

Testez l’identité, le routage et le DNS comme trois résultats distincts. Un profil qui s’authentifie et route mais casse la résolution de noms est un profil partiellement adapté, pas un profil fonctionnel.