Passerelle Juniper ou Pulse : quel protocole OpenConnect utiliser

Choisir un protocole pour OpenConnect est un exercice d'appariement, pas une recherche de marque. Une passerelle qui affiche Juniper sur la page de connexion peut exposer Network Connect, Pulse ou les deux, et la valeur par défaut du client n'est ni l'un ni l'autre. Deviner coûte une connexion échouée et, pire, un fil de support qui blâme les identifiants pour une incompatibilité de protocole. Confirmez le service avant de saisir un nom d'hôte dans un profil.

OpenConnect nomme le protocole plus ancien nc et le plus récent pulse, et les deux vivent dans le même binaire. L'indicateur choisi change l'échange de connexion, pas le routage après une connexion réussie.

Les deux noms de protocole partagent une histoire de produit

Le Network Connect de Juniper et le client Pulse Secure ultérieur sont des protocoles différents qu'une famille d'appliances a exposés au fil du temps. OpenConnect a développé un gestionnaire nc pour le premier et un gestionnaire pulse pour le second. Ce sont des chemins de code distincts avec des formats de requête distincts, donc la prise en charge de l'un ne dit rien de l'autre.

La différence apparaît immédiatement dans la conversation de connexion : les points de terminaison, les champs de formulaire et la manière dont le client signale un second facteur rejeté varient entre les deux gestionnaires.

Choisir en ligne de commande est un changement d'un mot : openconnect --protocol=nc vpn.example.com pour Network Connect, ou openconnect --protocol=pulse vpn.example.com pour Pulse. Les deux tentatives sont de vraies tentatives de connexion qui peuvent reconfigurer les routes et le DNS, alors exécutez-les délibérément. Ne placez jamais un mot de passe sur la ligne de commande et ne désactivez pas les vérifications de certificat pour contourner une erreur de protocole, car cela masque l'incompatibilité au lieu de la corriger. Si vous devez voir ce que le client envoie, --dump-http-traffic imprime l'échange, ce qui identifie généralement le gestionnaire attendu par la passerelle.

Adaptez le protocole à ce que la passerelle expose

L'appliance ne répond qu'au protocole pour lequel elle est configurée. Un service uniquement Pulse rejette une connexion nc même avec des identifiants valides, et un ancien service Network Connect n'a aucun point de terminaison pulse auquel répondre. Demandez à l'administrateur lequel est activé, et quel client ils prennent en charge. Une appliance renommée, une page wiki obsolète et un portail web familier sont tous des preuves faibles.

Une fois le protocole connu, confirmez les exigences environnantes : authentification par certificat ou jeton, sélection d'un groupe d'authentification et toute vérification de conformité du point de terminaison. Celles-ci décident si un client en ligne de commande peut terminer la connexion.

L'authentification peut trancher la question avant le protocole

Un déploiement peut exiger un certificat client, un aller-retour SAML via un navigateur ou un contrôleur d'hôte qui inspecte la machine avant d'accorder l'accès. Le gestionnaire pulse d'OpenConnect documente des limites de compatibilité pour certains de ces flux, et le gestionnaire nc a ses propres lacunes. Un mot de passe qui fonctionne dans le navigateur prouve que le compte est valide ; il ne prouve pas qu'une CLI ou un greffon de bureau arbitraire peut terminer la même séquence. Quand un contrôleur d'hôte est en jeu, le client a besoin d'un script d'enveloppe fourni par l'administrateur. Sans lui, la connexion bloque après la première réponse et ressemble à un échec de protocole alors qu'il s'agit en réalité d'une étape de conformité manquante.

La sélection du groupe d'authentification est l'autre point de friction courant, car une passerelle à plusieurs groupes attend que le client en nomme un.

En ligne de commande, --authgroup="Employees" fournit ce choix, et l'omettre peut placer la session dans un groupe par défaut qui rejette le compte. Avec des certificats, --certificate pointe vers le certificat et la clé du client, et la passerelle peut encore exiger un jeton ensuite. Testez la séquence complète une fois avec une sortie détaillée avant d'automatiser quoi que ce soit autour.

Quand l'interface de bureau ne peut pas exprimer le choix

Les interfaces graphiques ont leurs propres ensembles de fonctions, et un ancien greffon peut précéder le protocole dont vous avez besoin. L'intégration OpenConnect de NetworkManager stocke le choix dans ses données de connexion, donc nmcli connection modify "Office VPN" vpn.data "protocol=pulse" peut définir ce que l'éditeur n'affiche pas. Vérifiez que la version installée du greffon prend en charge la clé avant de supposer que la modification a pris effet.

Si un menu n'offre que PPTP ou L2TP, en choisir un ne convertit pas un service Pulse en ce protocole. Installez l'intégration approuvée au lieu de passer à ce que le menu liste par hasard.

Quoi consigner quand la connexion échoue encore

Consignez quatre choses : le protocole choisi, les versions du client et du greffon, le flux d'authentification attendu et la première erreur revenue avec un code de statut plutôt qu'un délai d'attente. Cet ensemble sépare un mauvais gestionnaire d'un certificat manquant, d'un groupe d'authentification rejeté ou d'une vérification de conformité bloquée. La sortie détaillée mérite d'être conservée pour la même raison, car elle montre la requête qui a échoué et pas seulement le symptôme.

Gardez la commande ou le profil qui fonctionne à côté du nom de la passerelle une fois qu'il réussit. Sinon, la prochaine personne qui se connecte répétera la même supposition de marque contre protocole.