Pourquoi un profil OpenVPN ne s’importe pas dans SoftEther

Deux fichiers qui ressemblent tous deux à une configuration VPN atterrissent dans le même dossier, et un seul fonctionne. Le profil OpenVPN décrit un tunnel TLS avec des directives que ce client comprend, tandis qu’une connexion SoftEther décrit une session contre un concentrateur virtuel avec un contrat d’authentification différent. Convertir l’un en l’autre n’est pas un exercice de formatage, car les deux clients n’implémentent pas le même protocole. Identifier le service que l’opérateur a réellement publié décide de tout ce qui suit.

Deux fichiers, deux contrats

Un profil OpenVPN est une configuration client : un point de terminaison distant, un transport, du matériel TLS et des directives pour le routage et la renégociation. Une connexion SoftEther est une session client native contre un concentrateur virtuel, avec un adaptateur virtuel qui y est rattaché.

Ils peuvent décrire l’accès au même réseau sans être interchangeables. L’écouteur OpenVPN est une fonction de compatibilité que le serveur peut publier sur un port séparé, et il parle OpenVPN plutôt que le protocole natif. Le client natif parle le protocole natif et attend son propre profil. Un serveur, deux portes, et chaque porte a sa propre clé.

L’extension du fichier ne vous dit presque rien, c’est pourquoi la réponse de l’opérateur compte plus que le nom du fichier.

Lisez le serveur avant de toucher un bloc de certificat

Demandez trois choses à l’opérateur : quel port et quel transport, quelle méthode d’authentification et quel client ils attendent que vous utilisiez. Ces réponses éliminent la majeure partie des suppositions.

Confirmez ensuite ce qui écoute réellement, plutôt que ce qu’affirme un guide. Un écouteur de compatibilité désactivé ne montre rien sur son port, et un écouteur activé montre une socket même si personne ne s’est jamais connecté. La différence entre un port fermé et une connexion refusée est le premier diagnostic utile. Tout ce qui suit dépend de la porte à laquelle on a frappé.

ss -lunp | grep -E ':1194|:443'
sudo ss -ltnp | grep -E ':992|:5555'
grep -nE '^(remote|proto|auth-user-pass|ca |cert |key )' profile.ovpn

Un port UDP absent de la liste des écouteurs est une fonction désactivée et non un problème de pare-feu.

Ce dont le client natif a besoin et qu’un profil ne peut pas lui donner

Le client natif installe un adaptateur réseau virtuel et y rattache une connexion. Sans cet adaptateur, il n’y a aucune interface par laquelle router, ce qui explique qu’une connexion native puisse s’authentifier et ne transporter aucun trafic.

L’authentification native s’exécute contre un concentrateur virtuel, avec un objet utilisateur créé par l’administrateur du concentrateur. Les blocs de certificat copiés d’un profil OpenVPN ne deviennent pas des utilisateurs du concentrateur, et un utilisateur du concentrateur ne devient pas un certificat client. Les deux systèmes stockent des choses différentes, et un profil n’a nulle part où placer l’enregistrement utilisateur du concentrateur. C’est une différence structurelle et non un problème de syntaxe.

Gardez la clé privée hors de tout service de conversion, car une clé qui quitte la machine doit être traitée comme divulguée.

Ce que l’écouteur compatible OpenVPN accepte

L’écouteur de compatibilité est un véritable serveur OpenVPN du point de vue du client : il attend un client OpenVPN et les directives que ce client prend en charge. Les blocs de certificat en ligne sont une fonction d’OpenVPN, et ils appartiennent à ce côté de la clôture.

Ce qu’il ne fera pas, c’est accepter un profil SoftEther natif, car ce profil n’est pas une configuration OpenVPN. L’écouteur ne transforme pas non plus le client natif en client OpenVPN. Si l’opérateur ne propose que le service natif, la réponse est le client natif ; s’il propose l’écouteur de compatibilité, la réponse est OpenVPN et son propre matériel.

Demandez l’export pris en charge de l’opérateur au lieu d’en assembler un à partir de fragments, car l’export porte des détails qu’un fichier construit à la main oublie généralement.

Prouvez le chemin avant de modifier des directives

Une fois le client choisi, testez le tunnel avant de toucher aux routes. Une connexion réussie et une interface qui transporte du trafic sont deux résultats différents.

sudo openvpn --config profile.ovpn --verb 3
ip -br addr
ip route get 10.70.4.20
resolvectl status | grep -A2 'DNS Servers'

Comparez l’adresse attribuée au pool décrit par l’opérateur, puis examinez séparément les routes et le résolveur. Une connexion native au concentrateur peut s’authentifier proprement et n’installer aucune route, ce qui ressemble côté client à un tunnel cassé. Ce n’est qu’une fois ces trois éléments d’accord qu’il vaut la peine de modifier une directive. Modifier plus tôt masque quelle couche était en cause.