vpncli -s versus a GUI: iniciar sessão no Cisco Secure Client

O Cisco Secure Client dá duas formas de responder aos mesmos pedidos de início de sessão: uma pessoa a escrever em vpnui.exe, ou um script que envia respostas para vpncli.exe através da entrada padrão com -s. A segunda torna possíveis as ligações agendadas sem ler o ecrã da GUI, e também converte um início de sessão num ficheiro que tem de ser protegido como uma credencial. Qual querer depende de haver uma pessoa junto à máquina e da frequência com que a palavra-passe roda. Nenhuma opção altera o que o gateway pede, apenas quem responde.

Os dois caminhos terminam no mesmo túnel, por isso a comparação é de operação, não de protocolo.

Duas formas de responder aos mesmos pedidos

O caminho da GUI é interativo por conceção: o cliente pergunta, alguém responde e a sessão vive enquanto essa pessoa a deixar em paz. É a escolha certa num portátil usado por uma pessoa, porque os pedidos adaptam-se ao método de autenticação do gateway e ninguém tem de guardar uma palavra-passe em texto simples no disco.

O caminho do script serve para um quiosque, uma máquina de laboratório ou uma tarefa agendada onde não há ninguém para escrever. A troca é explícita: aceita um ficheiro de credenciais no disco em troca de uma ligação sem supervisão. Se o gateway oferece autenticação por certificado ou SAML, essa troca normalmente não compensa, porque o ficheiro só existe para responder a pedidos que um método mais forte evitaria.

Não misture os dois na mesma máquina ao mesmo tempo. A linha de comandos e o cliente gráfico competem pelo mesmo estado de sessão, e esse é o problema da secção seguinte.

O que o ficheiro de respostas deve conter

O cliente pergunta por ordem — gateway, por vezes uma seleção de grupo, nome de utilizador, palavra-passe e qualquer confirmação de banner. Um ficheiro que responde a tudo isso tem este aspeto, com os valores reais substituídos:

connect vpn.example.com
MyGroup
alice
correct-horse-battery
y

A forma fiável de construir esse ficheiro é ligar uma vez à mão, anotar cada linha que escreve e cada Enter que prime, e depois reproduzir exatamente essa sequência. As instalações que guardam o grupo e o nome de utilizador no perfil podem precisar de linhas vazias onde esses pedidos já não aparecem, e a última linha continua a precisar do seu próprio fim de linha. Um ficheiro a que falta uma linha normalmente fica pendurado no último pedido em vez de falhar com um erro claro, e é por isso que se culpa a rede. Compare o ficheiro com a sua transcrição duas vezes, uma pela ordem e outra pelas linhas vazias.

Mantenha o ficheiro fora de qualquer pasta sincronizada e legível apenas pela conta que executa a tarefa. Essa palavra-passe é texto simples, por isso o ficheiro é uma credencial: sem repositório, sem disco partilhado, sem anexo num ticket. O cliente não o avisa de nada disto.

Porque a GUI tem de sair primeiro

Comece o script terminando o processo da GUI e só depois execute a CLI a partir do seu próprio diretório de instalação, porque tanto o diretório de trabalho como a compilação do cliente contam. Um invólucro 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.txt

Os códigos de saída não são aqui um sinal fiável de sucesso. O cliente imprime o seu progresso e mantém o túnel num processo separado, por isso leia a saída à procura da linha de estado da ligação e só então comece o trabalho que depende da VPN.

Se saltar o encerramento da GUI, o script pode parecer estar a correr enquanto a sessão existente fica no estado em que o utilizador a deixou. Essa falha parece intermitente, e é exatamente o tipo de erro que sobrevive a uma semana de suposições.

Confirme uma sessão, não a suponha

Depois de o script regressar, verifique algo que só existe dentro do túnel — um anfitrião interno ou um sufixo DNS a que só o resolver corporativo responde. Leia também a linha de estado da ligação na saída do cliente e trate tudo o resto como falha em vez de sucesso lento. Voltar a executar o ficheiro com uma sessão já ativa pode deixar o cliente meio configurado, por isso ou desliga primeiro ou salta o início de sessão quando a sessão está presente.

Depois decida quem é responsável pela reconexão. Um ciclo que faz ping a um endereço interno e volta a executar o início de sessão pode manter um quiosque online durante meses, e também pode bloquear uma conta na primeira vez que a palavra-passe roda. Limite o número de tentativas, alerte quando for excedido e deixe a equipa de identidade rodar o ficheiro em vez de deixar uma palavra-passe obsoleta a tentar novamente até ao bloqueio.

O vpnclient.exe antigo não é a mesma ferramenta

A mesma automatização aparece sob um nome mais antigo, e os dois não são intermutáveis. O cliente Cisco IPsec retirado usava vpnclient.exe com argumentos em linha como um verbo connect, um nome de perfil, um utilizador e uma palavra-passe numa só linha de comandos; ao passo que vpncli.exe espera uma sequência de pedidos na entrada padrão com -s. Por isso, copiar um script antigo de fórum para uma máquina atual produz um comando que corre, não faz nada visível e de que se culpa o gateway.

Antes de editar qualquer argumento, verifique que cliente está instalado e qual o script chama realmente. A diferença de nome é pequena o suficiente para passar despercebida numa tarefa agendada, e é a primeira coisa a verificar quando um script herdado deixa de funcionar após uma atualização.