La plupart des gens supposent qu’un fichier .ovpn configure un VPN. Ce n’est pas le cas : il configure un client, et tout ce qu’il demande doit déjà exister de l’autre côté. Modifier une ligne du fichier peut changer ce que votre machine tente, jamais ce que le serveur propose. Cette distinction explique l’essentiel de la confusion autour des profils qui ne s’importent pas ou ne se connectent pas.

Lisez le fichier comme une liste de demandes adressées à votre client, et la plupart de ses lignes deviennent évidentes.

Le fichier décrit votre client, pas le serveur

Un profil regroupe le point de terminaison remote, un transport, un type d’interface, du matériel d’identité et tout comportement côté client que l’opérateur souhaite. Chaque ligne est exécutée par le client au démarrage. Aucune n’atteint le serveur comme un changement de configuration, et aucune ne peut créer un écouteur qui n’est pas déjà en cours d’exécution. Un profil qui indique TCP 443 face à un serveur qui n’écoute que sur UDP 1194 échoue au premier paquet.

C’est aussi pourquoi le même fichier se comporte différemment sur deux clients : le fichier demande, et le client décide de la part de la demande qu’il peut honorer.

Les lignes de transport doivent correspondre à un écouteur qui existe déjà

proto et remote doivent correspondre à ce que le serveur lie réellement. UDP est le choix habituel car un datagramme perdu ne bloque pas le tunnel, tandis que TCP peut survivre à des réseaux restrictifs au prix d’un blocage en tête de file à l’intérieur du tunnel. Passer un profil d’UDP à TCP ne fait pas accepter TCP au serveur ; cela fait seulement envoyer le client vers un port que personne ne lit.

Le port 443 est populaire parce qu’il traverse des réseaux qui n’autorisent presque rien d’autre, et il reste une session OpenVPN plutôt qu’une requête HTTPS. Si l’opérateur publie plusieurs remote lignes, le client les essaie dans l’ordre, ce qui est une liste de basculement et non une décision d’équilibrage de charge. Conservez les combinaisons fournies par l’opérateur au lieu de mélanger un hôte d’une entrée avec un port d’une autre.

Les clés intégrées changent la façon de manipuler le fichier

Les certificats et les clés peuvent être intégrés entre les balises <ca>, <cert> et <key>, ou être référencés comme des fichiers séparés. Le matériel intégré rend le profil autonome et en fait aussi un secret, car la clé privée du client voyage à l’intérieur. Un certificat CA est un matériel de confiance public et peut être partagé sans risque ; une clé privée non, même lorsqu’elle ressemble à un bloc de texte illisible.

La phrase secrète qui protège une clé est un secret distinct du mot de passe du compte, et les confondre produit un échec d’authentification qui ressemble à des identifiants erronés.

Les routes et le DNS peuvent ne pas venir du fichier du tout

Le routage peut être poussé par le serveur, défini par le profil avec redirect-gateway, ou laissé aux valeurs par défaut du client. Le fichier téléchargé ne détermine donc pas entièrement où va le trafic une fois le tunnel monté. Quand les noms internes se résolvent et que les sites publics ne le font pas, la politique de tunnel divisé fait ce pour quoi elle a été conçue, elle n’échoue pas.

Le DNS suit le même schéma : un dhcp-option DNS poussé peut être appliqué par le client, ignoré ou remplacé par un gestionnaire de résolveur local. Vérifiez l’état du résolveur après la connexion plutôt que de relire le profil.

Les options non prises en charge sont une question de version du client

Les avertissements d’importation signifient généralement que le client n’implémente pas une directive, pas que le fichier est corrompu. Les clients de bureau peuvent exécuter des scripts et des plugins sous des contrôles documentés, tandis que les clients mobiles acceptent un ensemble plus étroit et peuvent ignorer silencieusement des lignes qu’ils ne comprennent pas. Un réglage de chiffrement ou TLS qu’un client plus ancien refuse est un problème de version à régler avec l’opérateur. Activer des privilèges inconnus pour forcer une importation échange un avertissement contre une surface d’attaque plus large.

Conservez le fichier d’origine pour comparaison, notez la directive non prise en charge exacte dans votre demande, et demandez un profil conçu pour le client que vous exécutez réellement.

Après tout remplacement, confirmez quelle entrée de profil l’application utilise, car importer un nouveau fichier n’écrase pas toujours l’ancien.

Articles similaires