AnyConnect cade alla chiusura di un terminale: controlli di sessione

Il tunnel è attivo, chiudi un terminale in più e la VPN cade senza una sola pressione di tasto nel client. Nel client AnyConnect su Linux la causa riportata è la contabilità delle sessioni e non l'instradamento: il client registra quali sessioni di accesso esistevano quando è salito il tunnel e considera la fine di una qualsiasi di esse come motivo per abbatterlo. I controlli qui sotto vanno eseguiti in ordine, e il primo che fallisce ti dice se stai davvero guardando questo comportamento. Nulla nell'output abituale del client menziona un terminale, per questo il primo istinto, dare la colpa al concentratore, di solito è fatica sprecata.

Non iniziare modificando file di sistema. Ogni passo o spiega la caduta o elimina un candidato, e i passi economici vengono prima.

Separare una caduta di sessione da una caduta della rete sottostante

Riconnettiti subito dopo la disconnessione. Un tunnel che torna in pochi secondi, sulla stessa rete, senza nuove credenziali, indica un innesco locale come una sessione chiusa e non un collegamento in uscita morto, un roaming Wi-Fi o un timeout di inattività sul concentratore. Un tunnel che resta bloccato su Connecting, o che fallisce finché non cambi rete, è un altro articolo.

Annota cosa era aperto quando è salito il tunnel: il terminale da cui hai avviato il client, ogni seconda shell, l'accesso grafico e ogni sessione SSH da un'altra macchina. Ti servirà quella lista tra un momento, e ricostruirla a memoria dopo la caduta successiva non è affidabile.

Controlla cosa ha registrato il client al momento della connessione

Il client non ispeziona i processi padri né la proprietà del terminale. Scatta un'istantanea dell'insieme delle sessioni di accesso presenti al momento della connessione e confronta quell'insieme più tardi; quando un membro scompare, il confronto fallisce e il tunnel se ne va con lui. Per questo chiudere la finestra da cui ti sei connesso può essere innocuo mentre chiudere un terminale in più non correlato uccide la connessione: conta se quella sessione era nell'insieme originale. Il controllo è un confronto di insiemi e non un conteggio, per questo sostituire una sessione può essere fatale quanto perderne una.

Elenca cosa poteva vedere il client prima di cambiare qualcosa:

who
w
last -n 10
sudo ls -l /run/utmp

Ogni riga di who è una voce di processo utente in utmp. Se la tua sessione compare due volte, una per l'accesso grafico e una per il terminale, entrambe le voci esistevano al momento della connessione ed entrambe sono candidate.

Rimuovi solo la tua voce da utmp

La soluzione pubblicata rende invisibile in utmp la sessione che stai per usare prima che il client parta. Un piccolo programma in C percorre getutent(), individua il record il cui ut_line coincide con il TTY dell'input standard e poi riscrive quel record. L'ordine è deliberato: setutent(), leggi la voce, copia il suo ut_id, imposta ut_type su DEAD_PROCESS, svuota i campi utente e riga, riscrivila con pututline(), poi endutent().

Compilalo, poi eseguilo come root dalla shell che avvierà il client:

sudo ./utmpremove && /opt/cisco/anyconnect/bin/vpn -s connect vpn.example.edu

Due modi di fallire spiegano la maggior parte delle segnalazioni secondo cui lo strumento non fa nulla. Agisce sul TTY collegato all'input standard, quindi eseguirlo da uno script o da un'attività cron senza terminale non gli lascia nulla da confrontare. E /run/utmp non è scrivibile dagli utenti normali, quindi un'esecuzione senza root fallisce in silenzio se non controlli lo stato di uscita.

Verifica che il tunnel sopravviva alla chiusura

Metti alla prova il meccanismo invece di darlo per scontato. Connettiti da una sessione che intendi mantenere, apri un secondo terminale, chiudi il secondo, poi conferma che il tunnel è ancora attivo con vpn state e uno sguardo all'elenco delle interfacce. Se il tunnel sopravvive, l'innesco era un tipo di sessione specifico e non ogni sessione, e hai trovato la sessione che deve restare aperta.

Se cade ancora, la sessione osservata era altrove, quasi sempre l'accesso grafico che ha generato il tuo terminale, e rimuovere una sola voce TTY non aiuterà. Ripeti l'osservazione con l'elenco completo del primo passo invece di aggiungere altra chirurgia.

Quando riscrivere utmp è la risposta sbagliata

utmp è contabilità condivisa, non una tabella privata. Riscrivere la voce di una sessione ancora viva fa sì che who, w e alcuni strumenti di audit la riportino per difetto, e un programma che in seguito chiude la stessa voce può fallire del tutto. Mantieni lo strumento limitato alla tua sessione, conserva una copia del file originale e non trasformarlo in un servizio di avvio che elimina ogni record.

Se la tua organizzazione raccoglie la contabilità delle sessioni per la conformità, la soluzione è in conflitto con quel requisito e la risposta supportata è un'altra versione del client o un altro metodo di accesso, non un utmp corretto. Per la maggior parte delle persone la correzione meno invasiva è semplicemente avviare il client da una sessione che resterà aperta tutto il giorno e lasciare in pace quella finestra.

Prima di chiudere il ticket, annota quale sessione stava osservando il client quando è salito il tunnel. È quella singola riga che trasforma una disconnessione misteriosa in una condizione riproducibile per la prossima persona sulla macchina.