Client natif SoftEther ou profil OpenVPN : choisissez le bon port

Un serveur SoftEther peut répondre en même temps sur le port SSL natif et sur un port compatible OpenVPN, ce qui fait ressembler les deux à un seul service avec deux portes. Ce sont deux services avec des clients différents, des formats de configuration différents et des capacités différentes. Déposer un profil natif dans un client OpenVPN échoue à l’analyse, et l’erreur dit rarement pourquoi.

Choisissez d’abord l’écouteur, ensuite le client.

Deux écouteurs, deux formats de configuration

Le protocole natif utilise un client SoftEther et une définition de connexion qui nomme le serveur, le port, le hub virtuel et l’utilisateur. L’écouteur compatible OpenVPN attend un profil OpenVPN avec une directive remote, du matériel TLS et des options issues d’un ensemble pris en charge bien plus petit que ce qu’offre un serveur OpenVPN autonome. SoftEther appelle cela une fonction de clone OpenVPN, et clone est un indice utile sur la fidélité.

La compatibilité est une question de version. Vérifiez ce que la version déployée accepte plutôt que ce que documente un manuel OpenVPN actuel.

Étape 1 : trouvez quel écouteur l’exploitant a activé

Demandez la liste des écouteurs au lieu de deviner à partir d’un numéro de port. Un serveur qui répond en TLS sur le 443 n’est pas forcément un point de terminaison OpenVPN, car le protocole natif peut utiliser le même port. La section du manuel sur les fonctions de serveur compatibles décrit quels clones existent et comment ils sont activés.

Si vous pouvez joindre l’hôte, testez le port qu’on vous a donné plutôt que celui d’un tutoriel : openssl s_client -connect vpn.example.com:443 -brief au moins vous dit-il si TLS est présent.

Étape 2 : utilisez le client et le profil correspondants

Pour l’accès natif, installez le client SoftEther, créez une connexion avec les informations de l’exploitant et attachez l’adaptateur virtuel. Pour l’écouteur compatible, importez le profil OpenVPN que l’exploitant a exporté du serveur, car il porte le matériel CA et client que cet écouteur attend. N’assemblez pas un profil à la main à partir d’un exemple générique, et ne collez pas une définition de connexion native dans une configuration OpenVPN.

Une erreur d’analyse à l’importation est un problème de format, pas de réseau, et elle ne devrait pas vous envoyer vers le pare-feu.

Étape 3 : gardez la comparaison honnête

Si l’exploitant publie les deux, comparez-les en gardant l’appareil, le réseau d’accès et la tâche constants. Les deux chemins peuvent différer par l’authentification, par les sous-réseaux auxquels ils se rattachent et par ce que le serveur fait ensuite de votre trafic. Un hôte partagé n’est pas une règle partagée. Gardez aussi la tâche constante, car une copie de fichier et un appel vidéo sollicitent des parties différentes du même chemin.

Résistez aux correctifs qui apparaissent chaque fois qu’une importation échoue. Désactiver les contrôles de certificat ou activer des chiffrements anciens pour forcer un profil est une régression, pas une fonction de compatibilité.

Étape 4 : vérifiez le chemin après la connexion

Une fois connecté, vérifiez l’adresse reçue, les routes qui l’accompagnent, le DNS et une ressource interne. Côté natif, l’adaptateur virtuel est l’interface à inspecter ; côté OpenVPN, c’est le périphérique tun ou tap créé par le client. Dans les deux cas, la question est de savoir si l’écouteur choisi délivre l’accès dont vous avez besoin, ce qui est un fait distinct du fait que le tunnel soit monté. Notez l’adresse avant et après, et comparez-les.

Notez quel écouteur et quelle version de client ont produit le résultat qui fonctionne. Sinon, la personne suivante recommencerait la découverte depuis le numéro de port.