Le profil verrouillé au serveur échoue derrière un proxy TLS : quelle génération ?

Un utilisateur peut se connecter et un autre non, via le même portail, le même jour. Les deux ont des profils verrouillés au serveur, les deux sont sur la même version d’Access Server, et la seule différence est le moment où leur profil a été généré. C’est le schéma qu’il vaut la peine de reconnaître, car « verrouillé au serveur » nomme une politique et non une séquence de connexion. Access Server a livré deux générations de cet artefact, et un proxy inverse TLS ne se trouve devant qu’un seul de leurs chemins. Trois conditions décident de la branche où vous êtes.

Deux générations, deux séquences de connexion

Dans l’ancienne conception, en vigueur jusqu’à la 2.8, le fichier importé est un pseudo-profil. OpenVPN Connect l’utilise pour s’authentifier auprès de l’API web d’Access Server via HTTPS, reçoit un profil temporaire verrouillé à l’utilisateur et un jeton de session, et n’établit le VPN qu’ensuite. Deux transports s’exécutent en séquence, et le premier est une requête web ordinaire.

Le format introduit avec la 2.9 n’effectue pas cette initialisation par connexion. C’est un profil natif utilisable par les OpenVPN clients compatibles, pas seulement par OpenVPN Connect. Le télécharger ou l’importer par URL peut encore impliquer HTTPS — c’est une étape de publication, pas une récupération de profil temporaire par connexion.

Une mise à niveau ne réécrit pas nécessairement les profils déjà émis, donc une version actuelle du serveur peut encore distribuer l’ancien artefact. La version du serveur vous dit ce qui est possible, pas ce que cet utilisateur a importé.

Trois conditions qui choisissent votre branche

La première condition est la génération de l’artefact. Demandez le fichier, regardez comment il a été produit, et notez la version du client qui l’a importé. Si vous ne pouvez pas établir la génération à partir du fichier, un profil neuf émis pour un compte de test vous dira ce que le serveur produit aujourd’hui, ce qui est une information différente de celle que détient l’utilisateur en échec.

La deuxième est ce que votre front-end termine réellement. Un proxy inverse HTTP de couche sept qui décharge TLS n’est pas le même objet qu’un redirecteur TCP de couche quatre, et un redirecteur UDP non plus. La disposition habituelle d’Access Server sur le port 443 amène le démon OpenVPN TCP à reconnaître le trafic du navigateur et à le remettre aux services web, donc insérer un terminateur HTTPS étranger devant ne préserve pas le traitement de protocole de ce démon. Partager le numéro 443 ne rend pas deux conceptions équivalentes.

La troisième est où l’échec atterrit. Un échec avant le VPN et un échec du canal de contrôle se ressemblent dans un client qui dit seulement « connexion », mais ils laissent des preuves à des endroits différents. Si l’ancien format est en jeu, l’initialisation est candidate. Si le nouveau format est en jeu, un journal d’accès web vide est attendu et ne prouve rien dans un sens ou dans l’autre.

Quand l’artefact est ancien : l’initialisation échoue d’abord

Lisez l’erreur réelle du client plutôt que son état final. Les champs intéressants sont l’erreur HTTPS, l’identité de serveur que le client attendait, la destination vers laquelle la requête est allée, et si la validation du certificat s’est terminée. Confrontez-les ensuite aux journaux du service web et du proxy côté serveur.

Qu’un navigateur atteigne la page de connexion ne prouve pas que l’authentification API de ce client a réussi. Ce sont des requêtes différentes, avec des attentes de certificat différentes et souvent des noms d’hôte différents. Si le portail est correctement servi et que le client échoue toujours, le désaccord se situe dans le chemin d’initialisation, pas dans le mot de passe de l’utilisateur.

Ne faites pas réussir la comparaison en désactivant la vérification TLS ou en assouplissant la politique d’authentification. Cela transforme un écart de configuration diagnosable en un chemin qui fonctionne mais n’est pas vérifié, et c’est exactement le changement qui transforme un test temporaire en trou permanent. La documentation d’Access Server sur les profils de connexion décrit les deux générations et le flux du profil temporaire, et c’est la référence à consulter avant de supposer qu’un proxy est en cause.

Quand l’artefact est nouveau : lisez plutôt le canal de contrôle

Avec un profil de style 2.9, le client va directement au point de terminaison natif du VPN. Examinez les points de terminaison du profil, le transport utilisé et l’erreur du canal de contrôle. Si le client n’émet jamais de requête HTTP, cela est cohérent avec la conception et n’est pas un symptôme.

C’est aussi ici que la question du proxy change de forme. Un déchargement HTTPS ne peut pas casser un flux uniquement TCP qu’il ne voit jamais, mais il peut encore casser le téléchargement qui publie le profil, et un redirecteur uniquement TCP ne transportera pas du tout UDP. Vérifiez quel transport le profil demande avant de conclure que le front-end est sans importance.

Le passthrough TLS pour un seul flux est une disposition étroite. Il ne fournit pas de redirection UDP et ne reproduit pas le comportement de redirection de services du démon lui-même sur le 443. Si votre front-end fait l’une de ces choses, dites laquelle, car le remède diffère.

Des remèdes qui restent étroits

Le contrôle le moins intrusif consiste à générer un profil neuf pris en charge pour un compte de test et à se connecter via le point de terminaison natif prévu avec les mêmes exigences d’authentification. Si cela fonctionne et que le profil ancien conservé ne fonctionne pas, vous avez séparé l’artefact du serveur et du proxy en une seule étape.

La distribution d’un profil verrouillé à l’utilisateur supprime entièrement la dépendance à l’initialisation héritée, car il n’y a aucun échange de profil temporaire qui puisse échouer. Il doit être émis pour l’utilisateur prévu, jamais copié d’un administrateur, et il change ce à quoi le client est autorisé, alors traitez-le comme une décision de politique et non comme un contournement.

Corrigez ensuite la disposition de publication pour que chaque chemin requis existe : le chemin web pour les téléchargements et l’usage du portail, et le chemin VPN natif sur le transport que les profils attendent. Gardez le travail du proxy sur une seule couche. Un tunnel verrouillé à l’utilisateur qui fonctionne prouve que ce chemin fonctionne ; il ne prouve pas que toute disposition de proxy prenne en charge toute génération, et un échec d’initialisation ancien ne condamne pas le format plus récent.

• Identifiez la génération de l’artefact avant de toucher au proxy.
• Établissez si l’échec se produit avant le tunnel ou à l’intérieur de celui-ci.
• Confirmez ce que le front-end termine : HTTP, flux TCP ou UDP.
• Testez un profil tout juste émis contre le point de terminaison natif avec une politique inchangée.