Puerta de enlace Juniper o Pulse: qué protocolo OpenConnect usar

Elegir un protocolo para OpenConnect es un ejercicio de emparejamiento, no una búsqueda de marca. Una puerta de enlace que dice Juniper en la página de inicio de sesión puede exponer Network Connect, Pulse o ambos, y el valor predeterminado del cliente no es ninguno de ellos. Adivinar cuesta un inicio de sesión fallido y, peor, un hilo de soporte que culpa a las credenciales de una discrepancia de protocolo. Confirme el servicio antes de escribir un nombre de host en un perfil.

OpenConnect llama nc al protocolo más antiguo y pulse al más reciente, y ambos viven en el mismo binario. El indicador que elija cambia el intercambio de inicio de sesión, no el enrutamiento posterior a una conexión correcta.

Los dos nombres de protocolo comparten una historia de producto

Network Connect de Juniper y el cliente posterior Pulse Secure son protocolos distintos que una familia de dispositivos ha expuesto con el tiempo. OpenConnect incorporó un gestor nc para el primero y un gestor pulse para el segundo. Son rutas de código separadas con formatos de solicitud separados, así que el soporte en uno no dice nada del otro.

La diferencia se ve de inmediato en la conversación de inicio de sesión: los puntos de conexión, los campos del formulario y la forma en que el cliente informa de un segundo factor rechazado varían entre los dos gestores.

Elegir en la línea de comandos es un cambio de una palabra: openconnect --protocol=nc vpn.example.com para Network Connect, o openconnect --protocol=pulse vpn.example.com para Pulse. Ambos intentos son intentos de conexión reales que pueden reconfigurar rutas y DNS, así que ejecútelos a propósito. Nunca ponga una contraseña en la línea de comandos ni desactive las comprobaciones de certificados para sortear un error de protocolo, porque eso oculta la discrepancia en lugar de corregirla. Si necesita ver qué envía el cliente, --dump-http-traffic imprime el intercambio, que normalmente identifica el gestor que espera la puerta de enlace.

Ajuste el protocolo a lo que expone la puerta de enlace

El dispositivo responde solo al protocolo para el que está configurado. Un servicio solo de Pulse rechaza un inicio de sesión nc incluso con credenciales válidas, y un servicio antiguo de Network Connect no tiene ningún punto de conexión pulse al que responder. Pregunte al administrador cuál está habilitado y qué cliente admiten. Un dispositivo renombrado, una página wiki desactualizada y un portal web conocido son todas pruebas débiles.

Una vez que conozca el protocolo, confirme los requisitos del entorno: autenticación por certificado o token, una selección de grupo de autenticación y cualquier comprobación de cumplimiento del punto de conexión. Esas deciden si un cliente de línea de comandos puede completar el inicio de sesión.

La autenticación puede resolver la pregunta antes que el protocolo

Un despliegue puede exigir un certificado de cliente, un viaje SAML a través del navegador o un verificador de host que inspecciona la máquina antes de conceder acceso. El gestor pulse de OpenConnect documenta límites de compatibilidad para algunos de estos flujos, y el gestor nc tiene sus propias lagunas. Una contraseña que funciona en el navegador demuestra que la cuenta es válida; no demuestra que una CLI o un complemento de escritorio arbitrario pueda completar la misma secuencia. Cuando hay un verificador de host, el cliente necesita un script envolvente proporcionado por el administrador. Sin él, el inicio de sesión se detiene tras la primera respuesta y parece un fallo de protocolo cuando en realidad es un paso de cumplimiento que falta.

La selección de grupo de autenticación es el otro punto de tropiezo habitual, porque una puerta de enlace con varios grupos espera que el cliente nombre uno.

En la línea de comandos, --authgroup="Employees" proporciona esa elección, y omitirla puede dejar la sesión en un grupo predeterminado que rechaza la cuenta. Con certificados, --certificate apunta al certificado y la clave del cliente, y la puerta de enlace aún puede exigir un token después. Pruebe la secuencia completa una vez con salida detallada antes de automatizar nada a su alrededor.

Cuando la interfaz de escritorio no puede expresar la elección

Las interfaces gráficas traen sus propios conjuntos de funciones, y un complemento antiguo puede ser anterior al protocolo que necesita. La integración de OpenConnect de NetworkManager guarda la elección en sus datos de conexión, así que nmcli connection modify "Office VPN" vpn.data "protocol=pulse" puede establecer lo que el editor no muestra. Compruebe que la versión instalada del complemento admita la clave antes de suponer que la edición ha surtido efecto.

Si un menú solo ofrece PPTP o L2TP, elegir uno no convierte un servicio Pulse en ese protocolo. Instale la integración aprobada en lugar de cambiar a lo que el menú enumere por casualidad.

Qué registrar cuando el inicio de sesión sigue fallando

Registre cuatro cosas: el protocolo que seleccionó, las versiones del cliente y del complemento, el flujo de autenticación previsto y el primer error que volvió con un código de estado en lugar de un tiempo de espera. Ese conjunto separa un gestor equivocado de un certificado ausente, un grupo de autenticación rechazado o una comprobación de cumplimiento bloqueada. La salida detallada merece conservarse por el mismo motivo, porque muestra la solicitud que falló en lugar de solo el síntoma.

Guarde el comando o el perfil que funciona junto al nombre de la puerta de enlace cuando lo consiga. De lo contrario, la siguiente persona que se conecte repetirá la misma conjetura de marca contra protocolo.