vpncli não funciona no Windows? Execute o Cisco Secure Client corretamente

Escreve vpncli na linha de comandos do Windows e recebe um erro de comando não reconhecido, ou a janela abre e fica parada numa pergunta que não esperava. Ambos os sintomas costumam vir do mesmo sítio: a máquina tem mais de uma linhagem de cliente VPN Cisco instalada, e o comando executado pertence à errada. A solução é iniciar o executável fornecido com o Secure Client e depois responder aos avisos que a gateway envia realmente.

O sintoma aponta para dois clientes diferentes

O Cisco Secure Client inclui uma interface de linha de comandos do Windows chamada vpncli.exe. O antigo cliente Cisco IPsec VPN trazia outro programa, vpnclient.exe, com comandos e opções de palavra-passe diferentes. Os guias que misturam os dois produzem comandos que parecem plausíveis e falham imediatamente. A pasta do programa instalado é a forma mais rápida de os distinguir.

O facto de vpncli não estar no PATH não é prova de que o componente falte. O instalador simplesmente não adiciona a pasta ao PATH, por isso chama o executável pelo caminho completo.

Execute o ficheiro executável que pertence ao Secure Client

Numa instalação do Secure Client 5.x, a localização documentada é a pasta Secure Client em Program Files (x86). No PowerShell é necessário o operador de chamada porque o caminho contém espaços: & 'C:\Program Files (x86)\Cisco\Cisco Secure Client\vpncli.exe'. Se esse ficheiro não existir, verifique a versão instalada e a respetiva pasta em vez de descarregar um cliente antigo para colmatar a falha.

A partir do cmd.exe o mesmo caminho funciona sem o operador de chamada, mas continua a precisar de aspas. Escolha uma shell e mantenha-se nela, porque as duas tratam as aspas de forma diferente e metade dos exemplos que falham online são um problema de aspas.

Ligue-se e responda ao que a gateway pede

No aviso do cliente, ligue-se à gateway aprovada ou a um alias configurado: connect vpn.example.com. Substitua o exemplo pelo seu próprio nome de anfitrião. O cliente pede então as credenciais exigidas pela sua implementação, que podem incluir uma seleção de certificado, um código de token ou um segundo fator. Responda a cada aviso pela ordem em que aparece.

O exemplo documentado da Cisco mostra também um banner que exige uma resposta explícita, pelo que um script que forneça apenas nome de utilizador e palavra-passe pode parar nesse banner. Leia a pergunta no ecrã em vez de assumir que o aviso seguinte é a palavra-passe.

Verifique a sessão antes de confiar nela

Depois de estabelecida a ligação, stats imprime informações da sessão: a gateway, o endereço atribuído, o protocolo e a duração. Verifique também um recurso interno previsto, porque uma sessão existe antes de ter provado que as suas rotas, o DNS e as permissões de aplicação satisfazem a tarefa. Registe o endereço atribuído enquanto a sessão está ativa.

Execute disconnect quando quiser terminar a sessão VPN e quit quando quiser sair da CLI interativa. Os dois não são sinónimos, e fechar a janela não é um substituto documentado de nenhum deles.

A automatização é uma decisão separada

Um início de sessão no terminal a funcionar não prova que uma tarefa agendada consiga concluir a mesma autenticação. Registe a identidade necessária, a conta de execução, o acesso ao certificado e qualquer interação do utilizador antes de transformar a sessão num trabalho em segundo plano. Se a implementação exigir um início de sessão no navegador ou uma aprovação, confirme o fluxo de trabalho suportado com o seu operador em vez de tratar o aviso como um obstáculo.

Não adapte exemplos antigos que colocam uma palavra-passe diretamente na linha de comandos. Linhas fixas injetadas numa conversa interativa quebram assim que a gateway muda as suas perguntas, e uma credencial guardada num script é um achado que só espera ser redigido. A referência da CLI da Cisco documenta os comandos suportados para este cliente.

Quando um início de sessão falha, guarde a versão do cliente, a gateway, a hora e o texto do erro que não seja secreto. Esses quatro factos separam um executável errado de uma rejeição de autenticação e de uma sessão ligada que não chega à sua aplicação.