vpncli -s frente a la GUI: inicie sesión en Cisco Secure Client
vpncli -s lee un archivo de respuestas preparado, mientras que la GUI lee a una persona. Compare cuándo el script se justifica, qué necesita el archivo y cómo demostrarlo.
Cisco Secure Client le da dos formas de responder a las mismas peticiones de inicio de sesión: una persona que escribe en vpnui.exe, o un script que alimenta respuestas a vpncli.exe por la entrada estándar con -s. La segunda hace posibles las conexiones programadas sin leer la pantalla de la GUI, y también convierte un inicio de sesión en un archivo que debe protegerse como una credencial. Cuál quiera depende de si hay una persona en la máquina y de la frecuencia con la que rota la contraseña. Ninguna opción cambia lo que pide la pasarela, solo quién responde.
Ambos caminos terminan en el mismo túnel, así que la comparación es de operación, no de protocolo.
Dos formas de responder a las mismas peticiones
La ruta de la GUI es interactiva por diseño: el cliente pregunta, alguien responde y la sesión vive mientras esa persona la deje tranquila. Es la elección correcta en un portátil que usa una persona, porque las peticiones se adaptan al método de autenticación de la pasarela y nadie tiene que guardar una contraseña en texto plano en el disco.
La ruta del script es la adecuada para un quiosco, una máquina de laboratorio o una tarea programada donde no hay nadie que escriba. El intercambio es explícito: acepta un archivo de credenciales en disco a cambio de una conexión sin supervisión. Si la pasarela ofrece autenticación por certificado o SAML, ese intercambio suele no valer la pena, porque el archivo solo existe para responder peticiones que un método más fuerte evitaría.
No mezcle las dos en una misma máquina al mismo tiempo. La línea de comandos y el cliente gráfico compiten por el mismo estado de sesión, y ese es el problema de la sección siguiente.
Qué debe contener el archivo de respuestas
El cliente pregunta en orden — pasarela, a veces una selección de grupo, nombre de usuario, contraseña y cualquier confirmación del aviso. Un archivo que responde a todo eso tiene este aspecto, con los valores reales sustituidos:
connect vpn.example.com
MyGroup
alice
correct-horse-battery
yLa forma fiable de construir ese archivo es conectarse una vez a mano, anotar cada línea que escribe y cada pulsación de Enter, y luego reproducir exactamente esa secuencia. Las instalaciones que guardan el grupo y el nombre de usuario en el perfil pueden necesitar líneas en blanco donde esas peticiones ya no aparecen, y la última línea sigue necesitando su propio salto de línea. Un archivo al que le falta una línea suele colgarse en la última petición en lugar de fallar con un error claro, y por eso se culpa a la red. Compare el archivo con su transcripción dos veces, una por el orden y otra por las líneas en blanco.
Mantenga el archivo fuera de cualquier carpeta sincronizada y legible solo por la cuenta que ejecuta la tarea. Esa contraseña es texto plano, así que el archivo es una credencial: ni repositorio, ni disco compartido, ni adjunto en un tíquet. El cliente no le avisará de nada de esto.
Por qué la GUI tiene que irse primero
Empiece el script terminando el proceso de la GUI y después ejecute la CLI desde su propio directorio de instalación, porque importan tanto el directorio de trabajo como la compilación del cliente. Un envoltorio ilustrativo:
@echo off
taskkill /IM vpnui.exe /F >nul 2>&1
cd /d "%PROGRAMFILES(x86)%\Cisco\Cisco Secure Client"
vpncli.exe -s < C:\secure\login.txtLos códigos de salida no son aquí una señal fiable de éxito. El cliente imprime su progreso y mantiene el túnel en un proceso aparte, así que lea la salida para encontrar la línea de estado de conexión y solo entonces empiece el trabajo que depende de la VPN.
Si se salta matar la GUI, el script puede parecer que se ejecuta mientras la sesión existente se queda en el estado en que el usuario la dejó. Ese fallo parece intermitente, que es justo el tipo de error que sobrevive a una semana de conjeturas.
Confirme una sesión, no la suponga
Cuando el script vuelva, compruebe algo que solo existe dentro del túnel — un host interno o un sufijo DNS al que solo responde el resolutor corporativo. Lea también la línea de estado de conexión en la salida del cliente y trate cualquier otra cosa como un fallo en lugar de un éxito lento. Volver a ejecutar el archivo con una sesión ya activa puede dejar al cliente medio configurado, así que o desconecte primero o sáltese el inicio de sesión cuando la sesión esté presente.
Después decida quién se encarga de la reconexión. Un bucle que hace ping a una dirección interna y vuelve a ejecutar el inicio de sesión puede mantener un quiosco en línea durante meses, y también puede bloquear una cuenta la primera vez que rota la contraseña. Limite el número de intentos, avise cuando se supere y deje que el equipo de identidad rote el archivo en lugar de dejar que una contraseña obsoleta reintente hasta el bloqueo.
El vpnclient.exe antiguo no es la misma herramienta
La misma automatización aparece bajo un nombre más antiguo, y las dos no son intercambiables. El cliente Cisco IPsec retirado usaba vpnclient.exe con argumentos en línea como un verbo connect, un nombre de perfil, un usuario y una contraseña en una sola línea de comandos; vpncli.exe espera una secuencia de peticiones en la entrada estándar con -s. Copiar un script antiguo de foro en una máquina actual produce, por tanto, un comando que se ejecuta, no hace nada visible y se culpa a la pasarela.
Antes de editar cualquier argumento, compruebe qué cliente está instalado y a cuál llama realmente el script. La diferencia de nombre es lo bastante pequeña para pasarla por alto en una tarea programada, y es lo primero que hay que verificar cuando un script heredado ha dejado de funcionar tras una actualización.