Le profil OpenVPN de Windows échoue sur Ubuntu : trois couches

Lancez le même profil depuis un terminal et le message que la plupart des gens copient est un avertissement, pas la raison de l’arrêt du client. Trois couches indépendantes échouent ici : une directive poussée que la compilation Linux n’implémente pas, les droits nécessaires pour créer un périphérique tun et l’assistant de résolution qui transforme une connexion en DNS fonctionnel. Traitez-les dans l’ordre, car chacune peut masquer la suivante.

Conservez le téléchargement tel qu’il est arrivé et modifiez une copie, afin qu’un nouveau téléchargement n’annule pas vos modifications en silence.

Lisez l’avertissement avant de l’accuser

block-outside-dns verrouille le DNS sous Windows via la plateforme de filtrage de Windows, et le client Linux n’a rien à quoi l’associer. Quand le serveur le pousse, le client affiche une ligne d’option inconnue pour cette entrée poussée et continue, car une option poussée n’est pas traitée comme fatale. La ligne identique dans votre propre fichier est autre chose : là, l’analyseur s’arrête. Déterminez laquelle des deux vous avez avant de toucher à quoi que ce soit, car une seule des deux met fin à l’exécution.

Pour supprimer le bruit, filtlez-le avant l’analyse : une entrée pull-filter ignore pour ce nom, ou --ignore-unknown-option quand la ligne est dans le fichier local. Les deux font taire une ligne que vous avez déjà lue ; aucune ne répare une panne que vous n’avez pas diagnostiquée.

Les privilèges échouent avant tout le reste

Un périphérique tun et les routes qui l’accompagnent sont des objets privilégiés, et un compte normal ne peut pas les créer. L’option --user explique ce partage : le démon n’abandonne ses privilèges qu’une fois le travail privilégié terminé. Lancez-le en root, ou via une unit qui le lance ainsi, puis cherchez une erreur de permission avant de regarder les certificats. Assouplir les permissions du fichier du profil ne donne pas au processus les droits qui lui manquent.

Une erreur TLS signifie que le client a franchi cette couche. Une plainte concernant le périphérique ou la route signifie qu’il n’a jamais atteint la couche du dessus.

Ce que fait l’interface graphique et pas le terminal

Se connecter avec succès alors que chaque résolution échoue encore, c’est la troisième couche. NetworkManager fait son propre travail de résolution, ce qui explique qu’un import depuis le bureau puisse distribuer du DNS même lorsque le script up du profil n’a jamais abouti. La commande openvpn --config exécute ce que --up désigne, et si cet assistant manque, l’interface apparaît tandis que les requêtes continuent vers les serveurs précédents. Comparez les scripts des deux chemins avant d’installer quoi que ce soit.

Utilisez l’assistant empaqueté de votre distribution ; un script copié depuis un billet de blog vise généralement un autre résolveur. L’intégration fournie pour systemd-resolved n’est pas le script générique de style vpnc, et chacune attend ses propres arguments et variables du client. Les scripts up définis par l’utilisateur exigent aussi script-security 2 avant que le client ne les exécute.

Séparez les couches à la prochaine exécution

Exécutez une fois avec --verb 4 et lisez le journal dans l’ordre où les choses se sont produites : création du périphérique, routes, poignée de main TLS, puis sortie du script up. La première défaillance de cette séquence est celle qui vaut la peine d’être corrigée ; tout ce qui suit en découle généralement. Un tunnel qui s’établit alors que le résolveur ne suit pas vous place sur la troisième couche, où le certificat est sans importance. Laissez le profil téléchargé intact pendant la comparaison.

Dès que chaque retouche de l’opérateur produit une ligne rejetée de plus, le fichier vise une autre plateforme. Demandez un export Linux au lieu de construire une liste de filtres permanente.

Notez quelle couche a échoué et ce qui l’a changée, car la personne suivante qui recevra le même fichier s’arrêtera elle aussi à l’avertissement.