Come creare uno script per l’accesso ad AnyConnect su Linux e macOS

Lo script esce con zero, il tunnel appare e l’esecuzione successiva viene rifiutata prima ancora che chieda una password. Oppure lo stesso comando funziona in un terminale e fallisce da un’attività pianificata con un errore «evento non trovato» che non nomina nulla di utile. Entrambi sono la conversazione sull’input standard del client AnyConnect che va storta, non un guasto di rete. Trattate l’accesso come una domanda e risposta scritta e gli errori diventano prevedibili e piccoli.

Perché lo stesso comando fallisce dentro uno script

Il client legge le sue risposte dall’input standard, una riga per richiesta, nell’ordine in cui il gateway le chiede. Qualsiasi cosa cambi il numero di richieste, come un nuovo banner, un selettore di gruppo o una sfida di secondo fattore, sposta ogni risposta successiva di una riga. Il client legge allora un nome utente dove si aspettava una password e segnala un errore che non punta a nessuna delle due.

Una password che contiene un punto esclamativo aggiunge un secondo errore più silenzioso. Tra virgolette doppie la shell la espande molto prima che il client veda qualcosa.

Mettete il payload tra virgolette singole e il carattere viaggia intatto. È tutta la correzione, e spiega un’intera classe di segnalazioni in cui la stessa credenziale funziona quando viene digitata e fallisce quando viene salvata. Controllate cosa ha fatto la shell prima di controllare il gateway: stampate il payload attraverso un involucro che mostri i byte esatti e contate le righe. La maggior parte di queste indagini finisce proprio lì.

Scrivete le risposte nell’ordine in cui il client le chiede

Eseguite il client una volta in modo interattivo e annotate ogni richiesta in ordine. Un selettore di gruppo compare solo quando il gateway pubblica diversi profili, e una richiesta di banner compare solo quando ne è configurato uno. Il file delle risposte deve corrispondere al gateway verso cui siete davvero indirizzati, non a quello della documentazione.

Poi costruite il file con quella sequenza esatta, una risposta per riga. L’indice del gruppo è il numero che il client elenca, non la posizione di un profilo in un documento. Accettate il banner solo se il vostro gateway ne invia uno, e aggiungete una riga per ogni domanda extra che quel gateway è noto per porre. Avviate il client con il flag non interattivo perché consumi il file invece di attendere un terminale.

connect vpn.lab.example
0
username
password
y
exit

/opt/cisco/anyconnect/bin/vpn -s < anyconnect.txt

La stessa sequenza può arrivare attraverso una pipe quando preferite non tenere un file sul disco. Le regole di quotatura decidono ancora se sopravvive.

Tenete la credenziale fuori dall’elenco dei processi

Un argomento sulla riga di comando è leggibile da ogni utente locale per tutta la vita del processo, quindi la password appartiene a un file o a una pipe e mai all’elenco degli argomenti. Rendete quel file leggibile solo all’account che esegue lo script, ed eliminatelo quando il lavoro finisce. Su macOS il binario di solito si trova allo stesso percorso di Linux, ma confermate la posizione installata invece di darla per scontata. Un involucro che prova entrambi i percorsi è più corto del rapporto sull’incidente.

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

Non lasciate nemmeno che lo script riprovi all’infinito. Un banner cambiato o una password scaduta durante la notte trasformano un file di risposte fisso in un ciclo di tentativi, ed è quel ciclo a bloccare l’account.

Fallite una volta, stampate il testo di errore del client stesso e uscite. Un’attività pianificata richiede la stessa verifica di identità e disponibilità delle credenziali di qualsiasi altro compito non sorvegliato, perché una credenziale che scade in silenzio è indistinguibile da un’interruzione alle tre del mattino.

Confermate la sessione prima di fidarvi del codice di uscita

Uno stato connesso prova che il tunnel esiste e nulla di più. Provate una risorsa che deve essere raggiungibile attraverso di esso prima che lo script inizi il lavoro vero, e trattate un errore lì come un guasto diverso da un accesso fallito. Altrimenti riproverete una connessione perfettamente buona che semplicemente non riesce a raggiungere la destinazione.

Chiedete al client il suo stato prima e dopo la disconnessione, perché una sessione obsoleta può rifiutare la connessione successiva mentre il vostro script segnala successo.

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

Registrate l’output dello stato accanto al codice di uscita, perché un codice da solo non può separare un accesso rifiutato da una sessione che non si è mai chiusa. Quando il gateway richiede un secondo fattore o un’approvazione interattiva, smettete di scrivere quel passaggio come script e usate invece il meccanismo supportato dal client. Un file di risposte fisso è una comodità per una credenziale che controllate, non un modo per aggirare un passaggio di autenticazione che non controllate. Mantenete l’ambito così stretto e questo resta uno script breve.

Quando un file di risposte fisso è lo strumento sbagliato

Un secondo fattore o una richiesta di approvazione sconfiggono del tutto lo schema, e questo è un confine di progetto, non un rompicapo di script. Usate qualunque meccanismo il client supporti per quel passaggio invece di indovinare la risposta in anticipo. Un file fisso funziona solo per credenziali che restano uguali tra un’esecuzione e l’altra.

Due stili di credenziali più vecchi vengono anch’essi confusi con AnyConnect. Un profilo vpnc parla un altro protocollo e vuole il nome del gruppo come identificatore IPSec, poi un segreto di gruppo condiviso e poi i dettagli del vostro account.

Poiché i protocolli differiscono, vpnc non può raggiungere un gateway che pubblica solo profili AnyConnect, e l’alternativa aperta abituale per quel servizio è openconnect con il suo protocollo anyconnect selezionato. Un file pcf appartiene al client Cisco legacy e, sebbene il suo host, il nome del gruppo e la password di gruppo si possano reinserire in un client che parla ancora Cisco IPsec, il file non si trasferisce tra client. Una porta inusuale o una modalità di tunnelizzazione non standard vanno di solito perse in quel trasferimento. Decidete quale protocollo offre il gateway prima di scegliere uno strumento.