La connexion OpenConnect atterrit sur la mauvaise page ? Vérifiez d’abord le chemin

Vous collez l’adresse de l’e-mail d’intégration, le client atteint la passerelle, et le formulaire de connexion qui apparaît est le portail général et non celui du partenaire décrit par l’opérateur. Rien ne signale d’erreur, et c’est justement ce qui perturbe : le tunnel peut même monter, mais derrière un mauvais point d’entrée. Le chemin de cette URL faisait un travail, et ce qui l’a remplacé a perdu ce travail.

Séparez deux choses qui arrivent comme une seule chaîne dans un ticket : l’adresse qui atteint le service et l’entrée qui décide où commence l’authentification. Réparer la première en ignorant la seconde, c’est ainsi qu’un nom d’hôte correct produit quand même une connexion erronée.

Ce que le client envoie avant que vous voyiez un formulaire

Avec une adresse comme https://vpn.example.net/partners, le premier acte du client est une requête HTTPS vers ce chemin plutôt que vers l’hôte nu. Ce qui revient est généralement une redirection vers le point de connexion, ou le formulaire lui-même. Un client qui ne reçoit que vpn.example.net part de la page d’atterrissage par défaut, quelle qu’elle soit, ce qui peut être un autre portail, une autre liste de groupes ou une page attendant un protocole tout différent. La différence est visible dans les en-têtes de réponse bien avant qu’un identifiant soit saisi.

C’est pourquoi un onglet de navigateur qui fonctionne et un profil client qui échoue peuvent nommer la même passerelle et pourtant ne pas être d’accord. Le navigateur a suivi le chemin ; le profil ne l’avait jamais.

Deux entrées qui semblent interchangeables et ne le sont pas

OpenConnect expose le chemin HTTPS initial sous la forme --usergroup, et la page du manuel traite une URL complète portant ce chemin comme la même requête écrite autrement. --authgroup est une option distincte : elle choisit une entrée dans la liste que la passerelle présente à l’intérieur du formulaire de connexion. Certains protocoles appellent cette entrée un groupe, d’autres un domaine ou une passerelle, et c’est exactement là que les deux paramètres se confondent.

Un service peut légitimement avoir besoin des deux. Le chemin peut vous amener sur le bon portail tandis que le formulaire vous demande encore de choisir parmi des groupes à l’intérieur. Donner le nom du portail comme nom de groupe, ou l’inverse, produit une connexion qui semble acceptée puis n’autorise pas, parce que la valeur était syntaxiquement valide et sémantiquement fausse.

Demandez à l’opérateur chaque valeur sur sa propre ligne : chemin d’entrée, sélection du formulaire, et si les deux sont nécessaires. Ne déduisez pas l’une de l’autre parce que les libellés se ressemblent.

Pourquoi rogner le chemin change le résultat

Les clients qui n’acceptent qu’un hôte et un port se connectent souvent quand même, si bien que le symptôme est rarement un échec franc. À la place, vous obtenez la mauvaise page de connexion, une liste de groupes vide, un nom de certificat qui ne correspond plus à ce que l’opérateur a publié, ou un tunnel qui monte sans route vers le service voulu. Chacun de ces cas siège à une couche différente, et aucun n’est réparé en collant une chaîne plus longue dans un champ documenté comme nom d’hôte. Deux d’entre eux sont aussi indiscernables de l’extérieur, puisque tous deux arrivent comme un formulaire de connexion qui simplement ne continue pas.

Remplacer le nom d’hôte par une adresse IP est une erreur distincte qui voyage souvent avec celle-ci. La sélection de service par nom et la validation du certificat dépendent toutes deux du nom, si bien qu’une adresse numérique peut transformer un problème de format de chemin en erreur TLS.

Les adresses de navigateur portent aussi plus que des chemins. Les identifiants de session, les cibles de redirection, les préfixes de langue et les paramètres temporaires de connexion apparaissent tous dans la barre d’adresse, et aucun d’eux n’a sa place dans un profil client enregistré.

Confirmez le point d’entrée avant de modifier quoi que ce soit d’autre

Lisez les en-têtes du chemin qu’on vous a donné. Une requête comme curl -sS -o /dev/null -D - https://vpn.example.net/partners imprime la ligne de statut et tout en-tête Location sans suivre la redirection. Un 302 pointant vers un point de connexion nommé confirme que le chemin existe et montre où il mène ; un 404 signifie que l’adresse de l’opérateur est périmée.

Reproduisez ensuite le même point d’entrée dans le client approuvé, par exemple openconnect --usergroup=partners vpn.example.net, et observez quel formulaire apparaît. Si le formulaire est correct et que le tunnel échoue encore, le chemin n’a jamais été le problème et l’arrêt suivant est la politique ou le routage.

Notez le nom d’hôte, le port, le protocole, le chemin d’entrée et la sélection du formulaire comme cinq champs distincts dans le ticket. Cette liste est ce qui permet à l’ingénieur suivant de distinguer un serveur injoignable d’un refus TLS, d’une sélection refusée et d’un tunnel monté sans les routes nécessaires.