O script termina com zero, o túnel aparece e a execução seguinte é recusada antes mesmo de pedir uma palavra-passe. Ou o mesmo comando funciona num terminal e falha a partir de uma tarefa agendada com um erro «evento não encontrado» que não nomeia nada de útil. Ambos são a conversa pela entrada padrão do cliente AnyConnect a correr mal, não uma falha de rede. Trate o login como uma pergunta e resposta escrita e as falhas tornam-se previsíveis e pequenas.

Porque é que o mesmo comando falha dentro de um script

O cliente lê as suas respostas da entrada padrão, uma linha por pedido, na ordem em que o gateway as pede. Tudo o que altere o número de pedidos, como um novo banner, um seletor de grupo ou um desafio de segundo fator, desloca cada resposta seguinte uma linha. O cliente lê então um nome de utilizador onde esperava uma palavra-passe e comunica uma falha que não aponta para nenhum dos dois.

Uma palavra-passe com um ponto de exclamação acrescenta uma segunda falha mais silenciosa. Dentro de aspas duplas, a shell expande-a muito antes de o cliente ver alguma coisa.

Coloque a carga entre aspas simples e o caráter viaja intacto. É toda a correção, e explica toda uma classe de relatos em que a mesma credencial funciona ao ser escrita e falha ao ser guardada. Verifique o que a shell fez antes de verificar o gateway: imprima a carga através de um invólucro que mostre os bytes exatos e conte as linhas. A maioria destas investigações termina exatamente aí.

Escreva as respostas na ordem em que o cliente as pede

Execute o cliente uma vez de forma interativa e anote cada pedido por ordem. Um seletor de grupo só aparece quando o gateway publica vários perfis, e um pedido de banner só aparece quando um está configurado. O ficheiro de respostas tem de corresponder ao gateway para o qual está realmente apontado, não ao da documentação.

Depois construa o ficheiro com essa sequência exata, uma resposta por linha. O índice do grupo é o número que o cliente lista, não a posição de um perfil num documento. Aceite o banner apenas se o seu gateway enviar um, e acrescente uma linha por cada pergunta extra que se saiba que esse gateway faz. Inicie o cliente com a opção não interativa para que consuma o ficheiro em vez de esperar por um terminal.

connect vpn.lab.example
0
username
password
y
exit
/opt/cisco/anyconnect/bin/vpn -s < anyconnect.txt

A mesma sequência pode chegar por um tubo quando prefere não manter um ficheiro no disco. As regras de citação continuam a decidir se sobrevive.

Mantenha a credencial fora da lista de processos

Um argumento na linha de comandos é legível por qualquer utilizador local durante toda a vida do processo, por isso a palavra-passe pertence a um ficheiro ou a um tubo e nunca à lista de argumentos. Torne esse ficheiro legível apenas pela conta que executa o script e apague-o quando a tarefa terminar. No macOS o binário costuma estar no mesmo caminho que no Linux, mas confirme a localização instalada em vez de a presumir. Um invólucro que testa os dois caminhos é mais curto do que o relatório do incidente.

printf 'username\npassword\ny\n' | /opt/cisco/anyconnect/bin/vpn -s connect vpn.lab.example

Também não deixe o script repetir para sempre. Um banner alterado ou uma palavra-passe expirada durante a noite transformam um ficheiro de respostas fixo num ciclo de tentativas, e é esse ciclo que bloqueia a conta.

Falhe uma vez, imprima o próprio texto de erro do cliente e saia. Uma tarefa agendada precisa da mesma revisão de identidade e de disponibilidade de credenciais que qualquer outra tarefa sem supervisão, porque uma credencial que expira em silêncio é indistinguível de uma falha às três da manhã.

Confirme a sessão antes de confiar no código de saída

Um estado ligado prova que o túnel existe e nada mais. Teste um recurso que tem de estar acessível através dele antes de o script começar o trabalho a sério, e trate uma falha aí como uma avaria diferente de um login falhado. Caso contrário vai repetir uma ligação perfeitamente boa que simplesmente não consegue chegar ao destino.

Pergunte ao cliente pelo seu estado antes e depois da desconexão, porque uma sessão desatualizada pode recusar a ligação seguinte enquanto o seu script comunica sucesso.

/opt/cisco/anyconnect/bin/vpn state
/opt/cisco/anyconnect/bin/vpn disconnect

Registe a saída de estado ao lado do código de saída, porque um código sozinho não consegue separar um login recusado de uma sessão que nunca foi fechada. Quando o gateway exige um segundo fator ou uma aprovação interativa, deixe de escrever esse passo como script e use o mecanismo suportado pelo cliente. Um ficheiro de respostas fixo é uma comodidade para uma credencial que controla, não uma forma de contornar um passo de autenticação que não controla. Mantenha o âmbito assim estreito e isto continua a ser um script curto.

Quando um ficheiro de respostas fixo é a ferramenta errada

Um segundo fator ou um pedido de aprovação derrotam completamente o padrão, e isso é uma fronteira de conceção, não um quebra-cabeças de script. Use o mecanismo que o cliente suportar para esse passo em vez de adivinhar a resposta de antemão. Um ficheiro fixo só funciona para credenciais que se mantêm iguais entre execuções.

Dois estilos de credenciais mais antigos também são confundidos com o AnyConnect. Um perfil vpnc fala outro protocolo, e quer o nome do grupo como identificador IPSec, depois um segredo de grupo partilhado, depois os dados da sua própria conta.

Como os protocolos diferem, o vpnc não consegue chegar a um gateway que só publica perfis AnyConnect, e a alternativa aberta habitual para esse serviço é o openconnect com o seu protocolo anyconnect selecionado. Um ficheiro pcf pertence ao cliente Cisco antigo e, embora o seu anfitrião, nome de grupo e palavra-passe de grupo possam ser reintroduzidos num cliente que ainda fala Cisco IPsec, o ficheiro não transita entre clientes. Uma porta invulgar ou um modo de tunelamento não padrão perdem-se geralmente nessa transferência. Decida que protocolo o gateway oferece antes de escolher uma ferramenta.

Artigos relacionados