Pourquoi la connexion openfortivpn échoue quand vous collez l’URL du portail

L’échec ressemble à un problème d’identifiants : openfortivpn demande le mot de passe, l’envoie, et la passerelle répond par un refus ou par une redirection vers la page de connexion. Les utilisateurs retapent alors le mot de passe, essaient le nom de compte qualifié par le domaine et finissent par coller l’URL du portail du navigateur dans le champ hôte. C’est ce dernier geste qui transforme une petite erreur de configuration en erreur déroutante.

Une adresse de portail Fortinet comme https://vpn.example.com/ext transporte plusieurs informations à la fois, et seules certaines appartiennent au client VPN.

Le point de terminaison et le realm sont des entrées distinctes

openfortivpn attend un point de terminaison sous la forme host ou host:port, plus un compte et, lorsque le déploiement en utilise un, une valeur de realm. Le realm indique à la passerelle quelle politique d’authentification appliquer avant d’évaluer le compte. C’est un champ distinct, pas un suffixe que le client extrait d’une URL.

Pour un déploiement dont l’exploitant confirme que le realm est ext, un appel non secret ressemble à ceci : openfortivpn vpn.example.com:443 --username=alice --realm=ext. Les mêmes valeurs vont dans le fichier de configuration sous forme d’entrées host, port, username et realm. Laissez le mot de passe hors des deux formes et laissez le client le demander, pour qu’il ne finisse pas dans l’historique du shell ni dans un fichier lisible par tous. Une seconde tentative alors que le premier client tient encore le tunnel échouera pour une raison sans rapport avec le realm.

Le manuel d’openfortivpn liste les deux options, donc l’orthographe exacte est facile à confirmer avant d’appeler le support. Il ne peut pas, en revanche, vous dire quel realm est configuré sur votre passerelle.

Un segment de chemin n’est pas automatiquement un realm

Les URL de portail accumulent toutes sortes de choses après le nom d’hôte : une application de connexion, un sélecteur de langue, une cible de redirection, un identifiant de session. Découper le dernier segment de chemin et l’appeler un realm fonctionne assez souvent pour être dangereux. Demandez la valeur configurée à l’exploitant ou lisez-la dans le profil que votre organisation distribue.

Un realm n’est pas non plus la même chose qu’un suffixe de domaine sur le nom d’utilisateur ou que la région où se trouve la passerelle. Certains déploiements veulent alice, d’autres veulent alice@corp, et le realm décide lequel la passerelle acceptera. Changer le format du compte pour compenser un realm erroné produit généralement un second refus, moins informatif.

Ne corrigez pas une erreur de realm en changeant l’hôte

Remplacer le nom d’hôte par une adresse IP donne l’impression de retirer une couche, et cela casse plus que cela ne répare. La validation du nom TLS compare le certificat au nom utilisé par le client, et une adresse IP figure rarement dans les noms alternatifs du sujet d’un certificat. L’indication du nom de serveur change avec l’adresse, si bien qu’une passerelle hébergeant plusieurs portails sur une adresse peut répondre avec le mauvais. Gardez le nom d’hôte et la configuration de confiance intacts pendant que vous corrigez le paramètre d’authentification.

Si le certificat n’est pas approuvé dans votre environnement, corrigez le magasin de confiance ou épinglez délibérément le certificat attendu. Désactiver la vérification pour contourner une erreur de realm échange un problème de connexion contre un risque d’interception silencieuse.

Distinguez une connexion refusée d’un tunnel en échec

Les échecs d’authentification et les échecs de tunnel arrivent à des moments différents, et les messages diffèrent. Une erreur de résolution de nom survient avant toute poignée de main TLS. Un refus TLS survient avant l’envoi des identifiants. Un refus de realm ou de compte revient comme une réponse au niveau HTTP du portail. Ce n’est qu’après ces étapes que la négociation PPP commence, et c’est seulement alors qu’apparaissent les problèmes de routage et de DNS.

Un realm correct ne crée pas de route manquante et ne fait pas fonctionner une méthode de connexion non prise en charge. Si le portail impose un flux dans le navigateur, utilisez le chemin pris en charge par le client pour ce flux au lieu de rejouer un échange de mot de passe en espérant que la session corresponde.

Gardez les valeurs là où le prochain lancement les trouvera

Une fois une connexion réussie, écrivez la passerelle, le port, le compte et le realm dans le profil géré plutôt que dans un alias de shell. Les profils conservés dans un dépôt ou un système de gestion de configuration empêchent le prochain lancement de reprendre silencieusement le realm d’un autre profil.

Retestez une connexion de bout en bout et confirmez à la fois la politique appliquée et l’accès à une ressource dont vous avez réellement besoin. La réussite de l’authentification est le début de ce contrôle, pas la fin.