Comment vérifier le serveur d’un profil OpenVPN avant de l’importer

On vous envoie un profil, vous l’importez, et trente secondes plus tard un client compose une destination que personne n’a vérifiée. Lisez d’abord le fichier dans un éditeur de texte, car tout ce qui compte tient dans une poignée de directives : remote, proto, port, ca, cert, tls-crypt et verify-x509-name. Tout le reste relève des valeurs par défaut, et c’est dans les valeurs par défaut que se cachent les surprises.

Lister tous les points de terminaison que le fichier peut utiliser

Commencez par les points de terminaison, car un même profil peut en contenir plusieurs. grep -nE '^[[:space:]]*(remote|proto|port|remote-random|connection)' profile.ovpn affiche chaque candidat dans l’ordre du fichier, y compris ceux imbriqués dans des blocs <connection> en ligne.

Quand une directive omet le port, le client retombe sur la valeur par défaut de l’écouteur : remote vpn.example.com seul signifie donc le port 1194 avec le proto qui apparaît plus loin dans le fichier. Plusieurs lignes remote simples sont des alternatives : le client les essaie dans l’ordre, sauf si remote-random les mélange, et il ne remplace jamais silencieusement l’hôte d’un autre opérateur. Deux lignes remote sur des domaines sans rapport, c’est le moment de vous arrêter et de demander laquelle était voulue.

Notez aussi l’orthographe de proto. tcp est accepté comme synonyme de tcp-client côté client, mais tcp-server dans un profil client est une erreur de configuration qui a tendance à bloquer plutôt qu’à échouer proprement.

Confirmer le nom, puis le port

dig +short vpn.example.com indique si le nom existe et quelles adresses il renvoie, et un point de terminaison multi-homé ou mandaté peut légitimement en renvoyer plusieurs. La résolution est un prérequis, pas une preuve de propriété ; n’importe qui peut faire pointer un nom vers une adresse, et une adresse peut répondre pour plusieurs noms.

Vérifiez ensuite l’écouteur sur le port trouvé, en accord avec le transport. Sur TCP, openssl s_client -connect vpn.example.com:1194 -servername vpn.example.com affiche la chaîne présentée par le serveur. Sur UDP, il faut DTLS : openssl s_client -dtls1_2 -connect vpn.example.com:1194 exécute la même poignée de main sur des datagrammes. Une poignée de main aboutie prouve que quelque chose écoute et détient un certificat, ce qui est plus qu’un ping et moins que ce qu’exigent les propres réglages de confiance du profil.

Quand la poignée de main échoue alors que l’hôte répond au ping, le port est probablement faux ou filtré. Considérez cela comme une raison de demander le bon port, pas comme une invitation à balayer les ports voisins. nc -vzu signale aussi un succès sur certaines piles alors que rien n’écoute, donc une sonde UDP nue ne veut rien dire sans poignée de main derrière.

Lire les épingles de confiance séparément de l’adresse

L’adresse décide où va le client ; le bloc de confiance décide qui il croit une fois arrivé. verify-x509-name "vpn.example.com" name épingle le nom commun du sujet, et remote-cert-tls server exige l’usage étendu de la clé pour l’authentification du serveur. Un profil remis par un opérateur devrait porter les deux.

Cherchez ca, un bloc <ca> en ligne, et soit tls-crypt, soit tls-auth. Un profil qui utilise tls-auth a besoin de key-direction 1 côté client quand le serveur utilise la direction 0, et une incohérence fait échouer la poignée de main avec une erreur TLS qui ressemble à une faute de certificat. Un CA en ligne qui n’appartient pas à l’opérateur dont vous venez de résoudre le nom signifie que le fichier a été assemblé à partir de deux sources, et c’est le cas qu’il vaut la peine de refuser d’emblée.

verify-x509-name accepte les modes name, name-prefix ou subject, et le dernier attend un nom distingué complet dans l’ordre exact où le serveur l’affiche. Choisissez un mode qui correspond à la forme de la valeur, car le client rejette toutes les connexions au lieu d’avertir d’un quasi-match. Pour un fichier que vous n’avez pas écrit, name avec un simple nom d’hôte est le choix le moins surprenant.

Vérifier les options qui échouent en silence

OpenVPN 2.6 négocie les chiffrements via data-ciphers, et un profil qui ne porte qu’une vieille ligne cipher AES-256-CBC peut terminer le canal de contrôle puis se bloquer sur les données. Lire cette valeur vous dit si le fichier précède le serveur que vous rejoignez ; la page de manuel de la 2.6 liste l’ordre de négociation si vous devez le citer à l’opérateur.

auth-user-pass sans nom de fichier signifie que le client va demander, donc un profil qui semble autonome a quand même besoin d’identifiants. auth-user-pass credentials.txt signifie qu’il attend un fichier que vous n’avez probablement pas reçu. nobind et resolv-retry infinite sont ordinaires et inoffensifs, tandis que explicit-exit-notify est réservé à UDP et inutile sur TCP.

Aucune de ces options ne change l’endroit où le profil se connecte, mais chacune change s’il se connecte du tout, et aucune n’est visible dans la boîte de dialogue d’import d’un client.

Décider, puis consigner votre décision

Trois issues existent après cette lecture, et une seule est l’import. Quand le point de terminaison et les épingles correspondent aux instructions reçues par un autre canal, importez-le. Quand le point de terminaison semble correct mais que les épingles ou le CA ne correspondent pas, demandez un fichier corrigé. Quand le fichier mélange des points de terminaison ou du matériel CA de sources différentes, supprimez-le et demandez une copie neuve.

Consignez le hachage que vous avez vérifié, afin que la personne suivante puisse dire si le fichier a changé : sha256sum profile.ovpn, collé à côté du point de terminaison dans vos notes. Un profil est un agencement complet, pas une liste d’adresses : ne greffez jamais un remote qui fonctionne dans le bloc de confiance de quelqu’un d’autre en gardant ses identifiants.

Gardez les clés privées et les mots de passe hors des captures d’écran et des fils de discussion pendant que vous comparez vos notes. Le point de terminaison et les options non secrètes suffisent pour poser une question précise, et le reste appartient au fichier.

Si vous l’importez et que la première tentative échoue, lancez le client avec --verb 3 et lisez les dix premières lignes : l’adresse distante résolue, le proto négocié et l’erreur TLS apparaissent dans cet ordre, ce qui vous dit laquelle des vérifications ci-dessus vous avez sautée.