AnyConnect cade când închizi un terminal: verificări de sesiune

Tunelul este activ, închizi un terminal suplimentar și VPN-ul cade fără nicio tastă apăsată în client. În clientul AnyConnect pentru Linux cauza raportată este evidența sesiunilor, nu rutarea: clientul înregistrează ce sesiuni de autentificare existau când a urcat tunelul și tratează sfârșitul oricăreia dintre ele drept motiv să îl doboare. Verificările de mai jos se fac în ordine, iar prima care eșuează îți spune dacă te uiți deloc la acest comportament. Nimic din ieșirea obișnuită a clientului nu pomenește un terminal, de aceea primul instinct, să dai vina pe concentrator, este de obicei efort irosit.

Nu începe prin a edita fișiere de sistem. Fiecare pas fie explică scăderea, fie elimină un candidat, iar pașii ieftini vin primii.

Separă o cădere de sesiune de o cădere a stratului de bază

Reconectează-te imediat după deconectare. Un tunel care revine în câteva secunde, în aceeași rețea și fără credențiale noi, indică un declanșator local, cum ar fi o sesiune închisă, nu un uplink mort, roaming Wi-Fi sau un timeout de inactivitate pe concentrator. Un tunel care rămâne blocat pe Connecting sau care eșuează până schimbi rețeaua este alt articol.

Notează ce era deschis când a urcat tunelul: terminalul din care ai pornit clientul, orice al doilea shell, autentificarea grafică și orice sesiune SSH de pe altă mașină. Vei avea nevoie de lista aceea imediat, iar reconstruirea ei din memorie după următoarea cădere nu este de încredere.

Verifică ce a înregistrat clientul la conectare

Clientul nu inspectează procesele părinte sau proprietatea terminalului. Face o instantanee a mulțimii de sesiuni de autentificare prezente la conectare și compară acea mulțime mai târziu; când un membru dispare, comparația eșuează și tunelul pleacă odată cu ea. De aceea închiderea ferestrei din care te-ai conectat poate fi inofensivă, în timp ce închiderea unui terminal suplimentar fără legătură omoară conexiunea: contează dacă acea sesiune era în mulțimea inițială. Este o comparație de mulțimi, nu o numărătoare, de aceea înlocuirea unei sesiuni poate fi la fel de fatală ca pierderea uneia.

Listează ce putea vedea clientul înainte să schimbi ceva:

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

Fiecare linie din who este o intrare de proces de utilizator în utmp. Dacă sesiunea ta apare de două ori, o dată pentru autentificarea grafică și o dată pentru terminal, ambele intrări existau la conectare și ambele sunt candidate.

Elimină din utmp doar propria intrare

Soluția publicată face invizibilă în utmp sesiunea pe care urmează să o folosești, înainte ca clientul să pornească. Un mic program C parcurge getutent(), găsește înregistrarea al cărei ut_line este egal cu TTY-ul intrării standard și rescrie acea înregistrare. Ordinea este deliberată: setutent(), citește intrarea, copiază ut_id, setează ut_type la DEAD_PROCESS, golește câmpurile de utilizator și linie, rescrie cu pututline(), apoi endutent().

Compilează-l, apoi rulează-l ca root din shell-ul care va porni clientul:

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

Două moduri de eșec explică majoritatea rapoartelor că instrumentul nu face nimic. Acționează asupra TTY-ului atașat intrării standard, așa că rularea dintr-un script sau dintr-o sarcină cron fără terminal nu lasă nimic de potrivit. Iar /run/utmp nu este scriabil de utilizatorii obișnuiți, așa că o rulare fără root eșuează silențios dacă nu verifici starea de ieșire.

Confirmă că tunelul supraviețuiește închiderii

Testează mecanismul în loc să îl presupui. Conectează-te dintr-o sesiune pe care vrei să o păstrezi, deschide un al doilea terminal, închide-l pe al doilea, apoi confirmă cu vpn state și o privire la lista de interfețe că tunelul este încă activ. Dacă tunelul supraviețuiește, declanșatorul a fost un anumit tip de sesiune, nu fiecare sesiune, și ai găsit sesiunea care trebuie să rămână deschisă.

Dacă tot cade, sesiunea supravegheată era în altă parte, cel mai des autentificarea grafică ce a creat terminalul tău, iar eliminarea unei singure intrări TTY nu ajută. Repetă observația cu lista completă din primul pas, în loc să adaugi mai multă chirurgie.

Când rescrierea utmp este răspunsul greșit

utmp este evidență partajată, nu un tabel privat. Rescrierea intrării unei sesiuni încă vii face ca who, w și unele instrumente de audit să o raporteze mai puțin, iar un program care închide mai târziu aceeași intrare poate eșua complet. Limitează instrumentul la propria sesiune, păstrează o copie a fișierului original și nu îl transforma într-un serviciu de pornire care elimină fiecare înregistrare.

Dacă organizația ta colectează evidența sesiunilor pentru conformitate, soluția intră în conflict cu acea cerință, iar răspunsul susținut este o versiune de client sau altă metodă de acces, nu un utmp peticit. Pentru majoritatea oamenilor, remedierea cea mai puțin invazivă este pur și simplu să pornești clientul dintr-o sesiune care rămâne deschisă toată ziua și să lași fereastra aceea în pace.

Înainte să închizi tichetul, notează ce sesiune supraveghea clientul când a urcat tunelul. Acea singură linie transformă o deconectare misterioasă într-o condiție reproductibilă pentru următoarea persoană de la mașină.