Comment assembler un profil client OpenVPN à partir des fichiers délivrés

Votre opérateur vous remet un paquet de CA, un certificat client et sa clé, et le client ne démarrera pas tant qu'ils ne seront pas réunis dans un seul profil. Le profil est une configuration : il pointe vers ces fichiers, il ne les contient pas, et le modifier ne peut pas en faire un certificat. La procédure part d'un ordinateur portable déjà approuvé et se termine par un profil que vous pouvez lancer depuis un répertoire connu. Elle ne crée pas de CA, n'enrôle pas de nouveau certificat et ne touche pas au serveur.

La cible ici est un client en ligne de commande OpenVPN 2.6 sous Linux, routé en TUN sur UDP, avec authentification par certificat.

Ne rassemblez que les fichiers côté client

Travaillez dans un répertoire protégé et rassemblez le matériel de confiance CA approuvé, votre certificat client délivré et la clé privée qui lui correspond. Dans cet exemple, les noms sont ca.crt, laptop-a.crt et laptop-a.key. Les noms de fichiers ne sont que des étiquettes ; ils ne disent rien de ce que contient chaque fichier.

Si vous avez généré la clé lors de l'enrôlement, elle n'a jamais quitté la machine ; seuls le certificat signé et la chaîne publique doivent revenir de l'émetteur. Vérifiez que le certificat porte le rôle client attendu par le service. Vérifiez aussi que la clé appartient à ce certificat et non à un plus ancien d'une tentative précédente. Une paire qui ne correspond pas produit un échec TLS bien plus tard, qui ressemble à un problème de serveur.

Laissez la clé de signature privée de la CA, la clé privée du serveur et les paramètres DH hors de ce paquet.

Reliez les fichiers dans un petit profil

Le profil ci-dessous est volontairement court. Chaque ligne soit sélectionne le point de terminaison, soit contraint l'identité que le client acceptera, soit pointe vers l'un des trois fichiers.

client
dev tun
proto udp
remote vpn.example.net 1194
nobind

remote-cert-tls server
verify-x509-name vpn-gateway name
ca ca.crt
cert laptop-a.crt
key laptop-a.key

La ligne remote choisit le point de terminaison réseau. remote-cert-tls server exige que le pair présente un certificat avec le rôle serveur. verify-x509-name fixe le nom attendu, ici vpn-gateway comme Common Name du certificat du serveur avec le champ de nom par défaut d'OpenVPN. Cette valeur n'est pas déduite du nom d'hôte DNS, utilisez donc le schéma d'identité fourni par l'opérateur.

N'abandonnez pas ces contrôles simplement parce qu'un point de terminaison de test présente un autre certificat.

Ce profil de base suppose ni défi de compte séparé ni clé de canal de contrôle. Si le service a besoin de auth-user-pass, tls-auth ou tls-crypt, conservez la configuration et le matériel qui vous ont été remis, car un secret de canal de contrôle que vous générez vous-même ne correspondra pas à celui que détient le serveur. Conservez aussi la politique de chiffrement du service au lieu d'importer des lignes de compression ou de chiffrement d'un ancien exemple.

Rendez le répertoire de travail explicite

Les chemins relatifs suivent le répertoire de travail du processus, pas l'emplacement du fichier .ovpn.

Cela surprend ceux qui déplacent le profil dans un nouveau dossier et s'attendent à ce que la clé suive. Pour un répertoire choisi par l'administrateur, la commande ci-dessous passe à un chemin absolu avant de lire le profil et ses références.

sudo openvpn --cd /etc/openvpn/client/laptop-a --config laptop-a.ovpn

Un assistant d'importation de bureau ou un service système peut empaqueter les dépendances pour vous et appliquer ses propres règles. Il peut aussi utiliser un répertoire de travail différent de celui dans lequel vous avez testé. Vérifiez comment votre méthode de lancement résout les chemins de la clé, du certificat et de la CA. Déplacer seulement le fichier .ovpn ne déplace pas la clé privée séparée.

Gardez la clé lisible uniquement pour l'utilisateur ou l'identité de service prévus.

Vérifiez la remise, pas les noms de fichiers

Avant la première connexion autorisée, vérifiez le point de terminaison, l'identité du certificat, l'émetteur et la fenêtre de validité. Confirmez ensuite que les références de fichiers se résolvent depuis le répertoire de travail que vous utiliserez réellement. Après la connexion, testez le comportement de l'application et du DNS que la politique de routage est censée fournir. Trois fichiers lisibles ne prouvent rien sur l'autorisation du serveur ni sur un chemin de ressource utilisable.

Si une invite de phrase de passe apparaît, elle appartient à la clé privée, pas à un compte VPN.

Enfin, inventoriez le paquet comme matériel d'identification. Remettre le même certificat et la même clé à un second ordinateur portable copie l'identité, et renommer le fichier ne vous donne pas un second enrôlement. C'est la différence entre assembler un profil et le délivrer.